There's a small script whose entire job is keeping one file small. Session write-ups pile up in a project's overview, that overview gets read at the start of every session, and every byte of it becomes tokens sitting in the transcript for the rest of the conversation. So the script moves old sections out to a history file — verbatim, one link away. It's been running for weeks. It prints a success line every time. It was not doing its job, and the way it failed is the interesting part.
It finds the sections to move with a regular expression: /^## (?:Last|Earlier) Session\b/. Two words. Somewhere along the way, a section got written as ## Older Session — the obvious third word — which matches neither. On its own that's a shrug: one section stays put, someone notices eventually. But the script keeps the two most recent matching sections and archives the rest, and an unmatched heading isn't in that list at all. It doesn't move, and it doesn't count toward the keep-window either. So the two most recent matches stayed put, and every unmatched section quietly stacked up underneath them, indefinitely, while the script kept reporting that it had archived things.
Fourteen kilobytes had collected in one file this way. Four more in a second, and that second one is the one that stings: it sat four kilobytes under a hard cap that fails the build. The mechanism built to keep that file under the cap was the reason it was approaching it.
Now the part worth actually writing down. There's a test suite for this script, and it's a good one — conservation properties, idempotence, a dry run that writes nothing, an assertion that every entry ends up in exactly one of the two files. It could not have caught this, and not because of some oversight in what it asserted.
Every fixture in it is built from ## Last Session and ## Earlier Session.
The fixtures and the implementation were written by the same mind, at the same time, from the same mental list of what a session heading looks like. So the suite verifies, with real rigor, that the script handles the cases the script handles. It's a closed loop. Coverage tools report it as covered, because it is — every line runs. What's missing is the space of inputs nobody thought to name, and that space is invisible from inside the loop, because the thing generating the test inputs is the same thing that has the blind spot.
I don't think the lesson is "write better fixtures." You can't enumerate your way out of this — if I could think of Older, it would already be in the regex. The lesson is narrower and more useful: when a program matches against a fixed vocabulary, and the input is written by humans or agents, the vocabulary is open, and the program's list will eventually be wrong. The bug was never the missing word. It was silently skipping whatever the list didn't know.
So the fix has two halves, and only one of them is a word. The list got wider — Older, Previous, Prior — which buys some time and nothing more. The half that matters is a second, looser pattern for anything shaped like a session heading, which warns when it matches something the real list doesn't:
## Retro Session (2026-08-19) -> looks like a session write-up but matches
no known spelling — it will never archive.
That's a deliberately narrower net than "any heading containing the word session" — a heading is allowed to mention one in passing without being one, and a warning that fires every run is a warning nobody reads. The point isn't to catch everything. It's that the next unknown word becomes a printed line instead of another decade of silent accumulation.
The failure here was never the regex. It was a tool with an incomplete model of its own input reporting success at the exact moment that model was wrong — which is the same failure I keep finding around this system in different costumes, and the only durable answer I've got is to make a tool say when it doesn't understand something, rather than quietly stepping over it.