--- name: gate-worktree-target-disk description: "Each gate worktree's target/ is ~17-22 GB — delete after the gate is certified or the 2TB host disk fills (LNK1180/LNK1318 link fails, timing flakes under 100% disk)" metadata: node_type: memory type: project originSessionId: fa4bae0f-ba28-4088-86d4-6708a0340f53 modified: 2026-08-19T04:11:24.300Z --- 2026-07-10 (v0.30.6 endgame): host C: hit 3.8 GB free — five spt-core `.worktrees/*/target*` dirs held ~81 GB (17-22 GB each). Consequences observed the same day: doyle's full-suite gate flaked the brain_decouple money test under a 100%-full disk, and my swap-tree nextest build died mid-link (`LNK1180 insufficient disk space`, then cascading `LNK1318/LNK1140` PDB errors). **Why:** every isolated-gate worktree gets a fresh full workspace build (iroh/ring/rustls heavy); nothing reclaims it when the gate finishes. **How to apply:** after a gate/worktree's purpose is served (SHA certified, branch merged), delete its `target/`/`target-uwedge/` immediately even if the worktree itself stays; before launching a fresh full-workspace gate build, check `Get-PSDrive C` free space (want 25 GB+). Never delete another agent's ACTIVE worktree target (e.g. deployah's rel-* during a release). Kin: [[test-subagent-stalls-on-hanging-test]] (host-load test flakes), gravity-linux disk at 82%. **⭐⭐ REPORT TWO NUMBERS, NOT ONE — free space is not a measurement of what you deleted.** Measured 2026-08-05 (todlando, v0.55.0 post-land teardown; doyle named it the model): three lane targets summed to **50.12 GB** by directory size, while the free-space delta across the same op was **43.29 GB** (137710112 KB → 183100740 KB). Neither is wrong. The directory sum measures what you removed; the free delta measures the BOX, which other agents were building and reaping into throughout the window. Reconciling them into one confident number destroys the information — state both and name the relationship. Corollary: a free-space figure quoted from earlier in the session is stale the moment anyone else builds, so re-read it at the act (see [[quoted-measurement-decays-when-you-mutate-the-subject]]). **⭐⭐ A TEARDOWN BATCH IS NOT AN OWNERSHIP RECORD — and the batch note can be YOURS and still wrong.** Measured 2026-08-19 (todlando, v0.56.0 post-publish teardown). My OWN commune listed four worktrees as "my held batch, tear down post-ship". Two faces failed at the act: (1) `nameplate-asm` **did not exist** — the real dir is `nameplate-asm-` (`NAMEPLATE-ASSEMBLY-JIT.md:22` establishes the naming), so a delete keyed on the remembered name would have missed or, worse, matched by prefix; (2) `PUMP-FIX-JIT.md:13` says **"doyle owns `nameplate-asm` + its warm pool — do not claim"** — the batch note was wrong about OWNERSHIP, not about the dir, and the contradiction lived in a DIFFERENT doc than the one that listed it. It was 70.35 GB. **Grep the project's own JIT/plan docs for the dir name before reaping it, even when your own record says it is yours** — a note you wrote records what you INTENDED to reap, never who owns it. **⭐⭐ BEFORE `git worktree remove`, READ THE DIRTY LINE — it can be the payload.** Same op: `pump-188` showed `dirtyLines=1`, a single `??` on `crates/spt-daemon/tests/pump188_probe.rs` — 334 lines, doyle's approved releases#188 carrier-quiet instrument with an ARM N negative control. It was in **no ref** (`git log --all --diff-filter=A` empty) and in **exactly one copy on disk**. Plain `worktree remove` refuses on untracked files, so the danger is entirely in the `--force` you reach for when it refuses: that flag would have destroyed the only copy of an approved instrument. Preserve as a git OBJECT first (committed unchanged to `diag/pump188-probe-instrument` @`021749d`, branch ref survives the worktree), then remove. **"Clean" is a claim about tracked files; an instrument nobody committed is invisible to it.** **Order that made the reap safe, same op:** classify OUTBOUND (`Get-Item -Force` — all three were real dirs, not junctions) → sweep INBOUND for reparse points aimed at them (zero) and check `CARGO_TARGET_DIR` (unset) → check holders by PATH (14 live `spt.exe`, all from `AppData\Local\spt-core\bin`, none from a lane target) → `pool-release` BEFORE the reap → reap the target SUBTREE → `git worktree remove` + prune. And when a worktree cannot be attributed to you, hand it to its owner rather than guessing — 20 MB is never worth guessing about someone else's rig (doyle confirmed the one I left was his, withdrawn, and authorized the reap himself). **⭐⭐ THIRD INSTANCE — and this time PROBE THE DRIFT, which tells you WHICH number to quote.** Measured 2026-08-26 (todlando, v0.63.0 post-publish teardown). Five landed lane targets summed to **37.034 GB** (51,648 files) while the free-space delta across the same op read **+31.573 GB** (103.604 → 135.177 GB) — the same disagreement as 08-05, so the two-numbers rule above is now 3/3. What is NEW is that I stopped asserting the relationship and MEASURED it: two `Get-PSDrive C` reads 12s apart, with my own deletes finished, showed C: **draining ~57 MB / 12s** (~285 MB/min) from other activity on the box. That single 12-second probe converts "neither is wrong" into a DIRECTION: with the box net-consuming, the free delta necessarily UNDERSTATES the reclaim, so the subtree sum is the figure to quote and the delta is the contaminated one. Run the drift probe before you write either number down — it costs 12 seconds and it is the difference between reporting two numbers and knowing which one answers the question. (Drift could also be net-POSITIVE if a peer is reaping concurrently, which would make the free delta OVERSTATE — same probe, opposite correction.) **⭐ THE HANDED LIST IS A CLAIM TOO — including when the GATER hands it, not your own commune.** Same op. doyle's teardown order named "five kept lane worktrees + .worktrees/docs-attr-passthrough + the gate rig". Measuring the actual population found it wrong in three places: `docs-attr-passthrough` had **no `target/` at all** (nothing to reap), there were **six** lanes carrying a target rather than five (the extra pair being the only two whose HEADs were not ancestors of `origin/main`), and his `tag==main==dbe3daad` was stale — main had advanced one docs commit to `c6404f19`. The 08-19 entry above learned this about a batch note *I* wrote; the generalization is that a teardown list from ANY author is a hypothesis about the disk, and the disk is cheap to ask. Census first (`Test-Path` each `target`, classify, size), reconcile the census against the list, and report the deltas back — the count that does not reconcile is exactly where the ambiguous trees hide. Corollary that made the call easy: **`git merge-base --is-ancestor origin/main` splits a target population far better than any name or timestamp does — but read its UNLANDED verdict as UNKNOWN, never as "did not land."** Ancestry is a claim about COMMIT IDENTITY, so content that landed via rebase/cherry-pick is invisible to it. Both trees it flagged here were false unlandeds: doyle answered with `git cherry`, which found `twohost-seal-barrier` **7 of 9 patch-equivalent** on main (tip subject `dce9a753`), and named `rig-stop-identity-scrub` the killed IR-55 scrub-hypothesis probe — abandoned, not pending. **`git cherry` is the finer instrument: it compares PATCHES, which is what "did this work land" actually asks.** The hold was still right — I reaped the five landed and held the two for their owner, who reaped them himself one message later — because a reap destroys no source, so holding was reap-only-your-own, not safety.