---
name: ci-runner-has-no-warm-target
description: "golden's runners have NO warm cargo target — every job's actions/checkout runs `git clean -ffdx` and deletes it; the ~50 GiB the test leg rebuilds survives only until the NEXT job's checkout, so a free-space floor read BEFORE checkout refuses over bytes its own next step reclaims."
metadata: 
  node_type: memory
  type: project
  originSessionId: 8cc3808a-4878-4e70-9632-2ed3668002bf
  modified: 2026-08-04T00:22:13.136Z
---

**Measured 2026-08-03, hfenduleam, golden 30860770146.** Two mechanisms, one tree.

**1. There is no warm target.** `actions/checkout@v5` defaults to `clean: true`, which runs
`git clean -ffdx` — and `-x` takes gitignored files, i.e. `target/`. Every job starts by
deleting the previous job's build tree and pays a cold build. Evidence: of 30,022 files in
`C:\actions-runner\_work\spt-bs-core\spt-bs-core\target` (49.92 GiB), **29,777 files / 49.91
GiB carry mtimes inside the test job's own window**, newest 23:47:40Z against a job that
ended 23:48:14Z. Nothing survives from any earlier day. golden.yml's header claims the
opposite ("persistent cargo/target = warm builds … the persistent target dir IS the cache").

**2. The free-space floor is read before the reclaim that would satisfy it.** The ~50 GiB the
test leg materializes is deleted by the NEXT job's checkout — but the twohost jobs' step order
was preflight FIRST, checkout SECOND. twohost-a starts ~3s after the test leg ends, i.e. at
the disk's exact maximum, and refused: `RESOURCE=disk free_bytes=26224361472` (24.4 GiB) vs a
32 GiB floor, no test run. **The reorder alone would have turned that red green with zero
reclaim.** Fixed on the hertz CI-rider lane (doyle-ruled): checkout first, floor second, in
both twohost jobs only; `REQ-CI-FREE-SPACE-PREFLIGHT`'s "FIRST" amended to mean first among
EXPENSIVE steps there.

**Why:** a full-suite Windows leg costs ~50 GiB of scratch, so any disk arithmetic that treats
the runner target as a stable cache is wrong by that amount, in both directions — it neither
persists across runs nor gets cleaned at job end. It also rewrites what IR-2 can even ask:
not "does incremental pay on the warm runner" but "should the runner be warm at all".

**How to apply:** before blaming a resource red on consumption, check WHEN the consumer's
bytes die. Read mtime distribution on the target tree (one `Group-Object` over
`LastWriteTime`) rather than assuming a cache is a cache. And when a gate refuses over a
resource, ask what the next step does to that resource. Residual attribution matters too: the
60.4 GiB consumed during that leg was ~49.9 CI + ~14 GiB of LOCAL agent builds in the same
window (mine at 9.12, todlando's at 5.30) — "no competing consumer" was verified on the
PROCESS axis and was false on the disk axis. See [[free-space-floor-blocks-golden]],
[[hfenduleam-disk-full-ci]], [[quiet-window-predicate]], [[gate-clean-target-not-incremental]].