---
name: prefire-check-reads-the-disk-floor
description: "A pre-fire process census is structurally blind to a FINISHED build's disk cost — read the CI disk floor as its own axis before firing golden."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: af542e3e-b09f-4831-8947-e03c0c37926b
  modified: 2026-08-22T02:20:20.179Z
---

Golden run 30928816784 (USHER #150, `fc7fad1`, 2026-08-04) died in the Windows disk preflight
before any cargo or test process started:

    disk preflight: drive=C:\ free_bytes=26099576832 floor_bytes=34359738368
    RESOURCE=disk ... exit 1

128-line job log, ZERO `Compiling` / `PASS` / `FAIL` / `Summary` lines — no test signal at all, and
the merge chain was never indicted. Both Windows legs went the same way; both Linux legs were green.

My pre-fire check had come back clean minutes earlier: zero test-path `spt.exe` residents, zero
`cargo`/`rustc`/`link`/`cl` processes. Both readings were TRUE at the same instant. The gater's
assembly gates (`cargo check --workspace`, `clippy --workspace`, a bins+units run into
`.worktrees/golden-usher-assembly/target`) had already FINISHED — their cost was sitting on disk as
a directory, not running as a process. The box was already ~6 GB under floor while my census
reported clean.

**Why:** a process-axis probe cannot see a finished build's footprint by construction. The probe was
neither stale nor racy — it answered a different question from the one the preflight gates on. Same
shape as a rig immunity that exists only as a comment: the instrument is sound and still cannot see
the deciding variable. "Re-check closer to the fire" would have changed nothing; the axis was never
read at all.

**How to apply:** before firing golden, measure BOTH axes — process residents AND free space against
the workflow's own floor (32 GiB / 34359738368 bytes in `golden.yml`, described there as the
tens-of-GB full-suite footprint rounded up for ONE complete run). Passing preflight and surviving a
full Windows leg are different claims, so treat a number only modestly above the floor as unproven
rather than as license. The gater's assembly-gate disk cost counts against the same budget, so a
handoff does not imply a clean floor.

**Addendum, same run, measured later the same day — one floor reading is a SNAPSHOT, not a
guarantee.** Preflight lines pulled by text from the run's own Windows-side logs, same box, same
drive C:

    16:22:55  test Windows     free_bytes=26099576832   REFUSED
    16:23:07  n1-gate Windows  free_bytes=26096607232   REFUSED
    16:46:54  twohost-a        free_bytes=71033049088   PASSED, then ran 11 min to success

~45 GB came back inside the run window with NO deliberate teardown (the gater was holding all of
it), and my own reading at 17:13:45Z was 61352714240 — ~10 GB BELOW what twohost-a had seen 27
minutes earlier. The free-space number swings by tens of GB on a sub-30-minute scale, and the
observed swing amplitude EXCEEDED the margin I was about to fire on (25.14 GiB). So: reading the
floor axis is necessary but not sufficient — reclaim until the margin is larger than the observed
SWING, not larger than one sample. Corollary for triage: twohost-a runs the same 32 GiB preflight
on the same C: and passed, so a preflight refusal is a threshold event on a moving number, never
evidence the box cannot run the work.

**Third face, 2026-08-22 (TURNKEY #190 gate) — the floor is not only golden's preflight, and
READ-but-not-APPLIED is the dominant failure mode.** I had this file's craft in the loaded
GATE-TEST-INDEX and still fired a cold-pool full-workspace gate build (fresh worktree target,
~34.6 GB measured at reap) into a C: already carrying two same-window lane pools. C: hit 100%
(233 MB free); the RESIDENT NODE DAEMON's store writes died `disk I/O error` and the daemon
crashed and self-healed TWICE, interrupting the operator — the incident presented as "some agent
is resetting the daemon", i.e. as a security event, and only the log tail (ENOSPC storm, no stop
verb) separated the two. Local gate legs share golden's floor physics: the blast radius of a full
disk is not the run that fills it but every store-writing process on the box, the daemon first.
**Apply at the pool-claim moment** — the claim is the natural hook: `df` before every cold-pool or
full-workspace fire, count the OTHER live pools in the same window as budget already spent, and
reap finished pools before firing the next, not after the incident.

Kin: [[process-census-count-is-noise]] (the other half of the same census),
[[one-sample-is-not-a-negative]], [[intermittent-green-is-zero-information]],
[[a-predicate-without-its-tool-is-not-evidence]], [[verdict-from-probe-competence]],
[[measure-the-box-before-the-instrument]], [[panic-message-is-preauthored-not-a-finding]].