porch review-phase 3-way consultation (type 'pr') is unrunnable when the lane's PRs merge before the review phase

[waleedkadous]

Problem

porch's SPIR review phase asks for a 3-way consultation of type pr. consult's PR mode resolves OPEN pull requests only — by branch, and via --issue N — so a project whose PRs have already merged cannot run the consultation at all:

consult -m gemini --protocol spir --type pr --project-id 3358
-> 'No PR found for branch: builder/spir-3358'
# --issue 3379 (the merged PR) fails identically: 'No PR found for issue #3379'

A merged GitHub PR cannot be reopened, so there is no recovery path. Porch cannot advance past the phase.

Why this is structural, not operator error

In architect-mediated flows the merge is gated on a human word that can arrive at any phase — in this case both lane PRs (#3374 phases 1-6, #3379 phase 7 in cluesmith/shannon spir-3358) merged on the owner's explicit word BEFORE porch reached the review phase. The protocol's own sequencing produced the state its review phase cannot handle. The work was fully reviewed (phases had their own 3-way consultations; phase 7 ran five iterations to unanimous), so the gap is purely that the review-phase consult binds to an open-PR handle rather than to the merged diff.

Possible remedy shapes (not prescribed)

• consult PR mode accepts merged PRs (resolve by number regardless of state, review the merged diff), or
• a --ref/--range mode reviewing a commit range, or
• porch's review phase recognizes an architect-authorized skip artifact when the PR is already merged and prior consultations are on record.

Observed in cluesmith/shannon spir-3358, 2026-07-27. Resolved operationally by an architect-ruled dated skip-note in the expected artifact slot (honest provenance, no simulated consult output).

[waleedkadous]

Second instance of this gap, different protocol path (first was spir-3379's review phase; this is aspir-3362's phase-iteration loop).

Shape: builder ran the phase's 3-way consultation in the direct form (consult -m X --issue N --prompt-file) rather than the porch-watched form (--protocol aspir --type impl --plan-phase phase_N), so outputs never landed where porch watches. Work proceeded to PR, merge, and develop promotion — all verified. Porch then read the (relocated, provenance-headed) REQUEST_CHANGES verdict and opened iteration 2, demanding a fresh implement pass + another 3-way consultation on code already merged and frozen.

The builder's only in-protocol options were: re-spend a full consultation round on merged work (ceremony), fabricate review files (never), or a human gate approval that doesn't exist for the iteration loop. Architect ruling applied the skip-note precedent: real consult outputs placed at watched paths with honest provenance headers + a dated skip-note in the iteration-2 slots + porch done attempt; if the state machine refuses, the pointer permanently trails merged reality.

Structural ask remains: a first-class porch skip --reason (or equivalent) that lets a human/architect record an honest skip with receipts, so state machines don't demand either re-spend or fabrication on frozen work. Context datapoint: this workspace currently shows 86 pending gates, some from February — trailing pointers are the norm once work outpaces bookkeeping.