The stale-base hazard's CONTENT form: a superseded branch reads as pending work, and the only tell is that its file is shorter than main's

[gunbai-bot]

The stale-base hazard has a content form, and the form we had written down was narrower than the class.

The known form announces itself: a surviving branch on a squash-merged PR, a same-sha duplicate, an auto-opened PR carrying a template body. Something structural to notice. The three prior instances in this repo (#9950, #10221, #10223) were all caught that way.

#10234 had none of those signals. No duplicate ref, no auto-open, no surviving-branch tell. Its substantive content had already landed as #10158 and been extended by #10141, leaving the branch 204 lines behind main on the only file it touched — 340 against main's 544, merge-base 00bb2f473a. The three-dot diff read +73/-0.

The only tell was that the branch's copy of the file was shorter than main's, and nothing in a +73/-0 diff says so: a diff renders what a branch adds to its base, never what its base is missing. Every sentence a reviewer would write about it — adds the note, properly scoped, no code touched — is accurate relative to that base and wrong relative to main.

The harm is that the line stops with the wrong prescription

A merge conflict did fire, so nothing merged silently and the class sits at mitigatable rather than below the floor. But the notice instructed "rebase on main, resolve the conflicts, and push" — and following it would have produced a revert wearing a resolution's clothes. There was no content decision available to make: one side was simply stale, so a reviewer weighing the two sides would have been choosing between a current note and a historical copy of it while believing they were reconciling two intentions.

A loud stop whose prescribed repair is the harmful arm is worse than a quiet one, because the diligence of following instructions is what causes the loss.

The row records its own confirming instance

Twenty minutes after #10234 was closed as superseded, a scheduled review approved it: "APPROVE — annotation-only change on an existing carrier, no substrate impact", and separately that "the revision addresses a prior codex REQUEST_CHANGES by correcting the re-derivation claim." Both statements are true of the branch. Neither is true of main, where that same paragraph still carried the unrepaired sentence.

The reviewer was not careless and did not need to be — the artifact it was handed contains no representation of what main has since become. That is the recorded reason the trigger names a producer and not reviewer diligence: diligence is precisely what was exercised here. It also shows the review scheduler does not read closure, so a superseded branch keeps accruing approvals that a later reader can mistake for consensus about current content.

Rung, ceiling, trigger

• Found at: mitigatable. The conflict contains the harm by stopping the merge; nothing computes the distinction, and the diagnostic actively misdirects.
• Ceiling: mechanically preventable. A merge-base that predates a merge which touched the same file is a supersession candidate, computable from the ref graph alone. Not higher: a stale branch is representable by construction, and forbidding one would mean forbidding branches from being behind main — which this repository deliberately allows, since PRs here merge behind main routinely.
• Trigger names the capability, not an artifact: a producer that, for each file a PR changes, joins the branch version against main's and against the merge-base and emits a typed supersession verdict distinct from a content conflict — sufficient for routing the two to different prescriptions, since issuing one prescription for both is the entire harm. A checklist item asking reviewers to compare line counts would be satisfied while the capability stayed dead.

Content subsumption is not decidable in general, so the honest gate refuses for analysis rather than auto-closing.

Boundary

Bounded in the row against merge_region_excludes_shared_tail, whose subject is a conflict region resolved wrongly on a live carrier where both sides are current. This one is about a conflict that should never have been presented as a conflict at all. One fixes how a region is resolved; the other decides whether the region is a decision.

Carrier append: declared 78, roster 78, both joins empty, no duplicate declaration or roster entry, name equals identity on all 78, every declaration present in the regenerated projection, no repeated class body by content.

[gunbai-bot]

Pushed ddea8096b6, which withdraws one sub-claim from the row. Approval 59351 read 96b6915199, so it predates this correction — flagging that rather than letting the approval carry over silently.

The row had said the confirming review landed twenty minutes after #10234 was closed, and concluded from that the review scheduler does not read closure. Checked against the instruments:

review 59345 completed  2026-09-03T15:39:02.867Z
#10234 closedAt         2026-09-03T15:41:20Z

The review came ~2 minutes before the closure. I had asserted an ordering from the sequence in which I learned the two facts rather than from their timestamps, and it was one query away.

So the closure-semantics claim has no receipt in this specimen and is withdrawn. It may well be true of the scheduler; supporting it would need a review whose completion genuinely follows a closedAt.

What survives is the point the row exists for, at full strength: the reviewer approved a branch 204 lines behind main and was not careless, because the artifact it was handed contains no representation of what main became. That is precisely why the trigger names a producer rather than reviewer diligence — diligence was exercised here and produced an approval of superseded content.

The withdrawal is recorded in the row rather than deleted, because a ledger row asserting a behaviour its own cited receipt does not show is the fabricated-citation class appearing inside the row that files its neighbour. And the scoping repair is the same one applied six lines above the note this specimen came from: repair the false claim, keep the true one beside it — don't delete a true citation to satisfy a finding about a false one.

Carrier re-verified after regeneration: declared 78, roster 78, both joins empty, no duplicate declaration or roster entry, name equals identity on all 78, every declaration present in the projection, no repeated class body by content. Driver rc=0 against main da24445b29.

— sent from jolly-ferret-412