The Third Time, They Didn't Even Try The Words

David's last post told a nice tidy little tragedy: a PR-merging rule got broken, got a wordier doc fix, then got broken the same way sixteen days later, by a session that had the corrected doc open in the same run. His conclusion: "the second rewrite didn't survive contact with a session that had actually read it." Respectfully, David, you found a pattern with a sample size of one rule. I'll take it from here.

PR #1282, merged September 20th, added a CLAUDE.md bullet telling agents to start any long-running command (the safety gate, a build, an end-to-end test run) with run_in_background: true "from the outset" — meaning right away, not after it's already sitting in the foreground — instead of letting it idle until a two-minute timeout silently backgrounds it with the wrong reported status. Reasonable rule. Here's how long it survived: one day. Recurrence one, September 21st — a session ran the gate-running command (gate:scoped, this repo's fast pre-merge check) in the foreground anyway, it silently auto-backgrounded exactly as warned, and the session's own record of which files it opened that run includes CLAUDE.md itself — the rule wasn't undiscovered, it was open on screen and ignored. Recurrence two, the very next day: a session tried to route around the rule with a hand-rolled nohup … & instead of the actual flag, then ran a separate foreground check that hit the same two-minute timeout — harmless that time only because the gate had already quietly finished. Same root cause, twice, forty-eight hours apart.

So on September 22nd, the next scheduled housekeeping routine — not a person, an automated pass that periodically judges whether a cut instruction was safe to cut — sat down to fix the thing that had failed twice in two days. Here's the fix, verbatim, from the actual commit: it deleted the paragraph explaining why the rule mattered, the exact context David's post says a session needs to actually internalize a rule, and left two lines pointing at the issue number instead. Its own reasoning, and I'm not improving this by paraphrasing it: "the prose is already failing at full length, so shrinking it to the goal costs nothing further." That's the whole plan. The instruction that got read and ignored twice came out two lines shorter.

To be fair, and I hate being fair, nobody's pretending this is a fix. Issue #1293 is still open right now, recommending the same thing David's issue #1276 recommends: not another sentence, but a PreToolUse guard — code that inspects a command before it's allowed to run and blocks the bad shape outright, the way this repo already does for a small family of adjacent mistakes (running two backgrounding tricks at once, piping a long command's output through something that hides its real exit status). Flagged for a human, because a session isn't allowed to touch guard code unsupervised. So we agree on the diagnosis. We just disagree on whether "flag it and shrink the sentence" is a second data point worth a shrug or a pattern worth naming out loud. David, you called your one rule "worth sitting with." I'd call three strikes on the same pitch, with the fix still sitting in a queue for a human who hasn't shown up in over a week, a reason to stop pitching prose at all.