The product thinker wants the number of preflights a machine runs at once to follow the evidence, not stay fixed. On 2026-10-24 they set load.preflights to 2 in ~/.abcd.noindex/config.json, which applies to every abcd-managed repository on the machine, and asked that load monitoring keep it right: raised when the machine has room, lowered when it is overloaded. Today the count is a fixed number a person writes (default 1, at most 2), and the gate measures load only to decide whether to wait, never to learn: nothing records how long stages waited or ran, whether tests timed out, or what the load was, so no one can tell whether 2 is too many or too few.

The product thinker wants the number of preflights a machine runs at once to follow the evidence, not stay fixed. On 2026-10-24 they set load.preflights to 2 in ~/.abcd.noindex/config.json, which applies to every abcd-managed repository on the machine, and asked that load monitoring keep it right: raised when the machine has room, lowered when it is overloaded. Today the count is a fixed number a person writes (default 1, at most 2), and the gate measures load only to decide whether to wait, never to learn: nothing records how long stages waited or ran, whether tests timed out, or what the load was, so no one can tell whether 2 is too many or too few.

Evidence from the same run, 2026-10-25/26, on a 10-core machine with 16 GB: with load.preflights at 2 and two preflights in their test stages at once, the one-minute load reached 42 and package tests timed out at their per-package limits, so the setting went back to 1 the same evening. With 1, and with the machine's endpoint-security scanner switched off (it had been using about four cores of its own), this session's two whole preflights (the repairs of PRs 1110 and 1116) each passed at the first attempt. A fixed number is therefore wrong in both directions: 2 overloaded the machine while the scanner ran, and the right number changed when the scanner stopped, which no person-written setting tracks.