---
name: the-floor-to-read-is-the-one-in-the-job-you-fire-per-os
description: A pre-fire disk-floor check must read the floor VALUE from the job and OS it is about to fire; golden.yml carries 32 GiB on Linux jobs and 128 GiB on the Windows test job, and reading the first one green-lit a run that died at the second.
metadata:
  type: feedback
---

2026-09-22, #318 golden 35686372341 a1 (deployah): my pre-fire check said "C: 47.5 GB free (floor 32 GiB)" and I pushed. The Windows `test` job's `DISK start floor (Windows)` step is `$floorBytes = 128GB`; it read 108.9 GiB after its own reclaim and went RED before any cargo. The 32 GiB I quoted was the Linux `changes` job's floor, the first `floor_bytes` grep hit in the file. Cost: a whole Windows leg + a same-sha rerun, plus the runbook's "pre-fire check reads the DISK FLOOR" memory being CITED and still wrong.

**Why:** "the floor" is not one number. Each job step declares its own, per OS, and the grep that finds "a floor" returns the first one, which is the cheapest job's. A check that passes against the wrong floor is a stale-target check (see [[a-stale-target-makes-a-check-pass-harder-not-fail]]): it manufactures a confident green.

**How to apply:** before a golden push, grep `floorBytes|floor_bytes` in the workflow and list EVERY distinct value with its job name and OS; compare each runner's free space against ITS OWN largest floor. Read the Windows value from the `test` job, not from `changes`. Also: my own `Get-PSDrive` read 47.5 GiB while the runner read 108.9 GiB minutes later because the job's pre-floor reclaim step ran in between; the runner's `FLOOR_START` line is the meter, my reading is a forecast. Related: [[prefire-check-reads-the-disk-floor]].

**Re-hit 2026-09-22 (deployah, #318 golden a1):** my run monitor piped `gh run view --json` into a bare `jq` that does not exist on HFENDULEAM; every poll printed nothing for 60 minutes and the monitor timed out SILENT while attempt 1 finished 30 minutes earlier. Same face as the absent-jq verdict reader in [[a-stale-target-makes-a-check-pass-harder-not-fail]]. Use `gh api --jq` / `gh run view --jq` (built in) and SELFTEST the extractor in the foreground before arming a watcher.