CI lockups: main can never silently go red (pre-push check + auto-revert), bisect by halves, reserved gate capacity, every red names its test, gate logs kept #6466

Done: a red merge batch is now searched by prefixes of its own chain, each stacked on the one before, instead of disjoint pieces each gated on main alone. Every green piece now lands, in order. This is the fix the steward's 19:05Z comment on #5994 asked for first. The merge-queue suites, the five cross files, the type check and the 31 test files that drive the queue all pass. Six tests failed here, in the chromium screenshot suite and the origins suite, which tries to reach a host the sandbox blocks; neither touches the queue.

What changed (judged in src/checks/queue.ts)

• Before: each piece was gated on main alone (#6353). Once the first green piece landed, main moved and every other green result no longer applied. Those pulls went back to waiting and were gated again: the 18:39 batch spent five gates for one landing. A one-pull piece that went red after another red piece also went back to the line and was gated again (the #6387 case).
• Now: the gates are the candidate's chain cut short: the first run, the first two runs, and so on. That is the same shape the line already uses to stack candidates. The whole batch is already known red, so it is never gated again.

- The longest green prefix lands as it was gated. - The culprit is in the run that the first red prefix adds, and that run is searched again on top of what landed. - A culprit on its own is handed back on the red result already in hand, with no extra gate.

• Cost: the same number of gates per round as before. With no free slot it is still plain halving, gating the front half.
• A new helper, prefixOf, cuts the already-built candidate into these prefixes, so no prefix is built twice.

Tests

• test/merge-queue-search.test.ts: the first case asserted the old shape ("the gates share no step") and is rewritten for prefixes. The test was right for the old design; the design changed on purpose.
• A new case covers the steward's request: an 8-pull batch with one bad pull. The 7 good pulls land, the bad one is handed back once, and every green gate's pulls land.
• test/merge-queue-parallel.test.ts: two cases now take one round fewer, and their wave counts and comments say so. "Ten pulls, one red" now finishes in 4 rounds instead of 5.

Not done here

• The 8-pull case takes 3 rounds after the red, not 2. The head-alone split from #4999 still spends one round first; the search after it takes 2. I kept the split because it lands everything in one round when the head is the culprit.
• The steward's "never re-gate a pull red alone on the same head and base." This is only met inside the search. It would conflict with the 30-minute re-gate for unreliable reds (#3155), which merge-queue.test.ts still tests. A person should pick between the two rules.
• The other parts of #5994. The gate log, naming the test a killed shard was running, reserved gate slots, and auto-revert are already closed as #6351, #6352, #6376 and #6377. Still open, and not started here:

- running main's check before a release commit is pushed; - a lint for tests that assume a fixed size of growing records; - retrying a killed shard once on a quiet slot; - the KPIs on /flow.

To try it: bun test test/merge-queue-search.test.ts test/merge-queue-parallel.test.ts. The [queue] gating N pulls log lines show the stacked prefixes, and "red on top of its candidate" names the culprit.

🤖 Generated with Claude Code

Closes #5994

Done: a red merge batch is now searched by prefixes of its own chain, each stacked on the one before, instead of disjoint pieces each gated on main alone. Every green piece now lands, in order. This is the fix the steward's 19:05Z comment on #5994 asked for first. The merge-queue suites, the five cross files, the type check and the 31 test files that drive the queue all pass. Six tests failed here, in the chromium screenshot suite and the origins suite, which tries to reach a host the sandbox blocks; neither touches the queue.

What changed (judged in src/checks/queue.ts)

• Before: each piece was gated on main alone (#6353). Once the first green piece landed, main moved and every other green result no longer applied. Those pulls went back to waiting and were gated again: the 18:39 batch spent five gates for one landing. A one-pull piece that went red after another red piece also went back to the line and was gated again (the #6387 case).
• Now: the gates are the candidate's chain cut short: the first run, the first two runs, and so on. That is the same shape the line already uses to stack candidates. The whole batch is already known red, so it is never gated again.

- The longest green prefix lands as it was gated. - The culprit is in the run that the first red prefix adds, and that run is searched again on top of what landed. - A culprit on its own is handed back on the red result already in hand, with no extra gate.

• Cost: the same number of gates per round as before. With no free slot it is still plain halving, gating the front half.
• A new helper, prefixOf, cuts the already-built candidate into these prefixes, so no prefix is built twice.

Tests

• test/merge-queue-search.test.ts: the first case asserted the old shape ("the gates share no step") and is rewritten for prefixes. The test was right for the old design; the design changed on purpose.
• A new case covers the steward's request: an 8-pull batch with one bad pull. The 7 good pulls land, the bad one is handed back once, and every green gate's pulls land.
• test/merge-queue-parallel.test.ts: two cases now take one round fewer, and their wave counts and comments say so. "Ten pulls, one red" now finishes in 4 rounds instead of 5.

Not done here

• The 8-pull case takes 3 rounds after the red, not 2. The head-alone split from #4999 still spends one round first; the search after it takes 2. I kept the split because it lands everything in one round when the head is the culprit.
• The steward's "never re-gate a pull red alone on the same head and base." This is only met inside the search. It would conflict with the 30-minute re-gate for unreliable reds (#3155), which merge-queue.test.ts still tests. A person should pick between the two rules.
• The other parts of #5994. The gate log, naming the test a killed shard was running, reserved gate slots, and auto-revert are already closed as #6351, #6352, #6376 and #6377. Still open, and not started here:

- running main's check before a release commit is pushed; - a lint for tests that assume a fixed size of growing records; - retrying a killed shard once on a quiet slot; - the KPIs on /flow.

To try it: bun test test/merge-queue-search.test.ts test/merge-queue-parallel.test.ts. The [queue] gating N pulls log lines show the stacked prefixes, and "red on top of its candidate" names the culprit.

🤖 Generated with Claude Code