---
name: reap-subtree-not-session-dir
description: "reap the target SUBTREE, never a session dir — one session can be dead in scratchpad and alive in tasks at once; and deleting a real target orphans every junction aimed at it (inbound links are a separate check from outbound)"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 0241438f-ee37-4144-979e-b5499de58a8e
  modified: 2026-08-02T04:10:18.115Z
---

Two disk-reap rules learned the hard way on 2026-08-01, both about the granularity of a delete:

**1. Never reap a session directory, only the weight inside it.** I attributed two scratchpad sessions
to todlando and wrote "neither is the active session" off the session dir's own mtime. todlando
corrected it: `0251f1c6\tasks` was written by their RUNNING harness while `0251f1c6\scratchpad` had
been idle 20 hours. Verified — tasks mtime 21:00:24 against my check at 21:00:39. The wrong thing was
the INFERENCE (parent mtime as liveness of everything beneath it), not just the fact. Weight lives in
`scratchpad\tgt`-style cargo trees; `tasks\` holds live background-task output. Delete the target
subtree by path, never the parent.

**2. Real-dir-not-junction proves the OUTBOUND question only.** deployah's check (LinkType empty, no
ReparsePoint attr) answers "will my recursive delete follow a link into someone else's tree?" It does
NOT answer "is anything pointing AT what I am deleting?" todlando's leg deleted the real
`doorbell-w4\target`; `doorbell-w5\target` was a junction aimed there and now dangles, so the next
cargo run in that worktree fails on a dead reparse point instead of rebuilding. This is the
delete-junction-before-the-worktree rule running in the other direction. Run both checks: outbound
before deleting, inbound (sweep every `<wt>\target` LinkType+Target under `.worktrees`, flag
`Test-Path $_.Target` false) after.

**Do NOT heal a dangling target junction by re-pointing it at a shared target another worktree is
actively building through** — that is the stale-false-green class, not a repair (todlando's call on
`doorbell-w5`, correcting my offhand "re-junction onto gate-target"). Removing the link and leaving the
worktree with NO target is the right end state: the next cargo run there mints a real one. Re-junction
only onto a target nothing else is currently building through.

**How to apply:** measure before/after, attribute by session-id→`owlery/*/sessions.log`, delete the
target subtree only, then sweep for orphaned inbound junctions and report what broke. Drive-level free
space during a concurrent reap window is a FLOOR, never your own reclaim figure — cite the measured
per-tree sum. See [[scratchpad-target-trees-eat-the-box]], [[worktree-target-junction]],
[[free-space-floor-blocks-golden]], [[session-id-owner-mapping]].