# Target census, HFENDULEAM 2026-09-12 ~07:09Z — and what it does NOT establish hertz. Taken to answer one question doyle asked: whether I own a live dependency on `asm-304-w2/target` or `304-fold-admission/target` that a reclaim would destroy. **No reclaim is proposed by me and none is mine to authorize. No worktree removal is proposed by anyone — target SUBTREES only.** ## Measured | path | classification | size | |------|----------------|------| | `.worktrees/asm-304-w2/target` | REAL DIRECTORY, not a reparse point | 50.26 GiB | | `.worktrees/304-fold-admission/target` | REAL DIRECTORY, not a reparse point | 46.23 GiB | | `.worktrees/304-w2-repr/target` | REAL DIRECTORY, not a reparse point | 7.25 GiB (the WARM pool the combined gate needs) | | `.worktrees/hertz-integ/target` | **ABSENT** | — | | `.worktrees/hertz-arm1/target` | **ABSENT** | — | `CARGO_TARGET_DIR` unset in my session. Method: `Get-Item -Force` for the reparse-point attribute (a junction must be deleted as a link, a real directory as a tree), recursive file sum for size. `POOL-OWNER.json` present in all three pools, each naming its OWN worktree as `owner_tree`, `written_by: spt-poolguard`. Non-build file at a target root: `asm-304-w2/target/a7-rollout-state.json` — not a cargo artifact, and a target reap takes it. The other two targets have none. ## My dependency: NONE, and the reason is structural Both of my worktrees have no target at all — I have built nothing. My only dependency on `asm-304-w2` is its COMMIT: the 5b regression controls restore the pre-fix comparison with `git show 921aa68f:`, which reads the object database. `921aa68f` is held by four refs (`build/304-w2-field-seed`, `fix/304-w2-representation-compare`, `test/304-w2-arm1-render`, `test/304-w2-observed-spelling-cells`), so it does not depend on that worktree or its target existing. ## WHAT THIS CENSUS DOES NOT ESTABLISH (doyle, 2026-09-12 — read this before citing it) 1. **It clears MY ownership slice only.** "hertz owns nothing here" is not "nothing is owned here." 2. **`POOL-OWNER.json` establishes SOURCE-TREE OWNERSHIP, not the absence of other consumers.** It names which tree the pool belongs to. It says nothing about a process holding a handle right now, a build in flight, or another agent mid-lane. A pool can be self-owned on disk and busy in fact. 3. **The inbound clearance is SCOPED TO `.worktrees`, two levels deep.** A reparse point living anywhere else on this box could still aim at these targets and my sweep would not have seen it. I measured the directory tree I named and no more. 4. Size figures are a nominal sum of file lengths, not an on-disk allocation, and not a promise of how much free space a reap returns. ## Correction to my own probe, kept rather than deleted My first pass looked for `.spt-pool-claim.json` and reported "no claim" for all three pools. That filename does not exist — the record is `POOL-OWNER.json`. A clean zero from a guessed predicate is the same dead-instrument shape I have been reporting all morning, and it read as evidence for the minute before I checked the writer. The corrected reading is above. ## Pre-reclaim baseline, for todlando's receipt (taken 2026-09-12T07:11:42Z) doyle authorized the reclaim to todlando within the two named subtrees. AGENTS.md requires the reclaim be a NUMBER rather than a claim -- size and free space before and after -- so the "before" half is recorded here, timestamped, from the box itself: C: free = 34.02 GiB, used = 1828 GiB .worktrees/asm-304-w2/target 35063 files, 50.26 GiB nominal .worktrees/304-fold-admission/target 29430 files, 46.23 GiB nominal Nominal sums of file lengths, not on-disk allocation: the freed number will not match them exactly, and the AFTER reading is what settles it. The 96 GiB producer floor needs ~62 GiB recovered from this baseline; the two subtrees are 96.49 GiB nominal, so clearing the floor is plausible from these two alone but is NOT established until the after-reading exists. ## After the reclaim — verified independently, not relayed (2026-09-12T07:15:55Z) todlando reported the receipt; a peer reporting a number is CONTEXT, so this is my own reading of the same box: C: free = 124.49 GiB (his figure: 124.49 — agree exactly) .worktrees/asm-304-w2/target ABSENT .worktrees/304-fold-admission/target ABSENT .worktrees/304-w2-repr/target PRESENT, 7369 files, 7.25 GiB — the WARM pool the gate needs, unchanged in size from the pre-reclaim reading Both WORKTREES still present: only the target SUBTREES were removed, which is the scope doyle set. Delta: 34.02 -> 124.49 GiB free, i.e. 90.47 GiB recovered against 96.49 GiB nominal. My nominal-is-not-freed warning held: a ~6 GiB allocation gap, and the AFTER reading is what settled it, exactly as the before-half could not. **The 96 GiB producer floor is cleared by 28.49 GiB.** That is a measurement, not an admission: the combined-gate admission is doyle's and is still outstanding. ## One consequence for the twohost plan, from todlando's receipt The live release cache now holds the v0.69.0 PRODUCTION set (version 105, artifact `689503ad…`, 38072832 bytes, matching this node's LAN banner). A7's debug set has been REPLACED, and the A7 attested exe (`e99a352c…`, 38388224 bytes) existed in exactly one place — the deleted subtree — where todlando preserved it with its pdb and re-hashed it after the delete. For the field plan this changes nothing structural and one assumption: the isolated-home preparation (debug-keygen / debug-pin / debug-rollout / debug-mark-applied) was always going to run fresh against whatever exe the rig actually runs, so §D3 stands. What is now FALSE is any notion that a staged debug set survives in the live home to be reused — it does not, and a rig that assumed it would meet `LAN_BOOTSTRAP_REFUSED:set-not-applied`.