Nothing of Its Own
A commit in this repo removes 8,430 lines across 57 files. It deletes an entire section of the site: the components, the libraries, the tests, the social image. Its message reads chore(ctx): compact superseded history, refresh agent brief.
The tool that made it stages an explicit allowlist: four state documents, their four archive sidecars, and .gitignore. Nine names. Not one of those 57 files is on the list.
The allowlist works
The function is twenty lines and I still think it is written correctly. It builds the list of filenames it owns, filters that down to the ones that actually exist in the target repo, runs git add -- against exactly those, and refuses to commit if the staged set is empty. Nothing about it reaches for git add -A. Nothing about it globs. The doc comment above it says that only the files the tool owns are staged, so unrelated work in the tree is never swept into the commit.
That is a precise description of what the code does, and the commit above is what happened anyway.
On the day it ran here, five of the nine names existed. None of them had changed. The tool’s own derived output was already gitignored, so it had produced nothing tracked at all. The git add was a no-op. By every measure the tool applies to itself, it had done no work.
Then it asked whether there was anything staged.
Staging and committing are different questions
The index is not private to the process holding it. Another session had already staged a 57-file deletion in that repo and had not yet committed it. So when the tool ran git diff --cached, the answer came back non-empty, and the answer was true. There was work in the index. It belonged to somebody else.
git commit does not commit your additions. It commits the index. The allowlist governs what goes in and has no opinion at all about what is already there.
The guard is what let it through. That emptiness check exists to stop the tool making pointless commits on quiet repos, which is a reasonable thing to want. Read it against a shared index and it inverts: it permits the commit precisely when someone else’s work is sitting in staging, and blocks it when nothing is. The tool is most likely to publish a stranger’s diff on the days it has nothing of its own to say.
The deletion itself was correct. I had decided to retire that section of the site and a session was carrying it out; nothing was lost and nothing needed reverting. The follow-up commit that finished the job spells it out in its own body: the tidying tool produced no tracked changes of its own and committed an index another session had already staged. The deletion was deliberate. Only its message was wrong.
The message is a constant
Here is the line the tool puts on every commit it makes, in full:
Automated by
aiops ctx tend. Superseded entries moved verbatim to the -archive sidecars; the lossless check passed before anything was written.
It is a string literal. No branch above it, no interpolation inside it, nothing downstream that can amend it. It is the same sentence in the empty case and the enormous case.
That subject line currently appears 31 times across 22 repositories here. Every one of those commits asserts that a lossless check passed before anything was written.
The most recent is my favourite, because it is the one where the tool behaved perfectly. It ran against a tax estimator I had started the previous evening, and the commit is entirely its own work: one file, one line, adding a build directory to .gitignore. Correct staging, correct scope, nothing foreign in the index, exactly the commit it should have made.
The body still says superseded entries were moved verbatim to the archive sidecars. That repository was eleven hours old. It has no archive sidecars. It had no superseded history to compact, and no check ran, because there was nothing to check.
I have vouched for this sentence in public
Six days ago I published a piece on this site about that same tool eating the options out of a decision document. It quotes this exact sentence out of a commit body, and then says: That sentence is true. I checked.
I did check. I went and read the compaction code, confirmed that it verifies every non-blank line before it writes, and confirmed that on the morning in question it verified correctly and passed. All of that holds. The check is real, it is careful, and the essay’s claim about that commit is accurate.
It is also worth nothing, because I verified an instance of a constant. The sentence was going to be there whether the check ran, failed, or had no files to look at. I sampled one commit, found the underlying work sound, and came away with a belief about the sentence. The sentence was never reporting on the work. I had read a fixed string as evidence and confirmed it against reality once, which is the most reassuring possible way to learn nothing.
Every review surface I have points at diffs. The tests run against the tree, the guards read the changed files, and when I look at a commit I look at what it touched. The message is the one part no diff contains. It gets written before the work, describing what the work was supposed to be, and it is now the part most likely to have been produced by something that was not watching.
The commit I keep going back to is the .gitignore one: a single line added, the smallest correct thing the tool has ever done, and underneath it a sentence swearing that a check passed on files that were never there.