A pull enters the merge queue only after the full suite passes on its current head merged with main (not the impact-mapped subset) #7620

A pull now joins the merge queue only after the full gate passes on its head squashed onto main's tip. Its own fast-tier check is no longer enough. A test that the pull's impact-mapped subset never reached now fails before the queue, so it no longer costs a batch of up to 8.

• The proof (src/checks/proof.ts): when a repository's check has a fast tier, the green sweep's admit (src/crew/autonomy.ts) proves the pull before admitting it. It squashes the head onto the base tip and runs ChecksHandle.prove. That is the gate's own run (gateRun in src/checks/service.ts), so command, environment and sharding are identical to the gate's.

- The proof runs beside the sweep and holds a check slot the way a gate does (proofsInFlight). - A green proof is stored as a proof row in the decision ledger, with the head and base it ran on, and admits the pull straight away. - A red proof keeps the pull out of the queue and comments on it, naming the failing tests and linking the gate log. No batch is touched. - While the proof runs the pull waits as proving; after a red it waits as proof-red. Both show in the tick's waits. - Its log is kept as a gate log, but not as the forge's last gate, so the Resilience page still reads queue gates only.

• Stale proofs: a proof stops counting once main moves more than STALE_LANDINGS (16, two full batches) first-parent commits past its base, or if that base is no longer an ancestor of main.

- Before admission, the pull is proved again on the new tip. - A pull already waiting in the queue is left out of its next batch, like a conflicting pull, through the new Queued.proven hook in src/checks/queue.ts. It is proved again before it rejoins. - A red proof is final for its head until a push or until main moves that far.

• Unchanged: repositories whose check has no fast tier already ran the whole suite on the pull, so they are not proved again. A checks lane without prove (the test stand-ins) admits pulls as before.
• Visible: proof rows show on the board's decision list as "proved before the queue". docs/CREW.md describes the admission rule.

Not done: proof results don't get their own API or MCP tool. They are reachable through the decision ledger, the comment on the pull and the tick's waits. Shared sharding comes from reusing the gate's run, so the sibling sharding issue applies to both without more work here.

To try it: bun test test/merge-queue-proof.test.ts covers five cases:

• a pull that breaks an unrelated test is never admitted, and is told the test by name;
• a green proof admits the pull, which lands exactly the tree that was proved;
• a proof main has moved 17 landings past is proved again on the new main;
• a stale pull already in the queue is left out of its batch without being gated;
• the words of a red proof.

tsc --noEmit is clean, and the queue, landing, autonomy, gate and board suites pass (202 tests across 33 files). scripts/fast.ts said the diff reaches too many tests to run here, so I picked those suites myself and did not run the full suite.

🤖 Generated with Claude Code

Closes #7616

A pull now joins the merge queue only after the full gate passes on its head squashed onto main's tip. Its own fast-tier check is no longer enough. A test that the pull's impact-mapped subset never reached now fails before the queue, so it no longer costs a batch of up to 8.

• The proof (src/checks/proof.ts): when a repository's check has a fast tier, the green sweep's admit (src/crew/autonomy.ts) proves the pull before admitting it. It squashes the head onto the base tip and runs ChecksHandle.prove. That is the gate's own run (gateRun in src/checks/service.ts), so command, environment and sharding are identical to the gate's.

- The proof runs beside the sweep and holds a check slot the way a gate does (proofsInFlight). - A green proof is stored as a proof row in the decision ledger, with the head and base it ran on, and admits the pull straight away. - A red proof keeps the pull out of the queue and comments on it, naming the failing tests and linking the gate log. No batch is touched. - While the proof runs the pull waits as proving; after a red it waits as proof-red. Both show in the tick's waits. - Its log is kept as a gate log, but not as the forge's last gate, so the Resilience page still reads queue gates only.

• Stale proofs: a proof stops counting once main moves more than STALE_LANDINGS (16, two full batches) first-parent commits past its base, or if that base is no longer an ancestor of main.

- Before admission, the pull is proved again on the new tip. - A pull already waiting in the queue is left out of its next batch, like a conflicting pull, through the new Queued.proven hook in src/checks/queue.ts. It is proved again before it rejoins. - A red proof is final for its head until a push or until main moves that far.

• Unchanged: repositories whose check has no fast tier already ran the whole suite on the pull, so they are not proved again. A checks lane without prove (the test stand-ins) admits pulls as before.
• Visible: proof rows show on the board's decision list as "proved before the queue". docs/CREW.md describes the admission rule.

