porch ingests the last verdict in a lane's output, and counts a lane done because its file exists

[pseudoseed]

Found when a review lane wrote into the builder worktree, then reviewed its own edits, producing an output file with three verdict blocks: REQUEST_CHANGES, then APPROVE, then APPROVE. Porch was one lane away from recording that trailing APPROVE as a clean phase review. See #149 for the write-permission half; this issue is about what porch does with the result.

1. Last verdict wins, so an earlier blocking verdict is discarded

packages/codev/src/commands/porch/verdict.ts:26-43:

// Scan lines LAST→FIRST so the actual verdict (at the end) takes priority
// over template text echoed by codex CLI at the start of output.
for (let i = lines.length - 1; i >= 0; i--) {

The stated reason is sound: codex echoes the prompt template at the start, and that echo must not be mistaken for a verdict. But the implementation does not distinguish "template echo I should skip" from "a real earlier verdict from the same run". It returns the last one it finds and discards everything before it.

So an output containing a genuine REQUEST_CHANGES followed later by APPROVE is ingested as APPROVE. The blocking verdict vanishes with no signal that anything was overridden.

Suggested fix: if more than one non-template VERDICT: line is present, do not silently pick one. Either take the most severe (REQUEST_CHANGES > COMMENT > APPROVE), or refuse the file and report "multiple verdicts, ambiguous" as its own outcome. A single lane emitting two different verdicts is a malformed result, and malformed must not be spelled the same way as approved. Keep the template-echo skip by matching the template shape explicitly rather than by position.

2. A lane counts as complete because its output file exists

porch next reported the claude lane DONE and moved on to "Run remaining consultations (codex)" while status.yaml had no phase 5 reviews recorded at all. Renaming the output file immediately reset porch next to "Run 2-way consultation".

So lane completion is inferred from a file being on disk. Nothing checks that the file was produced by a lane that only read, that it contains exactly one verdict, or that it corresponds to the tree currently under review. A file written by any means counts as a completed review round.

Suggested fix: record what was reviewed alongside the verdict — at minimum the commit sha of the tree at review time — and reject a lane result whose sha does not match the current head. That also catches the ordinary stale-output case, where a lane result from an earlier iteration is still sitting on disk.

3. No verdict at all is ingested as non-blocking

parseVerdict (same file, line 51):

if (!output || output.trim().length < 50) return 'REQUEST_CHANGES';
return findVerdict(output) ?? 'COMMENT';

Output under 50 characters correctly fails safe. But a long output with no VERDICT: line becomes COMMENT, which is non-blocking. That is the exact shape this project keeps getting bitten by: "I could not tell" spelled the same as "nothing to report".

It has now happened three times in this program alone — a quota-exhausted codex lane exiting 0 with an empty file, an opencode lane returning no verdict, and this one. A lane that ran and produced prose but never stated a verdict has not reviewed anything, and should be REQUEST_CHANGES or a distinct NO_VERDICT outcome, not a silent pass.

[pseudoseed]

A third gap in the same accounting, surfaced when a lane had to be disqualified mid-phase.

After the phase 7 incident (a review lane authored and committed a security change, then would have approved it — see #149), the architect barred that lane for the rest of the phase. porch next then said:

Some consultations are still missing. Run: consult -m claude … --output 146-phase_7-iter2-claude.txt

and would not advance without that file.

Porch has no way to record a disqualified lane. Checked the full command surface: next, status, check, done, gate, pending, approve, verify --skip, rollback, init. Nothing marks a lane excluded, substituted, or void.

So a lane that must not be counted is indistinguishable to porch from one that has not run yet. The protocol can void a verdict socially — a human says "ignore that one" — but not structurally, and the structure is what actually advances the phase.

The builder was left with only bad options, and correctly refused all three of the tempting ones: fabricate a verdict, write one lane's output under another lane's filename, or hand-edit status.yaml. Writing opencode's verdict to the claude path would have put a fake independent approval into the permanent record, which is the exact failure that started this.

What is needed

• A way to mark a lane disqualified for this phase, with a reason, that satisfies the completeness check without inventing a verdict. porch lane disqualify <project> <phase> <lane> --reason "..." or equivalent.
• The record should show three states, not two: a verdict, a lane that did not run, and a lane whose result was rejected. Collapsing the third into either of the others is how a rejected review becomes a missing one, or worse, a counted one.
• A substitution — running opencode in place of codex, which has happened repeatedly this program because of quota — should be recordable as a substitution rather than silently filling a named slot.

Related

• A consult review lane can write into the artifact it is reviewing #149 — the lane that wrote to the worktree and would have approved its own work; the reason a disqualification was needed at all.
• The rest of this issue — last-verdict-wins, file-presence-means-done, and no-verdict-reads-as-comment. All four are the same shape: porch's lane accounting cannot express what actually happened, so it records something adjacent and moves on.