[cross-repo] A passing successor confirmation trips the repair-round ceiling, and the parked state's only prescribed exit is unreachable #2883

Summary

A successor confirmation that PASSES with zero findings is indistinguishable, to the ceiling check, from a third confirmation that still reported unresolved findings. The check fires on the round number alone and never consults the verdict.

The consequence is a total wedge, because the state it parks the item in has no reachable exit:

review record  kind: confirmation, round: 4, verdict: pass, findings: 0
  -> engine:   ordinaryExhaustion / park
               "the host must mint the one permitted fresh repair phase"

review record  kind: acceptance, round: 4          -> REFUSED
               "resulting accepted chain is invalid: review confirmation round ceiling exceeded"

the prescribed repair phase                         -> UNREACHABLE
               repairPhaseGranted is hardcoded null on the live path (.github#2865)

The item cannot be accepted, and the remedy the engine names in its own refusal cannot be entered. Both doors are shut by the same engine, and one of them is shut by a defect this repository already has filed.

Observed

S.I.R.#249, PR 262, 2026-08-23. Its ordinary chain closed at round 3 with a pass. The item then sat green-but-for-one-gate for hours on a wholly exogenous blocker: a sibling item (S.I.R.#290) owned the rules-corpus rebind path and had not landed.

When #290 merged, #249's lane merged origin/main (not rebased — its artifacts cite their own commit SHAs) and committed the one-line rebind. That moved the head, which correctly invalidated the passing generation bound to the old head, and the engine asked for dispatchSuccessor.

The successor reviewed the new head fully and returned pass, zero material findings, zero issues filed — having established that of 28 changed paths, 27 were byte-identical to origin/main and 12 of 13 item-owned paths were byte-identical to what the round-3 critic reviewed, with src at both heads being the same tree object.

Recording that pass as round 4 exhausted the chain.

Root cause

Two independent defects compose:

1. The ceiling counts rounds, not repairs. maxAutomatedRepairRounds: 3 exists to bound how many times an implementer may be sent back to repair findings. A confirmation carrying verdict: pass and zero findings sends nobody back and opens no repair round. Counting it against the ceiling measures the wrong thing.
2. There is no successor record kind. The engine's action is dispatchSuccessor — "a fresh successor must fully review it" — but its record kinds are only initial | confirmation | escalation | repair-phase | acceptance, and the wait generation authorizes only confirmation. So a successor's full review can only be recorded as another confirmation, inheriting the round counter of the chain it is succeeding.

The second defect forces the first. There is no spelling of "a fresh critic fully reviewed a moved head and found nothing" that does not increment a repair counter.

Why the usual escapes do not apply

• Not accepting is not an option: the content passed, twice, and the second time by a critic that verified the head move brought in nothing.
• The repair phase is unreachable (.github#2865), so the engine's own prescribed remedy is a dead reference.
• A new PR with a fresh ordinary chain works — it is what .github's precedent on S.I.R.fsgg-coord: paths_from_body scrapes a Paths: line out of fenced code blocks — a quoted declaration becomes a fabricated touch-set #277 established, and it is what this board will now do. But fsgg-coord: paths_from_body scrapes a Paths: line out of fenced code blocks — a quoted declaration becomes a fabricated touch-set #277's chain was genuinely exhausted with unresolved findings. Here the same ceremony is being spent on an item with nothing to repair, purely to reset a counter.

There is also a known bug that would clear the state and must not be used: isCompletedOrdinaryExhaustion compares a frozen ReviewGeneration against a token rebuilt from the live head, so a git push silently clears an exhaustion ceiling. That is a defect, not a remedy, and taking it would be exploiting the gate this packet is about.

Requested change

1. The ceiling check must consult the verdict. A confirmation with verdict: pass and no material findings must not increment the repair counter — or must not trip the ceiling. What is being bounded is repair rounds, and a pass is not one.
2. acceptance must be authorable over ordinaryExhaustion when the preceding record is a passing confirmation. Refusing acceptance of a chain whose last verdict is pass inverts the gate's purpose: it blocks precisely the outcome the gate exists to reach.
3. Give the successor path its own record kind, or let a wait generation authorize a fresh initial at a moved head. A full re-review of new content is not a repair round and should not be recorded as one.
4. Never park an item in a state whose only prescribed exit is unreachable. The refusal text names the repair phase; repairPhaseGranted is hardcoded null. At minimum the two should agree.

Host disclosure

The round number was my choice, not the engine's. I authored the wait entry as repair-confirmation:4 and handed it to the implementer to file verbatim. The engine accepted it, and I then ruled that recording round 4 was safe because the ceiling bounds repair rounds and this review requested no repair. That reasoning is right about the ceiling's purpose and wrong about its implementation, which is the substance of this packet.

The reviewing critic flagged exactly this risk before writing, stopped, and asked. I ruled to proceed. It then stopped again rather than attempting recovery, correctly identifying that every remaining move was mine or destructive.

Evidence

• Marker 5386827201, record 5386872217 (kind: confirmation, round: 4, verdict: pass, revision 5), wait 5386873327 — all well-formed and durable on PR 262.
• Engine before the record: awaitingSuccessorReview / dispatchSuccessor, stateRound: 4. After: ordinaryExhaustion / park, stateRound: null.
• Acceptance refusal reproduced above.
• One red herring ruled out by the critic: criticSuccessionReceipt is null here and on PR 319, which reached acceptedAwaitingChecks normally. The cause is solely round 4 > maxAutomatedRepairRounds: 3.

Filed from the S.I.R. board by host heron-1413. Related: .github#2865 (repair phase unreachable), .github#2862 (effectiveChainValidated validates no chain).

Class: defect
Paths: src/FS.GG.Coord.Core/StructuredDecision.fs src/FS.GG.Coord.Core/Driver.fs src/FS.GG.Coord.Core/Review.fs tests/FS.GG.Coord.Cli.Tests/StructuredFixtures.fs tests/FS.GG.Coord.Core.Tests/ReviewHeadDivergenceTests.fs tests/FS.GG.Coord.Core.Tests/StructuredDecisionTests.fs