Development record

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