ProjectEngine's in-review auto-merge sweep was a second merge authority. It
judged eligibility from column, status, steps and retry budget alone, with no
idea where the card sat in its workflow graph, so it merged work the graph had
never authorized: FN-9191 merged ~2s after fn_task_done, before Code Review had
ever started, and FN-9193 merged while Code Review was re-running — the gate
then requested revision and reset the steps, but the in-flight merge landed the
pre-remediation branch anyway and left the card mergeConfirmed WITH incomplete
steps, unfinalizable for five hours.
- classifyMergeSweepAdmission (core) admits only merge-confirmed finalization,
a card parked at a merge-region node, an interrupted attempt, or a fenced
quiescent stall. Every initiation is fenced on satisfied pre-merge gates.
- All four doors prove authority: the sweep, the 300ms column-entry handoff
(which matches FN-9191's timing better than any sweep tick), the unpause
re-enqueue, and a position-only pre-dispatch re-check for cards the graph
moved out of the merge lane while they were queued.
- workflow-merge-region.ts holds the canonical merge-region predicate;
INTERPRETER_ENTRY_NODE_KINDS now aliases it so the two cannot drift.
- Multi-repo: branch-group integration/promotion are merge-region nodes, an
in-flight sub-repo land reads as foreign liveness, and a cross-node
merge-dispatch lease defers.
- Sweep reads are batched, so admission costs O(1) queries per poll.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
038f802ba4