The 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.

Frontmatter

.abcd/work/issues/open/iss-2610241214065079-the-load-gate-meters-only-a-preflight-s.md
open on GitHub ↗ · commit history ↗

mentions3

• iss-2610260845422800The 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.
• iss-2611050840360484Nothing watches machine health for a long unattended drive: memory pressure, a growing system daemon or load can climb for hours while stages keep starting. The load gate reads load and memory before a gated run opens and not during it (the Makefile's preflight recipe and the race gate in its preflight-stages recipe; itd-2611012048006057 added the memory floor), and a drive's agent stages between gated runs read nothing, so a stage starts whatever the machine reads and a slow climb is never named.
• itd-2610262127138979A preflight waits for its turn as one whole run