---
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-28T07:26:48.714Z
---

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.

**Fourth face, 2026-08-24 (WAX-SEAL W3) — the budget CONSTANT, measured three times: a
full-sweep pool's steady state is ~90–112 GB, and it is a REBUILD cost, not an accumulation.**
The 2 TB volume hit 4 KB free mid-lane; I cargo-cleaned my own live pool (104.8 GB, reclaim
measured 100.2 GB) and read the incident as "accumulation across runs". WRONG PROPERTY: one
W3 leg chain (clippy --workspace --all-targets + workspace nextest's test-binary build)
regrew the SAME pool to 111.7 GB within the hour — a fully-built workspace pool just WEIGHS
that much (specimens: doyle's finished gate rig 90.9 GB, my W2 pool 104.8 GB, my W3 pool
111.7 GB; narrow lanes 12–13 GB). So cleaning a pool you still need buys ONE window and
schedules the same floor at the next full sweep, at rebuild price. Budget in POOLS, not GB:
the estate held FIVE pools that night (~230 GB); the drive can afford ~one full pool + one
narrow lane. Reap DEAD pools (classify-then-reap), never a live one you'll rebuild; when the
floor still can't fit one full pool + operator data, that is NEEDS-OPERATOR territory, not a
teardown problem. The kill signature at the floor: LNK1180 "insufficient disk space" +
LNK1318 PDB LIMIT (12) — those reds belong to the disk, never the diff (IR-59).

**Fifth face, 2026-08-24 (SIGNET #218 intake) — the figure was TRUE when measured and FALSE when
quoted; the defect is at the REPORTING seam, and a receiver's own preflight is what catches it.**
doyle's golden-head hand-off stated "131G free (above your 32G floor)". I measured **77.2 GB** at
intake, twice; todlando then measured **76.43 GB** independently before touching anything. Two
instruments against one, so the hand-off figure lost — and doyle's own account of it is the lesson:
his assembly-gate script read `df` at **BATTERY START** and he quoted that number in a **post-battery**
hand-off. The battery itself spent the difference. The figure was *true as an instant and false as
headroom*, which is why it never looked wrong to its author — and he had written this file's fourth
face (IR-59) the same day.

**How to apply, both directions.** As RECEIVER: a hand-off's box-state figure is a claim about a
moving number, so re-measure before predicating a run on it — it costs one command, and here it moved
the IR-59 part-1 pool reap FORWARD (from "at your release" to before the push), turning a 45 GB margin
into 169.65 GB verified on my own read. A peer's state figure wears fact clothes better than a ruling
does — that is exactly the miss recorded in [[relay-is-not-the-gaters-word]], caught this time only
because the number was checkable in one command. As REPORTER: any figure that outlives the instant it
was sampled ships **with its as-of**, or it defers to the consumer's own preflight. doyle adopted that
as the standing hand-off form the same day, and gave todlando the same commitment.

**Sixth face, 2026-08-24 (SIGNET fixup reap, todlando) — the RECLAIM figure has the same defect as
the headroom figure, measured in BOTH directions in one session.** His pool walk measured 5.97 GB;
the free-space delta across the reap read **14.09 GB** (something else released ~8 GB in the same
window). His earlier reap the same day ran the OTHER way: delta 93.88 GB against a 99.95 GB pool
(a sibling build was spending through the window). Neither delta was his action. His form, adopted:
**a free-space delta measures the BOX over an interval, not your action, unless you own the
interval** — claim the walked subtree size as your reclaim, and treat the delta as corroboration
only under sole occupancy. A delta LARGER than your teardown flatters and is exactly as wrong as
one smaller.

Corollary: a control and a treatment disagreeing is what settled this, per
[[identical-readings-across-opposite-outcomes-indict-the-meter]] — my single sample would not have
outranked the gater's; todlando's independent read is what made it two instruments rather than one
opinion.

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

## 5th face (2026-08-27, mine): the floor step reads as "CI is red on my branch"

Every IO-PARSER thin-lane run showed `conclusion: failure` on GitHub — W4, W5 (the sha doyle had
already PASSED on his own legs) and my docs sha alike. The job breakdown was BYTE-IDENTICAL across
them: traceability/changes/lint/unit-Linux all green, `unit (self-hosted, Windows, hfenduleam)`
failed, and its failing STEP was **"Assert workspace free-space floor (Windows)"** — C: was at
**7.1 GB against the 32 GiB floor**, so nothing ran and there was ZERO test signal in any of them.

Two things make this worth its own face. **The red is attributed to the newest branch by everyone
who looks**, because a failing run sits under your PR — while a control (an already-passed sibling
sha) failing identically is the whole refutation, available in one `gh run view --json jobs` per
sha. And **the box degrades silently between milestones**: nobody watches free space, so the first
symptom is a gate refusing on a lane whose diff cannot have caused it.

⚠ TWO REFINEMENTS FROM deployah, who re-measured this independently rather than relaying it
(2026-08-28). **The load-bearing fact is the STEP LIST, not the timing.** I argued the failures
predate my reclaim by minutes; he argued `Run actions/checkout@v5` is SKIPPED, so **the diff was
never on the box** and the job is structurally incapable of carrying information about the code.
That holds without a clock, and clocks are exactly what a reader disputes. **And the class explains
sibling reds, it does not MEASURE them:** a floor red is satisfiable-or-not per box at a moment, so
each instance still needs its own free-space read — I had written "same class hit every thin-lane
run" in a way that invited inheriting one instance's measurement across all of them. Kin:
[[relay-is-not-the-gaters-word]] — he verified the positive control at the API instead of accepting
my report of it, which is why his confirmation is worth more than an agreement.

Reclaim measured, not claimed: reaped ONE classified target subtree (my own gated lane's, claim
released; real dir not a junction, inbound reparse sweep clean, `CARGO_TARGET_DIR` unset) →
**7.1 GB → 58.2 GB, 51.1 GB reclaimed**. Then the question that actually decides whether the golden
can run: is the RUNNER's pool warm? `C:\actions-runner\_work\...\target` was 54.7 GB, so the golden
builds incrementally and clears the floor — a COLD runner pool would have needed the ~90-112 GB a
full-sweep pool weighs, which 58 GB free does not buy. **Check the runner's own pool before
declaring the floor cleared**; the free number alone answers a different question.

⚠ 6th face 2026-09-07 22:53Z (doyle, W2 re-gate at bccfaee8): free 15 GB -> 6 GB inside the CLAIM leg, and cargo died with `error[E0786] found invalid metadata files for crate spt_daemon ... failed to mmap ... The paging file is too small for this operation to complete (os error 1455)` — the system-managed pagefile could not grow on a near-full C:. Reads as a corrupt rlib / code red; it is the disk's. Same class as LNK1180/LNK1318 (IR-59). Also: the occupant was NOT cargo pools (190 GB) but ~1,000 GB of operator data (Downloads/Videos/x86) — reaping pools cannot fix a floor that pools did not set; escalate with the du numbers.