Not done: proof results don't get their own API or MCP tool. They are reachable through the decision ledger, the comment on the pull and the tick's waits. Shared sharding comes from reusing the gate's run, so the sibling sharding issue applies to both without more work here.

To try it: bun test test/merge-queue-proof.test.ts covers five cases:

• a pull that breaks an unrelated test is never admitted, and is told the test by name;
• a green proof admits the pull, which lands exactly the tree that was proved;
• a proof main has moved 17 landings past is proved again on the new main;
• a stale pull already in the queue is left out of its batch without being gated;
• the words of a red proof.

tsc --noEmit is clean, and the queue, landing, autonomy, gate and board suites pass (202 tests across 33 files). scripts/fast.ts said the diff reaches too many tests to run here, so I picked those suites myself and did not run the full suite.

🤖 Generated with Claude Code

A pull joins the merge queue only after the full gate passes on its head squashed onto main's tip; its own fast-tier check is no longer enough. A test that the pull's impact-mapped subset never reached now fails before the queue, so it no longer costs a batch of up to 8.

What changed

• The proof (src/checks/proof.ts): when a repository's check has a fast tier, the green sweep's admit (src/crew/autonomy.ts) proves the pull before admitting it. It squashes the head onto the base tip and runs ChecksHandle.prove. That is the gate's own run (gateRun in src/checks/service.ts), so command, environment and sharding are identical to the gate's.

- The proof runs beside the sweep and holds a check slot the way a gate does (proofsInFlight). - A green proof is stored as a proof row in the decision ledger, with the head and base it ran on, and admits the pull straight away. - A red proof keeps the pull out of the queue and comments on it, naming the failing tests and linking the gate log. No batch is touched. - While the proof runs the pull waits as proving; after a red it waits as proof-red. Both show in the tick's waits.

• Deadline: a proof that hasn't answered by the gate's own deadline (GATE_DEADLINE_MS, 15 minutes, #3430) is cut off.

- Its run's AbortSignal fires, passed through proveCandidate and prove, so the job stops. - No verdict is kept, the pull's proving entry and its slot are released, and the next sweep proves it again. - The entry is released before the answer is acted on, so the sweep that a green proof starts doesn't see the pull as still proving.

• Stale proofs: a proof stops counting once main moves more than STALE_LANDINGS (16, two full batches) first-parent commits past its base.

- Before admission, the pull is proved again on the new tip. - A pull already waiting in the queue is left out of its next batch through Queued.proven in src/checks/queue.ts, and proved again before it rejoins.

• Unchanged: repositories whose check has no fast tier already run the whole suite on the pull, so they are not proved again. A checks lane without prove admits pulls as before.
• Visible: proof rows show on the board's decision list as "proved before the queue". docs/CREW.md describes the admission rule and the deadline.

Cost: every fast-tier pull now runs the full suite twice: once as its proof and once in its batch gate. That buys a mostly green queue, but adds a full-suite run per pull for the check machines. This works against the 10x landed-per-hour goal until the batch gate runs only on impact. Proofs share the check slots, and a second proof starts only when a slot is free.

Not done: proof results don't get their own API or MCP tool. They are reachable through the decision ledger, the comment on the pull and the tick's waits.

To try it: bun test test/merge-queue-proof.test.ts covers seven cases:

• a pull that breaks an unrelated test is never admitted, and is told the test by name;
• a green proof admits the pull, which lands exactly the tree that was proved;
• a proof main has moved 17 landings past is proved again on the new main;
• a stale pull already in the queue is left out of its batch without being gated;
• a proof that never answers holds a slot and stands proving until its deadline, then lets both go and keeps no verdict;
• a head that doesn't merge onto the tip is not proved and holds no slot;
• the words of a red proof.

tsc --noEmit is clean, and the queue, landing, autonomy and gate suites pass.

🤖 Generated with Claude Code

The full gate on land was red; the pull is open again. Red tests:

• reviews, threads and the merge gate > require-review refuses the merge until the head is approved

The gate's log: /api/v1/repos/trevato/forge/gates/1793156876372-6185fd43aad0/log

Red on top of #7612, which landed first from the same merge-queue candidate: red on its own on that base, or only together with them. Bring this pull up to date with the base and push.