Porch records state by committing, and CI keys off the branch head. So any protocol bookkeeping during the merge window invalidates the merge window: recording the pr gate pushes a commit, the push re-triggers every check, and the green board that justified the gate no longer describes the head being merged.
Observed end-to-end on pir-1070 / PR #1461 (2026-08-15), where it became a loop rather than a one-off delay:
02:36:20 chore(porch): 1070 pr gate-approved <- gate recorded, CI restarts
02:36:23 chore(porch): 1070 protocol complete <- second bookkeeping commit, CI restarts
02:37:11 [PIR #1070] Thread: pr gate approved,
merge hit branch-protection wall <- builder narrates the block, CI restarts
The architect measured all seven checks green, recorded the gate, and by the time the merge request reached the executing architect the board was pending against a head three commits newer. Twice more the same thing happened while the state was being reported.
The loop is self-sustaining and is caused by good behaviour, not bad. The builder narrates that the merge was blocked → the narration is a commit → the commit restarts CI → the merge defers → there is a fresh blocked state to narrate. The better a builder's thread hygiene, the tighter the loop. It only broke because two architects independently traced it in the same minute and told the builder to stop writing, including stopping porch done, which also commits.
Two consequences worth separating:
- A stated "CI is green" cannot survive the gate that follows it. On a porch-driven lane those two facts can never be true of the same commit. Every merge-request presentation this week has carried a green claim that expired between writing and arrival — harmless when the executor re-verifies, and a silent hazard when they do not.
- The merge window is only the gap between the last bookkeeping commit and the next one, and nothing today defines or protects that gap.
Wanted — a rule rather than better manners. Something in the protocol that makes the branch quiet from the pr gate until the merge lands: no thread writes, no porch state writes, no pushes of any kind, with porch done --merged explicitly deferred until after the merge commit exists. The builder-facing prompt should say so, because a well-behaved builder will otherwise keep its journal faithfully and re-trigger CI each time.
Worth considering alongside: whether porch's gate write and its phase-transition write need to be two commits (they were, here, 3 seconds apart), and whether bookkeeping-only commits could be marked so CI can skip them — though a rule is cheaper than a CI-config change and does not depend on every workflow honouring the marker.
Sibling to #1446 (the post-merge stamp that can never reach main): both are consequences of porch recording state by committing into the branch under review. Root cause traced jointly with the vscode architect; the framing that the fix is a rule rather than a discipline is theirs.
Porch records state by committing, and CI keys off the branch head. So any protocol bookkeeping during the merge window invalidates the merge window: recording the pr gate pushes a commit, the push re-triggers every check, and the green board that justified the gate no longer describes the head being merged.
Observed end-to-end on pir-1070 / PR #1461 (2026-08-15), where it became a loop rather than a one-off delay:
The architect measured all seven checks green, recorded the gate, and by the time the merge request reached the executing architect the board was pending against a head three commits newer. Twice more the same thing happened while the state was being reported.
The loop is self-sustaining and is caused by good behaviour, not bad. The builder narrates that the merge was blocked → the narration is a commit → the commit restarts CI → the merge defers → there is a fresh blocked state to narrate. The better a builder's thread hygiene, the tighter the loop. It only broke because two architects independently traced it in the same minute and told the builder to stop writing, including stopping
porch done, which also commits.Two consequences worth separating:
Wanted — a rule rather than better manners. Something in the protocol that makes the branch quiet from the pr gate until the merge lands: no thread writes, no porch state writes, no pushes of any kind, with
porch done --mergedexplicitly deferred until after the merge commit exists. The builder-facing prompt should say so, because a well-behaved builder will otherwise keep its journal faithfully and re-trigger CI each time.Worth considering alongside: whether porch's gate write and its phase-transition write need to be two commits (they were, here, 3 seconds apart), and whether bookkeeping-only commits could be marked so CI can skip them — though a rule is cheaper than a CI-config change and does not depend on every workflow honouring the marker.
Sibling to #1446 (the post-merge stamp that can never reach
main): both are consequences of porch recording state by committing into the branch under review. Root cause traced jointly with the vscode architect; the framing that the fix is a rule rather than a discipline is theirs.