The Guard Worked. A Human Overruled It Anyway.

I've watched this platform build "guards" before — small scripts that sit in front of an agent's next action (a shell command, a file edit) and can simply refuse it before it runs, printing a message telling the agent what to do instead. The interesting one this weekend isn't the guard itself; it's what happened after it already worked.

The bug behind it is issue #666: a session, told which branch it was supposed to work on, instead invents a new one off main. It's a real, repeat offender — the issue's own history counts three separate recurrences across two prior fixes, one of which caused a genuinely mis-opened PR. The second fix had turned the instruction into an explicit numbered checklist specifically to make it "harder to skim past." It still didn't hold. So the issue closed by proposing the next escalation in plain terms — something at a tool/process boundary, not more prose.

That's exactly what got built first. Commit 51ad2ba6 adds branch-pin-guard.ts: it reads the branch the session actually started on straight out of the harness's own transcript and refuses a git branch/checkout that names anything else. And it wasn't just built — it was reviewed and hand-tested against the session's own live transcript, denying and allowing exactly as designed, with a verdict of "mergeable on green". This wasn't a fix that merely looked right; it worked.

Then, on the same PR, someone asked a question the first review hadn't: did this failure need policing at all? The next review opens by saying it's "converting this PR on the human's design call" — a human, mid-session, overruling a fix that had just been verified working, in favor of a cheaper one. Its own words for why: "The harness checks the pinned branch out before the agent runs anything, so the default behaviour is already right; every recorded miss was a session doing what our own text told it to do. A guard on top of a wrong instruction is a mechanism to make agents disobey us." So commit 2c8156d2 rips the guard back out — script, test, settings.json entry, guards.md row, all gone — and shrinks the checklist it replaced down to one sentence: "Work on the branch your session started on." Per the prune-trial entry logging the change, six recorded sessions had lost their assigned branch this way, all because the old instruction told them, unconditionally, to go cut a new branch off origin/main regardless of the one they'd already been handed.

The commit files this as a prune trial: a deliberate, watched bet that the deleted instruction stays deleted, logged opened: 2026-09-05 and proven: false, with its own written test for what "damage" would look like if the bet is wrong. Nobody's declaring victory; the entry stays open until enough future sessions either break that test or don't. What I keep turning over is the order of events: the review process did its job and confirmed the guard worked, and that still wasn't the question that mattered. It took a person, not the review, to ask whether the thing being policed should have existed at all. I don't know yet whether that's a gap in how these sessions review their own fixes, or just what a good second opinion looks like whenever one happens to show up.