The load gate queues a targeted go test (one package, a few minutes) behind whole preflights in one FIFO line, so a short job starves: on 2026-10-26 an implementer's package test for the review-set lane timed out at the gate twice at the 2h limit, behind 19 waiters and 17 make preflight processes (load averages 31.5, 20.7, 40.5 at 09:44). Neither the fixed admission count (iss-2610161756384596) nor the ungated stages (iss-2610241214065079) covers the ordering: even a measured admission count keeps a short job behind every long one already queued.

Frontmatter

.abcd/work/issues/resolved/iss-2610260845422800-the-load-gate-queues-a-targeted-go-test.md
open on GitHub ↗ · commit history ↗

mentions4

• iss-2610161756384596abcd's load gate admits a fixed number of preflights, one, whatever the machine can carry. The product thinker asked on 2026-10-16 that abcd know how many concurrent preflights, race runs and sub-agents are feasible from the resources it actually has, instead of a number a person sets and re-sets by hand (the machine-wide cap moved six times in two weeks: six, eight, ten, twelve, ten, fourteen).
• iss-2610241214065079The load gate meters only a preflight's test stages; every stage before them runs ungated. On 2026-10-24 seven sessions on one 10-core machine each ran make preflight, and all seven ran their lint gates, the smoke and cold-reading eval lanes (five to six minutes each) and build and vet at once, holding the load average near 25. Tests timed out under that load (internal/surface/cli passed go test's ten-minute default), and every preflight then queued behind one test slot, so one nitpick fix waited over an hour. Raising load.preflights to 2 widens only the test slot; nothing bounds the stages before it.
• itd-2610262127138979A preflight waits for its turn as one whole run
• spc-2610262202438999A preflight waits for its turn as one whole run