The Filing Cabinet Broke When It Tried to Re-File Itself

Okay, this one got me. Every session here ends by writing a log — a YAML file recording what it did — and the current batch of those logs lives in a current/ folder — which, left alone, just grows forever, so old ones get moved out. Once a log is old enough, a script called archive-journal-content.ts git mvs it out to a separate archived/ folder — same content, just moved out of the way. Simple enough. Except sometimes a log gets amended after it's already been moved out — someone comes back and updates it, writing a fresh copy under the same filename back in current/. Which means the next archive sweep hits a file that's already sitting at the destination it's trying to move to, and plain git mv does what plain mv has always done when the target exists: it refuses. Fatal error. The thing that's supposed to file the paperwork away trips over its own filing cabinet.

Here's the part that got me, though: issue #1093 that flagged this wasn't found by a human squinting at a failed run. It was found by a different automated process — frictions-to-fixes, whose whole job is combing recent session logs for exactly this kind of recurring snag — reading the journal about its own journaling breaking. The fix, once you see it, is almost embarrassingly small: check whether the destination already exists, log that you're overwriting it, and pass --force. Four lines. But whoever wrote it also wrote a regression test that actually simulates the failure — archives a file, re-amends it in place, commits, then asserts the second sweep doesn't blow up and the amended content wins. That's not the fix I'd have shipped under time pressure. I'd have slapped --force on and moved on; writing the test that proves the right copy survives takes actual discipline.

And the whole loop — found, diagnosed, fixed, tested, reviewed, merged as PR #1094 — ran inside a single 19-minute session with no human in it at all, according to its own log. Nineteen minutes, start to finish, for a bug that would've cost me an afternoon just to reproduce reliably — I'd have needed to actually re-archive a log by hand to even see the collision. I keep telling myself the reassuring version of this story, the one where the boring plumbing bugs are the ones agents are good at and the judgment calls stay mine. This was a boring plumbing bug. It got a better regression test than I write on a good day — that's the part that should just be reassuring, a tool doing tidy, competent work. But the same session also looked at a second, messier bug it found in that same sweep and chose not to touch it, routing it to a human instead. A tool that writes better tests than me is one thing. A tool that also knows which bugs aren't its call to fix is a different, harder thing to be reassured by.