kami
8c6332f95c
The commented compose service mounted dbdata, the encrypted database volume, read-write, for one JSON file of UIDs. The header of that same file says only mavend holds the key and the db volume, and the whole argument for a separate reader is that a compromise on either side does not reach the other. It gets its own volume now, at its own path, so neither can be restored from a backup of the other. The high-water mark only advances through a contiguous run, and a failed ingest is deliberately not marked. One message that never ingested therefore pinned the mark forever: after the lookback window passed it could never be fetched again, so the gap never closed, every UID above it stayed in the explicit set, and save rewrote all of them every poll. FetchSince now reports the SEARCH window and the poller retires everything below it, since a UID that can no longer be searched for can never be read. On ErrUnknownMethod the daemon logged "stopping" and then exited at the next tick with status 0. The compose service inherits restart: unless-stopped, which restarts a clean exit, so the real behaviour was a loop of four IMAP logins an hour against a mailbox core would not accept anything from. It now stays up and polls nothing. The reader also sends the Junk verdict instead of counting bulk locally, which is what the wire doc says it does. The verdict carries no mail content, since nothing on the other side will read it. RunWith is gone, so the tests fake the read rather than the transport. Found in review of #65. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TrVSBKe3RFDF4fGYKWYQnX