Observed on 2026-08-31 with bugfix-242, and it caused a real near-miss: the builder reported "protocol complete, ready for cleanup" while PR #282 was still open with all 9 CI checks pending. Cleaning up on that report would have removed the worktree of an unmerged branch.
What porch does
Approving the pr gate moves the project straight to verified / complete. porch next 242 then returns:
PHASE: verified
STATUS: complete
The protocol is complete. Merge the PR using: .../scripts/forge/github/pr-merge.sh ...
After merging, notify the architect: afx send architect "Project bugfix-242 complete. PR merged. Ready for cleanup."
So the state says complete, and in the same breath the instructions tell the builder to go and merge. The text it hands the builder to send afterwards asserts "PR merged" as a fact the builder has not yet established.
Why it matters
"Protocol complete" is the signal an architect acts on to close the issue and run afx cleanup. It currently means "the gate was approved", not "the work landed". Those differ by exactly the step that can still fail: CI going red, a merge conflict, a branch that never merges at all.
This is the shape the project already treats as a defect. A state that cannot yet observe whether the merge happened must not be spelled the same way as a state that observed it and found it done.
It also interacts badly with cleanup, which removes the worktree and the branch. An architect trusting complete deletes the only copy of unmerged work.
What would close this
- Do not enter
complete on gate approval. porch done <id> --merged <N> already exists as the signal that the merge landed; that is the transition that should produce complete.
- If an intermediate state is wanted, name it for what is true: the gate is approved and the merge is outstanding.
- Fix the canned notification text so the builder is not handed a sentence asserting something it has not checked. It should report what it did, and the merge should be verified before that sentence is sendable.
Reported by
Builder bugfix-242, which flagged it rather than acting on it.
Observed on 2026-08-31 with
bugfix-242, and it caused a real near-miss: the builder reported "protocol complete, ready for cleanup" while PR #282 was still open with all 9 CI checks pending. Cleaning up on that report would have removed the worktree of an unmerged branch.What porch does
Approving the
prgate moves the project straight toverified/complete.porch next 242then returns:So the state says complete, and in the same breath the instructions tell the builder to go and merge. The text it hands the builder to send afterwards asserts "PR merged" as a fact the builder has not yet established.
Why it matters
"Protocol complete" is the signal an architect acts on to close the issue and run
afx cleanup. It currently means "the gate was approved", not "the work landed". Those differ by exactly the step that can still fail: CI going red, a merge conflict, a branch that never merges at all.This is the shape the project already treats as a defect. A state that cannot yet observe whether the merge happened must not be spelled the same way as a state that observed it and found it done.
It also interacts badly with cleanup, which removes the worktree and the branch. An architect trusting
completedeletes the only copy of unmerged work.What would close this
completeon gate approval.porch done <id> --merged <N>already exists as the signal that the merge landed; that is the transition that should producecomplete.Reported by
Builder
bugfix-242, which flagged it rather than acting on it.