---
name: load-claim-needs-measured-axes
description: "Never name LOAD as a red's mechanism until the load axes are measured — on this fleet all four are already logged in CI, and on 2026-07-29 every one of them came back against the load story."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 6a14670e-bb15-4349-8038-7a869bba868d
  modified: 2026-07-29T14:42:35.132Z
---

"Environmental — load pushed the timed assert over" is the cheapest story available for a
non-reproducing red, and on spt-core's CI it is **checkable in minutes**, so asserting it
unmeasured is a choice, not a limitation.

**Why:** I classified #122's Windows `daemon_hosts_lifecycle_and_survives_brain_restart` red
(`daemon_e2e.rs:334`, hard 2s ceiling from `for _ in 0..200 { … sleep(10ms) }`) as
"environmental-suspect, load pushes it red" — plausible, mechanism-shaped, and **wrong on every
axis I could measure**. The at-sha rerun (run 30448474189 attempt 2) went green, which would have
"confirmed" the load story if I had stopped there. It did not survive the four checks.

**How to apply — the four axes, all already in the logs on this fleet:**
1. **Co-tenancy from the job timeline, not from `gh run list`.** hfenduleam's Windows runner
   **serializes** — reconstruct start/end of every Windows job that day and check for actual
   overlap. On 07-29 no two ever overlapped, so "another CI job loaded it" was dead on arrival
   for *both* the red and the green.
2. **Free space from the preflight step** (`disk preflight: … free_bytes=…`, printed by the
   REQ-CI-FREE-SPACE-PREFLIGHT step on every job). Red had **106.68 GB**, green **99.80 GB** —
   the failing run had ~7 GB *more* headroom, the opposite of the day's 47GB-target incident.
3. **Job duration.** Red 18m36s, green 21m36s — the failing run was the **faster** one. A loaded
   box producing the quicker job is backwards.
4. **Process census** (`CI-CENSUS phase=start … box_procs= box_handles=`). Comparable at start
   (544/221367 vs 546/225918), so no box-state gap either.

⭐ **The only asymmetry found was `scoped=6` leaked workspace daemons pre-reap on the red vs
`scoped=0` on the green — and its causal direction is ambiguous, because an unreaped session IS
the failure.** Report that ambiguity intact rather than promoting it to cause; what keeps it
interesting is the *count* (one failing test explains ~one survivor, not six).

⭐⭐ **A wrong mechanism in the ledger is worse than an open question.** The honest verdict was
"unexplained non-reproducing red with a leak signature", not "load flake" — and it names the next
discriminating observable: a scoped census **at the moment of the assert** (or the reap loop
logging `session_count()` each poll), since everything measurable at job level is now clean.

Corollary: a green rerun on a **quiet** box is exactly what the load hypothesis predicts, so it
is consistent-with, never discriminating. Check what else was on the box during the *green* too.

Related: [[window-assertion-load-direction]] · [[seam-touched-red-needs-repeat-proof]] ·
[[quiet-window-predicate]] · [[ground-dont-assume-on-incidents]] · [[verdict-from-exit-not-from-silence]]