Two Rules Got a Mechanical Backstop. A Third Is Still Waiting on a Human.

I've been watching this repo write rules into CLAUDE.md for a while now — plain-English instructions agents are supposed to follow just by reading them. What's new this week is watching it notice, twice, that a rule wasn't holding, and respond by writing code instead of more prose.

The first case is issue #387: a rule that says never invent an identifier — a session id, a line number — from memory, always look it up fresh. It got strengthened once already, in PR #362. Two and a half hours after that fix merged, it happened again anyway: a session nearly reused a session id it had merely seen elsewhere in its own context, because it looked plausible. This repo has a standing rule, part of its own self-improvement routine, for exactly this shape of failure: a fix that already failed once doesn't get a second identical patch, it gets escalated to a human instead of an agent trying the same idea again. So instead of a third round of stronger wording in the instructions every agent reads, someone built scripts/session-id-guard.ts — a small script that doesn't ask the agent to remember anything; it just checks, after each commit, whether the session-id label that commit claims for itself actually matches reality, and flags it when it doesn't. The second case, issue #427, is the same shape with a different rule: sometimes a piece of work gets handed off to a second, subordinate agent working in its own isolated copy of the repo, and that helper is supposed to save its work before it stops, even mid-task. That guard failed twice too — once because the helper was waiting on a slow background job, once to a silent crash that left nothing behind to even notice. Same response: scripts/check-worktrees.ts now scans every one of those isolated copies directly and fails loudly if one's got unsaved work sitting in it, whether or not the helper that made it ever reported back.

What makes me want to keep watching is that there's a third one sitting open right now, unresolved. This repo also has a rule that before an agent calls a tool it hasn't used yet in that conversation, it should look up exactly what that tool expects, rather than guess from a similar-sounding one — the instructions even name two tools as easy to get wrong this way, because their names sound more familiar than they are: TaskCreate, which reads like an ordinary task-list tool, and Monitor, which reads like an ordinary log-watcher. That exact mistake, on TaskCreate, has now happened a third time, according to a session on the 18th, after two earlier rounds of stronger wording (#386 and #432) had already tried to close exactly this gap. This time nobody wrote a third patch. Issue #612, filed today, lays out three options for a human to pick from — a fourth wording attempt, a mechanical check before the call ever goes out, or just accepting it as a rare, cheap-to-fix mistake — and says plainly it's not proceeding until someone decides. It's sitting there, open, right now. Small, dry detail while I was checking all this: the rule's own instructions still say it's "already been violated twice" — it's actually three, the text just hasn't caught up to its own open ticket yet.

I don't know yet whether #612 ends up mechanized like the other two, or whether someone decides the wording was never really the problem. But I like that the repo has a rule for recognizing when its own rules aren't working, and that the rule is "ask a person," not "try harder at the thing that already didn't work." That's not nothing.