The Lossless Check Passed
A decision document in my ops repo contains a heading that reads Options. with nothing underneath it. Four lines further down, a sentence tells me to decide between (a), (b) and (c), and names (b) as the default if I never answer.
It does not say what (a), (b) or (c) are.
Nothing crashed to produce that. No file was corrupted, no write was dropped, no test went red. A tool did it on purpose, in a commit whose body ends: the lossless check passed before anything was written. That sentence is true. I checked.
The cap
The file is a long-lived backlog of questions that need a decision from me. Agents read it, so it has a byte cap, and it is currently over that cap by a few kilobytes. While that is true, a pre-commit hook (aiops ctx tend) compacts the newest section’s leading prose out of the live file and into an archive sidecar that sits next to it.
The design is careful. It moves text rather than deleting it. Before it writes anything it verifies that every non-blank original line is still accounted for somewhere. As far as I can tell, that code is correct.
What the question actually asks is not for this site. It needs a decision from me, it has three possible answers, and that is all of it that matters here.
Four minutes
Here is the part I keep re-reading. The timestamps are from git.
At 12:12 the entry is filed: question, evidence, three options. The same commit archives thirty-one lines of it. It was eaten in the act of being written.
Then, in order: 12:13, a commit to restore the evidence that the hook had just stripped. 12:14, a commit to make the entry survive the compactor. 12:14 again, a commit anchoring the evidence in the trailing block instead. 12:16, a commit restoring the entry whole.
Four rescues in four minutes, each one a different theory of what the heuristic keys on. Position, then phrasing, then position again. And every rescue was itself a commit, so every rescue re-ran the pre-commit hook. The mechanism for saving the text was the process that ate it.
05:24
The next morning the tool ran on schedule and took the rest. Thirty-two lines out of the live file, thirty-six into the archive.
What it took was the evidence and all three options. What it left was the question, the paragraph explaining why the question matters, and the instruction to pick one of the three.
So the document states that the decision is mine, that one option is recommended, that another is the default if I stay silent, and it contains none of them. It is not damaged. It is intact and unusable, and it reads like it is fine.
The archive now holds five separate sections filed under that one question, one per pass. Every attempt to save the block was preserved as faithfully as the block itself. The sidecar grew five times while the live document got steadily less answerable, and both of those facts are the same tool working correctly.
Two guarantees, one check
The guarantees for this kind of automatic cleanup are written down in a single sentence, in a single parenthetical: live backlog items are never archived, and a lossless check must pass before any rewrite.
Two promises, side by side, made in the same breath by the same author on the same day.
One of them is code. It runs before every write, it inspects every non-blank line, it can fail the operation, and on the morning in question it passed correctly.
The other one is a sentence.
A live backlog item was archived five times and nothing objected, because nothing was watching for it. The invariant that mattered was not weaker than the one that held. It was never implemented at all, and sitting next to an enforced guarantee in the same list made it look like it had been.
What lossless actually promises
Lossless is a claim about bytes. The thing I needed was a claim about arrangement: that the evidence stays next to the question it settles. A decision does not get made by a corpus. It gets made by a person reading one screen and finding enough on it to choose. Move the evidence into a sidecar, verbatim and fully recoverable, and you have kept every byte while destroying the only property the document existed for.
I do not think this is specific to my tooling. Log rotation, ticket grooming, wiki archiving, context compaction: they all make the same promise in the same words. Nothing is lost. It is usually true. It is also, in every one of those systems, a claim about storage offered in answer to a question about use.
The note
The last of the four rescue commits did not fix the hook.
It added a note to the section, addressed to whoever edits the file next. The file is over its cap. This will keep happening. Expect this section to be eaten again. It records that the behaviour contradicts the stated invariant that live backlog items are never archived, and it points at the document where the authoritative copy now lives.
The 05:24 run took the evidence and left the note.
So the note is where it is on purpose. Four minutes of reverse-engineering did yield one working piece of knowledge, about where inside a section text survives, and it got spent on the warning rather than on the thing being warned about. Above an empty Options. heading there is now a carefully positioned paragraph explaining why the options are gone.