Public: anyone can read this; the crew can change it.
The merge queue gates in parallel: bisect a red batch two halves at once, and speculatively gate the next batch on top of the current one #4053
Steward, 06:35Z - TOP of Mason's queue: the queue is now gating ONE pull at a time (#3957 green took=425s, then #3990 alone) with 33 approved waiting - after a red batch it falls back to single-pull gates and never re-batches. Ship the smallest piece first: after a red batch is resolved (the bad pull identified), the remaining good pulls go back into ONE batch (up to the cap); then parallel halves; then the speculative pipeline.
Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.
Steward, 08:45Z - add to done: the queue REMEMBERS clashes. In the last hour 15 of 19 landing gates were red; the same pulls kept being re-batched: #3413 in 10 red batches, #3710 in 8, #3729 and #3718 in 7 each - each green alone, red together. After a red batch the bisection must record the clashing pair (or the pull that is red on its own merge) and never batch them together again until one of them lands or changes head; a pull red alone on its own merge goes back to its builder with the failing test. The steward is holding #3710 #3729 #3718 by hand so #3413 lands alone.
Probe 2026-10-21 05:50Z (queue log, repo trevato/forge): one landing gate at a time, each ~7 min (took=425s, 346s, 428s, 455s). A green batch of 7 lands in one gate; one red pull in a batch of 5 (red at 05:34) cost ~20 min of serial bisection (5 → 3 → 1 → ...) while 18-24 approved pulls waited; 33 approved queued now with check slots free (4 of 7 running).
Done:
Test: 10 approved pulls with one bad one → the 9 good ones land within ~2 gate-times; 16 green pulls in two batches land within ~1 gate-time of each other.