Development record

abcd adjusts how many preflights run at once from what it recorded

intentdraftsminoritd-2610262141001890

Press Release

abcd adjusts how many preflights a machine runs at once from its record of how earlier ones behaved: it lowers the number when tests time out or runs stretch well past their usual time, and raises it again, a step at a time, while runs finish comfortably inside their limits. Nobody adjusts the number by hand: a person may name a starting default, and abcd uses even that only once it has measured what the machine can take. abcd keeps the number it works out in a file of its own, never in the person's settings, and a repository can never raise it. Each change is written down with the runs it rests on, so the person can read why and override it.

Why This Matters

Why this matters to the user — replace before planning.

Mechanism

Prompted (the claim-recording gradient): why the authors expect this to work, as a falsifiable "we expect X because Y" — not the outcome restated. Replace this line with the claim, or with the exact token None stated. alone on its line to record the claim as considered and declined.

Scope Conditions

Required (the claim-recording gradient): the population, platform, scale, or assumptions this claim holds under, one per top-level bullet — abcd intent plan stamps each with a persistent identity. Replace this line with those bullets, or with the exact token None stated. alone on its line.

Acceptance Criteria

Required (the itd-1 discipline): add at least one Given-When-Then bullet describing the verifiable bar for "shipped" before this draft can be planned.

Decisions

The number allowed at once is adjusted automatically, never by hand; a person may name a starting default, used only once the machine's capacity has been measured (product thinker, 26 October 2026, at the planning interview of itd-2610262127138979). This reverses the standing rule that the person writes the number (the LOAD rules, dcn-2610161814279204), and the cap at 2 is lifted only on measured evidence that 2 still leaves room; both are settled at this intent's planning.

Open Questions

None recorded yet.

Audit Notes

Empty. Populated by intent-auditor when intent moves to shipped/.

Frontmatter

id	itd-2610262141001890
type	intent
lifecycle	drafts
severity	minor

.abcd/development/intents/drafts/itd-2610262141001890-abcd-adjusts-how-many-preflights-a.md
open on GitHub ↗ · commit history ↗

References2

itd-2610262140595217abcd records how each preflight on a machine behavedblocked by
itd-2610262140595217abcd records how each preflight on a machine behavedbuilds on

mentions11

dcn-26101618142792042026-10-16 — The product thinker approved a measured trial of two preflights in their test stages at once, with the race stage kept to one at a time; the default stays one, and a person may raise it only for their own machine (load.preflights in ~/.abcd.noindex/config.json, or ABCD_LOAD_PREFLIGHTS), never from a repository file. So the setting takes 1 or 2 and nothing more: 3 and 4 are refused, saying the limit rises once a measured trial supports it. At the default of one the preflight runs exactly as before, its race gate opening at once.
dcn-26102907410943042026-10-29 — Declined part of iss-2610241414124940's remedy: once a run holds a slot, the gate does not switch to judging capacity by the slot count alone and keeps its load limit. Grounds, the timeout evidence of the two records: on 2026-10-24, with several preflights' test stages admitted together at a load near 20 on 10 cores, six packages hit their 20-minute per-binary timeouts in one run, so admitting more than one at a time made all of them fail (iss-2610241414124940); and the gate opened a whole run at load 17.8 on 10 cores, under its limit, after which three packages (claim, implement/loop, surface/cli) hit the 20-minute timeout because the load stayed near the threshold for the whole run (iss-2610241911052191). Admitting by slots past the load would admit more runs into exactly that load. The starvation that part answered came from queued runs' ungated stages feeding the load they waited on, which whole-run admission removes (itd-2610262127138979): a queued run now does no work. The idle-slot part of the same remedy is carried by iss-2610262155232329. The same record's 2026-10-25 evidence points the other way from slot-only admission too: a run admitted alone at load 8.5 on 10 cores still timed out three packages while the machine's on-access scanner used one to two cores, a cost the load average does not show, so the load is if anything an optimistic signal there; admission on measured headroom is the draft itd-2610262141001890.
dcn-26102911322235522026-10-29 — iss-2610241911052191 takes the issue's second remedy, a per-binary test timeout scaled with the load as -p is, not admission on projected headroom (draft itd-2610262141001890). Each test stage's go test -timeout is the Makefile's 40m base while the one-minute load is at most one runnable per online core and twice it past that, two values only because go test hashes -timeout into its cache key and a budget moving with each reading would rerun every cached package on a busy machine, read once as the stage starts by `cmd/test-parallelism -timeout <base>` (machineload.GoTestTimeout, implement.PreflightTimeout). On a CI runner, or where the machine cannot be read, it is the base, so CI's race steps and the local race lane keep one declared budget. The cap of two keeps both stages inside land's four-hour run bound with room for the gates and eval lanes; a bad base is refused loudly, so the stage fails rather than running with go test's 10m default.
dcn-26103013163404112026-10-30 — itd-2610262127138979, delta docs-fidelity findings 7 and 8 before the cut: docs/how-to/install.md now says make preflight waits its turn at the load gate before its load check, but AGENTS.md's preflight comment is left as it is, because AGENTS.md has under thirty bytes of room under its smallest reader's cap and the gate's wait is taught in the implement page, the LOAD rule and the Makefile. The intent's slug and title stay as they are: a rename is not a wording fix, and the intent's own Decisions section hands sizing the count automatically to itd-2610262141001890. Agent decision in an autonomous run.
dcn-26110120490462592026-11-01 — With the drain wound down on 2026-11-01, three streams of work start in parallel: the terminal drain (itd-2610222215485265) in this session, the load work (itd-2610262140595217, itd-2610262141001890 and the memory floor) with Eve, and the CI work (itd-2610261025516272 and its new drafts) with Henry. While the subscription's weekly budget is near its limit, every agent a build or drain hands out runs on the person's API key through the claude runner, never as a host subagent; only the driving sessions stay on the subscription.
iss-2610262155232329A load-gate slot held by a run that has stopped using the machine is never released: a holder that hangs or idles keeps its slot until its own timeout, and every other waiter waits behind it (part of the remedy of iss-2610241414124940, split out of itd-2610262127138979 at its planning on 2026-10-26, because whole-run admission does not decide it). Admitting a run on the headroom it will need rather than the load at one instant (part of iss-2610241911052191) moves with it to the adaptive count, itd-2610262141001890.
itd-1Every Intent Has Acceptance Criteria; Every Audit Verifies Them
itd-2610262127138979A preflight waits for its turn as one whole run
itd-2611011325421304A one-package change is checked in minutes, not the whole suite
spc-2610262202438999A preflight waits for its turn as one whole run
spc-2611012047503720A one-package change is checked in minutes, not the whole suite