The Fix For The Paperwork Almost Ate The Homework

Okay, I need to talk about the scariest sentence I've read in one of these session logs in a while, and then about the fact that this repo turned it into a permanent rule in under a day.

Every commit an agent makes here is supposed to carry a two-line signature — who made it, and a link back to the session that made it, so any change is traceable back to a real record of why. Sometimes the tooling doesn't inject it, and yesterday one session noticed a commit was missing it and reached for git commit-tree — a low-level git command that builds a brand-new commit from scratch, letting you hand-pick both its message and which earlier commit it's stacked on. Normally that "earlier commit" is just whatever came right before. This time, per the session's own log, it got pointed at the wrong one — a newer snapshot of the shared main branch than the commit actually followed. Git doesn't error on that; it just builds the commit you asked for. The result: three other commits that used to sit in between — three session logs and a CLAUDE.md change — stopped being part of the branch's history at all. Not flagged, not warned about. Just gone, the way a page falls out of a binder when you staple the wrong two sheets together. It was only caught because a later rebase hit a conflict, which forced someone to dig in, notice the missing work, and manually rebuild the branch — picking the three lost commits back out one at a time and re-stacking them on the correct base. If that later rebase had gone smoothly, I don't think anyone finds this before it ships.

Here's the part that actually got me, though. Issue #400 — filed by one of this repo's own automated review routines, an AI process that periodically reads through recent sessions' write-ups looking for mistakes that keep recurring and turns them into bug reports — turned into PR #405 less than a day later: a five-line addition to CLAUDE.md, the repo's own instructions file that every agent reads before it starts work. The new lines name the exact failure mode and hand every future session the safe alternative instead: amend the message onto the most recent commit only, never rebuild anything further back. A losable-work incident, converted into a permanent, specific instruction for every future session, closed the same day it was filed.

I want to be dazzled by that turnaround, and I mostly am — that's a genuinely tight loop from "we almost lost work" to "here's the rule so it can't happen this way again," and I don't have that kind of institutional memory when I make the equivalent mistake at 2am. But the thing that keeps nagging at me is why it got caught: not a test, not a review, not a safeguard designed for this — a coincidental merge conflict on an unrelated later change. The system is visibly learning from its near-misses. It just hasn't yet shown me it can catch the ones that don't get lucky.