@@ -14,7 +14,30 @@ Copy everything below the line into a fresh session started in
 
 **This block is the live state. Update it after every task.** Everything below the next `---` is the older hand-over and is background. (Rewritten ~10:45 UTC; the earlier, longer version of this block is in git history — `git log -p NEXT_SESSION_PROMPT.md`.)
 
-### LATEST (27 Sep 2026, ~01:15 UTC, session 38ea1b2d) — RESUME HERE
+### LATEST (29 Sep 2026, ~06:40 UTC, session 129272e7) — RESUME HERE
+
+**This session resumed after session 38ea1b2d stopped abruptly (27 Sep ~17:36 UTC, right after T12e's gate went green).** Everything it built was found intact; nothing was lost.
+- **The owner pushed `767d346` (T10 and its fixes). CI run 36524222262:** macOS, Linux and Linux pt-BR GREEN; Windows green but for R96's worker probe, which now said how it died: exit code 3221225477 (0xC0000005, an access violation) after its stderr "the worker thread answered 0.5.0; terminating it".
+- **R96 root-caused and fixed (`9a8d76f`).** Node's `Environment` destructor closes every addon the environment loaded (`binding::DLib::Close`, read off Node 24.16.0's own binary); on Windows that is `FreeLibrary`, which unmapped a DLL the worker alone held while its teardown still called into it. tm-node pins itself as it is loaded (`crates/tm-node/src/pin.rs`, `GetModuleHandleExW` with `GET_MODULE_HANDLE_EX_FLAG_PIN`, from napi-derive's `module_init`). The probe also runs the app's own order (`mainFirst`). **The proof is this push's Windows leg: the worker-only probe must pass** (red without the pin in runs 36282411813 and 36524222262).
+- **The owner answered a third round (28 Sep; memory `treemap-owner-grants`):** Q1 yes (TreeMap may unlink its own spill files inside `<appData>/scan-spill`), cargo-mutants may be installed (v27.1.0 is), Q5/Q6/Q10/Q13 accepted, Q16 yes (open the installed app once, throwaway profile). Pushing stays the owner's: `gh` is signed in here, but the 25 Sep rule "you never push" stands.
+- **This push carries, each commit gated green (committed tree == gated tree; logs in the session scratchpad and `treemap-scratch-tools/session-129272e7/`):**
+  - T11 `4f2a0bd`, T12a `da5dd5c`, T12b `4895dd1`, T12c `e53de2d`, T12d `002f9d7`, T12e `6db8386` — the candidates session 38ea1b2d gated, landed as they were (their parent chain starts at `767d346`). T10's CI (3 legs green, Windows red only on R96's harness probe, which T10 does not touch) is the gate the plan asked for before T11.
+  - `379c0bf` **the live index's FSEvents churn** (the known "watch that attaches and says nothing"): libuv on macOS serves every `fs.watch` from one FSEventStream rebuilt "since now" on every attach and close, so another watch starting or stopping lost events for the rest. `src/platform/watchRegistry.ts` now owns every `fs.watch`; on macOS the other live roots go stale with a reason the badge shows; a rebuild holds its watch and Live mode shares the index's, so ordinary use no longer churns; the three live-watch test files prove a watch live before writing (0 self-skips in 14 stress rounds, 5 in 8 before). 38 mutants.
+  - `9a8d76f` R96 (above).
+  - `327dcf5` the throttle's tests count the rests it asks for (`setThrottleClockForTests`) instead of timing real sleeps — they failed a gate at load 57–112 while the throttle was right.
+  - `d827ffa` **T15a**: `tm-store/src/select.rs`, `select_prune` and `select_treemap`, byte for byte the JavaScript's selections on 3,898 oracle cases (`tests/fixtures/selectOracle.ts` writes `select-oracle.tsv`); notes for T15b in `treemap-scratch-tools/session-129272e7/notes-T15b.md`.
+  - `ba04a2b` T13a (spill files unlinked at creation), `7998b76` T13b (`spill_plan` and the ledger), `4094ea2` T13c (the boot sweep's one confined remover, `src/services/spillSweep.ts`; boot wiring is T17's; SECURITY.md lists `scan-spill`, which the gate caught missing), `776460f` T13's review round (Windows holds scan-spill open; FAT/exFAT spill again; **RISKS R97: on Windows a spill file keeps its name while open, so T17 must keep the walk out of scan-spill**).
+  - `4021e66` a snapshot's mount point is removed with `rmdir`, never recursively (it walked into a snapshot that had not come off), and a mount that stays is said.
+  - `bfce16a` the delete guard ("nothing outside Cleaner removes a user file") reads all of src/ and electron/ and sees `…Sync` and by-name-imported removals; each newly seen removal was read and is a named entry with its reason.
+- **Next, in order:**
+  1. Read every CI leg of this push (`watch-ci.sh`, base `767d346`); the Windows worker probe must pass.
+  2. `cargo mutants` over `tm-store/src/aggregate*` (T12's gate item) is PAUSED at 227/402 (`kill -CONT` its pid, or rerun). 23 survivors so far; triaged in part: `WorstFolder`/`Worst` `eq` and `size_bucket`'s `||` are equivalent; `Kept::clear`, `finish → Ok(())`, the `summary` guard, the zero-byte family rule, `merge`'s rank flag and `folders_answer`'s guards need tests → a T12f commit.
+  3. T13d (the link log's 32 MiB resident cap and disk runs), then T14 (SpillSink), T15b, T16–T23; then Phases 5–8 (ask each phase's open questions at its start).
+  4. Q16: measure E0 in the installed app once (throwaway profile, only while the owner is not using TreeMap).
+  5. Found, not yet done: `rustdoc -D warnings` fails on `tm-store/src/memory.rs:77` (pre-existing); the sweep would keep a Docker PID-1 leftover forever (T17's design); three live-disk tests still hold wall-clock bounds.
+- **Lesson (memory `count-dont-time-ci-tests` family):** never run several `cargo mutants` jobs, agents and a gate at once — at load 112 the governor's hold test and the old throttle test failed a gate the code did not deserve. Gates run alone.
+
+### Earlier: 27 Sep 2026, ~01:15 UTC, session 38ea1b2d
 
 **Newest (27 Sep, ~01:15 UTC): T10 BUILT — `9f59e5c` (T10a, pushed) and `5945a96` (T10b). S2 is complete. Two fixes on top: `bbb93a8` and `8fc8884`. The owner is asked to push.**
 - **The owner pushed `9f59e5c` (T10a). CI run 36282411813:** macOS, Linux and Linux pt-BR GREEN. Windows: 2 failures in `tests/benchMemoryPath.test.ts`, the worker-thread probe ("the measuring process wrote no result: ", nothing on stderr) and the matrix command that includes it.
 
@@ -9,7 +9,7 @@
 | Plan written | 18 Sep 2026 | this file |
 | S1 `tm-store`: the finalized store built in Rust, in the packed store's own layout | **done 24 Sep 2026**, commit `2415d6c`, committed after Phase 3's CI went green (run 36069755180): 41 tests, 89 mutants red, clippy on three targets, rustdoc `-D warnings`. The six-lens review's 29 CONFIRMED findings are all fixed (index mix-ups pinned with walks whose order differs from the store's; cloud × hard-link order; side tables refused unless strictly ascending, then binary-searched; `sparse_terms` so Node sums `sparseBytes` in the ingest's order past 2^53), and a second review of the fix round confirmed 6 more, repaired | `native/treemap-core/crates/tm-store/`; `docs/superpowers/plans/2026-09-24-phase4-s1-review-findings.md` |
 | S2 `PackedScanStore.fromColumns` + the native engine reads the Rust store through views (no ingest copy) | **done 27 Sep 2026** with T10 (`9f59e5c`, `5945a96`): every native scan walks through the memory store. The Node side was done 24 Sep 2026, commit `38469ee`: `PackedScanStore.adoptColumns` (the `fromColumns` above) adopts a finalized tree's columns in place, held to the object-store oracle on 96 random trees; 20 mutants, 19 red, the survivor explained in the code. T1–T10 built the rest (§S.9) | `src/services/scanStore.ts`; `tests/packedStoreAdopt.test.ts`; `tests/fixtures/storeFuzz.ts` |
-| S3–S5 as designed (§S below) | **designed 24 Sep 2026.** T0 (documents only) is written; its gate (§S.9) is the owner's answers to Q1–Q5 and Q7 (§S.11): ~~Q1, Q3 and Q5 wait for the owner~~ ~~Q1 and Q5 wait for the owner~~ Q5 waits for the owner (Q3 decided by the owner 25 Sep 2026: the 10M row is met by spill, memory mode up to 5M; Q1 decided by the owner 28 Sep 2026: yes, TreeMap may `unlink` its own spill files inside `<appData>/scan-spill`), and Q2, Q4 and Q7 are engineering decisions awaiting the owner's confirmation. T1–T6, T6b, T6c, T7 and T8 built 25–26 Sep 2026; T9 measured 26 Sep 2026, and its findings added T9b and T9c, built 26 Sep 2026 with T10; T11 and T12a–T12e built 25–27 Sep 2026 (T12e all but its `cargo mutants` run), T15a (the selection ports) and T13a–T13c (the spill file, `spill_plan` and the ledger, the sweep and the confined remover) 28 Sep 2026; T13d, T14, T15b and T16–T23 are not built | §S below |
+| S3–S5 as designed (§S below) | **designed 24 Sep 2026.** T0 (documents only) is written; its gate (§S.9) is the owner's answers to Q1–Q5 and Q7 (§S.11): ~~Q1, Q3 and Q5 wait for the owner~~ ~~Q1 and Q5 wait for the owner~~ ~~Q5 waits for the owner~~ (Q3 decided by the owner 25 Sep 2026: the 10M row is met by spill, memory mode up to 5M; Q1 decided by the owner 28 Sep 2026: yes, TreeMap may `unlink` its own spill files inside `<appData>/scan-spill`; Q5, Q6, Q10 and Q13 decided by the owner 28 Sep 2026: the proposals are taken, §S.11), and Q2, Q4 and Q7 are engineering decisions awaiting the owner's confirmation. T1–T6, T6b, T6c, T7 and T8 built 25–26 Sep 2026; T9 measured 26 Sep 2026, and its findings added T9b and T9c, built 26 Sep 2026 with T10; T11 and T12a–T12e built 25–27 Sep 2026 (T12e all but its `cargo mutants` run), T15a (the selection ports) and T13a–T13c (the spill file, `spill_plan` and the ledger, the sweep and the confined remover) 28 Sep 2026; T13d, T14, T15b and T16–T23 are not built | §S below |
 | S3 spill mode: columns written with `write()` ~~then mapped~~ and read with `pread()` (P4-5a), the free-space and same-volume rules, cleanup | in progress: T11 built; T13a–T13c (the spill file, `spill_plan` and the ledger, the sweep and the confined remover) and T15a (the selection ports, `select_prune` and `select_treemap`) built 28 Sep 2026; T13d, T14, T15b, T16 and T17 not built (T17 commits S3); the FullPassRunner is S3b, T18 | `native/treemap-core/crates/tm-store/src/spill.rs`, `spill/plan.rs`; `src/services/spillSweep.ts`; `tm-store/src/select.rs`; `tests/fixtures/selectOracle.ts` |
 | S4 aggregate-only mode: ~~directory rows~~ rows kept by the β rule (P4-7a), running totals, top-K, the notice naming what is off | in progress: T12 (the AggregateState, which spill runs too) built as T12a–T12e 27 Sep 2026, all but T12e's `cargo mutants` run; T19 (commits S4) and T20 (Windows large mode) not built | `tm-store/src/aggregate/` |
 | S5 the synthetic-source gate: 100M entries from a scripted lister through the walk and the store, peak RSS measured by the harness | not started: T3 (the `SyntheticLister`, moved forward), T21 (bench plumbing), T22 (the gate) | |
@@ -1416,29 +1416,29 @@ Each question's status was recorded on 24 Sep 2026 (T0).
 4. **Q4 — additive API fields.** Is `FileNode.omitted` (aggregate only) plus a `notKept` answer on `/nodes` and the facts acceptable under §11.1, which allows additions only?
    - **Status: engineering decision, 24 Sep 2026, the owner may overrule.** As proposed: `FileNode.omitted` is added in aggregate only, and `/nodes` and the facts answer `notKept`. Both are additions; the memory-mode goldens do not change.
 5. **Q5 — Live mode and container expansion.** Should they be off in spill and aggregate for Phase 4?
-   - **Status: engineering proposal, pending the owner.** Live mode and container expansion are off in spill and aggregate, and the notice names them (P4-6a, §S.7).
+   - **Status: decided by the owner on 28 Sep 2026 — the proposal is taken.** ~~Engineering proposal, pending the owner.~~ Live mode and container expansion are off in spill and aggregate, and the notice names them (P4-6a, §S.7).
 6. **Q6 — the FullPassRunner.** Must it land inside Phase 4 (S3b, proposed)? And may the per-node-state features stay off in spill until they are ported to native code?
-   - **Status: engineering proposal, pending the owner.** The FullPassRunner lands inside Phase 4 (T18, commit S3b). The features whose JavaScript state grows per node stay off in spill until they are ported to native code (§S.5.7).
+   - **Status: decided by the owner on 28 Sep 2026 — the proposal is taken.** ~~Engineering proposal, pending the owner.~~ The FullPassRunner lands inside Phase 4 (T18, commit S3b). The features whose JavaScript state grows per node stay off in spill until they are ported to native code (§S.5.7).
 7. **Q7 — the cloud rule.** Is one table shared by `cloudFolders.ts` and Rust acceptable, with memory mode keeping P4-3's Node pass?
    - **Status: engineering decision, 24 Sep 2026, the owner may overrule.** One table (`CLOUD_RULES`, T11) builds the regexes in `cloudFolders.ts` and feeds the Rust matcher; memory mode keeps P4-3's Node pass (P4-3a).
 8. **Q8 — the queue.** Do you accept the hybrid FIFO→LIFO queue (`Q_MAX` 65,536 in memory mode, 4,096 in the large modes), with a re-bench?
    - **Status: engineering decision, 24 Sep 2026, the owner may overrule.** The hybrid FIFO→LIFO queue, `Q_MAX` 65,536 in memory mode and 4,096 in the large modes (P4-13), re-benched against the Phase 3 baselines (T22: within 10%).
 9. **Q9 — the hard-link winner.** Keep today's breadth-first-first member (proposed, byte-identical)? Or adopt the digest's smallest-path rule, which changes native output for families that span folders?
    - **Status: engineering decision, 24 Sep 2026, the owner may overrule.** Today's breadth-first-first member stays the winner (P4-2a), so native output does not change. The digest's smallest-path normalisation (DESIGN §16 item 6) is untouched.
 10. **Q10 — no legacy fallback above `T_mem`.** A native failure there fails the scan with its reason (P4-14). How does that interact with step 2's open question about the native scan falling back under full CPU load?
-    - **Status: engineering proposal, pending the owner.** No legacy fallback in spill or aggregate or above `T_mem` (P4-14): a native failure there fails the scan with its reason. Step 2's question was answered by the owner on 24 Sep 2026 (commit `298d752`, RISKS R56): a native walk's 30 s stall clock counts only time in which the machine had CPU to spare. Under P4-14, a walk that rule cancels above `T_mem` fails the scan with that reason instead of falling back.
+    - **Status: decided by the owner on 28 Sep 2026 — the proposal is taken.** ~~Engineering proposal, pending the owner.~~ No legacy fallback in spill or aggregate or above `T_mem` (P4-14): a native failure there fails the scan with its reason. Step 2's question was answered by the owner on 24 Sep 2026 (commit `298d752`, RISKS R56): a native walk's 30 s stall clock counts only time in which the machine had CPU to spare. Under P4-14, a walk that rule cancels above `T_mem` fails the scan with that reason instead of falling back.
 11. **Q11 — prune's giant-folder behaviour (R-S10).** Keep it, or stop before a folder whose children would pass `maxNodes` by more than X and mark it `pruned`? That second option is a JSON change only for such folders.
     - **Status: engineering decision, 24 Sep 2026, the owner may overrule.** Phase 4 keeps today's behaviour: `select_prune` reproduces `pruneStore` exactly, every child of a popped folder included (§S.5.5), so no JSON changes. R-S10 (RISKS R82) stays open, and the gate's big-listing variant keeps that folder small in bytes.
 12. **Q12 — aggregate's weaker lists.** Is `exact:false` with a reason acceptable, rather than refusing the list?
     - **Status: engineering decision, 24 Sep 2026, the owner may overrule.** An aggregate answer the seal cannot prove exact carries `exact: false` with the reason instead of being refused (P4-16). In spill such an answer is recomputed (§S.5.6).
 13. **Q13 — Windows timing.** Must Windows large mode (T20) land inside Phase 4? The DoD's "Tier C" wording implies it does.
-    - **Status: engineering proposal, pending the owner.** Windows large mode (T20) lands inside Phase 4, proven at CI-fixture scale on the Windows leg.
+    - **Status: decided by the owner on 28 Sep 2026 — the proposal is taken.** ~~Engineering proposal, pending the owner.~~ Windows large mode (T20) lands inside Phase 4, proven at CI-fixture scale on the Windows leg.
 14. **Q14 — which shapes gate.** Does the developer shape (15% folders) gate, with the wide, dirheavy, links, windows and candidates variants gated too? Or should some only be recorded?
     - **Status: engineering decision, 24 Sep 2026, the owner may overrule.** The developer shape gates, and so does every §S.8 variant.
 15. **Q15 — the storage endpoint.** Is a separate `/api/scan/:id/storage` acceptable, so the `sseComplete` golden stays unchanged?
     - **Status: engineering decision, 24 Sep 2026, the owner may overrule.** A separate `GET /api/scan/:id/storage`, so the `sseComplete` golden stays unchanged (§S.6.5).
 16. **Q16 — E0 in the app itself.** T9 measured E0 in the installed app's binary run as Node (107 MB). Run that way it does not start Chromium's browser side, which the app's main process also runs. May the installed TreeMap be opened once, for about a minute, with a throwaway data folder and nothing of the owner's, so that its main process's memory can be read?
-    - **Status: asked 26 Sep 2026, pending the owner; recommended yes.** Until then, E0 is a lower bound.
+    - **Status: decided by the owner on 28 Sep 2026: yes, once.** ~~Asked 26 Sep 2026, pending the owner; recommended yes.~~ The installed app is opened once, for about a minute, with a throwaway profile (a temporary `TREEMAP_DATA_DIR` and Chromium `--user-data-dir`), only while the owner is not using TreeMap. Until that measurement is recorded, E0 is a lower bound.
 17. **Q17 — T9's gate.** 5M passes 700 MB in both runtimes, because sending the first tree costs +680 MB (Node) and +325–410 MB (Electron) whatever the scan's size (T9's entry). The two ways forward:
     - keep `T_mem` at 5M in both runtimes, and build T9b (the tree sent from the store, byte for byte today's) and T9c (Electron's hand-over off the JavaScript thread) before T10, measuring again after them;
     - or lower `T_mem` now: Electron to 2M, while Node has no size that meets 700 MB.