@herbertgao/pi-extensions 2026.8.4 → 2026.8.5

package/node_modules/pi-lens/CHANGELOG.md

@@ -8,8 +8,1513 @@ All notable changes to pi-lens will be documented in this file.
 
 ### Changed
 
+### Deprecated
+
+### Removed
+
 ### Fixed
 
+### Security
+
+## [4.0.0] - 2026-08-14
+
+### Added
+
+- **Bounded LSP pull-failure telemetry and lifecycle test seams (refs [#1292](https://github.com/apmantza/pi-lens/issues/1292), items 1 and 3)** — advertised diagnostic-pull failures retain the latest ten operational failures and surface through LSP status, while unsupported `-32601` responses remain unreported; focused coverage exercises acquisition races, descendant cleanup, shutdown protocol races, and honest push fallback. Strategy-gated `didSave` (item 2) remains out of scope.
+
+- **Occupancy and CPU-budget tests stay in the timing-sensitive Vitest project (refs [#1230](https://github.com/apmantza/pi-lens/issues/1230), [#1081](https://github.com/apmantza/pi-lens/issues/1081))** — a meta-test derives the expected membership of `timingSensitiveInclude` from the tests themselves (importing `measureMaxSyncBlockMs` from the perf harness, or calling `process.cpuUsage`) and fails if such a test lands outside the project, so the quiet phased measurement window can't silently drift. It reads the real config object rather than its source text (a commented-out entry is a removal, not a match), and rejects include entries whose file no longer exists so a rename can't leave a dead glob behind. The six sampler tests that had already drifted out are phased back in.
+
+- **Claude Code `Stop` hook drives the per-turn pass ([#538](https://github.com/apmantza/pi-lens/issues/538))**. `pi-lens-analyze` gains a warm-server-only turn-end mode (`--turn-end`, or a `Stop` payload on stdin) that runs incremental knip/madge, dependency checks, tests, and actionable-warning aggregation without an explicit `pilens_turn_end` call. PostToolUse records edited files in workspace turn-state and clears inherited pi session stamps before Stop consumes it. The tagged request shares the one-shot workspace IPC endpoint and build-staleness gate with warm analysis. A server-side FIFO orders every analyze and turn-end request, so a timed-out hook cannot let Stop overtake analysis still running in the server or race another turn-end. Missing or incompatible warm servers produce one reason-specific line on stdout and stderr and exit 0 (see the turn-end residuals entry below). `SubagentStop` stays excluded because its edits already feed the shared worklist.
+- **Generic read-recording bridge for co-process extensions ([#1265](https://github.com/apmantza/pi-lens/issues/1265))** — `clients/read-bridge.ts` mounts a `ReadBridge` object at `globalThis[Symbol.for("pi-lens:read-bridge")]` after the runtime initialises. Any co-process Pi extension whose custom tool performs file reads outside pi-lens's normal tracking can call `bridge?.recordRead({ filePath, requestedOffset, requestedLimit })` so that a subsequent `edit` on the same file is not blocked by the read-before-edit guard. The bridge is an advisory, trust-based protocol — it stamps the timestamp itself (`Date.now()`) matching the internal read path, and validates that `filePath` is a non-empty string and offsets/limits are finite positive integers. The bridge respects `no-read-guard`, gitignored paths, and external/vendor paths (consistent with the bash read-guard gate). Registration is a factory-scoped singleton (`_readBridgeRegistered` guard, same pattern as `_turnSummaryEmitRegistered`); `_readBridgeGetFlag` is refreshed on every factory activation so flag changes take effect immediately. Absent bridge is safe — producers guard with `bridge?.recordRead()`.
+
+- **tflint respects the project's linter policy (refs #1117)** — every other
+	dispatch runner gates on `getLinterPolicyForCwd` before spawning; tflint was
+	the one that never consulted it, so a project that elected a different
+	terraform linter got tflint's findings on top of its own. It now skips when
+	policy does not prefer it, matching golangci-lint and terragrunt. A project
+	`.tflint.hcl` is also an explicit opt-in, so `hasTflintConfig` promotes the
+	`.tf`/`.tfvars` policy from `smart-default` to `config-first` the same way
+	`.golangci.yml` does for Go. tflint ships built-in rules and still runs
+	unconfigured, so the no-config default is unchanged. `hasTflintConfig` takes
+	the edited file's directory rather than the project cwd, so it agrees with
+	what the runner hands tflint: keyed off cwd it would miss every `.tflint.hcl`
+	living in a terraform subdirectory, which is the common monorepo layout.
+- **tflint honors a repo-root `.tflint.hcl` (refs #1117)** — tflint resolves
+	`.tflint.hcl` from its own working directory and never walks parents (its only
+	fallback is `~/.tflint.hcl`), and the runner spawns it from the edited file's
+	directory. A config at the repo root therefore governed nothing beneath the
+	root: every module under `modules/` or `envs/` was linted with tflint's
+	built-in defaults, silently. The runner now walks up for the nearest
+	`.tflint.hcl` (via `findNearestDirWithAnyBasename`, so the same home-guarded,
+	depth-capped, mtime-invalidated walk every other marker lookup uses) and
+	passes it as `--config`. Skipped when `TFLINT_CONFIG_FILE` is set, since
+	`--config` outranks the env var in tflint's own precedence and would override
+	a deliberate choice. A `.tflint.hcl` that declares an uninitialized plugin
+	makes tflint exit non-zero with empty stdout, which the guard fix above turns
+	into a SKIPPED rather than a false clean.
+- **Terragrunt linting and formatting** — `terragrunt.hcl` and `root.hcl` now
+	get a dedicated `terragrunt` file kind (filename-detected only; a plain
+	`.hcl` file stays unmapped). New `terragrunt` dispatch runner wraps
+	`terragrunt hcl validate --json`, and a `terragrunt-hcl` formatter wraps
+	`terragrunt hcl fmt`. Terragrunt has no LSP, so it's runner/formatter only.
+	The `terragrunt` binary installs the same way as tflint (GitHub release,
+	bare per-platform binaries). Also added `.tf` (Terraform) to the
+	`trivy-config` runner's `appliesTo`, gated behind the existing
+	`trivy.enabled` opt-in — terragrunt itself stays excluded from trivy, since
+	trivy evaluates the Terraform language, not terragrunt config. The two
+	entrypoint filenames live in one exported `TERRAGRUNT_FILENAMES` constant
+	(`clients/file-kinds.ts`, same single-source-of-truth pattern as the .NET
+	root markers), consumed by kind detection, both tool policies, the formatter,
+	and the project/root markers; `tests/clients/terragrunt-filenames.test.ts`
+	derives its cases from that list, so a call site that hand-copies it and
+	misses a name fails CI. Diagnostic ids carry line, column, and a normalized
+	message slug (the actionlint shape), because `hcl validate` reports no rule
+	code: a line-only id collapses two findings at one position in the
+	dispatcher's dedupe (keyed `filePath:line:column:defectClass:rule||id`) and
+	hides a changed finding from delta mode, which keys on `id` alone.
+	Diagnostics are attributed by resolving `range.filename` against the unit
+	directory and comparing through `pathsEqual`, not by basename: a unit that
+	pulls in its parent via `find_in_parent_folders()` gets diagnostics from a
+	parent `terragrunt.hcl` whose basename matches the edited file's but whose
+	line numbers belong to another file.
+- **Smells self-surfacing (refs #1123 item 3)** — `scripts/analyze-pi-lens-logs.mjs`
+	(`npm run logs:smells`) already catalogues a wide set of operational smells,
+	but it's MANUAL: the #1123 investigation found 20 stale-ctx `emit_failed`
+	rows and 37 opengrep respawns sitting unread in logs for days until an audit
+	went looking. `clients/smells-rollup.ts` adds a small ALWAYS-ON rollup
+	covering the two smells the issue named, without touching every producer of
+	the underlying logs and without re-scanning the size-rotated (up to ~10MB,
+	`clients/log-cleanup.ts`) `~/.pi-lens/*.log` files on the `session_start`
+	hot path. **Design + cost bound:** a BOUNDED TAIL READ — at most 64KB from
+	the end of `bus-events.log` and `latency.log` each (~128KB total I/O per
+	check, enforced by construction via a single sized `fs.readSync` at a
+	computed offset in `tailReadText`, never a full-file scan) — counts
+	stale-ctx `emit_failed` rows (`outcome === "emit_failed"` with an `error`
+	containing the SDK's `"stale after session replacement"` fragment,
+	`session-lifecycle.ts`'s documented benign-but-worth-watching class) and
+	opengrep respawns (`phase === "lsp_server_respawn"` with
+	`metadata.serverId === "opengrep"`, `clients/lsp/index.ts`'s existing,
+	unmodified respawn log point). Because both source logs are append-only
+	NDJSON, the tail is always the most recently written activity, so the same
+	bounded read serves as both the cross-session glance and a live/this-session
+	proxy — no separate write-time counters were added at the producer call
+	sites (kept the change to one new module + three call sites). Both counts
+	are gated by trivial threshold constants (`SMELLS_THRESHOLDS`, currently 5
+	each) so a single stray event never surfaces. Three surfaces: one
+	`session_start` line (only emitted when a threshold trips, via
+	`runtime-session.ts`'s `emitSmellsSessionStartLine`), an always-on compact
+	`/lens-health` line (current counts regardless of threshold, matching
+	#1123 item 2's `formatMemoryHealthLine` style), and a `turn_end` note —
+	re-checked every 20 turns (`shouldCheckSmellsThisTurn`), `ctx.ui.notify`d
+	at most ONCE per smell per session (`checkSmellsAndNoteOnce`'s gate,
+	re-armed by `resetSmellsSessionState()` at the next `session_start`).
+
+	New tests: `tests/clients/smells-rollup.test.ts` (tail-scan cost bound
+	proven by construction — a file far larger than the byte budget only ever
+	yields tail content; threshold gating for both the session_start line and
+	the always-on health line; the once-per-session notify gate) and
+	`tests/index-smells-rollup-wiring.test.ts` (turn_end wiring: nothing before
+	the check interval, one notify at the trip turn, no repeat notify on the
+	next check turn for an already-notified smell) — fail-then-pass verified
+	against a deliberately broken threshold gate.
+
+- **Oxfmt formatting support for Svelte (refs #1134)** — `.svelte` is now a
+	recognized oxfmt extension, gated by a stricter conditional than oxfmt's
+	other extensions. Empirically verified against the real `oxfmt` npm
+	package (0.62.0, scratch fixture outside vitest, per this repo's
+	verify-the-CLI-contract-empirically rule): oxfmt requires BOTH the
+	`svelte` package installed AND the config's `svelte: true` flag enabled —
+	either alone exits non-zero ("excluded by ignore rules" or "Cannot find
+	module 'svelte/compiler'"), only both together format the file. The new
+	`hasOxfmtSvelteConfig` (`clients/tool-policy.ts`) encodes this, consulted
+	only for `.svelte` in `formatters.ts`'s `hasExplicitFormatterConfig` — the
+	other oxfmt extensions are unaffected. **Class fix**:
+	`oxfmtFormatter.extensions` (`clients/formatters.ts`) and
+	`OXFMT_SUPPORTED_EXTENSIONS` (`clients/tool-policy.ts`) were two
+	hand-maintained parallel lists (the #883 single-source-of-truth class);
+	`OXFMT_SUPPORTED_EXTENSIONS` is now exported as the sole source of truth
+	and `oxfmtFormatter.extensions` derives from it directly, plus a drift-guard
+	test asserting they stay equal. `docs/language-coverage.md`'s Svelte row now
+	reports the formatter and its gating condition instead of "—". The real
+	format-smoke fixture (`tests/fixtures/format-smoke/`) was NOT extended: no
+	fixture in that harness has a dependency-install step (oxfmt itself is only
+	found via a global `which` lookup, not `ensureTool`), so a svelte fixture
+	would either always skip (oxfmt unavailable) or, worse, hard-fail with a
+	"Cannot find module 'svelte/compiler'" error if oxfmt happened to resolve
+	without svelte actually installed — a strictly worse risk than omitting it.
+- **Instance health + memory-attribution observability (refs #1123 item 2)** — the #1126 sizing study diagnosed a 1.37 GB pi-lens instance from code + serialized artifacts alone, because nothing recorded a per-subsystem trajectory over time (the same detection-without-attribution gap loop_block had before #1122/#1125). Three pieces:
+	1. **Vanished-instance markers.** `deregisterInstance()` (`clients/instance-registry.ts`) synchronously removes a process's own `instances.json` entry on a clean `session_shutdown`, so an entry whose owning pid is confirmed dead is, by construction, proof that process never reached that shutdown path — no new "clean shutdown" flag is needed, the existing `heartbeatAt`/`rssBytes` fields already ARE the "lastSeen"/"rss" pair this needs (`clients/vanished-instance-marker.ts`). `session_start` now reads the registry and logs one `sessionstart.log` line per such entry — `previous instance pid X last seen <ts> (RSS <y>MB) exited without shutdown` — BEFORE `sweepOrphans()` (`clients/instance-reaper.ts`) prunes those same dead-pid entries; the read is sequenced ahead of the sweep (via `.finally()`) rather than let both fire-and-forget calls race, or the vanished set would already be empty by the time the marker ran.
+	2. **Periodic memory-attribution sample (`clients/memory-sampler.ts`).** Every 10 turns, one `memory_sample` `latency.log` phase line: `process.memoryUsage()` (rss/heapUsed/heapTotal/external/arrayBuffers) plus O(1)/O(bounded-cache-size) per-subsystem counters — review-graph resident workspace-cache entry count + summed node/edge counts (`getReviewGraphWorkspaceCacheSnapshot`, `clients/review-graph/builder.ts`), word-index doc/posting/forward-entry counts (off `runtime.wordIndex`), loaded tree-sitter grammar/parser/query-cache counts + tree-cache size/bytes (`TreeSitterClient.getRuntimeStats`, `clients/tree-sitter-client.ts`), and the dispatch cascade's turn-bounded cache sizes (`getDispatchCascadeCacheStats`, `clients/dispatch/integration.ts`). Every field is a `Map`/array `.size`/`.length` read or a `process.memoryUsage()` call — nothing iterates a large structure's contents, nothing snapshots the heap. **Documented gap vs the #1126 spec:** the WASM linear-memory byte length (`Module.wasmMemory.buffer.byteLength`) is NOT included — inspecting the installed web-tree-sitter 0.25.10 package confirmed that value lives in a private closure (`bindings.ts`'s `Module` singleton) with no public export, and reaching it would require either internal reflection (brittle across versions/bundling) or overriding Emscripten's `wasmMemory` init option with a hand-built `WebAssembly.Memory` (risks a memory-import mismatch breaking ALL structural analysis, for an observability-only feature) — `process.memoryUsage().arrayBuffers` is used as the process-wide proxy instead (WASM linear memory backs an ArrayBuffer, so it's already included there).
+	3. **`/lens-health` memory block**, reusing the same sample: RSS/heap/external plus the tree-sitter cache byte total and review-graph node/edge counts, following #1125's compact single-line health-line style. `instances.json`'s `rssBytes`/`heartbeatAt` refresh cadence needed no new wiring — `runtime-turn.ts`'s existing per-turn `updateHeartbeat()` call (#449 slice 1) already refreshes both every turn, which is what makes marker (1)'s RSS meaningful.
+
+	New tests: `tests/clients/vanished-instance-marker.test.ts` and `tests/index-vanished-instance-wiring.test.ts` (fail-then-pass: a dead-pid entry logs the marker and is still pruned afterward; a live-pid or already-clean entry logs nothing), `tests/clients/memory-sampler.test.ts` and `tests/index-memory-sample-wiring.test.ts` (cadence assertions: nothing before turn 10, exactly one sample at turn 10 and turn 20, never in between), and an `/lens-health` line assertion in `tests/index-wiring.test.ts`.
+
+- **Handle-origin tracer debug flag (refs #1123 item 4)** — institutionalizes the `async_hooks` handle-origin tracer the #1097 print-mode-hang investigation hand-rolled to find a leaked, ref'd `setTimeout` (root-caused/fixed in #1110); the #1097 reporter explicitly asked for a built-in active-resource dump. New `clients/debug-handles.ts`: `PI_LENS_DEBUG_HANDLES=1`, read ONCE at extension load, gates everything — unset (the default), every export is a no-op past that one boolean check (no writer constructed, no `async_hooks` hook installed, zero cost on the hot lifecycle paths that call it). Set at startup, `dumpActiveHandles(label)` writes one ndjson line to `~/.pi-lens/debug-handles.log` (standard `createNdjsonLogger` family — size-bounded, log-cleanup registered) with `process.getActiveResourcesInfo()` counts by resource type, plus per-type creation-site stack attribution from a bounded `async_hooks` tracker (capped at `TRACKER_MAX_ENTRIES`, never unbounded growth even in a timer-storm session) that is itself only installed when the flag was already on before the module first loads (real per-resource-creation overhead, strictly opt-in). **Eviction is protect-the-earliest, not drop-oldest**: a #1097-style leak is typically among the earliest handles created in a session, so a naive drop-oldest policy would let a later burst evict exactly that evidence — the first `TRACKER_PROTECTED_COUNT` insertion-order entries are pinned, eviction targets the oldest entry outside that zone, and a running `evictedCount` is always present on the dump entry once the tracker is installed (even at `0`) so an attribution gap from a burst past the cap is explicit rather than silent. Wired into `index.ts` at two points: `agent_settled` (after the quiet-window work is scheduled — the #1097-class leak is only visible once whatever settle itself queued is in flight) and `session_shutdown` (after teardown — whatever survives IS the leak). New tests: `tests/clients/debug-handles.test.ts` (flag unset → no writes/no tracker; flag set → dump emitted with type counts + creation-site attribution; a 600-entry burst against the 500 cap proves the first `TRACKER_PROTECTED_COUNT` and the most-recent entries both survive with `evictedCount` correctly reported; a real `async_hooks.createHook`-driven test creates and clears a genuine `setTimeout` and asserts it appears in, then is pruned from, a real dump) and two fail-then-pass wiring cases in `tests/index-integration.test.ts` asserting the dump fires strictly after LSP teardown / after quiet-window scheduling at the real `index.ts` seams.
+
+- **Source-walk generated-artifact escape hatch (closes #1107, phase 2 of 2)** — three pieces, building on phase 1's
+	counters (#1111):
+	1. **Directory-level skip counting.** `shouldRecurseIntoDir`'s
+		`isGeneratedArtifactDirectoryName` branch (`clients/source-walker.ts`)
+		pruned whole directories (`generated/`, `codegen/`, `__generated__/`, …)
+		with zero counting — an entire directory of real files reported zero.
+		`SourceCollectionResult` gains `generatedDirSkips`, threaded through the
+		same `SourceWalkSkipCounters` seam and the `source_walk_skip_summary`
+		log line: one count per PRUNED DIRECTORY, never per file inside it
+		(enumerating the contents would defeat the pruning). The
+		`SourceCollectionResult` docblock's former "KNOWN GAP" note is now the
+		real field doc.
+	2. **Tool-facing surfacing.** `ProjectDiagnosticsSnapshot` gains
+		`generatedFileSkips` (the raw skip total, all evidence tiers),
+		`generatedNameOnlySkips` (the narrower at-risk subset — see below), and
+		`generatedDirSkips` (only present, like `scanTruncated`, on a walk that
+		actually ran); `lens-engine.ts`'s new `generatedSkipNotice` renders a
+		one-line notice mirroring `scanTruncationNotice`'s (#784) style, wired
+		into both `pilens_project_scan` (`mcp/server.ts`) and `lens_diagnostics`
+		(`tools/lens-diagnostics.ts`). **Review fix (P1, empirically proven):**
+		the notice originally keyed off the raw `generatedFileSkips` total,
+		which includes STRONG evidence (lockfiles, declaration files,
+		minified/bundle/chunk output — expected on almost every real repo) —
+		a repo with just `index.ts` + an ambient `.d.ts` + `package-lock.json`
+		showed "2 file(s) excluded" on every single scan, forever. It now keys
+		off `generatedNameOnlySkips`: the narrower bucket of WEAK name matches
+		trusted with NO corroborating evidence check at all (only reachable
+		when a caller opts out of the header probe; the default project-walk
+		path always enables it, so this is rare-to-zero in practice — meaning
+		the notice is meaningful again when it does fire) plus `generatedDirSkips`
+		(directory pruning has no escape hatch, so it stays a genuine
+		unverified-content signal). Both `ProjectDiagnosticsScanOptions` and
+		both tool surfaces also gain `includeGenerated` (default `false`) so
+		the notice's opt-out advice is now actually actionable, not just prose.
+		`module_report` has no walk-backed section of its own to thread this
+		through (it reads the cached review graph, built asynchronously
+		elsewhere) — surfaced in the project-diagnostics path only.
+	3. **Content-probe escape hatch (the actual behavior change).** A file
+		matching a generated-artifact NAME pattern but with no other evidence is
+		now KEPT instead of silently dropped. `generated-artifacts.ts` splits
+		its path check into STRONG evidence (a generated directory segment, a
+		lockfile, minified/bundle/chunk output — always conclusive, never
+		rescued) and WEAK evidence (the remaining filename-regex patterns, e.g.
+		`gen.ts`, `foo_generated.go`); `classifyGeneratedOrArtifactDetailed`
+		requires a WEAK match to be corroborated by a generated-code header in
+		the first 4 KB (or the sibling-source probe already checked upstream by
+		every walk-driven caller) before treating it as an artifact —
+		cheapest-first. With NEITHER piece of evidence, the file is KEPT and
+		counted under the new `generatedNameOverrides` counter (also in the
+		rollup log line), so the heuristic's rescues stay observable.
+		**Review fix (P2, maintainer decision):** minified/bundle/chunk output
+		(`bar.min.js`, `vendor.bundle.js`, `runtime.chunk.js`) is STRONG tier,
+		not WEAK — the escape hatch's evidence checks are structurally dead for
+		it (minifiers strip banners, so the header leg never confirms; the
+		sibling probe looks for `app.min.ts`, never `app.js` at a different
+		stem, so that leg is unreachable too), which would have made it a
+		PERMANENT override rather than an occasional rescue. `app.min.js` next
+		to `app.js` is skipped unconditionally, like a lockfile.
+		Shipped **ungated**: the existing `LENS_FLAGS`/`.pi-lens.json` toggle
+		registry is sized for whole-subsystem behavior (lsp/tests/delta/…), not
+		a narrow heuristic refinement, and the new `includeGenerated` scan
+		option (item 2) already gives callers a full, actionable opt-out.
+		Documented tradeoff: a false-KEEP (one extra file an agent must judge)
+		is preferred over the prior silent false-DROP (a real file invisibly
+		never analyzed) — this changes walk output for review-graph/word-index/
+		project-diagnostics/call-graph: a repo with a real `gen.ts` gains
+		coverage (intended), and a repo with a headerless generated file with
+		no source twin also gains coverage (accepted per the issue). Invariant
+		preserved for lockfiles, declaration files, minified/bundle/chunk
+		output, and anything the ignore-matcher/extension filter already
+		excluded — none of those are ever rescued.
+
+- **Machine-wide test-suite lock (closes #1101)** — `npm test` /
+	`npm run test:unit` / `npm run test:integration` now route through the new
+	`scripts/with-test-lock.mjs` wrapper, which acquires a single machine-wide
+	`~/.pi-lens/test-suite.lock` before running vitest and releases it after.
+	Concurrent full-suite runs (several agents on parallel worktrees, plus an
+	interactive run) previously each spawned a fork pool sized for a dedicated
+	machine and fought over CPU/RAM, producing vitest worker-crash cascades and
+	timing-budget flakes that looked like real bugs but weren't; they now
+	serialize (queue) instead. A waiting run prints a heartbeat line at least
+	every 15s so it never looks hung, and — mirroring the installer's
+	`.install.lock` — a lock is stale only after its recorded PID is confirmed
+	dead, never on a timer alone. `PI_LENS_TEST_NO_LOCK=1` opts out (CI sets it:
+	runners are isolated, nothing to serialize against). Lock core lives in
+	`scripts/lib/suite-lock.mjs`, unit-tested for acquire/release, dead-PID
+	takeover, and real contention (two concurrent acquisitions serialize).
+	AGENTS.md documents the lock plus the companion layer-1 policy for agents
+	running tests concurrently.
+- **Source-walk skip observability (refs #1107, phase 1 of 2)** — the source
+	walk silently dropped real files whose NAMES match generated-artifact
+	heuristics (a real `src/gen.ts` was invisible to
+	`collectSourceFilesWithBudgetAsync`, with nothing anywhere saying so), an
+	invisible coverage hole for review-graph/word-index/project-diagnostics/
+	call-graph. This phase adds observability only — it does NOT change which
+	files get skipped (a content-probe escape hatch for name-only matches is
+	phase 2, tracked on #1107). `SourceCollectionResult` gains two additive
+	optional counters, `generatedOrArtifactSkips` (files dropped by the
+	generated/artifact NAME heuristic, `isGeneratedOrArtifact`) and
+	`buildArtifactSkips` (files dropped by the sibling-source artifact probe,
+	`isBuildArtifact`) — separate from extension-filter and ignore-matcher
+	skips, which are policy/config driven rather than name/content heuristics.
+	Both `collectSourceFilesWithBudget` and `collectSourceFilesWithBudgetAsync`
+	(and therefore every consumer that funnels through them — the review-graph
+	builder, project-diagnostics scanner, word index, etc.) populate the
+	counters and log a one-line rollup through the existing `logLatency`
+	channel (`phase: "source_walk_skip_summary"`) whenever either is nonzero; a
+	clean walk with no name/artifact-probe skips emits no new log line.
+	`tests/clients/graph-cache.test.ts`'s two remaining `gen.ts` fixtures
+	(unrelated to the drift-path test, which already used `alpha.ts`) were
+	unknowingly exercising empty-walk graph builds — renamed to
+	`buildstamp.ts`/`identitycheck.ts` since their assertions only cover
+	buildGeneration/cache-mode plumbing, never node/symbol content, so the
+	rename is behavior-preserving.
+
+- **LSP diagnostics content binding (refs #1095, first PR)** — diagnostics are now
+	bound to the document content they were computed against, so a consumer can ask
+	"were these diagnostics computed against what's on disk now?" instead of inferring
+	staleness purely from mtime/TTL proxies. When a `publishDiagnostics` notification
+	echoes a document `version`, the owning client binds the stored diagnostics to a
+	content fingerprint captured at didOpen/didChange SEND time (never a disk read on
+	the notification path). `getAllDiagnostics`/`touchFile` results and the
+	workspace-diagnostics cache lookup expose a `binding`
+	`{version?, contentHash?, boundToCurrentDisk: boolean | "unknown"}`, with
+	`boundToCurrentDisk` verified lazily against disk (memoized per file+mtime, reading
+	with the identical raw-UTF-8 transform the payload was built with, so CRLF/BOM files
+	round-trip correctly). Across multiple contributing clients the merged binding is
+	`false` if ANY contributor mismatches disk, `"unknown"` if all are unknown, else
+	`true`. `tools/lsp-diagnostics.ts` adopts it: a result whose binding demonstrably
+	mismatches disk (`boundToCurrentDisk === false`) is demoted to inconclusive — even a
+	non-empty result no longer re-cements the footer with a stale view (the #1092
+	re-cementing path). Servers that never report a version yield binding `"unknown"` and
+	behave exactly as before (zero regression). Binding state (`bound`/`mismatch`/
+	`unknown`) is logged in the `lsp_touch_file` latency metadata so an unbinding server
+	is diagnosable. Non-goals (stated for follow-ups): cascade adoption in
+	`clients/dispatch/integration.ts` (#1094 in flight), pull-diagnostics resultIds,
+	widget per-entry timestamps (#1093), aux retag (#1094).
+- **Cascade adopts LSP diagnostics content binding (refs #1095, second PR)** — the
+	cross-file cascade (`clients/dispatch/integration.ts`) now consults the `binding`
+	from the first PR instead of trusting a snapshot purely on TTL. A passive neighbor
+	snapshot whose diagnostics `boundToCurrentDisk === false` (the server's view diverged
+	from disk — e.g. the PRE-fix content) is no longer reconciled into the footer widget;
+	it falls through to an active touch on the existing cold-snapshot budget. This kills
+	the window where the first cascade after a fix-edit replayed a neighbor's stale
+	pre-fix snapshot. `"unknown"` bindings (version-less servers) keep EXACTLY the prior
+	TTL-only behavior; `true` reconciles (TTL stays the outer bound). On the active-touch
+	path, a bound-false result is treated like `inconclusive` — composed with it into one
+	`isConfirmedTouch()` predicate so a future flag can't be missed at just one gate — so
+	it neither reconciles nor seeds the recently-clean neighbor cache. `observedAt` stays
+	the snapshot's publish time (`entry.ts`) for passive reconciles. Binding-rejected
+	snapshots/touches are logged through the cascade channel (`bindingState`). The lazy
+	binding getter is re-read from a fresh `getAllDiagnostics()` every cascade run (the
+	Map is never retained across turns), with a caveat comment guarding future retention.
+- **Project-level rule policy via `.pi-lens.json` `rules.<id>.disable` / `rules.<id>.select`** — a project's own config can now narrow what diagnostics actually surface.
+	Filtering is output-only, so the baseline, widget state, and dedup cache stay
+	authoritative and a policy edit never corrupts or resets delta tracking.
+	Matching is project-wide: the `<id>` key is a grouping label, not a filter
+	scope. Every `disable` list across every key unions into one drop list, and
+	every `select` list unions into one allowlist, so
+	`"security": { "disable": ["no-eval"] }` works without `security` being a real
+	rule id. Disable wins over select project-wide, even across different keys.
+	A non-empty `select` anywhere silences every rule not listed, project-wide, so
+	it is a big hammer (documented as such). Findings that carry no rule id at all
+	are exempt from select, since `Diagnostic.id` is a dedup key rather than a rule
+	id and measuring it against an allowlist would have silently dropped blocking
+	findings like eslint parse errors. A user lists `no-eval` once and the filter
+	covers `no-eval`, `ast-grep:no-eval`, and `no-eval-js`, reusing the rule-id
+	normalization that `inline-suppressions.ts` and `tools/lens-diagnostics.ts`'s
+	dedup already applied, now consolidated in
+	`clients/dispatch/rule-id-normalize.ts` so the three surfaces cannot drift.
+	That normalization conflates a rule whose real name ends in `-js` with its stem
+	(`prefer-js` with `prefer`), which is now pinned by tests and called out in the
+	docs. The policy applies on the per-edit dispatch path
+	(`clients/dispatch/dispatcher.ts`, resolved from the project root so a
+	package-local `.pi-lens.json` in a monorepo cannot shadow the root's policy,
+	matching the root `lens_diagnostics` already used) and across the
+	`lens_diagnostics` tool's `mode=delta`, `mode=all`, and `mode=full` paths. Each
+	loads the policy map once per call, filters after inline suppression and
+	disposition, and re-summarizes so the blocking/error/warning counts reflect the
+	drop, including delta mode's carried-over tally and mode=full's structured
+	`details` counts. Silencing a rule is not the same as fixing it: the stored
+	delta baseline is deliberately unfiltered, so dispatch compares against a
+	policy-filtered view of it. Otherwise every disabled finding would sit in the
+	"fixed" set on every single dispatch and inflate the agent's resolved tally
+	(`trackAgentFixed`) for as long as the rule stayed off. In the project-config
+	loader (`clients/project-lens-config.ts`) the lists are tolerantly parsed: a
+	non-array, an empty array, or an all-whitespace array is logged once and
+	dropped, matching the existing threshold-validation warn-once contract.
+	Threshold-only entries are unaffected, and policy-only entries (no `threshold`)
+	coexist cleanly. A `rules.<key>` whose value is not an object, or whose keys are
+	all unrecognized, now warns instead of failing silent. That covers the two
+	shapes a user is most likely to reach for first, both of which parse as valid
+	JSON and do nothing: the lists written directly under `rules`, and `only`
+	instead of `select`. New `tests/clients/dispatch/rule-policy.test.ts` (32 tests:
+	matcher, normalization, project-wide grouping, disable-wins-select, the `-js`
+	conflation, the rule-less select exemption, and the hot-path fast return),
+	`tests/clients/dispatch/rule-policy-dispatcher.test.ts` (13 tests covering
+	dispatch integration including monorepo root-versus-nested config resolution,
+	baseline integrity, and the resolved-tally guard),
+	`tests/clients/dispatch/rule-id-normalize.test.ts` (7 tests), and
+	`tests/tools/lens-diagnostics-rule-policy.test.ts` (14 tests covering the three
+	mode paths, `select` on the cache-only paths, the delta carried-over tally, the
+	project-diagnostics delta report, and mode=full's structured details).
+	Docs: `docs/settings.md` and `docs/globalconfig.md` gained the project-wide
+	schema, precedence, the select warning, and the `-js` caveat. #533 hygiene is
+	preserved, so typo and unknown-key warnings still surface and foreign LSP
+	namespaces stay silent.
+
+- **Document the standing maintenance-routines menu (invoke-on-request)** — catalog named maintenance sweeps and their safety rails in `AGENTS.md`.
+
+- **Ast-grep dogfood rules for raw JSON store writes and win32 path qualification (refs [#1158](https://github.com/apmantza/pi-lens/issues/1158))** — flag direct JSON store writes and `win32.isAbsolute` qualification calls, with the atomic-write and `isFullyQualified` seams documented as the sanctioned alternatives.
+
+- **Helm chart linting (refs #1283, slice A)** — YAML and `.tpl` edits within a chart now run one bounded, canonical-root-deduplicated `helm lint`; warnings remain advisory and chart/template errors block. Rendered-manifest validation remains deferred to slice B.
+
+- **Session degradation telemetry in health and performance reports (refs #1292 items 4–5)** — Trust refusals, output-mode suppressions, TypeScript idle evictions, grammar blocks, untrusted formatter skips, and actionable spawn-failure buckets now remain visible as bounded per-session telemetry; LSP pull failures also appear beneath their server in `pilens_health`.
+
+- **Remaining silent degradation gates now surface in `pilens_health` (refs #1292)** — LSP breaker trips and diagnostic-timeout tallies, formatter failures, and tree-sitter WASM aborts are recorded with bounded per-session dedupe.
+
+- **Deterministic LSP acquisition-race coverage (refs #1292)** — concurrent initialization and an aborted waiter now assert single-client ownership, zero leaked leases, and teardown reaping through the shared interleaving kit.
+
+- **Weekly stale open-issue detector (closes #1323)** — the scheduled GitHub workflow reports open issues referenced by closing-shaped `master` commits or issue-named regression tests for human triage; it never closes issues automatically.
+
+- **Opt-in compact one-line tool result rendering (closes #1327)** — pi-lens tools can now render as a single theme-aware line (`<status glyph> <tool name> — <summary>`) instead of two rows, via `--lens-compact-tool-line` / `ui.compactToolLine=true` in `~/.pi-lens/config.json`. Default off — behavior is byte-identical when disabled. Expand-to-view-full-output is unchanged.
+
+- **HostPorts capability boundary (refs #1358, S2)** -- a typed interface over every host capability the engine consumes (notify, trust, mode, log, emit, status, spawn policy, render, session, workspace, flags, tools), with headless-parity defaults and the existing getter seams as thin adapters; no behavior change, direct-ctx migration deferred to S4.
+- **Global LSP configuration fallback (refs [#870](https://github.com/apmantza/pi-lens/issues/870))** — load shared LSP settings from `~/.pi-lens/lsp.json`, with project configuration taking precedence.
+- **Per-rule configuration controls (closes [#444](https://github.com/apmantza/pi-lens/issues/444))** — enable or disable individual rules through `.pi-lens.json`.
+- **Edit-batch read-guard observability (refs [#1053](https://github.com/apmantza/pi-lens/issues/1053))** — expose batch-level read-guard activity for clearer diagnostics.
+- **Review-graph call evidence (closes [#1070](https://github.com/apmantza/pi-lens/issues/1070))** — include call/reference evidence in project-intelligence reports and codebase models.
+### Changed
+
+- **Safe dependency refresh for v4** — updated the pi host SDK and TUI to `0.84.2`, ast-grep NAPI to `0.45.1`, and Biome to `2.5.8`; refreshed the transitive dependency graph to remove the audited high-severity `nanoid` finding. Major or otherwise non-essential updates remain deferred for follow-up validation.
+
+- **Installer probe-cache persistence now uses the shared durable-store protocol (closes #1212)** — awaited commits use the shared quarantine-recovering bounded PID lock, authoritative in-lock reread/delta merge, throwing atomic publication, and in-lock mirror refresh while retaining deferred/failed retry outcomes; TTL, existence, and mtime validation remain read-side policy. Turn-state folding remains a future decision, not part of this change.
+
+- **Shared durable-store and atomic-stage protocols (refs #1212, closes #1209)** — diagnostic dispositions and actionable-warning suppression now use one locked in-lock-reread/merge/throwing-atomic-write commit seam, while one staging namespace module owns `.tmp-<pid>-<threadId>-<seq>` minting, classification, and bounded own-stage sweeping.
+
+- **Standalone managed-tool clients share one typed availability/install seam (closes [#1290](https://github.com/apmantza/pi-lens/issues/1290), refs [#1214](https://github.com/apmantza/pi-lens/issues/1214))** — madge, Knip, Biome, and ast-grep now join Ruff/jscpd behind runner helpers. Single-command clients use the cached typed checker; ordered-candidate clients retain their local/global/npx/platform search through a typed custom-probe wrapper. The seam also owns managed child environments and read-only discovery, while a source coverage test rejects direct `ensureTool()` calls or bare managed-tool spawns outside sanctioned wrappers. Raw ENOENT consumers in `lsp/launch.ts` remain for #1214's safe-spawn-wide taxonomy.
+
+- **Cooperative word-index startup work (closes #1224, closes #1225, closes #1226, refs #1215)** — centralizes monotonic event-loop work budgets, time-budgets shared source walking and word-index reads, yields within high-document-frequency posting filters while publishing each replacement atomically, and reuses the bounded refresh preflight file/stat set for full rebuilds instead of walking and stating it twice.
+
+- Ruff and jscpd availability now use the shared dispatch checker, including typed missing-command installation, in-flight dedupe, install-failure suppression, and session reset (refs [#1290](https://github.com/apmantza/pi-lens/issues/1290), phase 1; not closing the issue). The seam adds configurable probe timeout and a managed-command fast path to preserve jscpd's 1500ms PATH probe and managed-tools lookup.
+
+- **Review-graph persistence lifecycle telemetry (refs #1048)** — `review-graph.log` now correlates graph/build and persistence generations, sequence hints, graph timestamps/counts, exact total/persisted node/edge/file coverage, source-walk truncation, coalescing and supersession, worker outcomes, and fallback status with bounded metadata, while preventing stale-generation fallback writes; source contents and paths are never added to the new metadata.
+
+- **Prompt-cache context attribution (refs #1018)** — add bounded `cache_context` latency records that correlate context injection sources, placement, message counts, sizes, and privacy-preserving hashes with provider `cache_usage` by session/turn, while keeping provider cache misses and local prefix changes distinct.
+- **Friendlier AST search (refs #125)** — correct agent-facing examples, add exact grammar-kind and explicit recursive descendant searches, bound explicit path lists, keep pagination output aligned with `maxMatches`, and document lazy-tool activation timing.
+
+- Document red-first regression-test and worktree-hygiene conventions
+
+- **Adopt commit-message and doc/prose (Google + STE) writing conventions**
+
+- **Refresh README/docs for v4 and update contributors** — reconciled the
+  README feature list and `docs/` reference against current code: documented
+  the four memory idle-eviction env vars (`PI_LENS_TS_IDLE_EVICT_MS`,
+  `PI_LENS_WORD_INDEX_IDLE_EVICT_MS`, `PI_LENS_PROJECT_SNAPSHOT_IDLE_EVICT_MS`,
+  `PI_LENS_REVIEW_GRAPH_IDLE_EVICT_MS`), the session degradation ledger
+  surfaced through `pilens_health`/`/lens-health`, deferred-format bounded
+  concurrency, and the `--lens-guard` commit/push blocker; linked
+  `docs/mcp.md` from the README and added an MCP-server bullet. Added six
+  external contributors (Nathan Cooke, Eli Stark, Marvin Aziz, Mark Faga,
+  aeturnal, floatGray) to the README contributors table, sourced from
+  `git shortlog` and merged-PR authorship.
+
+- **Dogfood the shape-2 path-semantics rule (refs #1158)** — Flag host-default path operations inside branches committed to Windows path semantics.
+
+- **Cooperative-budget acceptance coverage hardened (closes #1215)** — the shared time-budget helper's occupancy and abort-latency guarantees are now locked by non-vacuous regression tests at 800-item scale (assertions within a small multiple of the budget); no runtime behavior change.
+
+- **Per-entry changelog files end merge-train conflicts (closes #1321)** — User-facing changes can now land as independent per-entry files and roll up in the version-bump PR before normal CI and tag-time verification.
+
+- **TypeScript language services release idle program memory (refs #1332)** — After five inactive minutes (configurable with `PI_LENS_TS_IDLE_EVICT_MS`), TypeScript LSP clients shut down and rebuild transparently on the next request instead of retaining fully hydrated programs indefinitely.
+
+- **Terminal behavior now follows the pi host's run mode (refs #1334)** — pi-lens reads `ctx.mode` (`"tui" | "rpc" | "json" | "print"`) instead of assuming it owns an interactive terminal. The diagnostics widget mounts only in `tui`, and proactive `ui.notify` chatter is logged rather than rendered in the one-shot `print`/`json` modes, so piped and machine-readable runs stay clean. `/lens-widget-toggle` now says which mode is blocking it instead of blaming the pi version. Hosts that expose no `mode` field behave exactly as before.
+
+- **Enforce the host-SDK type-only import rule that keeps clean installs working (refs #1334)** — `@earendil-works/pi-coding-agent` is an optional peer that pi omits at install time, so a value import of it breaks pi-lens at user sites. That rule was prose only; a regression test now scans every shipped source file for static, dynamic and `require` value imports and fails the build on one. The edit-tool result payload also now uses the host's own `EditToolDetails` type instead of a locally re-declared shape.
+
+- **A formatter that exits nonzero is now reported as a failure (closes #1337)** — formatter exit-code strictness was opt-in, so any formatter that had not opted in turned every nonzero exit — rejected flags, a crashed binary, an unparseable file — into `{ success: true, changed: false }`, indistinguishable from "already formatted". That default is what let `ruff format` silently no-op for a full release cycle (#1336). The seam is now strict by default, with an audited opt-out (`lenientExitCode`, carrying its evidence) for the four lint-autofix formatters whose exit status reports remaining offenses *after* a successful rewrite: `rubocop -a`, `standardrb --fix`, `ktlint -F`, and `sqlfluff fix`. **Behavior change:** the other 29 formatters now surface an error where they previously reported a silent no-op — most visibly, saving a file with a syntax error reports the formatter's parse error instead of quietly doing nothing. Three supporting fixes make that surfacing trustworthy: Biome now passes `--no-errors-on-unmatched` (it exits 1 on paths its own `biome.json` ignores, which would otherwise report a failure on every edit under an ignored directory); the reported message skips decorative banners and falls back to stdout, so tools that report there — Biome, ktlint, `mix format` — no longer surface a bare exit code; and the PowerShell formatter now runs with `$ErrorActionPreference = 'Stop'` plus a null guard, so a failing `Invoke-Formatter` reports the failure instead of exiting 0 and truncating the file it was asked to format.
+
+- **Re-home probe-cache ageing and cooperative yields (closes #1354)** — authoritative probe-cache commits now prune expired entries while preserving durable-store quarantine recovery; the remaining corpus-scaled scan yields use the cooperative time budget.
+
+- **Warm dispatch, LSP async consumers, and formatter catalog lazily at session start (refs #1394 — Phase 2).**
+
+### Removed
+
+- **Dead-code cleanup: 5 orphaned production modules + the `server-strategies.ts` deprecated shim (refs #1090)** — `clients/project-metadata.ts` (orphaned since the `/lens-booboo` removal, #397/#396), `clients/lsp/interactive-install.ts` + its test (superseded by `resolveAndLaunch`, #374/#375), `clients/ast-grep-parser.ts` (superseded by the napi runner, #197), `clients/types.ts` (initial-commit LSP types, superseded by `LSPDiagnostic` in `clients/lsp/client.ts`), and `clients/lsp/lsp-index.ts` (stillborn barrel, zero references ever) all had zero remaining importers, re-verified at current master (including dynamic `await import()` patterns). `clients/lsp/server-strategies.ts` (a `@deprecated` re-export shim over `wait-policy/strategies.ts`) is also deleted after repointing its last two consumers — `scripts/probe-clean-signal.mjs` and `tests/clients/lsp/server-strategies.test.ts` — directly at `clients/lsp/wait-policy/strategies.ts`, plus ~25 stale doc/comment references across `CONTRIBUTING.md`, `docs/lsp-capability-matrix.md`, and the LSP/probe source. Non-goals: `clients/module-report-lsp.ts` and `clients/source-groups.ts` (parked pending #236 / roadmap decisions) and the un-export candidates identified in #1090 remain untouched.
+
+### Fixed
+
+- **Git guard closes shell-expansion and command-wrapper bypasses (refs #1084, PR #1395)** — command-position normalization now handles all supported IFS and positional-parameter forms, and guarded verbs nested in known or unknown command-string launchers fail closed while literal text remains non-blocking.
+
+- **LSP roots and per-session clients are conservatively bounded (closes #1325, refs #1126, refs #1129)** — manifest-bearing fixture conventions (`tests/fixtures`, `__fixtures__`, and `testdata`), gitignored directories, and atomic-write staging namespaces no longer become standalone LSP roots; their files attach to the nearest eligible ancestor project. Client reuse remains keyed by server and normalized resolved root, while a configurable `PI_LENS_LSP_CLIENT_CEILING` (24 by default) evicts the least-recently-used idle client through graceful shutdown before spawning another and never evicts a client with an active LSP request.
+
+- **Fully qualified Windows paths use one shared classifier (closes [#1213](https://github.com/apmantza/pi-lens/issues/1213))** — drive-relative (`C:foo`) and rooted-relative (`\\foo`) paths are no longer mistaken for self-contained absolute paths; UNC and drive-absolute paths remain fully qualified across command validation, installer caching, and managed-tool retention.
+
+- **Kotlin formatter selection follows Spotless configuration deterministically (closes #1306)** — a Spotless `kotlin { ktlint() }` block pins ktlint and `kotlin { ktfmt() }` pins ktfmt, so both selection branches cannot claim the same Kotlin file and unconfigured projects retain the style-preserving no-format policy.
+
+- **Managed npm clients see and execute off-PATH installs (closes [#1289](https://github.com/apmantza/pi-lens/issues/1289))** — madge and Knip availability probes receive the managed environment, Knip threads the same environment into analysis, Biome checks the managed absolute candidate before its npx fallback, and every install result is retained as the command used by the client.
+
+- **Turn-end madge telemetry stays compact and its batch metadata is runtime-tested (closes [#1250](https://github.com/apmantza/pi-lens/issues/1250), [#1251](https://github.com/apmantza/pi-lens/issues/1251))** — aggregate batch counters remain exact, while per-target timing breadcrumbs are retained only for spawns taking at least 100 ms and capped at 12 slow targets, preserving the smells-rollup lookback; the real turn-end path now verifies madge batch execution and metadata propagation.
+
+- **Rule-policy normalization and source-filter matrices no longer drift (closes #1087)** — P3.2 derives CodeRabbit's language suffixes from the vendored rules tree so disable/select and inline suppression cover every shipped language; P3.3 aligns source-twin precedence ordering with sibling resolution and adds a behavioral agreement guard while preserving the broad `.jsx` build-artifact fallback.
+
+- **Smart-default formatters preserve existing indentation when a repository has no style configuration (closes [#1144](https://github.com/apmantza/pi-lens/issues/1144))** — Biome and shfmt now infer and pin a file's indentation for unconfigured formatting, skipping when their style cannot be inferred; Prettier and Ruff receive the same fallback indentation flags. Explicit formatter configuration and `.editorconfig` remain authoritative.
+
+- **Bus emitters no longer retain a stale session context after replacement (closes #1128)** — all pi-lens event publishers resolve the live `pi.events` emitter at delivery time through a shared getter seam; deferred lens events also resolve inside their `setImmediate` callback. The sweep found no other outliving session-context emitter closures: the quiet-window summary already uses its current-context holder and its stale-session guard; LSP repaint callbacks capture UI primitives intentionally rather than `ctx`; remaining lifecycle callbacks use the event-time context or runtime generation gates.
+
+- **Durable disposition marks no longer lose sibling-process updates (closes [#1202](https://github.com/apmantza/pi-lens/issues/1202))** — the repo-wide shared-store audit classifies every durable writer and records accepted best-effort caches explicitly. The sole unguarded behavior-gating read/modify/write store, `diagnostic-dispositions.json`, now takes a bounded pid-owned cross-process lock, re-reads under that lock, and merges only its anchor delta, so an older writer cannot promote a stale whole-file snapshot over a concurrent mark.
+
+- **Behavior-gating durable stores no longer lose sibling-process updates (closes [#1202](https://github.com/apmantza/pi-lens/issues/1202))** — the repo-wide shared-store audit classifies every durable writer and records accepted-loss telemetry explicitly. Diagnostic dispositions and actionable-warning suppression state now share a bounded pid-owned cross-process lock, re-read under that lock, and merge only the caller's delta before atomic replacement. Disposition telemetry fires only after persistence succeeds, and turn-state clear/cycle/deferred-format paths now enforce the same live-owner boundary as edit registration.
+
+- **Tool discovery caches now recover from session changes and deleted binaries (closes [#1203](https://github.com/apmantza/pi-lens/issues/1203))** — cwd-scoped runner probes and the shared ast-grep memo follow the existing dispatch session generation, while installer in-memory positives revalidate absolute paths and evict the matching persisted entry before re-probing when the binary disappears.
+
+- **Managed ruff, jscpd, and madge installs are now actually used after auto-install (refs [#1289](https://github.com/apmantza/pi-lens/issues/1289))** — retain the absolute path returned by `ensureTool` so off-PATH managed shims are spawned directly instead of falling back to the bare command name.
+
+- **The shared async walk engine no longer reads directories synchronously (refs [#1137](https://github.com/apmantza/pi-lens/issues/1137), [#1170](https://github.com/apmantza/pi-lens/issues/1170))** — `walkTreeStackAsync` (`clients/source-walker.ts`) already `setImmediate`-yielded every N entries, but every per-directory read still went through `readDirEntriesSafe` → `fs.readdirSync`. Chunked yielding only covers the CPU axis: on a cloud/network-backed tree (OneDrive) one stalled directory read held the Node event loop — and pi's TUI — for the entire stall, no matter how often the walk yielded around it. This is the exact shape #1170 fixed in `pipeline.ts`'s autofix snapshot walk while explicitly deferring the shared engine; fixing it here means every async walker (`collectSourceFilesAsync`, `countSourceFilesWithinLimitAsync`, and so the session-start source scans and word-index refresh) inherits the fix at once. The traversal itself is untouched: the one shared generator now yields a directory-read *request* and each driver satisfies it — `readdirSync` for the sync driver, `fs.promises.readdir` for the async one — so the sync/async pair still cannot drift, and visit order, `maxFiles` cap behaviour and results are identical. `tools/lsp-diagnostics.ts`'s directory-mode `collectFiles` walk is converted the same way (it was fully synchronous with no yielding at all, bounded only by files *kept*, and ran once per language in the `LANG_EXTENSIONS` loop); it keeps its immediate-descent recursion rather than adopting the stack-based shared driver, because the `maxFiles` cap makes traversal order observable. A `measureMaxSyncBlockMs` fail-then-pass occupancy screen injects the same per-directory stall into both APIs and pins that the async walk no longer holds the loop (verified to fail against pre-fix code: a 420ms block against a 30ms budget).
+
+- **Direct-write cache stores now publish JSON atomically (refs [#1239](https://github.com/apmantza/pi-lens/issues/1239) [#1205](https://github.com/apmantza/pi-lens/issues/1205))** — turn state, rule, diagnostics, call-graph, codebase-model, actionable-warning, and metrics-history stores stage JSON through the shared tmp-plus-rename writer, so a process killed during a write leaves the previous complete cache value rather than a truncated file.
+
+- **Dispatch's install-failure suppression never cleared, and a completed install could keep serving a pre-install madge resolution (closes #1266, refs #1276)** — `handleSessionStart`'s install-attempt suppression window (`installFailureReasons`, #1222/#1223) had no reset hook, so a tool that legitimately failed once stayed suppressed for the rest of the process even across sessions; it is now reset at session start for both sequential and MCP session starts (the existing concurrent-session guard already prevents a subagent session start from over-resetting a live parent). Separately, `DependencyChecker`'s madge managed-path memo (#1276) is keyed only by `projectRoot` but reads PATH/discovery/managed-install state that a completed install changes, and `finishInstallAttempt` dropped it via a fire-and-forget dynamic import — a caller that started the next madge resolution the instant `installTool`/`ensureTool` resolved could still observe the stale pre-install memo, and a rejected import became a silent unhandled rejection with no invalidation at all. The reset is now `await`ed before `installTool`/`ensureTool` return, wrapped in try/catch that logs (rather than swallows) an import failure, so a resolution issued right after a successful install deterministically sees the reset memo. The checker's own instance registry (needed so the reset reaches every live checker, not just whichever one ran the install) now holds instances via `WeakRef` instead of a strong `Set`, so short-lived checkers (tests, reinit) can be collected instead of retained for the process's lifetime; and the bare-command spawnability revalidation `resolvedCommandIsStale` added under #1276 is now cached per checker (invalidated by that same reset) instead of re-running a synchronous PATH scan on every cached resolution.
+
+- **Orphan staging-file reaping no longer deletes legitimately named files (refs [#1267](https://github.com/apmantza/pi-lens/issues/1267), [#1260](https://github.com/apmantza/pi-lens/issues/1260))** — the session-start atomic-stage sweep now requires the full writer-emitted `.tmp-<pid>-<threadId>-<seq>` shape with strict, unpadded decimal components, so names such as `backup.tmp-000123-02-03` are left alone while genuine current-shape dead-pid orphans are still reaped.
+
+- **`no-bare-except` and `duplicate-function-arg` grammar coverage, including a binding-aware fix for the broadened traversal (closes [#1269](https://github.com/apmantza/pi-lens/issues/1269), closes [#1270](https://github.com/apmantza/pi-lens/issues/1270))** — `no-bare-except`'s `not: any: [...]` exception-spec enumeration (identifier/attribute/tuple/parenthesized/as_pattern/subscript) was a denylist that any new node shape could slip past; it now matches the grammar's bare `except:` syntax directly (`pattern: "except:"`), so a future exception-spec kind cannot become a false negative by omission. `duplicate-function-arg`'s query previously bound `(required_parameter (identifier) @NAME)` with no depth restriction, so a rest parameter (`...a`) and other non-`required_parameter` shapes went unmatched; the query and its `same_param_name` post-filter's `bindingNames` helper were broadened to walk the full parameter pattern (covering rest params, arrow functions, and destructured/renamed collisions). That broadening over-corrected: `bindingNames` treated every descendant `identifier` as a bound name, so a reference inside a destructuring **default** (`{a = b}`, `[a = b]`, `{x: a = b}`, `{a = (() => b)}` — the `b` is a default-value expression, not a binding) or inside a **computed property key** (`{[key]: a}` — `key` is a reference) was wrongly counted, producing false-positive duplicate reports against an unrelated same-named parameter elsewhere in the list. `bindingNames` is now binding-aware: it descends into an `assignment_pattern`/`object_assignment_pattern`'s `left` field only (never `right`, the default expression) and skips `computed_property_name` entirely, while still walking nested destructuring binding positions so `{a}`/`[a]`/renamed-binding collisions keep flagging. (`{a = a}, a` legitimately still flags — the left side of `{a = a}` binds `a`, colliding with the second parameter's own `a`; Node itself rejects that snippet with "Duplicate parameter name not allowed in this context".) Both false-positive fixtures were confirmed to reproduce against the pre-fix traversal before the change and pass after.
+
+- **Stop-hook turn-end residuals: stdin hang, invisible skips, unguarded client cwd, delivery-loss on the ack error path, and transcript rendering (refs [#1271](https://github.com/apmantza/pi-lens/issues/1271), [#1272](https://github.com/apmantza/pi-lens/issues/1272), [#1273](https://github.com/apmantza/pi-lens/issues/1273), [#1274](https://github.com/apmantza/pi-lens/issues/1274), [#1275](https://github.com/apmantza/pi-lens/issues/1275))** — five defects found in post-merge review of #1211, all on the turn-end path.
+  - `pi-lens-analyze`'s `main()` awaited the stdin read BEFORE examining `--file`/`--turn-end`, with no timeout and only an `isTTY` guard, so any spawner that left a piped stdin open hung the bin forever — a regression on the pre-existing `--file` path, and as a Stop hook a full 60 s Claude Code timeout every single turn. argv now wins: stdin is read only when neither flag answers the question, and the read is raced against a 2 s timer so a stuck pipe degrades to "no payload" instead of hanging. Every existing test called `child.stdin.end()`, which is exactly why the suite could not catch this; the two new guards deliberately do not.
+  - Every turn-end skip wrote one line to **stderr** and exited 0, and Claude Code does not surface stderr from a hook that exits 0 — so a permanently dead integration was byte-for-byte indistinguishable from a clean turn, indefinitely. The skip now also goes to stdout (the hook's only transcript-visible channel, one line), the message names the actual wire reason instead of always claiming "no warm pi-lens MCP server" (absent server, slow pass, schema skew and stale build have different remedies), and the hook records `{ran, skipped, lastSkipReason, lastRunAt}` per workspace so `pilens_health` reports it — the #544 precedent applied to the hook process, which is separate and short-lived and therefore left no other trace. That per-workspace status file is a shared-tmpdir read-modify-write two concurrent Stop hooks for the same workspace can race; the write now routes through `writeFileAtomic` (`clients/atomic-write.ts`) so a race can no longer torn-read the file (parse failure resetting both counters) or hit a Windows sharing violation — the read-modify-write itself can still drop one increment under a true race, which is accepted for this bounded best-effort telemetry.
+  - The warm turn-end IPC route trusted the client-supplied `cwd`, called `ensureReady` on it and ran **that directory's configured test runner** there. Turn-end and its ack now reject any cwd that is not the server's own `DEFAULT_CWD` or inside it, and log the mismatch; every legitimate client already derived the socket path from that same cwd, so the guard costs nothing legitimate. A subdirectory of the workspace stays accepted. The guard's first cut wrongly rejected the exact workspace root on win32 whenever the cwd it was handed differed from `DEFAULT_CWD` only in case (drive letter or a path segment): `path.relative` is case-insensitive there and returns `""` for that pair, but the guard's `rel !== ""` term read that as "outside the workspace" — a real gap, since Claude Code's Stop-hook cwd can legitimately differ in case from how the server derived its own `DEFAULT_CWD` (`ipcPathForCwd`/`workspaceHash` in `clients/mcp/ipc.ts` already `.toLowerCase()` for exactly this reason), silently no-opping the feature at the root on every turn. Fixed by dropping the redundant `target === DEFAULT_CWD` fast path and the `rel !== ""` term together — `rel === ""` only ever means "this is the workspace root" and must be accepted, not rejected.
+  - `acknowledgeTurnEnd` deleted the pending delivery BEFORE calling `commit()`, so a throwing consume destroyed the only handle to the findings — the exact loss the two-phase protocol exists to prevent, reintroduced on its error path. It now commits first and drops the capability only on success. `pendingTurnEndDeliveries` also had no expiry and no size cap (every timed-out client and every distinct raw-cwd alias left an entry for the life of the process); it now expires at 10 min and caps at 8, both dropping entries **without** committing so the findings re-arm for a later Stop rather than vanishing. The route no longer starts a heavy pass for a client whose socket is already destroyed, and byte-identical in-flight Stop requests (no files, no sessionId) coalesce onto the one pass instead of a third being rejected outright by the single-waiter queue.
+  - Transcript rendering: the 2000-character cap sliced UTF-16 code units and split surrogate pairs, putting U+FFFD where an emoji marker belonged; the cut now backs off a high surrogate. The `tests` section is the raw vitest failure dump, so ANSI escape sequences and C0 control characters (newline/tab excepted) are stripped before capping, which also removes the half-sliced-escape leak. The injection-framing strip was `startsWith`-only and now removes every occurrence, so a token carried into the middle of a joined section cannot survive.
+
+- **Marksman silent-clean confirmation now requires a liveness check, so a wedged server is no longer rendered clean (refs [#1277](https://github.com/apmantza/pi-lens/issues/1277))** — #1253 converted a diagnostics timeout on a `tier3-silent` server (e.g. Marksman) into a confirmed-clean verdict from the static capability classification alone. A server that accepted the notify write and then became unresponsive was therefore reported clean rather than inconclusive — the unresponsive-server-as-clean silent-failure shape. The gate now additionally requires `clientPingLiveness`, an active `workspace/symbol` round-trip bounded at 300ms and independent of the notify-write: a wedged server never answers, the timer wins, the ping returns false, and the result stays inconclusive. A genuinely silent-clean server (alive, tier3-silent, no diagnostics) still confirms clean, and the enumerable `confirmation` wrapper contract is unchanged. Guarded by a notify-accepted-then-unresponsive test confirmed to fail against the pre-fix body.
+
+- **Stop-hook turn-end findings are no longer lost when the client deadline wins (refs [#1218](https://github.com/apmantza/pi-lens/issues/1218))** — the warm Stop route now separates execution from durable delivery. It returns a delivery capability over one one-shot connection, and consumes the turn-end/test finding bridges only after a receipt acknowledgement on a separate one-shot connection. A timeout, late reply, or connection close leaves findings available for a later authorized Stop; repeated acknowledgements are idempotent. Turn-state writers now carry explicit pi/MCP ownership, so `sessionId:null` cannot erase a shared worklist or let a live foreign session consume it. Spawn tests use isolated temp workspaces/data/home roots and refuse the real workspace socket.
+
+- **Markdown `lsp_diagnostics` now preserves Marksman's authoritative silent-clean confirmation (closes [#1253](https://github.com/apmantza/pi-lens/issues/1253))** — `LSPService.touchFile` already treated a successful Marksman notify followed by its expected no-publish clean behavior as confirmed, but the tool boundary retained only the empty diagnostics array and `inconclusive` flag. The tool then reclassified the same empty tier-3 result, attempted the TypeScript-only fallback path, and rendered clean Markdown as inconclusive. `TouchFileResult` now carries explicit confirmation metadata for completed collections, and every local diagnostics request routes through `touchFile` when available — including default all-scope batches with no explicit wait. Primary-scope and non-TypeScript all-scope consumers accept that confirmation; all-scope TypeScript still runs its synchronous tsserver fallback before any clean verdict, so unpublished TypeScript findings remain visible. Absent metadata, failed writes, timeouts, binding mismatches, and ambiguous capability state remain unconfirmed; confirmed clean results remain cacheable and widget-reconcilable, and real findings are unchanged. Two carriage holes that only became reachable once the confirmation was surfaced to the tool are closed with it. (1) `touchFile` recorded its recent-touches debounce entry even when a server's notify write TIMED OUT or rejected, so the next touch inside the 1500ms window skipped the notify entirely and reported `notifyWriteTimedOut: false` — the exact precondition both silent-clean gates (#799 single-server, #814 aggregate) read as "the server saw this content". A `silentOnClean` server that never received the file was therefore confirmed clean one debounce window later; in a batch this fired routinely, because `ensureWarmForSweep`'s warm-up touch is the first push and the per-file touch is the second. The debounce is now keyed **per server** (`file:clientScope:serverId`) and each entry is recorded at the moment that server's own write lands, so a failed write re-pushes instead of laundering into a confirmation. Per-server rather than the file-level "record only when every spawned server's write landed" this fix first shipped as: `recentTouches` carried no server component, so withholding the entry withheld it from every co-touched server, and one wedged auxiliary disabled the debounce for its HEALTHY siblings — re-pushing them on the next touch and clearing diagnostics they had already computed, which is the same per-file collapse #743 removed from the notify-write deadline (and which its own in-file doctrine comment forbids). Keyed per server both hold at once: the stalled server has no entry and is re-pushed, while every sibling whose write landed keeps its own debounce and its original timestamp, so the window still expires naturally instead of being extended by reuse. The version-baseline diagnostics wait is likewise per-server now, so a server that WAS pushed still gets its `minVersion` wait when a sibling was debounced away. Guarded by a two-server test (one stalled, one healthy, same content twice) confirmed to fail against the pre-fix body — the healthy server's `notify.open` was called twice where it must be called once. (2) The warm-attach collection branch returns before the local touch and had no provenance to carry, so a warm-attached session reported every clean Markdown file unconfirmed regardless of the tool-side fix; `WarmDiagnosticsResponse` now carries the incumbent touch's `confirmation` as an explicit enumerable DTO field (same doctrine as `inconclusive`), consumed as an AGGREGATE confirmation because the incumbent always touches `with-auxiliary` — an incumbent that omits the field stays unconfirmed. A confirmed touch whose findings are all filtered away by the requested severity floor now renders **clean at that severity** rather than consulting the empty-result classifier (which answered "unconfirmed" for a tier-3 silent server): the unconfirmed doctrine exists for a server that said NOTHING, not for one that demonstrably answered and had its findings filtered by the caller's own floor. The filtered diagnostics are still cached and widget-reconciled, and the tier-3 sync escape hatch is still reserved for a genuinely empty result. Covered end-to-end: a new suite drives the real `LSPService` through the real tool with only the server registry and client transport faked, so the confirmation has to actually flow rather than being asserted separately on each side of a mock; the incumbent-side DTO composition is pinned separately (a confirmed touch emits the field, an unconfirmed or inconclusive one OMITS the key rather than serializing `undefined`, which is what makes the absent-field degradation byte-identical to a pre-#1253 incumbent and the no-version-bump safe).
+- **Turn-end madge resolved its command once per FILE, and a slow older pass could overwrite newer circular-dep state (refs [#766](https://github.com/apmantza/pi-lens/issues/766))** — `resolveMadge` ran inside `checkFilesBatch`'s per-file mapper, and its `findNodeToolBinary` miss path spawns uncached `npm config get prefix` / `pnpm bin -g` / `yarn global bin` probes, so a turn touching N import-changed files paid that whole chain N times before falling back to `npx madge` — never consulting the managed tools tree pi-lens installs madge into in the first place. Resolution now runs once per project root (memoized on the instance) and falls through local/global bin → `ensureTool("madge", { allowInstall: false })` → `npx madge`; the discovery step can never download, because installation stays owned by `ensureAvailable()`. That memo is deliberately not one-way, since re-probing per spawn is also what used to make resolution self-healing: a memoized absolute path is re-validated with one `existsSync` per resolution, so a madge uninstalled mid-session re-resolves instead of failing every remaining spawn, and the `npx` result is never pinned — it is the slow path being removed, and one transient installer failure would otherwise disable managed resolution for the whole session. The resolved command's `kind` is classified from the returned STRING (`local`/`managed`/`global`/`path`/`npx`) rather than from the step that produced it: `findNodeToolBinary` probes the npm/pnpm/yarn/bun GLOBAL bins as well as the project's `node_modules/.bin`, and the installer's discovery legitimately hands back a bare PATH name or an npm-global path as well as the managed one. `checkFilesBatch` now returns `{ results, stats }`, and turn-end attaches `MadgeBatchStats` — requested/missing/cacheHits/spawned/failed, `commandKind`, `resolveMs`, and per-target durations capped at 12 with `targetsTruncated` so the cap is never silent — as metadata on the existing `phase: "madge"` latency entry, which as one whole-phase duration could not distinguish many files from one slow file from command resolution. Separately, `lastCircular`/`circularFiles` are shared instance state that `checkFile`, `checkFilesBatch` and `scanProject` all overwrite wholesale while genuinely overlapping (turn-end against the background scans in `runtime-session.ts` and `project-diagnostics/fresh-fetch.ts`): each writer now takes a generation when it CLASSIFIES and publishes only while that generation is still the newest, so an operation that started against older file content can no longer resurrect that view over a newer one, whatever order the spawns finish in. The batch folds into a batch-local copy and publishes once at the end, so its returned map keeps the array-order sequential equivalence either way, and both guard tests were confirmed to fail against the unguarded publish rather than merely to pass after it. No result cache was added (#533, "when in doubt, re-run") — changed content still re-runs madge, and the guard only skips writes that a newest-wins sequential interleaving would also have discarded. A content-fingerprint single-flight map was considered and dropped as unreachable: `importsChanged` writes its `{timestamp, size}` entry synchronously during classification and neither caller has an interleaving await there, so a second overlapping operation on the SAME content always classifies as a cache hit and never reaches a spawn. Scope honesty: `isInCircular`/`getCircularForFile` have no production callers and turn-end only dbg-logs `hasCircular`, so the guard's payoff today is the correctness of future cache-hit results rather than user-visible output — which is input to the still-open step 4 of #766 (whether the turn-end madge pass should exist at all).
+- **`duplicate-function-arg` no longer fires a false duplicate when a parameter's default-value expression references an earlier parameter name (closes [#1256](https://github.com/apmantza/pi-lens/issues/1256))** — the query bound `(required_parameter (identifier) @NAME)` with no depth restriction, so an identifier at **any depth** inside the second parameter's subtree — the default value (`root = node`) or a type annotation — captured as `@NAME`, and `same_param_name` compared it to the first parameter's name and fired. Dogfooded live: `containsYieldInFunctionBody(node, root: TreeSitterNode = node)` in `clients/tree-sitter-client.ts` reported a phantom duplicate on every dispatch. Both captures now bind through `pattern: (identifier)`, the field the grammar actually exposes (`name:` does not exist on `required_parameter` — it would silently kill the rule; `pattern:` is already used by the sibling `variable-shadowing.yml`), so only the parameter NAME can match. Regression tests: a default-value reference must NOT match, and genuine duplicates with a default-valued earlier parameter must still match.
+
+- **Autofix surfaces now apply the same config as the lint surfaces that reported the diagnostics (closes [#1247](https://github.com/apmantza/pi-lens/issues/1247))** — `markdownlint-cli2 --fix`, `ruff check --fix` and `biome lint --write` ran with NO `--config`, so on projects without their own config the tool's default ruleset rewrote files per rules the lint surface never endorsed: markdownlint's default all-rules-on config produced whole-file rewrites of CHANGELOG.md/AGENTS.md and `#946` → `# 946` heading-spacing corruption (MD018), while ruff/biome applied default rule sets instead of the package-owned `core.toml`/`core.jsonc`. The lint runners and the autofix paths now consume ONE shared config-args seam (`markdownlintConfigArgs`/`ruffConfigArgs`/`biomeConfigArgs` in `clients/tool-policy.ts`) — package-owned fallback when the project has no config, the user's config when present — so the two surfaces cannot drift again. `biomeClient.fixFileAsync`/`ruffClient.fixFileAsync` gained an optional dispatch-cwd for discovery. Guarded by builder-level tests (fallback + user-config states for all three tools) and a pipeline-level test pinning the `--fix` invocation args.
+- **Three hand-rolled `.tmp-<pid>` staging writers bypassed `atomic-write.ts` and never inherited the #1205 fix, and the fixed staging name still collided across worker threads (closes [#1205](https://github.com/apmantza/pi-lens/issues/1205), closes [#1217](https://github.com/apmantza/pi-lens/issues/1217), refs [#1202](https://github.com/apmantza/pi-lens/issues/1202))** — #1205 made `writeFileAtomic`'s staging path unique per call, but only for writers that actually route through the module. `clients/instance-reaper.ts`'s `pruneDeadInstances` (machine-global `~/.pi-lens/instances.json`), `clients/gzip-stage-write.ts` (both persist workers' streamed-gzip stage write) and `clients/grammar-source.ts`'s `downloadGrammar` each interpolated their own per-PROCESS staging name, so all three still published torn files exactly as pre-#1205 code did. The reaper was the reachable one: `instances.json` is written fire-and-forget from `instance-registry.ts`'s `prunePids` as well, with nothing serializing the two, and `readInstanceRegistry` degrades a parse failure to empty — so a tear dropped **every** registered instance rather than the one entry being pruned. Reproduced against the pre-fix body at **22/40 unparseable on Linux**, the same scale as #1205's own 21/40. All three now source their staging name from `atomic-write.ts` (`writeFileAtomicAsync` for the reaper and `writeFileAtomic` for the grammar fetch, which also gains the failure-path staging cleanup neither hand-rolled copy had; `stagePathFor` alone for `gzip-stage-write.ts`, which needs its own streaming pipeline). `stagePathFor` itself gained `threadId`: its counter is per-THREAD (a worker gets its own module instance, so its own `_stageSeq` starting at 0) while `process.pid` is shared across every thread, so two threads each minted the identical `${target}.tmp-<pid>-0` — #1205's shared-inode tear reintroduced one axis over, and no longer hypothetical now that `gzip-stage-write.ts` is a real worker-side caller. The staging name is therefore `${target}.tmp-<pid>-<threadId>-<seq>`, covering the three ways two writes can overlap — pid across processes, thread id across threads, counter within one thread — and `STAGE_TMP_PATTERN` grew a third optional group so sweepers still collect leftovers in all three shapes on disk (`.tmp-<pid>`, `.tmp-<pid>-<seq>`, `.tmp-<pid>-<threadId>-<seq>`). `gzip-stage-write.ts`'s docstring claimed "the `stagePath` itself is only ever created by the atomic rename, so a crash mid-write can never leave a torn stage file behind" — true for a crash, false for concurrency, the same false-confidence pattern #1205 found in `atomic-write.ts`'s own docstring — and now scopes its guarantee to crash-safety and states that it provides no ordering and no isolation beyond tear-freedom. The repo-wide sweep #1217 asked for ran over every `rename` call site rather than a `.tmp-` grep, which is what surfaced `grammar-source.ts` (missed by the incidental discovery that filed #1217); the remaining renames are log rotation, installer moves, and LSP workspace edits, none of which stage. Every new guard was confirmed to fail against the pre-fix body on Linux, not merely to pass after (recurring defect shape 2/7): the reaper tear at 22/40, the gzip writers' renames at `ENOENT`, and two worker threads minting one byte-identical staging path.
+
+- **The review graph's stale-stage sweep deleted OTHER modules' in-flight atomic-write staging files out of the shared project cache dir (refs [#1206](https://github.com/apmantza/pi-lens/issues/1206), [#1202](https://github.com/apmantza/pi-lens/issues/1202))** — `sweepStaleStageFiles` (`clients/review-graph/builder.ts`) matched `entry.includes(".stage-") || /\.tmp-\d+$/` and `fs.rm`'d the result out of `getProjectDataDir(cwd)/cache`. The `.tmp-<pid>` alternative is the generic staging shape `clients/atomic-write.ts` produces for **every** durable store — diagnostic dispositions, cache-manager scanner data, project snapshot, call graph, codebase model, workspace/project diagnostics caches — not the review graph's property. A review-graph persist that readdir'd the cache dir while another process sat between its `writeFileSync` and its `renameSync` deleted that staging file, so the rename threw `ENOENT` (propagating out of `markDisposition` into the agent's mark tool for `bestEffort: false` stores) or silently dropped the update for `bestEffort: true` ones — one subsystem's garbage collection reaching into unrelated subsystems' transactions, and the inverse of the atomic-write contract. The predicate is now scoped to artifacts the review graph itself produces (basename starts with `review-graph.` **and** contains `.stage-`, covering `review-graph.json.gz.stage-<pid>-<gen>`, the checkpoint stage, and either's persist-worker `<stage>.tmp-<pid>`), and an entry whose embedded stage pid is still alive is skipped via the reaper's conservative `realIsPidAlive` (ESRCH-only-means-dead) rather than a second hand-rolled liveness probe — so a concurrent healthy owner's in-flight stage survives, and a recycled pid leaks one stage file rather than destroying a live one. Because the bare `.tmp-<pid>` shape is no longer matched at all, this is independent of the per-call-unique staging rename in #1205; the now-unowned orphaned-atomic-write-temp GC gap is tracked separately by #1228.
+
+- **`writeFileAtomic` published torn files for concurrent same-process writes — the staging name was per-PROCESS, not per-CALL (refs [#1205](https://github.com/apmantza/pi-lens/issues/1205), [#1202](https://github.com/apmantza/pi-lens/issues/1202))** — `clients/atomic-write.ts` staged every write at `${target}.tmp-${process.pid}`, so two in-flight writes from one process to one target shared a staging inode: both `open(O_TRUNC)`ed it, the first `rename` published that inode to the target, and the second writer's still-open fd kept writing into the now-published file. The result was a torn hybrid at the target path — measured 35/40 in the issue report and reproduced by the new regression test against the pre-fix body on **both** OSes — 13/40 on a Windows dev box and **21/40 on ubuntu-latest CI** (verified by pushing the pre-fix body to a throwaway draft PR so the test would actually run on the CI OS, rather than assuming a Windows-only reproduction generalizes — recurring defect shape 2/7). The test carries deterministic structural assertions too (two concurrent `bestEffort: false` writers must report two different `err.path` staging files; `stagePathFor` must never repeat), so the guard does not depend on winning a scheduler race on any platform. The precondition is violated by design: `recordLspChild` (`lsp/client.ts`), `updateHeartbeat` (`runtime-turn.ts`), `prunePids` (`instance-registry.ts`) and `appendRecentTouches` (`bus-publish.ts`) are all deliberately fire-and-forget, and every reader in that family swallows parse errors to `{}`/`[]`, so a tear degraded to silent TOTAL loss of the store rather than partial loss. Fixed by routing both the sync and async paths through a new `stagePathFor()` that appends a monotonic per-process counter (`${target}.tmp-<pid>-<seq>`), making the staging path unique per call; the failure-path cleanup unlinks that same per-call path, so it still removes exactly the file the call created. A counter rather than `randomBytes` because it is allocation-free on these hot per-turn/per-touch paths and makes collision impossible by construction rather than merely improbable, with `process.pid` still supplying cross-process distinctness. The module docstring previously claimed "a concurrent reader always sees either the fully-old or fully-new file" — true cross-process, false same-process — and has been rewritten to state the real guarantee (crash-safe replacement + tear-free publication) alongside what the primitive explicitly does NOT provide: no read-modify-write isolation, no ordering, no mutual exclusion, no fsync durability, no orphan reaping (tracked in #1228), and a Windows-specific `bestEffort: true` loss mode when a reader holds the destination open without `FILE_SHARE_DELETE`. The naming scheme is now exported as `stagePathFor`/`STAGE_TMP_PATTERN` so orphan-staging-file sweepers consume it instead of re-deriving `.tmp-<pid>` (the pattern keeps the `<seq>` group optional so pre-#1205 leftovers on disk are still swept); `sweepStaleStageFiles` in `review-graph/builder.ts` is migrated to it separately under #1206, which must add its own pid-based exclusion rather than rely on that sweeper's existing `.stage-<pid>-` own-marker, which does not cover the `.tmp-` branch.
+
+- **Dense word-index startup refresh no longer turns quadratic or monopolizes the TUI event loop (refs [#1197](https://github.com/apmantza/pi-lens/issues/1197))** — replacing one stale document is cheap, but the incremental path repeated posting-array filters even when almost the entire persisted index was stale: pi-lens refreshed 2,061 documents with zero reuse in 216.8s and recorded a genuine 22.5s event-loop block, while a linear full build of the same corpus took 7.5s. Refresh preflight now selects a separately-built full replacement before mutating the old index whenever the stale set's estimated WORK exceeds one full rebuild — density is not a bound, because per-document cost grows with the corpus: 800 documents with 239 stale (29.875%, under any 30% ratio) measured 90,577ms with a 39,553ms synchronous block against 1,029ms / 10.6ms for a full build, and at the 6,000-file cap up to 1,799 stale documents stayed on that path. The work model is calibrated against this repository's own 2,062-document corpus and its predicted crossover (23 stale documents) matches the measured one (~21). The >30% ratio, >30% file-set-churn and legacy-metadata transitions remain as-is. Every bulk path — the cooperative full builder and both refresh loops — now yields on an ~8ms monotonic budget OR'd with its item checkpoint rather than count-only, including within large documents and after any line of 4,096+ characters (a minified bundle previously got zero in-document yields). A build superseded mid-warmup returns gracefully instead of throwing out of the quick-mode warmup pass and skipping the #947 LSP pre-warm. Results remain byte-equivalent to the synchronous reference builder, superseded sessions never publish partial state, and sparse refreshes retain their unreadable-file retry semantics.
+
+- **Windows bare-command resolution ignored the caller's child `PATH`/`PATHEXT` and could reuse another environment's cached answer (closes #1199)** — `safeSpawnAsync` and deprecated `safeSpawn` now derive case-insensitive Windows command resolution from the exact normalized environment passed to the child, so managed command shims such as Knip's `.cmd` are found even when only `options.env.Path`/`PATH` contains their directory. Cache identity includes the effective path and extension list; explicit/relative Windows paths use `path.win32`, and the same canonical absolute cwd used by drive-relative resolution is passed to the child. Positive cache hits revalidate the executable, negative entries expire after one second, and successful managed installs invalidate the cache immediately, while existing shell, UTF-8, timeout, abort, and tree-kill behavior remains unchanged.
+
+- **`project_report`'s `toDisplayPath` hand-rolled relativization without the shape-aware `isWindowsPath` branch, mis-rendering a Windows-shaped path as the full absolute path on Linux CI (closes #1194, refs #1163 #1152 #1024)** — `clients/project-report.ts`'s `toDisplayPath` used host-default `path.isAbsolute`/`path.relative` directly, the exact defect `toProjectRelativePath` (`clients/path-utils.ts`) was fixed for in #1163 — its sibling `module-report.ts`'s `toDisplayPath` already delegates to that shape-aware helper, but this file reimplemented the same convention natively instead, so `path.isAbsolute("C:\\repo\\src\\x.ts")` returned `false` on Linux and short-circuited to the whole absolute path instead of `src/x.ts`. The #1163 sweep missed it because it grepped the `isWindowsPath` hot zone and this file never branched on it at all. Fixed by delegating to `toProjectRelativePath`, matching `module-report.ts`. Second-axis sweep of every other hand-rolled `path.relative`/`path.isAbsolute` relativizer in `clients/`/`tools/` found no further offenders: `call-graph.ts`'s `formatImpact` and `lens-map.ts`'s `toDisplayPath` already delegate to `toProjectRelativePath`; every other `path.relative`/`path.isAbsolute` hit resolves a live, same-process, same-OS path (dispatch context, LSP results, subprocess/runner output, filesystem walks) rather than a persisted/cross-OS review-graph path, so none share this class. Fail-then-pass verified directly against the pre-fix body under explicit `path.posix` semantics (not host-default, since a Windows dev box's bare `path` is already win32 and would pass vacuously) — it returned `"C:/repo/src/x.ts"` instead of `"src/x.ts"`, which the delegated implementation now corrects on any OS.
+- **`trivy-config.test.ts` hardcoded a POSIX path literal (`/tmp/main.tf`), so it failed on a Windows dev machine while staying green on Linux CI (closes #1190, refs #1024)** — the terraform pass-through tests built `ctx.filePath`/`ctx.cwd` from the string literals `"/tmp/main.tf"`/`"/tmp"` and asserted the mocked `safeSpawnAsync` call against those same literals. The runner itself (`clients/dispatch/runners/trivy-config.ts`) is OS-agnostic — it resolves the scan path with `path.resolve(cwd, ctx.filePath)` — but on Windows that resolves `/tmp/main.tf` to a drive-relative `C:\tmp\main.tf`, so the hardcoded POSIX-form expectation no longer matched: the inverse of the #1024 class (a test only holding on one OS, this time POSIX-only rather than Windows-only). Test-only fix: the two cases now derive `tfCwd`/`tfFile` via `path.join(os.tmpdir(), ...)` and assert against those same derived values, so the expectation is computed the same way the runner computes its resolved path — real on both POSIX and Windows, with no hardcoded separator on either side.
+
+- **Structural shape-5 hardening: LSP `touchFile` now returns a `{ diags, inconclusive, binding }` wrapper whose flags survive any copy by construction, plus a fail-closed graph-build-info guard (closes #1179, refs #1108 #1094 #1096)** —
+	the #1108 audit found all five side-channel flags safe as-is (every consumer
+	reads off the original), but the three LSP diagnostics flags stayed
+	fragile-by-construction: a non-enumerable property hung on the returned
+	diagnostics array, silently dropped by any `[...]`/`.map`/`.filter`/
+	`structuredClone`/`JSON` copy between producer and consumer (the class that bit
+	as #1094 `inconclusive` and #1096 `binding`). `touchFile` now resolves an
+	explicit `TouchFileResult` wrapper (`clients/lsp/diagnostic-binding.ts`) with
+	`inconclusive` and `binding` as ENUMERABLE fields alongside `.diags`, so a copy
+	operates on `.diags` and can no longer drop them — the copy-loss is impossible
+	by construction. Every flag-reading consumer was migrated in lockstep (the
+	cascade `readInconclusive`/`readBoundToCurrentDisk`/`isConfirmedTouch` and its
+	`.filter()` site in `clients/dispatch/integration.ts`, the dispatch LSP runner,
+	the `lsp_diagnostics` tool, the workspace-sweep `lens_diagnostics mode=full`
+	path, and the warm-attach IPC producer — which continues to re-surface
+	`inconclusive` as an enumerable DTO field over the socket). Behavior is
+	IDENTICAL — same flags, same values, same decisions; only the carriage
+	changed. `getAllDiagnostics`'s per-entry `binding` is DELIBERATELY left as a
+	lazy non-enumerable getter on the documented read-off-original contract (making
+	it enumerable would fire the per-file disk stat+hash on any incidental spread —
+	the stat storm its laziness exists to prevent). Separately closes a latent P3
+	from the #1108 review: `getGraphBuildInfoForGraph`'s global-slot fallback could
+	serve a SIBLING graph's build-info on a `_graphBuildInfoByGraph` identity miss,
+	feeding the `graph_degraded` marker gate a (possibly healthy) sibling verdict —
+	a new `graphBuildInfoIsTrustworthy` guard fails CLOSED so an unstamped/rehydrated
+	graph surfaces an honest degraded/unknown advisory instead of a #533 false
+	clean. Inert on the live path (every build stamps its returned graph before the
+	cascade reads it). An ast-grep rule remains not viable (AGENTS.md shape 5 is
+	semantic; cross-ref #1158).
+- **Per-entry widget observation timestamps: a cross-file cascade merge no longer over-clears a whole footer record, dropping only the genuinely-stale entries (closes #1186, refs #1093 #1092 #1020)** —
+	`reconcileCascadeNeighborLspErrors` → `commitDiagnostics` used to stamp the
+	ENTIRE merged record's single `touchedAt` with the incoming `observedAt`
+	(e.g. a passive snapshot's `entry.ts`, up to ~240s old), including PRESERVED
+	entries observed more recently. If the neighbor's mtime later fell between
+	that stale stamp and a preserved entry's true observation time,
+	`reconcileStaleWidgetFiles` dropped the WHOLE record — losing the newer
+	preserved findings (the residual documented at `clients/dispatch/integration.ts`).
+	`WidgetDiagnostic` now carries a per-ENTRY `observedAt`: `normalizeDiagnostics`
+	stamps each incoming entry at its observation time, the cascade merge keeps
+	each preserved entry's own prior stamp (never re-aging a fresh finding to the
+	incoming stamp), and `reconcileStaleWidgetFiles` gates per ENTRY — dropping
+	only entries observed before the file's current mtime, keeping the record when
+	any survive, and dropping the record only when empty (a clean, finding-less
+	record still gates on `touchedAt`). `PersistedWidgetState` bumps v1→v2:
+	`importWidgetState` accepts a v1 snapshot and migrates each stampless entry to
+	inherit the record's `touchedAt` (a safe, over-conservative default; a
+	missing/non-numeric version or a future version this build can't understand is
+	still rejected — the pre-existing strictness is preserved). The sibling gates
+	`dropStaleFiles`
+	(session-state-store) and `reconcileProjectDiagnosticsSnapshot` are unchanged
+	— both compare against a single save/scan time ≥ every entry's observation, so
+	a whole-record drop there already equals dropping every entry. The
+	`markDependentsUnverified`/seq-stamp half of #1093's sketch is a separate,
+	non-contained follow-up (left open under #1093).
+- **The `runtimeExitWindow` breaker map never dropped a stale/aged-out key, and its cooldown comment described the wrong call order (closes #1183, refs #1142 #1181)** — two P3 hygiene follow-ups from the #1181 review of the #1142 windowed-rate breaker in `clients/lsp/index.ts`. (1) `runtimeExitWindow` was only ever `delete`d on the currently-unreachable optional-trip path, so a key that crashed once then recovered kept a stale timestamp array forever (bounded by servers×roots, not a leak, but untidy). The "survived past the threshold" branch now also drops the key once every entry in its window has aged out, mirroring where `runtimeExitCounts` is already `delete`d there — anchored on the death's own `exitedAt` (not `Date.now()`) so it only ever fires for deaths `recordRuntimeExitWindow` declined to record (over the sleep-gap ceiling, or a missing `exitedAt`), never for a death that was just added to the window. (2) The `Math.max` cooldown comment claimed it "never shortens a longer cooldown the fast path may have just set," which has the ordering backwards — `state.broken` is `delete`d at the top of the method, so the window's `.get(key) ?? 0` always reads 0, and the fast path runs AFTER this block. Reworded to describe the actual ordering; harmless either way since the non-optional branch latches `permanentlyBroken` and the optional branch is currently unreachable. Comment-only for (2); pure map hygiene for (1) — trip logic, thresholds, and the fast path are unchanged.
+- **`allowScripts` entries had drifted from what the declared dependency ranges actually resolve to, so npm v12's exact-version script-approval check saw stale pins (closes #1176)** —
+	`package.json`'s `@ast-grep/cli` dependency range is `"^0.45.0"`, but the
+	`allowScripts` map still keyed its approval on `"@ast-grep/cli@0.44.1"` — a
+	version the range can no longer even resolve to. pi-lens has no
+	`allowScripts`-enforcing tool of its own (no `@lavamoat/allow-scripts`, no
+	`.npmrc` script policy), so the field does nothing for pi-lens's own
+	`npm ci`; its only audience is an external consumer or vetting tool reading
+	the *published* package. The published package ships **no lockfile**
+	(`package-lock.json` is not in the `files` array and there's no
+	`npm-shrinkwrap.json`), so that consumer fresh-resolves `"^0.45.0"` against
+	the registry — which lands on `0.45.1` (registry `latest`; only `0.45.0`
+	and `0.45.1` exist in the `0.45.x` line), exactly what the original report
+	observed. The correct target is therefore the **freshest in-range /
+	fresh-resolve version**, not the locally-committed lockfile's resolution —
+	so the entry is `"@ast-grep/cli@0.45.1": true`, and the committed
+	`package-lock.json` was also bumped (`npm install @ast-grep/cli@0.45.1`,
+	an in-range patch bump — the `^0.45.0` dependency range is unchanged) so
+	pi-lens's own dev tree and a fresh consumer resolve both land on the same
+	version. `0.45.1` ships the same `postinstall` script `0.44.1` needed
+	approval for. Swept every other `allowScripts` member for the same drift
+	class (a pinned exact version no longer matching the freshest version its
+	governing range resolves to): `@google/genai@1.52.0` (transitive via the
+	`@earendil-works/pi-coding-agent` devDependency) already matched, unchanged;
+	`protobufjs@7.6.4` (also transitive via `@earendil-works/pi-coding-agent`)
+	had drifted the same way and moved to `"protobufjs@7.6.5": true` — the
+	freshest in-range version, which here happens to match both the lockfile
+	and a fresh resolve. `@ast-grep/napi` (also range `^0.45.0`) was re-checked
+	for an install-time script at both `0.45.0` and `0.45.1` (`npm view
+	@ast-grep/napi scripts`) and has none in either, so it correctly has no
+	`allowScripts` entry. `fsevents@2.3.3` also has an install script
+	(`hasInstallScript: true`) but is intentionally NOT listed: it's
+	`dev:true, optional:true, os:["darwin"]`, so it's never part of a
+	consumer's production install and out of scope for this allowlist — noting
+	it here rather than leaving the omission silent. No other version-pinned
+	metadata (`overrides`/`resolutions`/`pnpm.overrides`/`packageManager`)
+	exists in `package.json` to drift, and a repo-wide grep for hardcoded
+	`0.44.`/`0.45.` ast-grep version literals outside `package.json`/the
+	lockfile turned up only historical comments in test files and one rule
+	doc-comment describing ast-grep's behavior as of a past version — not pins
+	that need to track the current range.
+- **`switch-case-termination` false positives for returning try/catch and exhaustive conditionals (closes #1079)** — the `no_terminating_statement`
+	post-filter only checked whether a case's last statement was a literal
+	terminator, so a case ending in `try { return … } catch { return … }` (or an
+	exhaustive `if/else`) was flagged even though every path returns. It now
+	runs a bounded, fail-safe control-flow analysis: trailing blocks,
+	`try/catch/finally` (a returning try completes after finally; a try body
+	that completes normally only terminates via a finally), and exhaustive
+	`if/else` (no else still falls through). It also honors an intentional
+	`// fallthrough` marker comment (ESLint `no-fallthrough` convention),
+	checked against comment nodes only so a `case "fallthrough":` value can't
+	suppress a finding. Genuine fall-throughs are still reported. TS + JS
+	regression fixtures cover grouped labels, try/finally, and intentional
+	fallthrough.
+- **Non-enumerable side-channel flags — the shape-5 copy-loss sweep (refs [#1108](https://github.com/apmantza/pi-lens/issues/1108))** — Audited every non-enumerable / identity-scoped side-channel flag hung on a returned diagnostics or graph value for the copy-loss class that bit as #1094 (`inconclusive`) and #1096 (`binding`): the `inconclusive` and `binding` flags on `touchFile` results, the lazy `binding` getter on `getAllDiagnostics` entries, and the `_graphBuildInfoByGraph` / `_graphImportChanges` WeakMaps keyed by `ReviewGraph` identity. All five are safe — every consumer reads the flag off the ORIGINAL producer object before any `.filter()`/`.map()`/spread, the one genuine JSON boundary (the warm-attach IPC socket) already re-surfaces `inconclusive` as an explicit enumerable response field, and both WeakMaps fail safe on a copy/rehydrate miss (a global-slot fallback for build-info; a full-rebuild + generation-gate for the import delta). Hardened the contract durably where it is not owned by an in-flight PR: documented the "read off the original, never a derived copy; re-surface as an enumerable field to cross a serialization boundary" carriage contract on the `DiagnosticBinding` type, and added an IPC-boundary guard test asserting the consumer still honors an inconclusive answer carried as an enumerable field across the JSON round-trip. The producer-side type annotations and the structural `{ diags, inconclusive, binding }` wrapper migration live in the LSP index (owned by the #1142 breaker work) and are deferred to a tracked follow-up ([#1179](https://github.com/apmantza/pi-lens/issues/1179)); an ast-grep rule is not viable (AGENTS.md shape 5 is semantic — good and bad uses are syntactically identical).
+- **LSP runtime-exit breaker missed persistent low-frequency crash loops (closes #1142, refs #1127 #1139)** —
+	#1139's `runtimeExitCounts` counts a client death toward the circuit breaker
+	only when its lifetime (`exitedAt - spawnedAt`) is under
+	`RUNTIME_EXIT_UPTIME_THRESHOLD_MS` (60s) — the hot crash loop (opengrep dies in
+	seconds). A death OVER the threshold falls into the "survived → reset the
+	streak" branch, so a server that reliably dies at ~65-90s after every spawn
+	NEVER tripped: every death reset the streak and it churned forever, a slow loop
+	the hard-cutoff design structurally can't detect. Added a SECOND, independent
+	windowed-rate trip that COMPOSES with (does not replace) the fast path:
+	`RUNTIME_EXIT_WINDOW_TRIP_COUNT` (5, = `BROKEN_PERMANENT_AFTER`) non-intentional
+	deaths within a rolling `RUNTIME_EXIT_WINDOW_MS` (15 min) window trip the
+	breaker regardless of each death's individual lifetime. N/M err against
+	false-tripping: five clustered non-intentional deaths is definitionally a loop,
+	and sparse benign crashes age out of the rolling window before five coincide.
+	The fast path is byte-for-byte unchanged — a hot loop still trips at exactly 5
+	consecutive early exits, never delayed by the window. Benign over-threshold
+	"deaths" are excluded: intentional teardowns (user restart, config/workspace
+	reload, session change, #743 eviction, generation handoffs) are gated out by the
+	existing `!wasShutdownIntentional()` guard the windowed trip shares, and a
+	death whose lifetime exceeds a 10-min ceiling — a genuinely long healthy run, or
+	an `exitedAt - spawnedAt` inflated across a machine-sleep/Modern-Standby suspend
+	(the #1122/#1139 death-timestamp lesson) — is not recorded, backed structurally
+	by per-server-key windowing (one suspend kills at most one live client per key).
+	The death-timestamp window is bounded on BOTH axes (prune aged-out entries +
+	hard-cap the array at the trip count, drop-oldest) and needs no timer (ages by
+	prune-on-check). Fail-then-pass regression tests cover all three cases: the slow
+	~65-90s loop now converges (verified failing on pre-fix — the whole bug), the
+	hot loop still trips fast (no regression), and a sleep-gap/long-run death,
+	sparse aged-out crashes, and deliberate restarts do NOT trip.
+- **Closed out the three #1134 P3 tails left after #1138's Svelte oxfmt support (closes #1134)** —
+	1. **TOML line-match heuristic limits.** `hasOxfmtSvelteConfig`'s
+	   `OXFMT_SVELTE_TOML_TRUE` regex required `svelte = true` to be
+	   immediately followed by end-of-line/end-of-file, so a trailing inline
+	   comment (`svelte = true  # enable`) false-negatived. Relaxed the
+	   trailing match to tolerate an optional `#`-comment, and added a
+	   docblock sentence documenting the heuristic's remaining known limits
+	   (it is a line match, not a TOML parser — a `[table]`-sectioned or
+	   multi-line-string `svelte = true` occurrence could still false-positive;
+	   accepted since that only causes oxfmt to be offered, never a silent
+	   formatter failure). Added a fail-then-pass regression test for the
+	   `svelte = true  # comment` case (`tests/clients/tool-policy.test.ts`).
+	2. **Monorepo asymmetry.** `hasOxfmtSvelteConfig`'s svelte-dependency check
+	   stops at the nearest `package.json` (`hasNearestPackageJsonDependency`)
+	   while its config walk goes all the way to the repo root
+	   (`walkUpDirs`) — a root-level `svelte` dependency with a sub-package
+	   `cwd` under-offers oxfmt for `.svelte` there. Documented via a
+	   docblock sentence (no behavior change: this cell fails safe —
+	   under-offering, never mis-offering a formatter that then errors at
+	   runtime — and stays untested by design, matching the async
+	   `.tflint.hcl` nearest-vs-root-walk note already in this file).
+	3. **docs/language-coverage.md's Vue row** showed formatter `—` though
+	   `.vue` has been wired to `prettier` (default) + `oxfmt` (appended via
+	   `OXFMT_SUPPORTED_EXTENSIONS`) since #1138 landed. Corrected the row to
+	   `prettier, oxfmt`.
+- **Rule-cache disk cache could replay a stale compiled rule set on a same-mtime+same-size rule-file edit (closes #1118, refs #1105 #878)** —
+	`clients/cache/rule-cache.ts`'s `computeRuleHash` fingerprinted every
+	effective rule file over METADATA only (`mtimeMs:size`) — the review-graph
+	first-filter without its content-hash CONFIRM step. A rule-file edit
+	preserving both mtime and byte size (git-checkout timestamp restoration, a
+	same-length tweak, a formatter that preserves mtime) replayed a stale
+	compiled rule set from `<language>-rules-v6.json`, and because this is a
+	PERSISTED disk cache, the stale set was re-persisted under the
+	fresh-looking fingerprint, poisoning every future process (the #878
+	`force`-reload failure mode, one axis over). Fixed by splitting the
+	fingerprint on rule-file origin, mirroring the project/bundled split
+	`yaml-rule-parser.ts`/`ast-grep-napi.ts` already use for ast-grep rules
+	(#1105): the small, mutable PROJECT-LOCAL subset (under
+	`<project>/rules/tree-sitter-queries/`) now gets a content-hash CONFIRM on
+	top of the metadata fingerprint; the ~705 BUNDLED files (immutable within a
+	process) stay metadata-only, so `RuleCache.get`'s per-edit tree-sitter
+	runner hot-path cost is unchanged when a project has no rule overrides.
+	`CACHE_VERSION` bumped v6→v7 so a v6 entry persisted under the old
+	metadata-only formula (a potentially poisoned one) misses once on upgrade
+	instead of being trusted. Fail-then-pass regression tests pin a rule
+	file's mtime via `utimesSync`, edit its content while preserving byte size,
+	and assert the cache invalidates for project-local files but still hits
+	for bundled-only rule sets; a third test confirms a persisted
+	metadata-only-fingerprinted entry is rejected post-fix.
+- **Formatter definitions and `FORMATTER_POLICY_BY_EXTENSION` were unbound hand-maintained inverse lists; added a bidirectional drift guard and fixed two latent mismatches (closes #1135; refs #1086 #1134 #883)** —
+	`clients/formatters.ts` (formatter → `extensions[]`) and `clients/tool-policy.ts`'s
+	`FORMATTER_POLICY_BY_EXTENSION` (extension → `formatterNames[]`) are hand-maintained
+	INVERSE mappings of the same relation with no test binding the two directions — the
+	#883/#209 single-source-of-truth class, and the general shape under #1134's oxfmt/.svelte
+	gap. Added `tests/clients/formatter-policy-consistency.test.ts`, which imports the real
+	`ALL_FORMATTERS` definitions and the policy maps and asserts both directions: every
+	definition extension is policy-included / a documented deliberate exclusion / a documented
+	no-policy fallback (so a definition gaining a policy-gated extension can't be silently
+	never-offered — #1134's exact symptom); and every policy `formatterName`/`defaultFormatter`
+	is a real formatter whose definition claims that extension or filename (so a broken option
+	can't be offered — including the terragrunt-hcl filename-keyed variant). Fixed two real
+	latent drifts surfaced by the guard, both behavior-identical (the mismatched entries were
+	already inert): the `.sass` policy listed `oxfmt` though oxfmt does not support `.sass`
+	(absent from `OXFMT_SUPPORTED_EXTENSIONS`), and the `.fish` formatter policy named
+	`fish-indent`, which has no `FormatterInfo` (it is a lint runner) — a dead, unsatisfiable
+	entry, now removed. A structural derive (tool-policy importing the definitions) was rejected
+	because `formatters.ts` already imports `tool-policy.ts`, so the reverse edge would create a
+	module import cycle; the test-based guard binds both directions while keeping the dependency
+	one-way. Also bound `AUTO_INSTALLABLE_DEFAULT_FORMATTERS` keys to real formatter definitions
+	(same formatter-name-reference class). The guard reads four newly-exported read-only symbols
+	(`ALL_FORMATTERS` plus the three policy maps `FORMATTER_POLICY_BY_EXTENSION`,
+	`FORMATTER_POLICY_BY_FILENAME`, `AUTO_INSTALLABLE_DEFAULT_FORMATTERS`), and its own two
+	allowlists (deliberate exclusions, no-policy fallbacks) each carry a minimality check so
+	they cannot rot into blanket escape hatches.
+- **Pull-diagnostics entries never bound to document content, so they never demoted (closes #1104, refs #1095 #1096 #1100)** —
+	#1096 bound LSP diagnostics to a content fingerprint on the PUSH path
+	(`publishDiagnostics` version echo + send-time hash); the PULL path
+	(`textDocument/diagnostic`, `workspace/diagnostic`) recorded no fingerprint
+	at all, so pull-served cache entries read binding `"unknown"` forever and
+	the #1096 P2-1 service-sweep binding gate could never protect them. Fixed by
+	threading the server's `resultId` and a request-time content hash through
+	both pull requests: a `"full"` report is fingerprinted (the single-file path
+	reuses the exact sent-content hash `recordSentContent` already captures on
+	every didOpen/didChange — no extra read; the project-wide
+	`workspace/diagnostic` pull hashes disk bytes at request time since files
+	may not yet be open when it fires), and an `"unchanged"` report (now
+	requested via `previousResultId`/`previousResultIds`) inherits the prior
+	pull's diagnostics AND binding instead of being misread as a confirmed-clean
+	`[]` (the #570/#571 false-clean shape). The workspace pull-sweep record site
+	(`clients/lsp/index.ts`) now threads this `contentHash` into
+	`workspaceDiagnosticsCacheCtx.record()`, closing the gap the site's own
+	`#1095` doc comment used to document as intentional. Also closed an
+	AGENTS.md shape-5 gap in the sibling per-file touch path: `processFile` read
+	the `#1095` binding off the RAW `touchFile` diagnostics array before
+	`applyAuxiliarySuppressions`' `.filter()` rebuilds it (a `.filter()` copy
+	does not carry a source array's non-enumerable `.binding`), and
+	`LSPService.mergeBinding` no longer gates a contributor's `contentHash` on
+	that SAME contributor also carrying a `version` — pull bindings
+	legitimately carry a hash with no version, and the old gate silently
+	dropped it. Folded in two #1100-review P3s on the same surface: the
+	cascade's degraded/fallback display paths and the `lsp_binding_rejected`
+	indeterminate-advisory preamble (`clients/runtime-turn.ts`), which
+	previously reused the graph-unavailable wording even when the review graph
+	was fine and only the LSP display was withheld, now use a
+	binding-rejection-specific frame. Fail-then-pass regression tests cover:
+	the pull-sweep record site actually receiving a `contentHash`; a
+	pull-recorded entry whose content changed under a matching mtime being
+	demoted (not replayed) on the next sweep; the per-file touch path's binding
+	surviving the suppression filter; and the `"unchanged"`-report inheritance
+	on both the single-file and workspace pull protocols.
+- **Config caches gated freshness on mtime alone — the mtime-only cache-freshness class sweep (closes #1105)** —
+	Completed the shape-6 (freshness stamp that doesn't cover the data's real
+	dependency) sweep the #1092→#1119 diagnostics/word-index arc deferred. Audited
+	every persisted/derived cache with an mtime/TTL key: word-index (#1119),
+	`rule-cache.ts` (`mtime:size`), `sgconfig.ts` (content-hashed), the
+	`yaml-rule-parser` project/bundled split (project rules content-hashed via
+	`loadYamlRulesFresh`, bundled dir-mtime is safe by process-lifetime
+	immutability), `reverse-deps` (snapshot-seq/generation-coupled), installer
+	`probe-cache` (existence re-validated every read + ast-grep version-family
+	verify — mtime is a refresh hint, not the correctness gate), `TreeCache`
+	(content-hash authoritative, #890), and the project-snapshot per-file
+	`mtime:size` entries — all already-hardened or safe. The one gap: the
+	`.pi-lens.json` config caches gated reuse on the config file's **mtime alone**,
+	so an in-place edit that preserved mtime (git checkout timestamp restoration, a
+	same-second rewrite) but changed the file's byte length replayed a stale parsed
+	config / ignore matcher — a config that drives mutation, ignore, and rule
+	policy. This spanned every freshness gate in the two files: the root parsed-
+	config caches (`loadPiLensProjectConfig`/`loadPiLensConfigInDir` in
+	`clients/project-lens-config.ts`), the root ignore-matcher cache, and — the
+	member found in adversarial review — the **nested `.pi-lens.json`/`.gitignore`
+	layering cache** (`patternsForDir`, #783) in `clients/file-utils.ts`, which
+	short-circuits AHEAD of the root caches so a preserved-mtime, length-changing
+	edit to a NESTED config replayed stale patterns for that subtree. Fixed by
+	adding **`size` as the free second axis** of the review-graph `size:mtimeMs`
+	signature to every gate — the root `.pi-lens.json` (threaded through
+	`PiLensConfigMarker` in `clients/workspace-topology.ts`), the root `.gitignore`
+	and global `~/.pi-lens/config.json` (via a shared `fileFreshnessSignature`
+	helper), and both the nested `.pi-lens.json` and nested `.gitignore` axes. The
+	same stat that yields mtime already reads size, so the cheap hit path stays
+	cheap (no content hashing on the hot path). The residual (identical mtime AND
+	identical size, changed content) matches the review-graph/word-index accepted
+	residual by design. Fail-then-pass regression tests cover the root and nested
+	gates (each proven to replay stale on the pre-fix mtime-only code); FS-agnostic
+	(mtime pinned via `utimesSync`, size varied by content length) so they exercise
+	the gates identically on Linux CI.
+
+- **Windows drive-root & autofix-snapshot `readdirSync` blocked the event loop on slow cloud-backed dirs (refs #1137)** —
+	the genuine synchronous event-loop-block tier from #1122 (the 1.6–10.6 s
+	single-process blocks in `latency.log`, distinct from the machine-level
+	Modern-Standby/commit-exhaustion artifacts dispositioned in #1122 and tagged
+	`suspectSystemStall` by #1125). On a OneDrive/network-backed path a stalled
+	synchronous directory read blocks the Node loop — and pi's TUI — for the whole
+	stall. Converted the two clearly-live-path, low-risk offenders: (a) the Windows
+	Ruby drive-root enumeration (`readdirSync(driveRoot)` scanning `C:\` for
+	`ruby<N>` installer dirs), previously re-run **synchronously on every LSP spawn**
+	in `buildAugmentedPath` (PATH build) and on every Ruby candidate build in
+	`rubyBinCandidates` — now a shared `clients/lsp/ruby-drive-dirs.ts` module that
+	**memoizes** the result once per process (O(1) amortized) and reads the drive
+	root **off the loop** via `fs.promises.readdir` on the hot spawn path; and
+	(b) the `tool_result` autofix side-effect snapshot walk (`snapshotDirInto`,
+	`clients/pipeline.ts`), whose per-directory `readdirSync`/`statSync` are now
+	`fs.promises.readdir`/`stat` (the walk was already async + chunk-yielding, but
+	each synchronous per-dir read still blocked on a cloud stall). Same outputs,
+	just non-blocking. `measureMaxSyncBlockMs` occupancy guards assert the converted
+	drive-root path no longer holds the loop and fail against the pre-conversion
+	sync shape. Remaining suspect sites (the shared `walkTreeStackAsync` per-dir
+	read in `clients/source-walker.ts`; `hasProjectMarker`/`expandWorkspacePattern`
+	deep in sync memoized/bounded chains; the `safe-spawn.ts` Windows `spawnSync`
+	teardown/cached paths) are deferred as scoped follow-ups on #1137 — each ripples
+	into a widely-called sync API or subprocess-teardown correctness.
+- **`session_start_sequence_read` was an unbounded synchronous blocking read on the session_start hot path (closes #1162)** —
+	`readLatestProjectSequence` called `fs.readFileSync` on the project
+	change-log before `session_start_total` returned; normally ~2ms, but under
+	host I/O pressure it had no escape hatch and was observed to balloon to
+	2125ms in production latency.log. A `setTimeout`/`Promise.race` timeout
+	cannot preempt a synchronous read (the thread only returns to the event
+	loop once the OS call returns), so the fix adds an async twin
+	(`readLatestProjectSequenceAsync`, `fs.promises.readFile`) and races it
+	against a 250ms budget (`PI_LENS_SEQUENCE_READ_BUDGET_MS`-overridable) in
+	both the quick-mode and full-mode session_start paths. On a healthy read
+	(the common case) this adds ~zero overhead; on a stalled read, session_start
+	proceeds immediately with the safe cold-start sequence (only gates
+	snapshot freshness, never correctness) while the real read finishes in the
+	background and re-seeds the runtime — skipped for a one-shot `pi --print`
+	process via `isPrintMode()`, screening the #1154/#1153 one-shot
+	referenced-handle retention class. The fallback is never silent: the
+	`session_start_sequence_read` latency line now carries a `timedOut` flag,
+	and a background reseed logs its own
+	`session_start_sequence_read_deferred_reseed` phase. Fail-then-pass
+	regression tests inject a controllable slow read and assert session_start
+	returns within budget, falls back to cold-start with the flag set, and
+	still seeds normally on the healthy path. Adversarial review (#1168) caught
+	two P3s in this exact stall regime, both fixed in the same PR: (1) the
+	background reseed's `isCurrentSession` guard caught a cross-session move-on
+	but not a SAME-session advancement — an edit landing in the stall window
+	could have its `bumpFileSeq` result clobbered by a late reseed of the
+	pre-edit state; fixed with a `runtime.projectSeq > 0` guard (the cold seed
+	always sets it to exactly 0, so `> 0` at reseed time can only mean an
+	in-window bump happened). (2) The cold sentinel's `projectSeq: 0` was
+	indistinguishable from a project's legitimate first-ever snapshot (also
+	persisted at `seq === 0`), so a timed-out read could hydrate a stale seq-0
+	snapshot as fresh; fixed with a dedicated `UNKNOWN_PROJECT_SEQ` (`-1`)
+	sentinel fed only to the freshness check (never to `runtime.projectSeq`
+	itself, keeping fix (1)'s guard valid). Both have their own fail-then-pass
+	regression tests.
+- **Resource-sampler Windows CIM spawns were not `.unref()`'d, the same one-shot-retention shape as the orphan reaper (refs #1155)** —
+	`clients/resource-sampler.ts`'s two Windows-only `Get-CimInstance Win32_Process`
+	spawns (`findDescendantPidsWindows`'s descendant-tree lookup and
+	`sampleProcessesWindows`'s CPU/RSS query) used `stdio:["ignore","pipe","ignore"]`
+	with a piped, `data`-listener-attached stdout and neither the child nor its
+	stdout was ever `.unref()`'d — the same shape #1153/#1160 fixed for the orphan
+	reaper (shape 4 of AGENTS.md's recurring-defect catalog: a referenced handle
+	that outlives a one-shot settle). The sampler was empirically absent under a
+	trivial `pi --print` prompt (its own `setInterval` was already unref'd, and it
+	only runs bracketed to an awaited analyzer spawn), but was not safe by
+	construction for a file-editing repro that does exercise it. Fixed by
+	extracting the reaper's `unrefReaperChild` AND its `spawnCollectStdout`
+	spawn→pipe-stdout→resolve-on-close plumbing into a shared, dependency-free
+	`clients/child-unref.ts` (`unrefChildAndPipes`, `spawnCollectStdout`) and
+	calling `spawnCollectStdout` at both sampler spawn sites — a single source
+	of truth for both modules instead of a second hand-rolled copy (the
+	promotion also resolved a SonarCloud new-code-duplication gate failure:
+	adding an identical `unrefChildAndPipes(child)` line to both near-identical
+	spawn blocks had pushed duplicated-line density over the 3% threshold;
+	collapsing both blocks to parse-only call sites around the shared helper
+	removed the duplication instead of adding to it). Unref only detaches this
+	child ALONE from keeping a settled one-shot alive; in an interactive/
+	long-lived session (or one bracketed to real analyzer work) the loop stays
+	referenced for other reasons, so sampling is unaffected — the parse logic
+	at both call sites is otherwise unchanged, so a spawn/error failure still
+	resolves to the same empty/partial result as before. Fail-then-pass
+	regression tests assert both spawn sites unref the child and its stdout, in
+	both the sampler and (unchanged) the reaper.
+- **`toProjectRelativePath` never relativized a Windows-shaped path off native Windows (closes #1163, refs #1150/#1152/#1161/#1024)** —
+	shape-2 bug-class sweep of the `path.*`-on-cross-shaped-input hot zone.
+	`clients/path-utils.ts:toProjectRelativePath` used the host-default
+	`path.isAbsolute`/`path.relative` even when the input was Windows-shaped
+	(drive letter or UNC). On Linux CI, `path.isAbsolute("C:\\repo\\src\\x.ts")`
+	is `false` (no POSIX leading slash), so the function short-circuited and
+	returned the whole absolute path instead of the project-relative `src/x.ts`
+	it produces on Windows — a persisted call-graph symbol-key path or graph
+	display path (via `module-report`/`lens-map`'s `toDisplayPath` and
+	`call-graph`'s `formatImpact`) rendered as a full absolute path on Linux
+	(green-locally / wrong-on-CI, the #1024 divergence class). Fixed
+	shape-conditionally (`isWindowsPath(p) ? win32 : path`, the #1152 idiom):
+	a Windows-shaped path is parsed with `win32.*` on ANY OS; native same-OS
+	paths are unchanged. Fail-then-pass regression tests feed `C:\...`/UNC
+	literals as INPUT and assert the relative result on any OS (meaningful on
+	Linux CI). The rest of the swept hot zone
+	(`widget-state`/`file-utils`/`call-graph`/`installer`/`elixir-check`, plus
+	`file-role` #1152 and `resolveNonExisting` #1150 already fixed) was audited
+	and cleared as native-by-design — inputs are real on-disk paths the running
+	OS produced (cwd/project-roots/scanned files, `path.resolve`'d first) or
+	already fold through `normalizeEphemeralMapKey`/`PathKeyedMap`/the
+	regex-based `parseSymbolKey`.
+- **`generated-artifacts.ts` used module-default `path.basename` on Windows-shaped paths, under-detecting lockfiles/declarations off native Windows (closes #1161, sibling of #1150/#1152)** —
+	`hasStrongGeneratedArtifactPath` (lockfile match), `hasWeakGeneratedFileNamePattern`
+	(name-pattern match), and `isDeclarationFile` (`.d.ts`/`.d.mts`/`.d.cts` match)
+	all took the module-default `path.basename(filePath)` on shape-committed
+	input. On Linux CI, `path.basename("C:\\proj\\package-lock.json")` finds no
+	POSIX separator and returns the whole string unchanged, so
+	`LOCKFILE_NAMES.has(...)` misses — a Windows-shaped lockfile or declaration
+	path was silently treated as ordinary source. `generated-artifacts.ts` is
+	imported by `file-role.ts`'s `"generated"` branch, so this residual sat
+	within `detectFileRole`'s own call tree even after #1152 fixed the
+	dir-segment/basename split there. Fixed with a shared `basenameForShape`
+	helper that routes through `path.win32.basename` when `isWindowsPath`
+	(exported by #1152) is true, mirroring `file-role.ts`'s fix exactly —
+	shape-conditional, not shape-committed, so native-OS classification is
+	unchanged. The strong directory-segment match (`pathSegments`, which splits
+	on `[\\/]+`) was already shape-safe and untouched. Fail-then-pass regression
+	tests cover a `C:\...`-shaped lockfile and `.d.ts` literal.
+- **Quick-mode background warmup kept a one-shot `pi -p`/`--print` process alive (closes #1154)** —
+	`handleSessionStart` forces **quick mode** for both a real `pi -p`/`--print`
+	one-shot AND an interactive process's first session (to protect keystroke
+	latency, then warm caches for the next `/new`). Quick mode scheduled a +2s
+	background warmup that (1) armed a `setTimeout` that was **not** `.unref()`'d —
+	violating the repo-wide convention that every background timer is unref'd
+	(`clients/runtime-session.ts` previously had zero `.unref()` calls) — and
+	(2) launched LSP-prewarm children + a language-profile source walk that
+	outlive settle with **no `session_shutdown` abort**. In a one-shot (which
+	exits right after the turn and has no future session to warm) both are pure
+	waste AND referenced-handle keep-alives that hold the settled process open —
+	the located **#1122 hypothesis-A** concern and a member of the
+	one-shot-retained-by-a-referenced-handle class of #1097/#1110/#1148/#1149.
+	Fixed by (a) skipping the warmup entirely in print mode via a new shared
+	`isPrintMode()` helper (`clients/print-mode.ts`) — an interactive first
+	session (quick but not print) still warms — and (b) `.unref()`'ing the warmup
+	timer as defense-in-depth + convention conformity. Also unref'd the adjacent
+	full-mode `scheduleStartupScans` deferred timers (same latent violation, not a
+	one-shot member today). This resolves the #1122 hypothesis-A tail (cross-ref
+	#1122). Fail-then-pass regression tests assert the warmup does not run in print
+	mode and the scheduled warmup timer is unref'd.
+- **`detectFileRole` misclassified a Windows-shaped path off native Windows (closes #1152, latent sibling of #1150/#1151)** —
+	`clients/file-role.ts:detectFileRole` used the module-default `basename`/
+	`dirname` (POSIX on Linux) even when the input path was Windows-shaped
+	(drive letter or UNC prefix). A backslash-only `C:\...` path has no `/`
+	for POSIX `dirname` to find, so it collapsed to `"."` and the dir-based
+	role branches (`/tests/`, `/spec/`, generated-marker dirs) silently
+	misclassified — the byte-identical forward-slash form already worked,
+	since POSIX `dirname` handles `/` regardless of the leading drive
+	letter. `detectFileRole` is platform-native by design, so the fix is
+	shape-conditional rather than shape-committed (unlike #1151's
+	`resolveNonExisting`, which is already win32-committed): a Windows-shaped
+	path (per the now-exported `isWindowsPath`, `clients/path-utils.ts`) is
+	parsed with `path.win32.basename`/`dirname` regardless of the running
+	OS; a same-OS-native path is unaffected (native win32 already equals the
+	module default there; native POSIX was never win32-shaped). Added
+	regression coverage in `tests/clients/file-role.test.ts` asserting
+	coherent `"test"`/`"init"` classification for `C:\...`, `C:/...`, and
+	UNC-shaped inputs regardless of the running OS.
+	`clients/lsp/server.ts:639`'s `normalizeSlashKey(path.dirname(path.resolve(file)))`
+	(flagged in #1151's review as the same shape) was audited and verified
+	**safe, not fixed**: `path.resolve(file)` runs before `dirname`, so by
+	the time `dirname` sees it the value is already coerced to the running
+	OS's native absolute-path shape — `file` here is always a real on-disk
+	path produced by this process's own directory walking (extension-root
+	resolution backed by real `existsSync`/`stat` probes, confirmed via
+	`tests/clients/lsp/typescript-extension-root.test.ts`), never a
+	persisted or cross-OS-supplied literal. Same "platform-native by
+	design" exemption #1151 already applied to `path-utils.ts`'s
+	`walkUpDirs`/`findNearestContaining` family.
+- **Orphan-reaper fire-and-forget PowerShell/`ps` spawns kept a completed `pi --print` alive past settle (closes #1153)** —
+	the orphan reaper (`clients/instance-reaper.ts`) is fired fire-and-forget from
+	`session_start` (`index.ts` `sweepOrphans`/`sweepUntrackedOrphans`), not
+	awaited and not gated out of one-shot/`--print` mode. Its OS-process-table
+	enumeration spawns (`enumerateManagedProcesses`, `queryCommandLines`,
+	`findPidsByMarkerWindows` — PowerShell on Windows, `ps` on POSIX) used
+	`stdio:["ignore","pipe","ignore"]` with a `data` listener and **no `.unref()`
+	anywhere in the file**. A piped, listener-attached stdout stream keeps the
+	event loop REFERENCED until the child `close`s, and `sweepUntrackedOrphans`
+	guarantees ≥1 such PowerShell on every Windows `session_start` — so a settled
+	one-shot process could not exit until that PowerShell finished cold-starting
+	(routinely 300 ms–2 s). This is the child-process member of the referenced-
+	handle class (#1097/#1110 timers, #1148/#1149 worker ports). Fixed by
+	`unref()`-ing every reaper child AND its stdio pipes (a `child.unref()` alone
+	does not release a piped stdout that re-refs the loop) via a shared
+	`unrefReaperChild` helper applied at all six spawn sites (the five enumeration
+	spawns plus `killPidTree`'s `taskkill`). Unref, not a print-mode skip: the
+	reaper is a machine-wide orphan backstop, not a next-session-only concern, so
+	gating it out of `--print` would blind orphan cleanup on print-only machines
+	(CI/automation/subagents — exactly where one-shots dominate and orphans
+	accumulate); unref preserves the sweep in interactive sessions (the loop stays
+	referenced for other reasons, so every child's `close` still fires and the
+	sweep completes) while letting a genuinely-settled one-shot exit without
+	waiting. Regression test spawns a fake child per spawn site and asserts the
+	child + its stdout are unref'd (fails pre-fix, passes post-fix).
+- **Persistence workers could keep completed one-shot processes alive ([#1148](https://github.com/apmantza/pi-lens/issues/1148))** — project-snapshot and review-graph workers called `unref()` before registering their `"message"` listeners, and Node re-referenced the public `MessagePort` when each listener was added. Both workers now install all lifecycle listeners before `unref()`, so persistence remains asynchronous without retaining an otherwise-finished `pi --print` or subprocess workflow. Real child-process regression tests require both persistence paths to finish writing and exit naturally.
+- **`normalizeFilePath` mangled a Windows-shaped path on non-Windows OS (closes #1150)** —
+	`normalizeFilePath` commits to its win32 branch by path *shape*
+	(`isWindowsPath`), so a `C:/…`- or `C:\…`-shaped path enters that branch on
+	ANY OS — but `resolveNonExisting`'s upward walk used the module-default
+	`dirname` (POSIX on Linux) while the rest of the branch already used
+	`win32.resolve`/`win32.normalize`. On Linux the POSIX `dirname` found no
+	separator in the win32-resolved path, collapsed to `.`, stopped the walk at
+	`process.cwd()`, and produced `<cwd>/file.ts` instead of the literal key — so
+	a Windows-shaped path normalized to a DIFFERENT key on Linux than the
+	byte-identical literal it is on Windows (the #1024 OS-divergence class,
+	surfaced by #1139's green-on-Windows/red-on-Linux-CI). Fixed by using
+	`win32.dirname` in the win32-committed branch, making the function internally
+	coherent regardless of the running OS. Guarded by a both-OS-meaningful
+	regression test (native win32 path on Windows; shape-committed win32 branch on
+	Linux) and an AGENTS.md convention: tests must derive `normalizeMapKey`-keyed
+	structure keys via `normalizeMapKey`, never hardcode a drive-letter literal.
+- **Workspace-edit preflight: five contained P3 deferrals from #1085 (refs #1085)** —
+	`clients/lsp/edits.ts`:
+	- **P3-2** `mergeWorkspaceTextEditsByPriority`'s exact-duplicate dedup
+	  collapsed identical zero-width inserts duplicated within ONE server's
+	  own edit on the `renameFile` merge path, contradicting the documented
+	  multiplicity invariant (several identical zero-width inserts at one
+	  point are meaningful, same as `validateTextEdits` on the normal apply
+	  path). The dedup now only applies to non-empty ranges; a genuine
+	  cross-server exact duplicate (two servers proposing the identical
+	  non-empty replace) still collapses to one.
+	- **P3-3** an ordered edit `rename(b→c); create(b); textEdit(b)` was
+	  falsely rejected in preflight ("text edit target does not exist"): a
+	  `create` at a path vacated by an earlier rename in the same edit had
+	  `resolveVirtualPath` return `undefined` (correct — the path is
+	  virtually gone), so the created state was silently discarded instead
+	  of recorded. Added a `virtualOverrides` overlay, keyed on the raw
+	  query path, consulted only when `resolveVirtualPath` cannot resolve a
+	  physical address, so a later op at that same path (e.g. the trailing
+	  text edit) sees the re-established file.
+	- **P3-4** `version: null` (LSP 3.17: "don't check") combined with a
+	  numeric version for the SAME uri across two edit containers incorrectly
+	  threw "conflicting text document versions". A numeric version is now
+	  authoritative and adopted over a `null`/`undefined` counterpart; two
+	  genuinely different numeric versions still conflict, and a numeric
+	  version adopted from a `null` pairing is still checked against the live
+	  document version (a stale adopted numeric is still rejected).
+	- **P3-6** `fileDetails[].importsChanged` reported "the file contains any
+	  import statement" (`/^import\s/m.test(updated)`) rather than "this edit
+	  changed an import/re-export line", over-invalidating downstream
+	  dependency-graph re-checks (`cache-manager.ts`'s `importsChanged`
+	  filter, `lsp-mutation.ts`'s `addModifiedRange`) on every edit to a file
+	  that merely already had imports. Now compares an import/re-export-from
+	  line signature of the pre- and post-edit content; unchanged unless the
+	  edit actually touched those lines. `create`/`rename`/`delete` keep
+	  their existing conservative flags (a create writes an empty file;
+	  rename/delete are structural, not diffable against pre-edit text).
+	- **P3-8** an ordered edit that CREATEs `foo.txt` then case-renames it to
+	  `Foo.txt` within the SAME edit fail-closed with "destination already
+	  exists" on a case-insensitive FS: the alias check (`isSameFsEntry`)
+	  lstats disk, but the just-created file exists only in the preflight's
+	  virtual overlay, never on disk yet. The rename branch now also treats
+	  a rename as an alias when the destination's cached `VirtualFile`
+	  object is referentially identical to the source's (both `stateFor`
+	  calls resolve through the same case-folded map key), before falling
+	  back to the physical `isSameFsEntry` probe — which is unchanged for
+	  genuinely-physical paths, so the #1024/#1120 ino-guard and
+	  case-sensitivity invariants are untouched.
+
+	**Deferred at the time (now fixed, see below):** P3-5 and P3-7 were
+	rehomed to #1147; see the #1085 closing comment for that history.
+- **Workspace-edit CRLF boundary class + rename close-failure plaintext reopen (closes #1147, refs #1085)** —
+	the two P3 deferrals left open after #1146:
+	- **P3-5** (`clients/lsp/edits.ts`) — #1120 fixed only the past-EOL clamp
+	  member of the CRLF-boundary class. Two general members remained: (a) a
+	  `newText` containing a bare `\n` was spliced verbatim into a CRLF
+	  file's content, producing mixed line endings, because the LSP
+	  workspace-edit apply path (unlike the host-edit path) never
+	  EOL-normalized `newText`; (b) `utf16Position`'s past-EOL clamp only
+	  triggered on `character > wireLength`, so an in-bounds,
+	  caller-supplied `character === wireLength` on a line whose `\r` is
+	  folded into `lineTextAt`'s with-`\r` length landed the position
+	  squarely between `\r` and `\n`, splitting the pair on write. Fixed by
+	  (a) normalizing every `newText` through the exact
+	  `detectLineEnding`/`normalizeToLF`/`restoreLineEndings` contract
+	  `clients/host-edit-normalize.ts` already uses for the host-edit path
+	  (LF files are unaffected — `restoreLineEndings` is the identity for
+	  `"\n"`), applied once in `normalizeTextEditsForContent` so it covers
+	  both the preflight virtual-content chain and the final on-disk write;
+	  (b) clamping on `character > clampedWireLength` (the `\r`-stripped
+	  length) instead of the with-`\r` length, which subsumes and simplifies
+	  #1120's original past-EOL clamp into the same branch. All of #1120's
+	  existing invariants (single application-ordering sort, clamp, tie-break)
+	  are unchanged and covered by the full `edits.test.ts` suite.
+	- **P3-7** (`clients/lsp/index.ts`) — the rename close-failure recovery
+	  path reopened the old document as a hardcoded `"plaintext"` languageId,
+	  degrading that server's diagnostics until the next genuine open. Now
+	  reopens with `getLanguageId(oldFilePath) ?? "plaintext"` — the same
+	  resolver every genuine `notify.open` call in this file already uses —
+	  so a recognized extension reopens with its real language ID and only a
+	  genuinely unrecognized extension still falls back to `"plaintext"`.
+- **Post-init runtime exits now count toward the LSP circuit breaker (closes #1127)**
+	— `LSPService`'s (`clients/lsp/index.ts`) exponential-backoff breaker
+	(`failureCounts` → cooldown → permanent-disable after
+	`BROKEN_PERMANENT_AFTER`) only incremented on spawn/initialize failure.
+	A server whose spawn SUCCEEDS but then exits shortly after (opengrep's
+	post-init "Unhandled message" JSON-RPC crash, per #1122's Phase C
+	corroborating-signal review — 37 respawns in one real session, never
+	converging) hit the "dead client — needs respawn" path instead, which
+	never touched the breaker: `failureCounts` was already cleared by the
+	preceding successful spawn and the runtime exit itself was never counted.
+	Fixed by adding a parallel `runtimeExitCounts` counter fed only by EARLY
+	(lifetime < 60s) non-intentional exits, sharing the same cooldown formula
+	and the same `state.broken`/`permanentlyBroken` maps as the existing
+	breaker — tracked separately from `failureCounts` specifically because a
+	successful respawn (which correctly resets the spawn/init failure streak)
+	is not proof of health for a crash-loop server, so reusing that map would
+	erase the streak on every respawn attempt (the #1127 bug). Deliberate
+	teardowns (session reset, `#743` notify-backpressure eviction, generation
+	handoffs) call `shutdown()` themselves before the process exits and set
+	`shutdownRequested`; a new `wasShutdownIntentional()` accessor on
+	`LSPClientInfo` (`clients/lsp/client.ts`) exposes that flag so the breaker
+	distinguishes a genuine crash from a restart it initiated and never counts
+	the latter. Adversarial review caught that lifetime was originally
+	computed from the moment a dead client is lazily DETECTED (the next
+	`getClientForFile` attach), not from when it actually died — #1127's
+	documented pattern is attach-triggered respawns minutes to hours apart, so
+	an early crash detected an hour later would misread as a long healthy run
+	and never count. Fixed by stamping a real `exitedAt` on `LSPClientState`
+	the moment the client's connection/process actually dies (first of
+	`onError`/`onClose`/process `exit` to fire) and exposing it via a new
+	`getExitedAt()` accessor; the respawn site computes lifetime as
+	`exitedAt - spawnedAt`, falling back to the detection-time delta only when
+	`exitedAt` is unexpectedly unset. New coverage in
+	`tests/clients/lsp/service-runtime-exit-breaker.test.ts`: a crash-loop
+	respawn sequence converges to permanent-disable instead of respawning
+	forever (fails against pre-fix behavior), an early death with detection
+	delayed by hours still counts (death time, not detection time, decides —
+	fails against the pre-fix detection-time computation in both directions),
+	a deliberate `shutdown()`-driven restart sequence never counts, a runtime
+	exit past the lifetime threshold resets the streak instead of counting,
+	and the REAL `#743` notify-write-backpressure eviction path (driven
+	through `touchFile`, not a synthetic stand-in) never double-counts against
+	this breaker. Full existing LSP suite (536 tests) stays green.
+
+- **`terragrunt hcl fmt` reported success when it never ran (refs #1117)** —
+	`formatFile` decided success from `result.error` alone, and a formatter that
+	fails leaves the file byte-identical, which is indistinguishable from
+	"already formatted". A terragrunt binary predating the `hcl` command group
+	exits non-zero without touching the file, and pi-lens reported
+	`success: true, changed: false`. `FormatterInfo` gained an opt-in
+	`strictExitCode`, set on `terragrunt-hcl`, which folds the exit status into
+	the check and surfaces the tool's own first stderr line as the error. It is
+	opt-in rather than global because the lint-autofix formatters (`rubocop -a`,
+	`ktlint -F`, `standardrb --fix`, `sqlfluff fix`) exit non-zero when offenses
+	remain AFTER a successful rewrite; failing those would surface a formatter
+	error on every file with an unfixable offense.
+- **Runners reported a clean file on a non-zero exit with no output (refs #1117)** —
+	seven runners gated their "the tool never ran" skip on
+	`result.error` alone. `safeSpawnAsync` sets `error` only for spawn, timeout,
+	signal and abort failures, and resolves a NORMAL exit with no `error` at any
+	status (see `SpawnResult.failure`: "nonzero exit statuses are not spawn
+	failures"). So an unknown subcommand, a rejected flag, or a config that fails
+	to load — non-zero exit, message on stderr, empty stdout — fell straight
+	through the guard, parsed `""` into zero diagnostics, and reported the file as
+	clean. Terragrunt was the visible case: its docblock claimed a binary
+	predating the `hcl` command group was classified SKIPPED, and it was not. The
+	test now lives in `spawnFailedWithNoOutput`
+	(`clients/dispatch/runners/utils/spawn-outcome.ts`) and folds `status` into
+	the check; terragrunt, tflint, hadolint, taplo, trivy-config, htmlhint and
+	detekt all use it. Runners that exit non-zero BECAUSE they found something are
+	unaffected, since their findings are on the stream the guard tests. ktlint,
+	prisma-validate, gleam-check, zig-check, dart-analyze and elixir-check already
+	covered the case through their own non-zero follow-up branches and are
+	unchanged.
+- **Bare-binary GitHub release assets skip signature siblings** — the installer
+	picked a release asset with `assets.find(a => a.name.includes(substring))`.
+	Archive-based tools are unaffected (their substrings end in `.zip`/`.tar.gz`),
+	but the three bare-binary entries (terragrunt, marksman, expert) resolve to
+	the FULL asset name, which is a strict prefix of every `.asc`/`.sig`/`.sha256`
+	sibling, so whichever the release listed first would be downloaded and marked
+	executable as the binary. Selection now lives in an exported
+	`pickReleaseAsset`: exact name first, then a substring match that excludes
+	known sidecar suffixes.
+- **Cascade fallback-display paths re-displayed bound-false LSP snapshots (refs #1104)** —
+	#1100 gated the cascade's RECONCILE path (the footer/widget) onto content
+	binding (`boundToCurrentDisk`), but two DEGRADED-fallback DISPLAY paths in
+	`clients/dispatch/integration.ts` still re-read TTL-fresh `getAllDiagnostics()`
+	snapshots without consulting binding at all: the touch-error fallback (a
+	failed active LSP touch falling back to the passive snapshot) and
+	`appendFallbackNeighbors` (the CR-3/A2 degraded-fallback path when no
+	neighbor produced trustworthy LSP data). A bound-false snapshot — diagnostics
+	computed against a DIFFERENT disk state than what's currently on disk, e.g. a
+	pre-fix-edit read — could still reach cascade OUTPUT even though the widget
+	was protected. Both sites now apply the same false/`"unknown"`/true contract
+	#1095/#1100 already established for reconcile: `false` → skip the stale
+	display (logged via the cascade channel with `bindingState`), `"unknown"` →
+	unchanged (the pre-existing fallback contract), `true` → display. HONESTY
+	fix: filtering a display candidate could otherwise make a genuinely degraded
+	cascade look clean, so when every fallback candidate a run considered was
+	binding-rejected and nothing else produced output, the run now carries the
+	same `indeterminate` marker #1023 built for a degraded graph compute (new
+	`CascadeIndeterminateReason: "lsp_binding_rejected"`), so the turn-end
+	advisory still surfaces an honest note instead of silence. The `resultId`
+	pull-diagnostics plumbing that #1104 also tracks remains open — this covers
+	only the cascade display-binding gap (#1100 review P3-1).
+- **`parseSymbolKey` mis-parsed LSP-fallback symbol kinds (refs #1088)** —
+	the canonical-id parser whitelisted only the 7 kinds `buildSymbolId` mints
+	directly, but `addLspFallbackSymbols` mints ids using the much larger
+	`lspSymbolKindName` vocabulary (`enum`, `constant`, `struct`, `namespace`,
+	`field`, `constructor`, `module`, the `lsp-symbol-<n>` catch-all, ...). Any
+	of those ids failed the whitelist and fell through to the legacy
+	last-colon split, shearing the id at the wrong boundary (e.g.
+	`c:\p\a.kt:Color:enum:42` parsed as `filePath: "c:\p\a.kt:Color:enum"`,
+	`symbolName: "42"`). `clients/review-graph/symbol-id.ts`'s
+	`parseSymbolKey` now matches the trailing `:<kind-token>:<digits>` shape
+	STRUCTURALLY (any lowercase, optionally hyphen-segmented token) instead of
+	whitelisting specific kind strings, so it stays correct for the open-ended
+	LSP-fallback vocabulary without needing a matching update per kind.
+- **Java try-with-resources suppression was dead (refs #1089)** —
+	`clients/tree-sitter-client.ts`'s `not_closed_or_try_with_resources`
+	post-filter built its resource-word regex as `` new RegExp(`\b${resource}\b`) ``
+	inside a template literal, where `\b` is the BACKSPACE control character
+	(U+0008), not a regex word-boundary escape. The regex could never match,
+	so the Java 9 short-form `try (resource) { ... }` was never recognized as
+	closing its resource — only an explicit `.close()` call suppressed the
+	"resource should be closed" finding. Fixed to `\\b` plus a regex-escaped
+	identifier. No shipped Java fixture used try-with-resources syntax, so no
+	existing expected-findings fixture changes with this fix.
+- **Raw NUL byte in `review-graph/builder.ts` made the file look binary to grep (refs #1088)** — the checkpoint's `ignoredIds` join separator was a
+	literal 0x00 byte embedded in source, which makes `ripgrep`/`grep` treat
+	the whole 4,900+ line file as binary and stop scanning partway through —
+	silently defeating the AGENTS.md-mandated repo-wide grep sweep for every
+	commit that touched this file. Replaced the raw byte with the `\u0000`
+	escape sequence, which is the byte-identical runtime string (same
+	`hashIgnoredIds` function computes both the write-time and read-time
+	hash, so no persisted checkpoint compatibility is affected).
+- **`buildCallGraph` same-file evidence accounting hardened + dead code removed (refs #1089)** — added regression coverage for the audited
+	same-file evidence class (divergent path forms for the same file must
+	both be recognized as same-file AND counted exactly once per reference,
+	keeping the coverage sum invariant `validatePersistedCallGraph` enforces
+	on every load); the normalized-compare fix for this had already landed
+	upstream, so this closes out the finding with a fail-then-pass regression
+	test rather than a behavior change. Also removed `clients/call-graph.ts`'s
+	dead duplicate `saveCallGraph` overload signature (byte-identical to the
+	implementation signature) and the unreachable `{}`-spread branch on the
+	required `identity` parameter.
+- **JS destructured params dropped from `parameterCount` (refs #1089)** —
+	`clients/dispatch/facts/function-facts.ts`'s `getParameters` recognized
+	`required_parameter`/`optional_parameter` wrapper nodes (how TypeScript's
+	grammar represents every parameter, destructured or not) but not the bare
+	`object_pattern`/`array_pattern` nodes plain JavaScript's grammar uses
+	for a top-level destructured parameter with no wrapper. `function
+	f({a, b})` counted 0 parameters in a `.js` file while the TS-annotated
+	equivalent counted correctly. Added JS-vs-TS parity tests.
+- **`call-graph.ts`'s exported `CACHE_VERSION` renamed to `CALL_GRAPH_CACHE_VERSION`** — collided in name (not value — separate
+	modules) with `clients/cache/rule-cache.ts`'s own `CACHE_VERSION` export;
+	renamed to match the `<SUBSYSTEM>_CACHE_VERSION` convention already used
+	by `WORKSPACE_DIAGNOSTICS_CACHE_VERSION` and
+	`PROJECT_DIAGNOSTICS_CACHE_VERSION`. Updated the two test-file imports.
+- **Dead SIGTERM→SIGKILL escalation guard on non-Windows kills (closes #1114)**
+	— `clients/safe-spawn.ts`'s non-Windows `killTree` branch armed a 1s
+	escalation timer gated on `if (!child.killed) child.kill("SIGKILL")`, but
+	Node sets `ChildProcess#killed = true` the moment `kill()` successfully
+	SENDS a signal — not when the child actually dies — so immediately after
+	the `child.kill("SIGTERM")` one line above, the guard was always false
+	and the SIGKILL escalation could never fire: a SIGTERM-ignoring child on
+	Linux/macOS was never force-killed. Fixed by tracking OBSERVED death via a
+	`closed` flag set synchronously (before any `await`) in the close/error
+	handlers, gating the escalation on `!closed` instead — composes cleanly
+	with the existing #1109/#1113 `escalationTimer` clear-on-close fix rather
+	than switching to the LSP `killProcessTree` analog's unconditional-SIGKILL
+	design, since `safeSpawnAsync` already has a real per-call close/error
+	observation point to hang the flag off of. Proven with a new "child
+	ignores SIGTERM → SIGKILL sent at the 1s mark" test
+	(`tests/clients/safe-spawn-kill-escalation-timer.test.ts`) that fails
+	against the pre-fix guard and passes post-fix; the existing #1109 timer-leak
+	tests (escalation timer cleared when close/error DOES arrive) remain green.
+	**Class sweep** of every `.killed` consumer under `clients/` and `scripts/`
+	found two siblings of the same shape in `clients/lsp/client.ts`'s
+	`killProcessTree`/`createLSPClient` and fixed both in this PR: (1) the
+	`fast`-shutdown escalation timer checked `!proc.killed`, but the primary
+	SIGTERM send there goes through the raw `process.kill(-pid, …)` process-group
+	call (which never touches `proc.killed`), so the guard was either always-true
+	(unconditional SIGKILL after the window on the common group-kill path) or
+	dead (on the direct-child fallback path) — now tracked via a real `exit`
+	listener set once up front, seeded from the same `exitCode`/`signalCode`
+	pre-check the function's top-of-body early return already uses (a process
+	that was already dead on entry — reachable when `options.processExiting`
+	skips that early return — would otherwise miss its own "exit" event and
+	still draw a redundant group SIGKILL at the escalation window); (2) the
+	`initialize()`-timeout 2s SIGKILL backstop had the identical always-true
+	`!lspProcess.process.killed` guard — switched to `lspProcess.process.exitCode
+	=== null && lspProcess.process.signalCode === null` (both, not `exitCode`
+	alone: a process killed BY a signal — the common case here, since
+	`killProcessTree` above it signals rather than lets the process exit on its
+	own — has `exitCode === null` forever and only `signalCode` set, so
+	`exitCode` alone still re-armed the backstop's kill against an
+	already-dead corpse; harmless in practice since `ChildProcess#kill()` on an
+	exited handle is a swallowed no-op, but not an accurate "still alive"
+	read). Other `.killed` reads audited and left as-is because they're
+	liveness/status checks, not escalation-action gates: `isClientAlive`'s
+	`!state.lspProcess.process.killed` (redundant with `isDestroyed`, already
+	set from real exit/close handlers), `checkProcessAlive`'s informational
+	"was killed" health-check string, `launch.ts`'s post-spawn
+	immediate-failure check (`proc.killed` read before any kill was ever sent),
+	`scripts/with-test-lock.mjs`'s `.once`-registered first-forward guard, and
+	`scripts/smoke-tools.mjs`'s read of Node's own `execFileSync` timeout-kill
+	flag on the caught error object.
+
+	**Adversarial-review follow-up round:** the reviewer ran
+	`kill-process-tree.test.ts` against PRE-fix `client.ts` and it passed 7/7 —
+	the sibling fixes above had ZERO effective test coverage, because the
+	"non-fast shutdown escalates" mock (and the other pre-existing mocks in
+	that file) lacked `once`/never set `killed`, so BOTH the old dead guard and
+	the new fix's guard were vacuously permissive against them (the #1106
+	vacuous-mock class, recurring in mock form: a test's fixture is too weak to
+	distinguish correct from broken behavior, so it passes either way). Fixed
+	by: upgrading that test's mock to be `.once`-capable so it actually
+	exercises the `exited`-flag logic; adding two new `fast`-shutdown tests with
+	a real `.once`-capturing mock proving BOTH directions (exit observed before
+	the 1.5s window → no group SIGKILL; no exit observed → group SIGKILL at the
+	window) — the "no premature SIGKILL" direction fails against the pre-fix
+	`!proc.killed` guard (proven by temporarily reverting the guard and
+	re-running); and adding a real-subprocess POSIX-only test
+	(`tests/clients/lsp/initialize-timeout-backstop.test.ts`, skipped on win32
+	with an explicit reason — killProcessTree's Windows path is
+	`taskkill`-based, not signal-based, and is already covered by the
+	kill-process-tree suite) for the previously fully-untested `initialize()`
+	2s backstop.
+- **Micro-gap sweep: recorded coverage/observability/doc gaps (refs #1106, refs #1104)**
+	- `session-state-store.ts`'s `loadSessionState` STATE_VERSION reject path
+		(a wrong-version persisted snapshot is ignored, not rehydrated) had no
+		test; `STATE_VERSION` is now exported so the new test can drive the
+		mismatch off the real constant (`STATE_VERSION + 1`) rather than a
+		hardcoded literal (#1116 pattern).
+	- `tests/clients/cache/rule-cache.test.ts`'s deliberate `raw.version = "v2"`
+		schema-mismatch override now pins `expect(CACHE_VERSION).not.toBe("v2")`
+		alongside it (#1082/#1116 pattern), so the assertion can't vacuously pass
+		if `CACHE_VERSION` ever became `"v2"`.
+	- The cascade `neighbor_touch` log entry (`clients/dispatch/integration.ts`)
+		now carries an `inconclusive` boolean in its metadata alongside
+		`bindingState`, so the two independent unconfirmed-touch causes (notify/
+		diagnostics wait lapsed vs. disk-diverged binding, #1093/#1095) are
+		distinguishable from `cascade.log` alone, without cross-referencing
+		`latency.log`.
+	- `tools/lens-diagnostics.ts`'s `includeGenerated` param description now
+		states it only takes effect with `mode=full refreshRunners=cheap/all`
+		(it's silently a no-op under `cached`/`none`, since no project scan runs
+		to apply it to) — a doc-only fix from PR #1115's review.
+- **mtime-only cache freshness sweep (refs #1105)** — the #1092→#1096 arc bound
+	LSP-diagnostics freshness to real content; this sweep audited the OTHER
+	persisted/derived caches for the same "mtime unchanged ≠ content unchanged"
+	class (git checkout timestamp restoration, formatters preserving mtime,
+	same-second writes) and hardened the two CONTAINED members whose fix is free:
+	- **word index** (`clients/word-index.ts`): the incremental session-warmup
+		refresh gated re-read on mtime ALONE (`fileMtimes.get(file) !== mtimeMs`), so
+		a mtime-preserving content change left stale identifiers served to
+		`symbol_search`/`pilens_symbol_search`. It now stores a per-file byte `size`
+		(the SAME `stat` the walk already runs to enforce the byte cap — zero extra
+		I/O) and re-reads when mtime OR size differs, matching the review graph's
+		gold-standard `size:mtimeMs` first filter. `size` is a new optional parallel
+		array in the serialized snapshot (`SerializedWordIndex.fileSizes`); a
+		pre-#1105 snapshot lacking it forces one self-healing full re-read on the
+		next refresh (the safe direction) rather than a version bump.
+	- **dependency checker** (`clients/dependency-checker.ts`):
+		`DependencyChecker.importsChanged`'s mtime fast path (`cached.timestamp >=
+		stat.mtimeMs`) skipped the madge circular-dep re-check on a mtime-preserving
+		import edit; it now also requires `cached.size === stat.size`.
+
+	The residual (same mtime AND same byte length, changed content) is left as the
+	same accepted residual the review graph itself carries — closing it needs an
+	unconditional per-read content hash, which the event-loop/hot-path discipline
+	forbids. The sweep's full verdict table (word-index/dependency-checker fixed;
+	project-snapshot seq, installer probe-cache, sgconfig, reverse-deps, TreeCache,
+	yaml-rule-parser bundled cache all SAFE/already-hardened; rule-cache disk cache
+	filed as a follow-up because a content-confirm there would read 700+ rule files
+	on the per-edit hot path) is recorded in the PR.
+- **Test-role files no longer leak into collateral cascade/impact surfaces (closes #1080)**
+	— the review graph is already tests-free, but several
+	collateral surfaces re-derived neighbors from OTHER sources that never saw
+	that filter, so an UNIGNORED `*.test.*` / `tests/` file could still surface
+	as cascade collateral. The existing `getProjectIgnoreMatcher` filtering only
+	closed the ignored-file half of the gap (#297). A new shared predicate
+	`clients/collateral-test-role.ts:isTestRoleCollateral` composes the SINGLE
+	existing structural classifier (`clients/file-role.ts:detectFileRole`) — no
+	second matcher, no private test-filename list — and is applied at every
+	collateral producer boundary: (1) `computeCascadeForFile` filters
+	`impact.directImporters` / `directCallers` / `neighborFiles` AFTER graph
+	neighbors, reverse-deps, LSP reference expansion, and transitive expansion
+	are merged, so a test neighbor is excluded from the active-touch/passive-
+	snapshot set, the returned `impact`, AND the formatted header
+	(`formatImpactCascade` reads `impact` verbatim for `Direct importers` /
+	`Check next` counts and names) — module-level downstream files (added inside
+	`computeImpactCascade`) are caught here at the consumption boundary rather
+	than inside the shared graph query; (2) `appendFallbackNeighbors` drops an
+	unignored test file from the passive-snapshot fallback (ignore filtering
+	stays separate and unchanged); (3) `runtime-turn.ts` filters call-graph
+	`impact()` results so a test caller appears in neither the turn-end advisory
+	text nor the persisted delta; (4) `callGraphImpactToProjectDiagnostics`
+	re-applies the predicate at the persistence producer boundary. Honesty
+	preserved: a KNOWN `"test"` role is filtered, but a role-classification
+	failure RETAINS the candidate (never a false clean), the ignore matcher's
+	fail-open behavior is untouched, and LSP-unavailable/inconclusive cascade
+	semantics are unchanged. Per-runner and auxiliary-profile `skipTestFiles`
+	semantics, primary LSP diagnostics, intentional test-runner findings, and
+	the generic project-diagnostics snapshot/delta display are all left as-is.
+
+- **`no-bare-except` (Python, ast-grep) still flags dotted/qualified exception types as bare (closes [#1031](https://github.com/apmantza/pi-lens/issues/1031))** — the ast-grep twin of the #1026 tree-sitter fix never received its `attribute` alternative: `except asyncio.TimeoutError:` has no direct `identifier` child (the identifiers live inside the `attribute` node), so the `not: any:` check passed and the rule reported a false positive on every dotted exception type — live for binary-installed users, where the ast-grep LSP/CLI runs this rule on every Python file. The rule now accepts the same five exception-spec shapes as the tree-sitter filter's `bare_except_only`: identifier, attribute (dotted name), tuple, `parenthesized_expression`, and `as_pattern` — the parenthesized-single-name case is the same latent class and was swept in with it (verified firing pre-fix via the real CLI). Fixtures: dotted + parenthesized names added to `no-bare-except-test.yml` as valid cases; the bare `except:` invalid cases unchanged. Verified against the real ast-grep CLI: pre-fix fired on `except asyncio.TimeoutError:` and `except (ValueError):`, post-fix fires only on genuine bare `except:` among the identifier/attribute/tuple/parenthesized/as_pattern spec shapes (`subscript` specs like `except dict[str, int]:` remain a tracked gap on both surfaces); the full 251-case `ast-grep test` corpus passes.
+- **The warm IPC side-channel re-dispatched the same request on stray bytes (closes [#1219](https://github.com/apmantza/pi-lens/issues/1219))** — the server's socket `data` handler (`mcp/server.ts` `startIpcServer`) buffered chunks but never consumed the request line, so any further `data` event on the connection — stray bytes without a newline still re-found the original line — re-ran the whole warm `analyzeFile` pass (three dispatches per connection in the pre-fix repro). The channel's clients write exactly one newline-delimited request and read one reply (`requestWarmAnalyze` ends the socket), so the handler is now strictly one-shot: `createWarmIpcLineReader` (`clients/mcp/ipc.ts`, re-exported through the lens-engine seam) accumulates chunks, dispatches the first complete line exactly once, and ignores everything after it. The stdio JSON-RPC loop already consumed its lines and is untouched. Regression tests drive the real reader: one request + stray bytes → exactly one dispatch (pre-fix: three), a second newline-terminated request is ignored, and a request split across chunks still assembles.
+
+- **`npm run test:unit` runs again, and actually excludes the integration files** — the script passed `--ignore <file>`, which is not a vitest option, so every invocation died with `CACError: Unknown option --ignore` before a single test loaded (broken since the tier split was written; CI never caught it because CI runs `npm test`). The rename to the real flag, `--exclude`, fixes the crash but not the intent: `vitest.config.ts` defines per-project `exclude` lists, and a project's `exclude` REPLACES the root/CLI value rather than merging with it, so a command-line `--exclude` is silently dropped (verified with `vitest list`: both integration files still resolved). The exclusion now lives in the config, keyed off the script name npm exports (`npm_lifecycle_event`), which survives the `with-test-lock` wrapper identically on every OS — unlike an inline `FOO=1 …` prefix, which cmd.exe cannot parse. `npm run test:unit` is now 456 files, `npm run test:integration` the other 2, and `npm test` all 458.
+- **`loop_block` no longer reports a machine sleep or paging stall as a pi-lens synchronous block (refs #1122, refs #1123 item 1)** — the event-loop occupancy probe (`clients/event-loop-monitor.ts`) wraps Node's native `monitorEventLoopDelay`, whose libuv timer-lag is measured against the monotonic clock (`uv_hrtime`/`QueryPerformanceCounter`). When the whole process is frozen — Windows Modern Standby, or paging thrash under commit-charge exhaustion — the next timer fires late by the entire wall-clock gap, and that gap was logged as a "block". Two distinct machine artifacts were confirmed against the Windows System event log: a 290,179 ms block lined up exactly with a 14:33:05Z→14:37:55Z Modern Standby window (Kernel-Power 506/507), reported byte-identically by two independent pids because the histogram is HDR-bucketed and quantizes ~290 s into one bucket; and a later silent host exit with **zero** sleep events but twelve Resource-Exhaustion-Detector (2004) events at 97% commit charge. `latency.log` also held multi-*hour* "blocks" that can only be overnight sleep. Comparing a wall clock to a monotonic clock does NOT catch this — on Windows both advance across Modern Standby — so the probe now uses **CPU accounting**: a genuine synchronous block of D ms burns ≈ D ms of main-thread CPU, so its window must have consumed ≥ ~D ms of CPU; a frozen/thrashing process consumes ~0 CPU across the gap. The histogram is now windowed **per turn** (its long-intended reset, previously never wired, so each block is attributable to its turn and its CPU budget is bounded), and a worst block above a 20 s floor that the window's CPU cannot account for is tagged `suspectSystemStall` in the `loop_block` metadata (alongside `windowCpuMs`/`windowWallMs` and the `lastPhase` attribution hint) rather than raising the genuine-block high-water — so a machine freeze can no longer permanently suppress logging of later real blocks, and `/lens-health` reports the worst *genuine* block. Sub-floor blocks are never auto-tagged, but the logged CPU-vs-wall ratio still exposes a shorter paging stall for a human. Pure `isSuspendSuspectedBlock` and `getLastLoggedPhase` seams are unit-tested without a real machine sleep.
+- **`runtime-tool-result.ts`'s three tool-result-turn maps now key through `PathKeyedMap` (refs #1086, the #210/#1020/#1025 raw-path-key class)** — `inFlightPipelines`, `lastAnalyzedStateByFile`, and `debouncedPipelines` keyed directly on `filePath`, which is only `path.resolve`d from raw agent-supplied tool input (never case-folded, never realpath'd). A divergent Windows spelling of the same file (case, or an unresolved absolute path an agent supplies verbatim) bypassed the concurrent-state dedupe and debounce coalescing, producing duplicate pipeline runs, doubled LSP dispatch, and split telemetry participant counts; `flushDebouncedToolResults(filePath)` silently missed the pending entry it was meant to flush. All three now wrap `PathKeyedMap` with `normalizeEphemeralMapKey` — the cheap slash-fold + win32-lowercase normalizer (no `realpathSync`), matching the state's ephemeral, turn-scoped, single-process lifetime per AGENTS.md's normalizer-choice guidance (`normalizeMapKey`'s realpath cost is for long-lived cross-call-site state, not this). `inFlightPipelines`'s composite `${filePath}:${stateHash}` key is now a `PathKeyedMap<Map<string, InFlightPipeline>>` — normalized path outer, raw stateHash inner — rather than folding both halves through one string normalizer, so a genuine same-path content change still gets a distinct entry while divergent spellings of the same state collapse to one. Every read/write/delete/iteration site in the file was audited; `flushDebouncedToolResults`'s iteration and `scheduleDebounced`'s coalesce path both continue to see the map's preserved display path. No other raw path-keyed map exists in the file. New tests (`tests/clients/runtime-tool-result-debounce.test.ts`) prove, fail-then-pass, that (1) two concurrent `tool_result`s for the same file under a divergent (win32-normalizer-driven) spelling collapse into one pipeline run, and (2) `flushDebouncedToolResults` addressed by a divergent spelling still hits the entry scheduled under the other spelling (asserted by elapsed time, not just call count, so a silent miss falling back to the natural debounce timer can't vacuously pass); a third test proves the composite key's stateHash axis still keeps same-path-different-content calls distinct.
+- **`pi --print --no-session` no longer hangs after `agent_settled` — uncleared race-loser timers (refs #1097, recurrence of #22's symptom via a different handle)** — a completed one-shot print-mode process kept running in the event loop instead of exiting. Root cause: `LSPService.getClientForFile` raced the client-wait against an inline `setTimeout(effectiveMaxWaitMs)` whose handle was never stored, so when the client resolved first (the common case) the losing timer stayed a **ref'd** pending timer for the full remaining wait budget. In a long-lived interactive session that is invisible (it fires later, resolves an orphan promise, is GC'd); in a `--print`/subagent process it keeps the loop alive for up to `effectiveMaxWaitMs` (15s in the report, minutes with a server whose `clientWaitTimeoutMs` is large) after the run settled — the `session_shutdown` handler runs and `resetLSPService` completes, but nothing owned or cancelled this timer. Proven via `process`-handle async-hooks tracing: the sole pi-lens-owned handle surviving into the hang was this timeout. The defect **shape** — *an operation raced/bounded by an independently-armed timer whose loser is never cancelled on the operation's resolution* — was swept repo-wide; two same-shape siblings were fixed in the same pass: the quiet-window heartbeat sample-timeout (`clients/quiet-window.ts`, 2s ref'd, kept a one-shot alive ~2s per settle) and the formatter timeout (`clients/format-service.ts`, 30s ref'd). All three now store the timer and `clearTimeout` it in a `finally`, matching the `withDeadline` helper contract the rest of the codebase already uses. Regression test (`tests/clients/lsp/client-wait-timer-cleanup.test.ts`) asserts no pending timer survives a fast client win — it fails on the pre-fix code (`expected 1 to be 0`). One further same-shape site — the cascade references race in `clients/dispatch/integration.ts` (750ms) — is tracked in #1109 for a follow-up as it is under concurrent modification.
+- **Two more uncleared-race-timeout members closed out (closes #1109, sweep follow-up to #1097/#1110)** — the two class members #1110's adversarial review flagged rather than fixed. (1) `computeCascadeForFile`'s symbol-level blast-radius upgrade (`clients/dispatch/integration.ts`) races `lspService.references()` against an inline `setTimeout(() => reject(...), 750)` per changed symbol (up to 3 per file); when `references()` wins — the common case — the losing timer was never stored, so it stayed a REF'D pending timer for the remaining budget. Same `finally`-clear contract as the #1097 fix: the handle is now stored in a per-call `let` and cleared once the race settles. (2) `safeSpawnAsync`'s non-Windows `killTree` else-branch (`clients/safe-spawn.ts`) arms a REF'D 1s SIGTERM→SIGKILL escalation timer that was neither cleared on child exit nor unref'd (the main per-spawn `timeoutId` alongside it was already correctly cleared on both the `close` and `error` paths). Bounded to 1s and only on kill paths, so it can't reproduce #1097's hang by itself, but it is the same defect shape and now clears alongside `timeoutId` in both handlers. (Review-round finding: the escalation ACTION itself has always been dead code — `!child.killed` is false after a successful SIGTERM *send*, so SIGKILL never fires; this change fixes only the timer-handle leak and preserves the window; the dead guard is tracked in #1114.) Regression tests prove both fail on pre-fix code: `tests/clients/cascade-compute.test.ts` (`vi.getTimerCount()` after a fast `references()` win) and the new `tests/clients/safe-spawn-kill-escalation-timer.test.ts`, which mocks `process.platform` and `node:child_process`'s `spawn` (mirroring `tests/clients/lsp/kill-process-tree.test.ts`'s established technique) so the non-Windows branch is exercised deterministically on any host OS, including Windows dev machines — no vacuous platform-gated pass. A re-run of #1110's repo-wide `setTimeout`/`setInterval`/`Promise.race` grep over every file changed since that sweep (#1103, #1110, #1111) found no new members of the class.
+- **`sg scan` exit-1-with-matches is no longer misclassified as a CLI failure (refs #1087)** — ast-grep's linter-style contract (verified first-hand against the bundled CLI: a `severity: error` rule that MATCHES exits **1** with valid JSON matches on stdout and stderr "Scan succeeded and found error level diagnostics"). `SgRunner.interpretScanResult()` / `exec()` only exempted `status===1` with *empty* output, so every real match under an error-severity rule was dropped as `failure: "cli-failure"` with `matches: []`. Now `status===1` + stdout that parses as valid JSON is treated as SUCCESS (matches parsed); stderr-with-unparseable-stdout stays a failure, and the historical status-1/no-output no-match convention is preserved. Invariant: **an exit code that means "scan succeeded with findings" must never be classified as a CLI failure.** This restores `ast_grep_search`/`pilens_ast_grep_search` raw error-severity rules, the `pilens_ast_grep_replace` preview/preCheck path, and `validateRule` for a matching error-severity rule.
+- **"Silencing is not fixing" now covers the whole suppression class, not just the policy member (refs #1087)** — the delta baseline in `dispatcher.ts` was only re-filtered through the project rule policy before `filterDelta`, while the live set was additionally filtered by LSP/docker-overlap suppression, inline `pi-lens-ignore` comments, and agent/user dispositions. A finding persistently dropped by any of those three sibling filters stayed in the baseline's `after` view forever, so it counted in `resolvedCount` on EVERY dispatch and inflated `trackAgentFixed` unboundedly. The output filter pipeline (overlap → inline → disposition → policy) is now a single closure applied identically to the live set AND the delta baseline, so a persistently-suppressed finding is absent from both sides and never oscillates into `fixed`. The stored baseline remains the unfiltered deduped set (a policy/suppression edit never resets the user-authored delta baseline).
+- **Inline `pi-lens-ignore` comment tokens are now normalized like the diagnostic id (refs #1087)** — the diagnostic side matched raw OR normalized, but the comment side stored only the raw token, so `// pi-lens-ignore: no-eval-js` failed to suppress a finding surfaced under the normalized `no-eval` even though the identical `disable: ["no-eval-js"]` config key worked. The comment token now also contributes its `normalizeRuleId` form, making the two suppression surfaces symmetric.
+- **`"disable": []` / `"select": []` no longer warn spuriously (refs #1087)** — an explicitly empty rule-policy list is a well-formed no-op, not an error; it is now dropped silently. A NON-empty array whose entries are all blank/non-string is still a real authoring mistake and still warns ("must contain at least one non-empty string").
+- **Test-runner subcommands no longer lost during binary resolution (closes #1098)** — `TestRunnerClient`'s `resolveExec` unconditionally dropped `args()[0]` whenever local/global binary resolution succeeded, an npx-wrapper-convention assumption (arg 0 names the binary, e.g. `npx vitest run …`) that only holds for wrapper-style runners. For direct runners whose args lead with a real subcommand it silently ate that subcommand instead — `cargo test --no-fail-fast` resolved to the argv-invalid `cargo --no-fail-fast` (a clap usage error), likewise for go/dotnet/maven/mix, misreported at turn-end as a false "1/1 failed". The new `stripWrapperArgs` helper strips a leading arg ONLY when it actually names the resolved binary (`[binName, ...]`, or the pytest-style `["-m", binName, ...]` pair) and leaves every other argv untouched, applied at both the local-bin and global-bin resolution sites. Also fixes the same defect's inverse: `rspec`'s config declares `command: "bundle"` with `args: ["exec", "rspec", file]`, but binName resolution defaulted to the runner key `"rspec"` instead of the real binary `"bundle"`; it now declares `binName: "bundle"` so local/global resolution looks up the right binary and `exec rspec <file>` reaches `bundle` intact. A generic regression matrix (`tests/clients/test-runner-client.test.ts`) iterates the exported `RUNNERS` table (not a hand-copied runner list) across local-bin/global-bin/fallback resolution paths, so a future runner is automatically covered. A repo-wide sweep for the same defect shape (positional argv stripping tied to binary resolution, and command/binName-resolution-name mismatches) found no other live instance — every other `findGlobalBinary` caller (biome-client, formatters, ast-grep runners, LSP launch) builds its argv as fresh literals per resolution branch rather than slicing a shared generator, so none share this defect's precondition. Three additional command/binName-mismatch members exist but are unreachable in practice (their binaries never land in the npm-family bin dirs findGlobalBinary probes) and now resolve MORE correctly if they ever did: gradle, maven, and minitest (command "ruby" vs default binName "minitest"); pytest's resolved-path argv was also silently broken pre-fix (slice(1) ate "-m") and is now correct.
+- **Call-graph persisted-cache validator and canonical-freshness invariant now have real test coverage (refs #1089)** — two `call-graph.test.ts` "rejects…" tests hand-wrote `version: 4`, identity-less fixtures, so `loadCallGraph` returned `undefined` at the version/identity gate before the ~200-line semantic validator (`validatePersistedCallGraph`) ever ran; rewritten as `version: 5` fixtures with a valid canonical identity, each now isolating and proving out the ONE validator check it claims to cover (the inDegree/adjacency cross-check and the `complete && unsupportedEvidence > 0` honesty check). Also added the first tests anywhere that pass `expectedIdentity` to `loadCallGraph`, covering the freshness invariant edab5d5d introduced: a mismatched `reviewGraphVersion` or `reviewGraphSignature` rejects the cache (the #210/#1020 stale-replay class), while a matching identity loads normally.
+- **`module_report`'s `callGraph: true` surface gains coverage for the `file-cap` and `identity-missing` unavailability reasons and the `provenance.callGraph` field (refs #1089; the Java try-with-resources regex and grammar co-load items remain open there)** — `cached-call-graph` / `unavailable:file-cap` / `none` / omitted-when-not-requested are now all asserted, so the tool description's own honesty contract ("unavailable cache state is never reported as zero calls") is enforced by tests, not just documented.
+- **Review-graph cache-identity guard now detects a stale graph instance instead of a vacuous schema-tag compare (refs #1088; the `parseSymbolKey` LSP-fallback-kind item remains open there)** — `getReviewGraphCacheIdentity` compared `version`, the constant schema tag (e.g. `"v8"`, identical for every live graph), so it could never tell a caller's graph reference apart from a newer one that had since replaced it in the workspace cache — the concrete race is a session call-graph task computing a projection from an older `graph` instance while a concurrent cascade build races ahead and replaces `_workspaceGraphCache` before the identity lookup runs, letting a stale call-graph projection get persisted under a fresh-looking signature. Now compares the workspace-cache ENTRY's `buildGeneration` stamp (#459) — not the stored graph object's, which the reuse paths deliberately leave unstamped on their `cloneGraph` copies — so identity resolves for the graph a drift-reuse or disk-hit build just returned, while a stale or unstamped instance is still rejected.
+- **Nested-link diagnostics no longer flag ordinary JSX wrappers (closes #1076)** — report only the outermost anchor in a directly or deeply nested chain, while allowing single and sibling links inside non-anchor containers across both ast-grep and Tree-Sitter dispatch paths.
+- **LSP workspace edits apply safely in declared order (refs #1053)** — preserve text/resource operation ordering (including directory subtrees), stabilize same-position inserts, collapse identical replacement duplicates, prevalidate every text batch before writing, and close an open old URI before rename notifications.
+- **LSP workspace-edit apply paths: reversed same-position inserts, win32 casing destruction, versioned-edit rejection, out-of-range clamping (closes #1085; P3-1 folded in, P3-2/3/4/5/6/7 deferred on #1085)** — four empirically-reproduced defects in the `clients/lsp/edits.ts` write pipeline, each with a fail-then-pass regression test.
+  1. **Same-position inserts applied REVERSED through `applyWorkspaceEdit` (the #1066 invariant).** The tie-break sort was correct only for exactly one pass, but the apply pipeline sorted an even number of times (and differed by server position-encoding), so `["A","B"]` inserted at one position produced `"aBAbc"` instead of `"aABbc"` for UTF-16 servers (typescript-language-server, pyright — the majority). The application-ordering sort is now performed **exactly once**, at the single string-write site; `normalizeTextEditsForContent` returns validated edits in original array order (never pre-sorted), so the same-position order can no longer flip on an even number of passes. Invariant: same-position inserts apply in array order through every entry path (direct `applyTextEditsToString`, `applyWorkspaceEdit` `changes`, `documentChanges`) under all three position encodings — a full encoding×entry-path matrix now asserts it.
+  2. **Windows case-preservation destroyed on create/rename; case-only renames rejected (invisible to Linux CI).** Disk mutations routed the URI through `uriToPath`→`normalizeFilePath`, which lowercases a nonexistent path tail on win32 — so `create NewFile.txt` wrote `newfile.txt`, `rename → MixedCase.txt` wrote `mixedcase.txt`, and a legitimate case-only rename (`foo.txt → Foo.txt`) was rejected as "source and destination must differ". Confinement/validation still run on normalized paths, but the actual `fs.writeFile`/`fs.rename`/`fs.readFile`/`fs.rm` calls now target the URI's decoded path via the new `uriToDiskPath`. The preflight "destination exists" check decides a case-only (or otherwise-aliased) rename by on-disk **FS identity** (matching `dev` and matching **nonzero** `ino` via `lstat({ bigint: true })`), not a platform-keyed path fold — so it works on ANY case-insensitive FS (win32 **and** macOS APFS/HFS+, per the #1024 "probe the FS, don't branch on platform" lesson) and closes the inverse edge where a case-sensitive FS holding both spellings would otherwise silently clobber. The nonzero-`ino` requirement (and BigInt comparison) is fail-closed: on ino-less filesystems that report `ino: 0` (FAT32/exFAT, some SMB redirectors) the identity check never matches, so the destination-exists check runs and a rename can only error, never silently clobber — a genuine case-only rename there needs an explicit `overwrite`. Tests are FS-probe-guarded (assert casing preservation on a case-insensitive FS, success on a case-sensitive FS) plus a direct unit test of the `ino: 0` guard — never a vacuous pass.
+  3. **Versioned `TextDocumentEdit`s always rejected on the tool apply paths.** Rename `apply:true` (`tools/lsp-navigation.ts`) and code-action autofix (`clients/actionable-warnings.ts`) never pass `documentVersions`, while `client.rename`/`codeAction` validated versions against the live map and then PRESERVED them — so a numeric `textDocument.version` reached an apply site with no map and failed 100% for version-stamping servers (gopls). `normalizeClientWorkspaceEdit` now validates the version against the live map (unchanged) and then STRIPS it (spec `null` = don't check), so the tool paths succeed. The server-initiated `workspace/applyEdit` handler does NOT route through here (it applies `params.edit` with the live `documentVersions`), so its real version check is fully intact. The existing rejection test's key-mismatch vacuity (raw-path key vs `normalizeMapKey` lookup — the #1106 class) is fixed and a positive success-path test added.
+  4. **Out-of-range positions threw instead of clamping (LSP 3.17 regression).** A line past EOF now clamps to end-of-document and a character past line end clamps to line length, so the `(0,0)-(9999,0)` whole-document-replace sentinel idiom works again; malformed shapes (negative/non-integer, `start > end`, mid-codepoint boundary) still throw. The character clamp is **CRLF-safe**: because `lineTextAt` keeps a trailing `\r`, the clamp targets the length BEFORE that `\r`, so a char-past-EOL insert lands at the CRLF boundary and the whole-line sentinel replace preserves the `\r\n` (it does not eat the `\r` or leave a stray one mid-line).
+  P3-1 (an insert listed after a replace starting at the same position was spuriously rejected as overlapping — LSP-legal, VSCode applies it) is fixed as a byproduct of the sort rework via an end-descending tie-break, making the result independent of listing order. The general CRLF-boundary hazard (P3-5) and P3-2/3/4/6/7 remain deferred on #1085.
+
+- **Read-guard did-you-mean no longer quotes NFKC-normalized text as "current lines"** (#1050) — the `Did you mean one of these current lines?` block (#505) rendered its rows from the normalized match space instead of the file's real characters, so for CJK markdown it folded `：`→`:`, `，`→`,`, `；`→`;`, `（）`→`()` and `—`→`-` and presented the result as ground truth about file content. That inverted #505's own stated invariant ("only for COMPARISON, never for the written content"). The damage compounded past a bad suggestion: an agent that copied the half-width row into `oldText` got past the guard, then the host's `fuzzyFindText` missed exact match, fell into fuzzy space, and `applyReplacementsPreservingUnchangedLines` rewrote the *touched* line from the normalized base — silently replacing full-width punctuation with ASCII while reporting success (untouched lines are safe per earendil-works/pi#5899; touched-line normalization is wontfix per earendil-works/pi#3554, so the suggestion is the only place this can be fixed). The failure mode is self-reinforcing: the agent re-reads the file next turn, sees changed punctuation, and concludes a markdown formatter is corrupting the file — a wrong root cause it then acts on. `findSimilarLines` now returns only `{ line, score }` and `formatSimilarLines` renders from the raw file, making it structurally impossible to leak normalized text into an error. The raw view is `normalizeToLF(stripBom(raw).text)` — the same STRUCTURAL normalization the match space applies, so line numbers cross-index 1:1 even on lone-CR or BOM files, but none of the CHARACTER folding, so full-width punctuation, smart quotes, and NBSP survive. A naive `\\r\\n`-only fold desyncs on lone-CR files and is covered by a regression test.
+- **Experimental git guard correctness (refs #1063)** — `--lens-guard` now detects real commit/push invocations through the shared shell tokenizer, gates only structured blocking findings (including blocking test failures), and rejects stale, malformed, cross-session, or sequence-mismatched state conservatively. Aggregate per-file blocker state, clean-turn invalidation, and bounded decision telemetry prevent advisory findings or a later clean file from silently clearing an unresolved blocker.
+- **Stale cross-file footer diagnostics now clear (refs #1093, refs #1092)** — a widget finding in file A that was *caused* by file B (a missing declaration, a changed export) is fixed by editing B, but every widget staleness gate compares A's OWN mtime to the record timestamp — and A's mtime never advances, so the resolved finding rendered forever (footer, `lens_diagnostics` replay, resume, fork adoption). Two minimal fixes close the reported shape. (1) The per-edit cascade already re-checks every edited file's dependents (`clients/dispatch/integration.ts`) but threw the result away as "display-only"; each **confirmed** neighbor result (a valid passive snapshot or a completed, non-inconclusive active touch — #571 semantics) now reconciles into widget state, **including the confirmed-clean `[]` case** that clears A's stale entry, keyed by the primary edit's `writeSeq` so a genuinely newer per-edit write still wins the `WriteOrderingGuard`. A touch that resolves `[]` while flagged `inconclusive` (its wait lapsed) is never treated as confirmed-clean — it neither reconciles nor seeds the recently-clean cache, so it cannot wipe a live finding (#533). Because the cascade only re-checks the *language server* and only for *errors*, the reconcile **merges** rather than replaces: it swaps out just the neighbor's existing LSP-error entries and preserves live biome/ruff/ast-grep findings and LSP *warnings* it never re-examined. Auxiliary-LSP findings (opengrep/ast-grep/zizmor/typos, identified by `findAuxiliaryProfileForSource`) are excluded from what the cascade writes — unlike the per-edit/scan writers it does not run `retagAuxiliaryDiagnostics`, so writing them would double-count the neighbor's own aux entry and escalate an advisory finding into a blocking `tool:"lsp"` error, bypassing aux policy. Tier-3-silent/recently-clean/within-turn-cache/rejected-touch results are never written. (2) `reconcileScanDiagnostics`/`recordDiagnostics` accept an observation timestamp; the `lsp_diagnostics` workspace-cache-hit branch (plus `lens_diagnostics mode=full`'s cache-served results) stamp `touchedAt` with when the diagnostics were *observed* (the cache entry's `scannedAt`), and the cascade's passive-snapshot reconcile stamps the snapshot's own publish time (`entry.ts`, up to `CASCADE_TTL_MS` old) — not `Date.now()` — so replaying an aging cached/snapshot view no longer keeps re-arming the mtime gate. The structural seq-stamping redesign (marking a changed file's reverse-dep set unverified up front) remains a follow-up under #1093.
+- **Class sweep: test fixtures hand-writing persisted-format version literals no longer go vacuous on version bumps (closes #1106; class generalized from #1089/#1082, fresh-risk flagged from #1096)** — a fixture that hand-writes a persisted-format `version:`/schema-tag literal a runtime gate checks BEFORE the code-under-test runs silently orphans on a version bump: the gate now rejects the (unrelated-stale) fixture and the test stays green for the wrong reason. Repo-wide sweep of `tests/` for hardcoded `version:` numerics and `"v<digit>"` schema tags across every known persisted-cache surface. Converted to import the runtime constant (exporting it where it was previously a private literal): `clients/call-graph.ts`'s `CACHE_VERSION` (was unexported — `tests/clients/call-graph.test.ts`'s `validPersistedCallGraph()` and `tests/clients/module-report.test.ts`'s call-graph-cache fixture both now import it instead of hand-writing `version: 5`), `clients/read-guard.ts`'s `READ_GUARD_STATE_VERSION`, `clients/widget-state.ts`'s `WIDGET_STATE_VERSION`, `clients/review-graph/builder.ts`'s `REVIEW_GRAPH_VERSION`, and a newly-extracted `clients/word-index.ts` `WORD_INDEX_FORMAT_VERSION` (previously an inline `2` duplicated at both the write and gate call sites). `tests/clients/project-diagnostics/scanner-wasm-abort.test.ts`'s `priorSnapshot()` fixture now imports the already-exported `PROJECT_DIAGNOSTICS_CACHE_VERSION` instead of hardcoding `2`. Every test that deliberately persists an OLD version to exercise the rejection path itself (call-graph v4, project-diagnostics v0 ×2, word-index v1, review-graph v3/v4) is pinned per the #1082 pattern: an adjacent `expect(CURRENT_CONSTANT).not.toBe(oldLiteral)` so a future bump onto that exact old value fails loudly instead of silently un-exercising the rejection path. Spot-proved non-vacuous for the three highest-traffic surfaces (call-graph, project-diagnostics, and — via the existing #1089 validator-disable proof already recorded in `call-graph.test.ts` — the semantic validator itself) by locally bumping the runtime constant, reverting the fixture to its old hardcoded literal, and confirming a loud failure (not a silent pass) before restoring both. Surfaces confirmed already immune (import the constant / derive-then-override a live value, so version drift cannot silently orphan them): `workspace-diagnostics-cache` (`WORKSPACE_DIAGNOSTICS_CACHE_VERSION` + self-relative `+1` mismatch), `warm-attach`/`mcp/ipc` (`WARM_DIAGNOSTICS_SCHEMA_VERSION`), `rule-cache` (`CACHE_VERSION`), `project-snapshot` (`PROJECT_SNAPSHOT_VERSION` for valid fixtures; deliberate-bad-version sentinels use `999`, permanently distant from the real 1-3 range). Confirmed NOT members of this class (noted for the next sweep so they aren't re-litigated): LSP wire-protocol `textDocument.version` fields (staleness/ordering, unrelated to a persisted-cache gate), assertions on production-EMITTED event/latency-log payloads (`lens-events`, `index-integration`, `cache-observability` — a bump fails these loudly, not vacuously, since they assert output rather than feed a hand-written fixture through a gate), in-memory-only `ReviewGraph` object literals in `transitive-impact.test.ts`/`lens-map.test.ts` (never round-trip through the persisted-JSON version gate), and `tests/tools/lens-diagnostics*.test.ts` (the entire `project-diagnostics/cache.js` module is `vi.mock`'d, so the real gate never runs). The installer's `probe-cache.json` has no version field/schema gate at all (not a member). `session-state-store.ts`'s own `STATE_VERSION` gate has no dedicated fixture test at all — a coverage gap, not a vacuous-fixture bug, left as a follow-up rather than expanded into new-test-authoring scope. SHAPE-gated fixtures (a loader that rejects on missing/malformed fields before the code-under-test) were also noted where encountered — `project-snapshot`'s "missing seq" meta test, `read-guard`'s malformed-`reads`-shape tests (now additionally non-vacuous on the version axis via the `READ_GUARD_STATE_VERSION` conversion above), and `word-index`'s malformed-input test — all correctly exercise their shape gate today.
+- **`no-bare-except` no longer flags subscripted exception specs (closes [#1244](https://github.com/apmantza/pi-lens/issues/1244))** — both detection surfaces (the ast-grep `no-bare-except` rule and the tree-sitter `bare-except` rule's `bare_except_only` post-filter) false-fired on valid subscript exception specs like `except dict[str, int]:` and PEP 654's canonical `except BaseExceptionGroup[TypeError, ValueError]:`. The #1031 sweep fixed the dotted-attribute sibling and stopped one member short: subscript was never in either surface's spec set, so neither surface suppressed it. The ast-grep `not: any:` and the tree-sitter filter's child-kind set both now accept `subscript`, keeping the two surfaces' shape spaces in lockstep (the same parity the #1026→#1031→#1243 arc enforced). Valid-fixture regression cases for both subscript forms fail against the pre-fix rule on both engines (2/2 false fires on the ast-grep CLI; 2/2 on the tree-sitter filter, confirmed by reverting the filter and re-running).
+
+- **Spawn failures now distinguish missing tools from invalid working directories (closes #1214)** — Auto-install and reinstall paths run only when the executable itself is missing, preventing futile reinstall loops for cwd and permission failures.
+
+- **Per-issue close-keyword CI validation** — Rejects comma-separated GitHub close lists and verifies merged PR close targets.
+
+- **Recover stale git-guard blocker records (closes #1084)** — Clear persisted blocker content only when complete, well-typed blocker-file provenance proves the last represented blocker was revalidated clean; incomplete or forged provenance remains blocked.
+
+- **Cascade module source-file walk is memoized on the existing freshness seams (refs [#1137](https://github.com/apmantza/pi-lens/issues/1137))** — `getModuleSourceFiles` (the #1318 slice-2 remnant) ran a recursive `readdirSync` walk per downstream module on every per-edit cascade in monorepos; it now memoizes per module root, revalidating on the visited directories' `mtimeMs` stamps plus ignore-matcher object identity (so `.gitignore`/`.pi-lens.json` edits re-walk), and clears with the module-graph cache.
+
+- **Review-graph supersession cleanup is deterministic (refs #1318)** -- a superseded generation's staged write is reaped synchronously (and fault-tolerantly) before completion becomes observable, so CI waiters can no longer observe a leftover stage file; the supersession lock test moved to the quiet timing-sensitive phase.
+
+- **In-pi extension logging no longer corrupts the pi TUI layout (closes #1333)** — pi owns the terminal, so the 26 ungated and 20 verbose-gated `console.error`/`console.warn` sites under `clients/` were landing raw bytes mid-frame and desyncing pi's screen model. Every site now writes to a `createNdjsonLogger` sink (the subsystem's own `tree-sitter.log`/`review-graph.log`/`latency.log` where one exists, otherwise the new `~/.pi-lens/extension.log`), user-facing degradations (invalid config, offline grammar fetch, WASM abort) additionally surface through `ctx.ui.notify`, and `index.ts` installs a defensive console reroute so a transitively loaded dependency cannot write to the frame either.
+
+- **npx formatter fallback honors style-preservation gating (closes #1345)** — Files that must be skipped by `SKIP_FORMATTING` no longer invoke the static Biome or Prettier `npx` fallback when a primary formatter command is unavailable.
+
+- **Formatter failures now appear in the diagnostics widget (closes #1346)** — Failed formatter runs render with a distinct error indication, remain deduplicated per formatter and file, and disappear after a successful retry.
+
+- **Instance-registry liveness tests no longer depend on arbitrary runner PIDs (refs #1352)** — synthetic dead PIDs are classified through deterministic test seams, preserving coverage of footprint exclusion, registry pruning, and vanished-instance wiring without relying on the CI process table.
+
+- **Trust-gated observability (refs #1334, #1358)** — LSP install refusals now log with warn-once deduplication, tree-sitter trust-blocked grammar toasts are deduplicated per grammar, trust transitions are recorded, and `~/.pi-lens/extension.log` is documented.
+
+- **BLIND WRITE no longer fires on self-authored files (closes #1364)** — A `write`/`edit` of the same normalized path earlier in the blind-write window now counts as file knowledge, so the common author-then-iterate loop (create a file with `write`, refine it with successive `edit` calls) stays quiet. A genuinely stale edit of a file not touched in the window still warns, and the two-write threshold, 5-call window, and thrashing detection are unchanged. Thanks to @snrogers for the field report and the fix.
+
+- **Edit counts now match normalized file paths (closes #1369)** — `AgentBehaviorClient.getEditCount` now uses the same path normalization as edit recording, so mixed-separator and case-variant lookups return the recorded count.
+
+- **Bound warm word-index memory (closes #1370, refs #1332)** — idle/LRU per-root eviction now releases inactive indexes safely, while persisted snapshot postings no longer remain duplicated in long-lived in-memory caches.
+
+- **Latency-log hygiene (closes #1371)** — Ast-grep unsupported-language telemetry now dedupes per language for each session and emits only a bounded rule-ID sample; the log analyzer excludes synthetic temp/scratchpad/heap-corpus rows by default, supports repeatable `--exclude` globs, and reports excluded-row counts.
+
+- **Review-graph size gates stop at the cap sentinel (closes #1372)** — the shared cooperative source walk now stops at `maxFileCount + 1`, reports the partial count honestly as “more than N files,” and emits a distinct near-miss telemetry event within 5% of the cap.
+
+- **Keep LSP roots inside the session project and coalesce nested marker clients (closes #1373, refs #1328)** — Clamp marker-selected roots at the declared cwd, and reuse same-server ancestor clients for config-only nested roots while preserving real manifest/lockfile sub-projects.
+
+- **Telemetry phase pairing and attribution (closes #1374)** — Deferred formatting now emits counted terminal phases; LSP warm-up and unavailable events reconcile correctly, diagnostic timeouts identify their server, and startup timing preserves the console guard's import-time position.
+
+- **Re-assert widget mounts after host UI replacement (closes #1381)** — The diagnostics widget remounts on the live UI at turn start when needed, while preserving mode and user visibility gates; unsupported widget hosts now emit a log-once diagnostic.
+
+- **Widget and inter-extension bus updates recover after session replacement (closes #1383)** — every `session_start`, including the #473 guarded in-process subagent path, now reclaims activation-scoped bus, notifier, and widget-render wiring before returning. Stale bus failures are logged and ledgered once per failure occurrence, with a successful publish re-arming observability for a later channel death.
+
+- **Deferred formatting uses bounded concurrency (closes #1387)** — the `agent_end` drain runs at most three formatter subprocesses in flight, applies results and synchronous bookkeeping in admission order with `setImmediate` yields between files, preserves per-file failure isolation, and requeues claimed records that were not started when the ambient turn aborts.
+
+- **Hardened codebase-model cache identity (closes #1388)** — persisted models now carry a version and canonical review-graph identity, stale caches invalidate on mismatch, and model file selection uses shared role and artifact filtering.
+
+- **Prevented consistency drift in language fixtures and extension handling (refs #1388)** — call-graph fixtures now cover every symbol-query language, JS/TS facts share the canonical extension policy, and bash file-access tracking derives source extensions from `KIND_EXTENSIONS`.
+
+- **Canonicalized LSP edit merge buckets and call-graph path comparisons (refs #1388)** — equivalent URI spellings now share conflict/deduplication buckets while preserving the first display URI, and call-graph symbol/reference indexes normalize file keys consistently.
+
+- **Bound and idle-evict review-graph workspaces and authoritative project snapshots (refs #1389).**
+
+- Bound and evict rebuildable Tier 2 reverse-dependency, tree-sitter query, and workspace-topology caches while retaining unconsumed ReadGuard records until their edit or session end. ReadGuard now applies a high sanity cap with oldest-to-re-read eviction for read-only sessions (refs #1389; widget-state and Tier 3 remain deferred).
+
+- **Bound Tier-3 process caches, prune expired negative LSP entries, decay widget/agent state, and close the cache audit (closes #1389).**
+
+- **Scope session-start smell-tail diagnostics to the current session boundary (closes #1398)** — historical failures in the bounded bus-events and latency log tails are no longer reported as current; rows must have a parseable UTC timestamp at or after session start.
+
+- **Unconfigured Python files are formatted again (refs #1144)** — `ruff format` rejects the `--indent-style`/`--indent-width` flags the style-preserving defaults were passing, exiting 2 without touching the file; because ruff was not treated as a strict-exit formatter, every unconfigured Python file silently reported "already formatted" and was never reformatted. Style is now pinned through ruff's inline TOML overrides, and a nonzero ruff exit is surfaced as a formatting failure instead of a clean no-op.
+- **Ast-grep console-rule exclusions (closes [#965](https://github.com/apmantza/pi-lens/issues/965))** — stop flagging intentional console usage in CLI scripts and logger implementations.
+- **Nullish equality exemptions (closes [#966](https://github.com/apmantza/pi-lens/issues/966))** — allow intentional `== null` / `!= null` checks while retaining other strict-equality findings.
+- **Security-pin dependency handling (closes [#968](https://github.com/apmantza/pi-lens/issues/968))** — stop Knip from flagging dependencies used only through override/resolution security pins.
+- **Unsafe-boundary fallback detection (closes [#969](https://github.com/apmantza/pi-lens/issues/969))** — recognize catch blocks that recover through fallback assignments.
+- **Promise-returning async callbacks (closes [#970](https://github.com/apmantza/pi-lens/issues/970))** — avoid async-noise findings when an explicit Promise return type is required.
+- **Native zizmor suppressions (closes [#971](https://github.com/apmantza/pi-lens/issues/971))** — honor inline `zizmor: ignore[...]` directives.
+- **Named URL constants (closes [#964](https://github.com/apmantza/pi-lens/issues/964))** — avoid hardcoded-URL findings for deliberate `SCREAMING_SNAKE_CASE` endpoint constants.
+- **Opengrep LSP compatibility (closes [#974](https://github.com/apmantza/pi-lens/issues/974))** — stop advertising unused work-done-progress support that could trigger client crash loops.
+- **Workspace configuration responses (closes [#983](https://github.com/apmantza/pi-lens/issues/983))** — return one resolved value for each requested configuration section.
+- **Same-file diagnostic ordering (closes [#1198](https://github.com/apmantza/pi-lens/issues/1198))** — prevent late diagnostic work from restoring stale pending results.
+- **Bounded installer retries (refs [#1222](https://github.com/apmantza/pi-lens/issues/1222), [#1223](https://github.com/apmantza/pi-lens/issues/1223))** — cap failed install retries and preserve probe-cache updates across concurrent writes.
+- **Stabilize LSP workspace-edit occupancy (closes [#1091](https://github.com/apmantza/pi-lens/issues/1091))** — keep workspace edits consistent under concurrent occupancy.
+### Security
+
+- **Git guard command-injection hardening (refs #1084, PR #1395)** — canonicalizes shell IFS parameter-expansion separators once, quote-aware, before verb classification and treats any non-leading guarded `git` invocation as suspicious, including arbitrary unknown wrappers and run flags; literal text consumers remain non-blocking.
+
+
+- **`toPosix()` / `splitPathSegments()` path primitives ([#1193](https://github.com/apmantza/pi-lens/issues/1193))** — the sanctioned backslash→forward-slash fold and shape-safe segment split, the single canonical form of the `p.replace(/\\/g, "/")` / `p.split(/[\\/]+/)` idioms otherwise hand-rolled ~138× across the codebase. Pure separator normalization — no resolve/case/realpath (use `normalizeFilePath`/`normalizeMapKey`/`normalizeEphemeralMapKey` when a canonical key is needed). First step of the OS-agnostic transformation-layer consolidation: funnelling the scattered transform makes a shape-2 lint/ast-grep rule possible for the first time (today a bare inline `.replace(/\\/g, "/")` is byte-identical to a sanctioned use; once everything routes through `toPosix`, an un-migrated inline `.replace` becomes detectable — #1158). Adds the primitives + tests only; migrating the existing call sites is a tracked follow-up under #1193.
+
+- **On-demand heap snapshots for retainer attribution ([#1126](https://github.com/apmantza/pi-lens/issues/1126))** — `PI_LENS_DEBUG_HEAP=1` makes `/lens-health` also write a V8 `.heapsnapshot` to `~/.pi-lens/` (plus a breadcrumb line in `heap-snapshots.log`), so the "which objects retain the bytes" follow-up to #1123's `memory_sample` trajectory is answerable on a live >1 GB instance without a fresh ad-hoc expedition. The flag is read once at startup and the writer mirrors `clients/debug-handles.ts`: zero cost + no file when unset, and the (synchronous, multi-second) snapshot is only ever triggered from the operator-invoked diagnostics command — never a hot path or timer. Snapshot files are pruned to the newest `SNAPSHOT_RETENTION` (3) after each write, bounding the growing on-disk axis (AGENTS.md shape 9). Auto-capture on an RSS threshold is a deliberately-deferred follow-up (it would reintroduce the pause onto an automatic path).
+
+- **Guard hardening (refs #1084)** - git commit/push detection now covers normalized wrapper launchers (including path- and PATHEXT-qualified names), shell-escaped verbs, keyword, combined-flag, and continuation forms; shell substitutions are treated as execution even inside text consumers, while literal text remains allowed; bash read and ownership grants use quote-aware tokenization and are recorded only after successful tool results. Stale-record recovery remains deferred.
+
+- **Honor the pi host's project-trust decision before installing or spawning anything (refs #1334)** — pi-lens now reads `ctx.isProjectTrusted()` at every `session_start`. When the host says a project is NOT trusted, tool auto-install degrades to discovery-only (nothing is downloaded or executed) and LSP servers are not spawned; in-process analysis, caches and tree-sitter continue unchanged. Hosts that expose no trust surface behave exactly as before.
+
+### Contributors
+
+- Apostolos Mantzaris (@apmantza)
+- Nathan Cooke (@3choBoomer)
+- Eli Stark (@white-hat)
+- Mark Faga (@mjfaga)
+- Marvin Aziz (@marvtub)
+- Dominic (@aeturnal)
+- Kenneth McCormick
+- jiangmt
+
 ## [3.8.74] - 2026-08-01
 
 ### Added
@@ -17,1114 +1522,1093 @@ All notable changes to pi-lens will be documented in this file.
 - **🙏 Huge thanks to @AngriestBird (Kenny McCormick), this round's standout community contributor** — five merged PRs landed this release: a single source of truth for CLI flags (#1011), secret redaction at the log-write boundary (#954), new slash commands (#906), tree-cache performance improvements (#877), and a test harness for rule-dispatch behavior (#871). Sustained, high-quality work spanning perf, security, config, and test infrastructure — thank you.
 
 - **Prompt-cache observability (refs #1018, closes #1018)** — two provider-independent
-	signals now land in `~/.pi-lens/latency.log` as `type: "phase"` records.
-	(1) Response-side: a defensively feature-detected `message_end` subscription
-	(clients/agent-nudge.ts pattern — guarded, never throws on older hosts) logs one
-	`cache_usage` record per assistant message that carries a `usage`, with
-	`metadata: { provider, model, cacheRead, cacheWrite, input, output, cost }`
-	(provider/model read straight off the assistant message; `cost` is the total).
-	Messages with no usage (or non-assistant messages) are skipped rather than
-	logged as zeros. (2) Request-side: the existing `context` handler now hashes
-	`messages[0]` on every call and logs a `cache_prefix_break` record
-	(`metadata: { turnIndex, previousHash, currentHash, sessionId, sessionRole }`,
-	plus a baseline record on first observation) whenever that hash changes
-	turn-over-turn — a regression guard that flags anything (pi-lens or otherwise)
-	breaking the byte-stable prefix #1016 established. The baseline is keyed by the
-	stable per-session id (`ctx.sessionManager.getSessionId()`) in a small bounded
-	LRU, so a resume/reload keeps comparing against its own baseline while a
-	new/fork or a concurrent in-process subagent (#473) gets an independent baseline
-	instead of a spurious cross-session break; each record is tagged with the
-	read-only #473 `sessionRole` classification, and a primary `session_shutdown`
-	drops the ended session's entry. The hash is pure observation: it never changes
-	the handler's injection behavior or return value, and runs even on non-injecting
-	turns. New `clients/cache-observability.ts`; no new dependencies.
+ signals now land in `~/.pi-lens/latency.log` as `type: "phase"` records.
+ (1) Response-side: a defensively feature-detected `message_end` subscription
+ (clients/agent-nudge.ts pattern — guarded, never throws on older hosts) logs one
+ `cache_usage` record per assistant message that carries a `usage`, with
+ `metadata: { provider, model, cacheRead, cacheWrite, input, output, cost }`
+ (provider/model read straight off the assistant message; `cost` is the total).
+ Messages with no usage (or non-assistant messages) are skipped rather than
+ logged as zeros. (2) Request-side: the existing `context` handler now hashes
+ `messages[0]` on every call and logs a `cache_prefix_break` record
+ (`metadata: { turnIndex, previousHash, currentHash, sessionId, sessionRole }`,
+ plus a baseline record on first observation) whenever that hash changes
+ turn-over-turn — a regression guard that flags anything (pi-lens or otherwise)
+ breaking the byte-stable prefix #1016 established. The baseline is keyed by the
+ stable per-session id (`ctx.sessionManager.getSessionId()`) in a small bounded
+ LRU, so a resume/reload keeps comparing against its own baseline while a
+ new/fork or a concurrent in-process subagent (#473) gets an independent baseline
+ instead of a spurious cross-session break; each record is tagged with the
+ read-only #473 `sessionRole` classification, and a primary `session_shutdown`
+ drops the ended session's entry. The hash is pure observation: it never changes
+ the handler's injection behavior or return value, and runs even on non-injecting
+ turns. New `clients/cache-observability.ts`; no new dependencies.
 
 - **Word-index build/refresh/persist outcomes are now durably observable**
-	(refs #958, #926, #533) — every word-index signal previously rode solely on
-	the optional `dbg` callback, a documented no-op in the MCP host where
-	`symbol_search` reads the index. The structured logger (`~/.pi-lens/
-	word-index.log`, shared `createNdjsonLogger` infra) now records, independent
-	of `dbg`: the full-rebuild-vs-incremental decision plus honest coverage
-	(`indexedFileCount`/`truncated` and `refreshed`/`dropped`/`skipped`/`reused`
-	counts) for both the session-start and cold-query (MCP) build paths; a
-	swallowed snapshot **persist failure** as `persist_failed` (a silent stale
-	index otherwise leaves no trace); and the safety refusal for a root at/above
-	`$HOME`. The full-build collector (`collectWordIndexDocs`) now also returns a
-	`skipped` count for files it enumerated but could not index (over the byte
-	cap / unreadable), so a partial index is never reported as complete. The
-	fragile string-parsing `dbg` adapter this replaces is removed.
-
-- **Closed four observability gaps in recently-changed typos-config and
-	project-snapshot code** (refs #533) — none of these change behavior, only
-	what's now logged: (1) the typos LSP's inject-vs-step-aside decision
-	(#967) now logs a `typos_config_resolved` phase in `latency.log` /
-	`sessionstart.log` with `mode: "project_config" | "injected_default"` and
-	the resolved `configPath`, so which typos config is actually active is no
-	longer a guess; (2) a project-snapshot body persist that falls back to the
-	synchronous main-thread gzip because the persist worker died/was
-	unavailable now logs an explicit `project_snapshot_worker_fallback` phase
-	with the `reason` (previously only visible via a test-only variable, or
-	buried in an `offloaded:false` success line) — this is the +656MB-risk
-	degraded path from #950; (3) a corrupt/truncated gzipped snapshot body
-	(gunzip/JSON.parse failure) now logs `project_snapshot_body_corrupt`
-	before failing open to a rebuild, instead of being indistinguishable from
-	"no snapshot yet"; (4) dropping the in-process authoritative snapshot
-	entry for an oversized (>24MB) body now logs
-	`project_snapshot_authoritative_dropped_oversized` — low-priority, but no
-	longer silent.
+ (refs #958, #926, #533) — every word-index signal previously rode solely on
+ the optional `dbg` callback, a documented no-op in the MCP host where
+ `symbol_search` reads the index. The structured logger (`~/.pi-lens/
+ word-index.log`, shared `createNdjsonLogger` infra) now records, independent
+ of `dbg`: the full-rebuild-vs-incremental decision plus honest coverage
+ (`indexedFileCount`/`truncated` and `refreshed`/`dropped`/`skipped`/`reused`
+ counts) for both the session-start and cold-query (MCP) build paths; a
+ swallowed snapshot **persist failure** as `persist_failed` (a silent stale
+ index otherwise leaves no trace); and the safety refusal for a root at/above
+ `$HOME`. The full-build collector (`collectWordIndexDocs`) now also returns a
+ `skipped` count for files it enumerated but could not index (over the byte
+ cap / unreadable), so a partial index is never reported as complete. The
+ fragile string-parsing `dbg` adapter this replaces is removed.
+
+- **Closed four observability gaps in recently-changed typos-config and project-snapshot code (refs #533)** — none of these change behavior, only
+ what's now logged: (1) the typos LSP's inject-vs-step-aside decision
+ (#967) now logs a `typos_config_resolved` phase in `latency.log` /
+ `sessionstart.log` with `mode: "project_config" | "injected_default"` and
+ the resolved `configPath`, so which typos config is actually active is no
+ longer a guess; (2) a project-snapshot body persist that falls back to the
+ synchronous main-thread gzip because the persist worker died/was
+ unavailable now logs an explicit `project_snapshot_worker_fallback` phase
+ with the `reason` (previously only visible via a test-only variable, or
+ buried in an `offloaded:false` success line) — this is the +656MB-risk
+ degraded path from #950; (3) a corrupt/truncated gzipped snapshot body
+ (gunzip/JSON.parse failure) now logs `project_snapshot_body_corrupt`
+ before failing open to a rebuild, instead of being indistinguishable from
+ "no snapshot yet"; (4) dropping the in-process authoritative snapshot
+ entry for an oversized (>24MB) body now logs
+ `project_snapshot_authoritative_dropped_oversized` — low-priority, but no
+ longer silent.
 
 - **Review-graph checkpoint discards and write failures are now observable**
-	(refs #936, #533) — a present resume checkpoint that's rejected now logs
-	`checkpoint_discarded` with a `reason` (`corrupt`, `version_mismatch`,
-	`not_in_progress`, `git_stamp_mismatch`, `ignored_ids_mismatch`,
-	`removed_file`, `all_stale`) instead of silently falling back to a full cold
-	rebuild, and a failed checkpoint write (worker error/death, promote failure,
-	sync-write failure) logs `checkpoint_write_failed` — so "why isn't my
-	checkpoint resuming / persisting?" is diagnosable from `review-graph.log`.
+ (refs #936, #533) — a present resume checkpoint that's rejected now logs
+ `checkpoint_discarded` with a `reason` (`corrupt`, `version_mismatch`,
+ `not_in_progress`, `git_stamp_mismatch`, `ignored_ids_mismatch`,
+ `removed_file`, `all_stale`) instead of silently falling back to a full cold
+ rebuild, and a failed checkpoint write (worker error/death, promote failure,
+ sync-write failure) logs `checkpoint_write_failed` — so "why isn't my
+ checkpoint resuming / persisting?" is diagnosable from `review-graph.log`.
 
 - **The review-graph full build is now resumable across sessions** (refs #936
-	limit 2) — a cold full build (walk + tree-sitter parse of every source file)
-	previously restarted from scratch every session, so on a large repo with
-	short-lived sessions it could never finish. The extraction loop now
-	periodically checkpoints the PRE-resolution graph plus the exact set of files
-	already folded into it (with content hashes) to a dedicated
-	`review-graph.checkpoint.json.gz`, and a later session resumes from it,
-	re-walking only files that changed/appeared since. The checkpoint lives in
-	its own file (never the authoritative `review-graph.json.gz`) and its
-	hydrated graph carries `persistCoverage.inProgress` on top of `partial`, so
-	no reader (`getCachedReviewGraph`, `loadPersistedGraph`) can ever serve or
-	launder a mid-build checkpoint as a complete graph (honesty doctrine, #533).
-	Resume equivalence to a cold build is guaranteed by `addFileToGraph`'s
-	per-file contribution being order-independent (all cross-file linking is
-	deferred to `resolveDeferredSymbolEdges`): content-changed processed files
-	are evicted and re-walked, orphaned placeholder nodes are pruned, and any
-	removed file, ignored-id-set change, version bump, or git-identity mismatch
-	fails open to a cold build rather than risking a wrong graph. Checkpoint
-	stride/interval are tunable via `PI_LENS_GRAPH_CHECKPOINT_EVERY_FILES` /
-	`PI_LENS_GRAPH_CHECKPOINT_MIN_INTERVAL_MS`.
+ limit 2) — a cold full build (walk + tree-sitter parse of every source file)
+ previously restarted from scratch every session, so on a large repo with
+ short-lived sessions it could never finish. The extraction loop now
+ periodically checkpoints the PRE-resolution graph plus the exact set of files
+ already folded into it (with content hashes) to a dedicated
+ `review-graph.checkpoint.json.gz`, and a later session resumes from it,
+ re-walking only files that changed/appeared since. The checkpoint lives in
+ its own file (never the authoritative `review-graph.json.gz`) and its
+ hydrated graph carries `persistCoverage.inProgress` on top of `partial`, so
+ no reader (`getCachedReviewGraph`, `loadPersistedGraph`) can ever serve or
+ launder a mid-build checkpoint as a complete graph (honesty doctrine, #533).
+ Resume equivalence to a cold build is guaranteed by `addFileToGraph`'s
+ per-file contribution being order-independent (all cross-file linking is
+ deferred to `resolveDeferredSymbolEdges`): content-changed processed files
+ are evicted and re-walked, orphaned placeholder nodes are pruned, and any
+ removed file, ignored-id-set change, version bump, or git-identity mismatch
+ fails open to a cold build rather than risking a wrong graph. Checkpoint
+ stride/interval are tunable via `PI_LENS_GRAPH_CHECKPOINT_EVERY_FILES` /
+ `PI_LENS_GRAPH_CHECKPOINT_MIN_INTERVAL_MS`.
 
 - **Bundled default typos allowlist for projects without their own config**
-	(fixes #967) — the `typos` auxiliary LSP now injects a small pi-lens-shipped
-	`_typos.toml` (`rules/typos/_typos.toml`, `[default.extend-identifiers]`
-	only: `dito`, `unparseable`) via `initializationOptions.config` whenever a
-	project has no `typos.toml`/`_typos.toml`/`.typos.toml` of its own. A
-	project's own config still always wins outright: when one is found,
-	pi-lens injects nothing at all (rather than letting typos-lsp merge ours
-	on top and risk our defaults outranking the team's own allowlist on key
-	collisions).
+ (fixes #967) — the `typos` auxiliary LSP now injects a small pi-lens-shipped
+ `_typos.toml` (`rules/typos/_typos.toml`, `[default.extend-identifiers]`
+ only: `dito`, `unparseable`) via `initializationOptions.config` whenever a
+ project has no `typos.toml`/`_typos.toml`/`.typos.toml` of its own. A
+ project's own config still always wins outright: when one is found,
+ pi-lens injects nothing at all (rather than letting typos-lsp merge ours
+ on top and risk our defaults outranking the team's own allowlist on key
+ collisions).
 
 - **Session-start latency is attributable end to end** (refs #948) — latency
-	telemetry now separates host boot from pi-lens evaluation and records quick
-	and full session-start totals, pre-handler/bootstrap work, runtime reset,
-	log cleanup, LSP reset, sequence/snapshot reads (including snapshot bytes),
-	and delayed warmup scan/profile/index phases.
+ telemetry now separates host boot from pi-lens evaluation and records quick
+ and full session-start totals, pre-handler/bootstrap work, runtime reset,
+ log cleanup, LSP reset, sequence/snapshot reads (including snapshot bytes),
+ and delayed warmup scan/profile/index phases.
 
 - **Review-graph LSP fallback nodes** (refs #307) — when tree-sitter yields
-	zero declarations, the builder may use `documentSymbol` from an already-live,
-	already-open capable server. Nodes carry `provenance: "lsp"`, hierarchical
-	containment survives persistence (including flat native-TypeScript-7 results
-	reconstructed through `containerName`), productive tree-sitter files never
-	pay the request, and unavailable/failed fallback attempts degrade without
-	opening or spawning while remaining visible in `review-graph.log`.
+ zero declarations, the builder may use `documentSymbol` from an already-live,
+ already-open capable server. Nodes carry `provenance: "lsp"`, hierarchical
+ containment survives persistence (including flat native-TypeScript-7 results
+ reconstructed through `containerName`), productive tree-sitter files never
+ pay the request, and unavailable/failed fallback attempts degrade without
+ opening or spawning while remaining visible in `review-graph.log`.
 
 - **Standalone out-of-band review-graph build CLI** (refs #924) — `npx pi-lens
-	build-graph [--cwd <dir>]` reuses the session builder and queued atomic
-	persist path for CI/cron, forces the debounced snapshot write before exit,
-	and prints file/node/edge/element counts, JSON bytes, and duration. Unsafe
-	roots, build errors/skips, persist failures, and persist-cap trips exit
-	non-zero with their reason instead of silently leaving no snapshot.
+ build-graph [--cwd <dir>]` reuses the session builder and queued atomic
+ persist path for CI/cron, forces the debounced snapshot write before exit,
+ and prints file/node/edge/element counts, JSON bytes, and duration. Unsafe
+ roots, build errors/skips, persist failures, and persist-cap trips exit
+ non-zero with their reason instead of silently leaving no snapshot.
 
 - **`/lens-perf` surfaces slow phases in-session** (closes #767) — the command
-	shows independent top-five p50 and p99 rankings with sample counts for both
-	the current process session and the machine-wide active `latency.log` window.
-	It flushes pending writes, streams a tail bounded by the log rotation
-	threshold (`PI_LENS_MAX_LOG_SIZE_MB`, 10MB by default), caps retained samples,
-	and reports malformed/truncated input instead of silently reading it as clean.
-	Session startup total and scan-context computation are now logged as phases so
-	the startup regressions that motivated the command are visible there too.
+ shows independent top-five p50 and p99 rankings with sample counts for both
+ the current process session and the machine-wide active `latency.log` window.
+ It flushes pending writes, streams a tail bounded by the log rotation
+ threshold (`PI_LENS_MAX_LOG_SIZE_MB`, 10MB by default), caps retained samples,
+ and reports malformed/truncated input instead of silently reading it as clean.
+ Session startup total and scan-context computation are now logged as phases so
+ the startup regressions that motivated the command are visible there too.
 
 ### Changed
 
 - **Session-start perf: bound the change-log replay + defer log cleanup (closes #1019)** —
-	the interactive session-start path recomputed the project sequence by reading
-	the ENTIRE append-only change log and folding every line — and each fold does a
-	`normalizeMapKey`/`realpathSync.native()` syscall per historical entry, so the
-	`session_start_sequence_read` phase (measured ~94ms, ~47% of a 200ms warm start)
-	grew unbounded with total log length, not the working set. The project snapshot
-	now embeds the DERIVED sequence index (`projectSeq` + per-file `fileSeqByPath`)
-	as of its `seq` (`clients/project-snapshot.ts`), mirrored into the tiny
-	`project-snapshot.meta.json` sidecar so session-start can hydrate it WITHOUT
-	parsing the 40-112MB body (preserving the #947 skip-stale optimization).
-	`readLatestProjectSequence` (`clients/project-changes.ts`) gained an optional
-	base param: it hydrates that index (O(files-in-snapshot), keys already
-	normalized → no per-key `realpath`) and folds ONLY entries with
-	`seq > snapshot.seq` — O(changes-since-snapshot). The fold uses the SAME
-	`Math.max`/`normalizeMapKey` the full replay does, so the result is
-	byte-identical to a full replay (proven by an equivalence test suite covering
-	no-new-entries, new/existing files, deletes, gaps/out-of-order, and the empty
-	log) and order-independent. Correctness-first fallbacks to a full replay: a
-	legacy/missing meta with no embedded index, a version-mismatched meta, and a
-	snapshot whose `seq` is AHEAD of the log (truncation/rotation) — it never serves
-	a wrong seq. Wired into BOTH the quick/interactive and the full session-start
-	paths. Secondary: `log_cleanup` (~7ms) was moved off the synchronous critical
-	path into a deferred `setImmediate` (it still runs every session and notifies
-	async — nothing on the hot path consumed its result).
+ the interactive session-start path recomputed the project sequence by reading
+ the ENTIRE append-only change log and folding every line — and each fold does a
+ `normalizeMapKey`/`realpathSync.native()` syscall per historical entry, so the
+ `session_start_sequence_read` phase (measured ~94ms, ~47% of a 200ms warm start)
+ grew unbounded with total log length, not the working set. The project snapshot
+ now embeds the DERIVED sequence index (`projectSeq` + per-file `fileSeqByPath`)
+ as of its `seq` (`clients/project-snapshot.ts`), mirrored into the tiny
+ `project-snapshot.meta.json` sidecar so session-start can hydrate it WITHOUT
+ parsing the 40-112MB body (preserving the #947 skip-stale optimization).
+ `readLatestProjectSequence` (`clients/project-changes.ts`) gained an optional
+ base param: it hydrates that index (O(files-in-snapshot), keys already
+ normalized → no per-key `realpath`) and folds ONLY entries with
+ `seq > snapshot.seq` — O(changes-since-snapshot). The fold uses the SAME
+ `Math.max`/`normalizeMapKey` the full replay does, so the result is
+ byte-identical to a full replay (proven by an equivalence test suite covering
+ no-new-entries, new/existing files, deletes, gaps/out-of-order, and the empty
+ log) and order-independent. Correctness-first fallbacks to a full replay: a
+ legacy/missing meta with no embedded index, a version-mismatched meta, and a
+ snapshot whose `seq` is AHEAD of the log (truncation/rotation) — it never serves
+ a wrong seq. Wired into BOTH the quick/interactive and the full session-start
+ paths. Secondary: `log_cleanup` (~7ms) was moved off the synchronous critical
+ path into a deferred `setImmediate` (it still runs every session and notifies
+ async — nothing on the hot path consumed its result).
 
 - **Config-consistency pass on the #166 flag registry (refs #166, #533)** — the
-	#883 registry core (scope split, precedence, negation) was audited consistent
-	and left untouched; the gaps were all in #533 malformed/unknown-input
-	signalling, asymmetric between the global and project loaders. (1) The
-	project loader (`.pi-lens.json`) now warns once on an unrecognized top-level
-	key — a typo like `maxProjectFile` or `lps` previously did nothing silently —
-	while tolerating the foreign namespaces the shared file legitimately carries
-	for the LSP loader (`servers`, `serverOverrides`, `disabledServers`,
-	`warmFiles`, plus `$schema`); a user-level-only lens key placed at project
-	scope (e.g. `lsp`, `tests`, `delta`) gets a distinct "not honored at project
-	scope" signal instead of being lumped in with typos. (2) The recognized-key
-	catalogs are single-sourced (#883): `GLOBAL_NON_FLAG_CONFIG_SECTIONS` and
-	`PROJECT_FOREIGN_CONFIG_NAMESPACES` are declared once beside `LENS_FLAGS`, and
-	both loaders derive flag sections from the registry, so adding a namespace is
-	a one-line edit and adding a flag needs none — replacing a drift-prone inline
-	literal set in the global loader. (3) Three global scalars
-	(`dispatch.runnerTimeoutFloorMs`, `widget.visible`, `format.mode`) that
-	silently coerced a present-but-malformed value to `undefined` now warn on
-	invalid input through the same path as `actionableWarnings.autoFix.maxFixes`,
-	while staying silent when the key is absent (no false warnings). (4) Removed
-	five dead global-only accessors that bypassed the precedence chain
-	(`getGlobalAutoformatEnabled`, `getGlobalAutofixEnabled`,
-	`getGlobalImmediateFormatDefault`, `getGlobalContextInjectionEnabled`,
-	`getGlobalTurnSummaryEnabled`) — no non-test callers existed. (5) Updated
-	`docs/globalconfig.md`, whose "unknown keys are ignored" claim was stale.
+ #883 registry core (scope split, precedence, negation) was audited consistent
+ and left untouched; the gaps were all in #533 malformed/unknown-input
+ signalling, asymmetric between the global and project loaders. (1) The
+ project loader (`.pi-lens.json`) now warns once on an unrecognized top-level
+ key — a typo like `maxProjectFile` or `lps` previously did nothing silently —
+ while tolerating the foreign namespaces the shared file legitimately carries
+ for the LSP loader (`servers`, `serverOverrides`, `disabledServers`,
+ `warmFiles`, plus `$schema`); a user-level-only lens key placed at project
+ scope (e.g. `lsp`, `tests`, `delta`) gets a distinct "not honored at project
+ scope" signal instead of being lumped in with typos. (2) The recognized-key
+ catalogs are single-sourced (#883): `GLOBAL_NON_FLAG_CONFIG_SECTIONS` and
+ `PROJECT_FOREIGN_CONFIG_NAMESPACES` are declared once beside `LENS_FLAGS`, and
+ both loaders derive flag sections from the registry, so adding a namespace is
+ a one-line edit and adding a flag needs none — replacing a drift-prone inline
+ literal set in the global loader. (3) Three global scalars
+ (`dispatch.runnerTimeoutFloorMs`, `widget.visible`, `format.mode`) that
+ silently coerced a present-but-malformed value to `undefined` now warn on
+ invalid input through the same path as `actionableWarnings.autoFix.maxFixes`,
+ while staying silent when the key is absent (no false warnings). (4) Removed
+ five dead global-only accessors that bypassed the precedence chain
+ (`getGlobalAutoformatEnabled`, `getGlobalAutofixEnabled`,
+ `getGlobalImmediateFormatDefault`, `getGlobalContextInjectionEnabled`,
+ `getGlobalTurnSummaryEnabled`) — no non-test callers existed. (5) Updated
+ `docs/globalconfig.md`, whose "unknown keys are ignored" claim was stale.
 
 - **Normalized call-graph impact checks into structured `ProjectDiagnostic`s**
-	(refs #179) — the last remaining adapter gap in #179's normalization sweep.
-	`runtime-turn.ts`'s turn-end call-graph impact check (WillBreak/MayBreak
-	callers of symbols edited this turn, via `impact()`/`call-graph.ts`) was
-	advisory-text only, unlike the other 9 runners already normalized through
-	`runner-adapters/*.ts`. Added `callGraphImpactToProjectDiagnostics`
-	(`project-diagnostics/runner-adapters/call-graph-impact.ts`), a pure mapper
-	attributing each diagnostic to the CALLER's file (no line — `impact()`'s
-	`ImpactResult` never carries one, and the underlying call-graph symbol
-	table only has a placeholder `line: 1`, so inventing one would be a fake
-	location). Severity is deliberately capped below this codebase's
-	"blocking" hard-stop tier for BOTH WillBreak and MayBreak (#533 honesty):
-	`impact()` is a name-resolution heuristic with no type information, so a
-	resolved caller is never a confirmed break. Wired at turn-end (not
-	`fresh-fetch.ts`/`ANALYZER_IDS`) since impact analysis is inherently
-	per-turn-edit, not a whole-project scan — same reasoning that keeps
-	test-runner's own turn-end fire out of that registry. The existing
-	human-readable advisory string is kept as-is (separate surface, same
-	dual-surface pattern already used by knip's turn-end delta). The call-graph
-	block now runs BEFORE the single `writeProjectDiagnosticsDeltaReport`
-	serialization point (alongside knip's delta push) rather than after it —
-	previously it pushed into `projectDiagnosticsDelta`/`projectDiagnosticsSources`
-	past the one-shot write, so a call-graph-only turn persisted nothing and a
-	mixed turn dropped the call-graph entries, leaving `lens_diagnostics` (a
-	pure reader of the persisted report) unable to ever surface the findings
-	(#533). Covered by a new `handleTurnEnd`-level regression test asserting the
-	persisted report for both call-graph-only and mixed turns.
+ (refs #179) — the last remaining adapter gap in #179's normalization sweep.
+ `runtime-turn.ts`'s turn-end call-graph impact check (WillBreak/MayBreak
+ callers of symbols edited this turn, via `impact()`/`call-graph.ts`) was
+ advisory-text only, unlike the other 9 runners already normalized through
+ `runner-adapters/*.ts`. Added `callGraphImpactToProjectDiagnostics`
+ (`project-diagnostics/runner-adapters/call-graph-impact.ts`), a pure mapper
+ attributing each diagnostic to the CALLER's file (no line — `impact()`'s
+ `ImpactResult` never carries one, and the underlying call-graph symbol
+ table only has a placeholder `line: 1`, so inventing one would be a fake
+ location). Severity is deliberately capped below this codebase's
+ "blocking" hard-stop tier for BOTH WillBreak and MayBreak (#533 honesty):
+ `impact()` is a name-resolution heuristic with no type information, so a
+ resolved caller is never a confirmed break. Wired at turn-end (not
+ `fresh-fetch.ts`/`ANALYZER_IDS`) since impact analysis is inherently
+ per-turn-edit, not a whole-project scan — same reasoning that keeps
+ test-runner's own turn-end fire out of that registry. The existing
+ human-readable advisory string is kept as-is (separate surface, same
+ dual-surface pattern already used by knip's turn-end delta). The call-graph
+ block now runs BEFORE the single `writeProjectDiagnosticsDeltaReport`
+ serialization point (alongside knip's delta push) rather than after it —
+ previously it pushed into `projectDiagnosticsDelta`/`projectDiagnosticsSources`
+ past the one-shot write, so a call-graph-only turn persisted nothing and a
+ mixed turn dropped the call-graph entries, leaving `lens_diagnostics` (a
+ pure reader of the persisted report) unable to ever surface the findings
+ (#533). Covered by a new `handleTurnEnd`-level regression test asserting the
+ persisted report for both call-graph-only and mixed turns.
 
 - **Parallelized the per-turn madge dependency check** (refs #766) — the
-	turn-end circular-dependency pass previously ran one `await checkFile()`
-	per import-changed file in a sequential `for…await` loop, serializing N
-	madge subprocess spawns. `DependencyChecker.checkFilesBatch()` now runs
-	those spawns concurrently (bounded to 6 in flight) via a new turn-end
-	entry point. `DependencyChecker` keeps its circular-dep findings
-	(`lastCircular`/`circularFiles`) as shared instance state that a single-file
-	check overwrites wholesale, so naively parallelizing risked one file's
-	spawn clobbering a sibling's write depending on subprocess completion
-	order. The fix keeps every spawn's result local until all have settled,
-	then folds them into the shared state in original file order — matching
-	the sequential loop's file-by-file overwrite exactly, just without waiting
-	for each subprocess before starting the next. Behavior-preserving: same
-	per-file results, same final circular-dep state, same `dbg` logs — only
-	wall-clock time changes.
-
-- **Every runtime toggle is now settable from BOTH the CLI and
-	`~/.pi-lens/config.json`, driven by one declarative registry** (closes #166) —
-	the flag/config mapping used to live in two disconnected places (twelve
-	`pi.registerFlag` calls in `index.ts` and an if/else chain in
-	`resolvePiLensFlagWithSource`), which let coverage gaps open and persist.
-	Seven flags were registered on the CLI but fell straight through the
-	resolver, so config could never set them: `--no-lens`, `--no-lsp`,
-	`--no-tests`, `--no-delta`, `--lens-guard`, `--no-opengrep`, and
-	`--no-read-guard`. They now read `lens.enabled`, `lsp.enabled`,
-	`tests.enabled`, `delta.enabled`, `guard.enabled`, `opengrep.enabled`, and
-	`readGuard.enabled` (positive keys — a `--no-*` flag is the key set `false`).
-	The four actionable-warning toggles went the other way: they were
-	config-only and are now registered CLI flags too
-	(`--lens-actionable-warnings`, `--lens-actionable-warning-actions`,
-	`--lens-actionable-warning-autofix`, `--lens-actionable-warning-all`).
-	`clients/lens-flag-registry.ts` is the single source both surfaces read, so
-	they cannot diverge again; the wiring test derives its expected flag set from
-	it rather than restating it (the old hand-written list had already drifted,
-	missing `lens-turn-summary`).
+ turn-end circular-dependency pass previously ran one `await checkFile()`
+ per import-changed file in a sequential `for…await` loop, serializing N
+ madge subprocess spawns. `DependencyChecker.checkFilesBatch()` now runs
+ those spawns concurrently (bounded to 6 in flight) via a new turn-end
+ entry point. `DependencyChecker` keeps its circular-dep findings
+ (`lastCircular`/`circularFiles`) as shared instance state that a single-file
+ check overwrites wholesale, so naively parallelizing risked one file's
+ spawn clobbering a sibling's write depending on subprocess completion
+ order. The fix keeps every spawn's result local until all have settled,
+ then folds them into the shared state in original file order — matching
+ the sequential loop's file-by-file overwrite exactly, just without waiting
+ for each subprocess before starting the next. Behavior-preserving: same
+ per-file results, same final circular-dep state, same `dbg` logs — only
+ wall-clock time changes.
+
+- **Every runtime toggle is now settable from BOTH the CLI and `~/.pi-lens/config.json`, driven by one declarative registry (closes #166)** —
+ the flag/config mapping used to live in two disconnected places (twelve
+ `pi.registerFlag` calls in `index.ts` and an if/else chain in
+ `resolvePiLensFlagWithSource`), which let coverage gaps open and persist.
+ Seven flags were registered on the CLI but fell straight through the
+ resolver, so config could never set them: `--no-lens`, `--no-lsp`,
+ `--no-tests`, `--no-delta`, `--lens-guard`, `--no-opengrep`, and
+ `--no-read-guard`. They now read `lens.enabled`, `lsp.enabled`,
+ `tests.enabled`, `delta.enabled`, `guard.enabled`, `opengrep.enabled`, and
+ `readGuard.enabled` (positive keys — a `--no-*` flag is the key set `false`).
+ The four actionable-warning toggles went the other way: they were
+ config-only and are now registered CLI flags too
+ (`--lens-actionable-warnings`, `--lens-actionable-warning-actions`,
+ `--lens-actionable-warning-autofix`, `--lens-actionable-warning-all`).
+ `clients/lens-flag-registry.ts` is the single source both surfaces read, so
+ they cannot diverge again; the wiring test derives its expected flag set from
+ it rather than restating it (the old hand-written list had already drifted,
+ missing `lens-turn-summary`).
 
 - **`actionableWarnings.autoFix.maxFixes` is now actually read** (#166) —
-	documented in `globalconfig.md` since #792 but no loader ever parsed it, so
-	`agent_end` always used the hardcoded default of 5 no matter what the config
-	said. Same defect class as the seven flags above: a documented config key
-	with nothing wiring it to the code that consumes it. Accepts any
-	non-negative whole number; `0` keeps the warning report while applying
-	nothing.
-
-- **Flag provenance gained an `env` tier and reports the global tier more
-	accurately** (#166) — `PI_LENS_NO_CONTEXT_INJECTION` moved out of a
-	hardcoded check in `index.ts` into the registry's `env` binding, so it
-	resolves through the same chain as everything else (env → cli →
-	nested-project → project → global → default) and reports `source: "env"`.
-	The global tier now reports `source: "global"` whenever the key is present,
-	not only when it happens to differ from the built-in default. Affects debug
-	and mutation-skip log lines only, no resolved values change.
-
-- **Unknown top-level keys in `~/.pi-lens/config.json` now warn once instead of
-	being dropped silently** (#166, refs #533) — a typo like `lps` for `lsp`
-	previously did nothing with no signal. The recognized-key set is derived from
-	the flag registry (`LENS_FLAGS`) plus the non-flag sections (`ignore`,
-	`dispatch`, `actionableWarnings`, `widget`) and `$schema`, so it stays in sync
-	with the single source of truth; anything else logs one `[pi-lens] ignoring
-	invalid global config …: unknown key "…"` line and is ignored.
-
-- **The review-graph resume checkpoint (#936) now offloads its gzip to the
-	shared persist worker** (refs #958, #883) — mid-build checkpoint writes
-	previously ran a synchronous `gzipSync` of the growing graph on the event
-	loop; they now stream the stringify+gzip through the same worker the
-	authoritative snapshot uses (via the newly-shared `writeGzipStageFile` core),
-	generation-gated so a slow write can't clobber a newer checkpoint or
-	resurrect one after the build completes and retires it, and falling back to a
-	synchronous write when the worker is unavailable. Best-effort as before — a
-	lost checkpoint only costs a cold rebuild.
+ documented in `globalconfig.md` since #792 but no loader ever parsed it, so
+ `agent_end` always used the hardcoded default of 5 no matter what the config
+ said. Same defect class as the seven flags above: a documented config key
+ with nothing wiring it to the code that consumes it. Accepts any
+ non-negative whole number; `0` keeps the warning report while applying
+ nothing.
+
+- **Flag provenance gained an `env` tier and reports the global tier more accurately** (#166) — `PI_LENS_NO_CONTEXT_INJECTION` moved out of a
+ hardcoded check in `index.ts` into the registry's `env` binding, so it
+ resolves through the same chain as everything else (env → cli →
+ nested-project → project → global → default) and reports `source: "env"`.
+ The global tier now reports `source: "global"` whenever the key is present,
+ not only when it happens to differ from the built-in default. Affects debug
+ and mutation-skip log lines only, no resolved values change.
+
+- **Unknown top-level keys in `~/.pi-lens/config.json` now warn once instead of being dropped silently** (#166, refs #533) — a typo like `lps` for `lsp`
+ previously did nothing with no signal. The recognized-key set is derived from
+ the flag registry (`LENS_FLAGS`) plus the non-flag sections (`ignore`,
+ `dispatch`, `actionableWarnings`, `widget`) and `$schema`, so it stays in sync
+ with the single source of truth; anything else logs one `[pi-lens] ignoring
+ invalid global config …: unknown key "…"` line and is ignored.
+
+- **The review-graph resume checkpoint (#936) now offloads its gzip to the shared persist worker (refs #958, #883)** — mid-build checkpoint writes
+ previously ran a synchronous `gzipSync` of the growing graph on the event
+ loop; they now stream the stringify+gzip through the same worker the
+ authoritative snapshot uses (via the newly-shared `writeGzipStageFile` core),
+ generation-gated so a slow write can't clobber a newer checkpoint or
+ resurrect one after the build completes and retires it, and falling back to a
+ synchronous write when the worker is unavailable. Best-effort as before — a
+ lost checkpoint only costs a cold rebuild.
 
 - **Project snapshot body is now written gzipped by a worker thread** (refs
-	#958 item 2) — the snapshot body (40-112MB observed) is persisted as
-	`project-snapshot.json.gz`, with the `JSON.stringify` + gzip run on a worker
-	thread off the save path, mirroring the review graph's
-	`persist-worker.ts`/generation-gated-promotion pattern (gzip measured 5-10x
-	on top of the #957 compaction win; the review-graph's own measurement was
-	60MB → 1.4MB). A slow worker write for generation N is discarded rather than
-	promoted over a newer generation N+1 already on disk, and the loader still
-	reads the previous uncompressed `project-snapshot.json` for one compatibility
-	release so an upgrade never loses a snapshot. The save path deliberately does
-	NOT sync-gzip (the #950 review measured a naïve sync gzip regressing host
-	memory by +656MB); when the worker is unavailable/dies the pending body falls
-	back to a synchronous main-thread gzip write, surfaced via the logger rather
-	than silently presented as saved (#533). Read-your-writes across the async
-	promotion is preserved by an in-process authoritative "latest write" that
-	`loadProjectSnapshot` consults before disk, so the merge-write callers
-	(`saveRuntimeProjectSnapshot`, word index, reverse deps) never observe a
-	stale body in the promotion window.
+ #958 item 2) — the snapshot body (40-112MB observed) is persisted as
+ `project-snapshot.json.gz`, with the `JSON.stringify` + gzip run on a worker
+ thread off the save path, mirroring the review graph's
+ `persist-worker.ts`/generation-gated-promotion pattern (gzip measured 5-10x
+ on top of the #957 compaction win; the review-graph's own measurement was
+ 60MB → 1.4MB). A slow worker write for generation N is discarded rather than
+ promoted over a newer generation N+1 already on disk, and the loader still
+ reads the previous uncompressed `project-snapshot.json` for one compatibility
+ release so an upgrade never loses a snapshot. The save path deliberately does
+ NOT sync-gzip (the #950 review measured a naïve sync gzip regressing host
+ memory by +656MB); when the worker is unavailable/dies the pending body falls
+ back to a synchronous main-thread gzip write, surfaced via the logger rather
+ than silently presented as saved (#533). Read-your-writes across the async
+ promotion is preserved by an in-process authoritative "latest write" that
+ `loadProjectSnapshot` consults before disk, so the merge-write callers
+ (`saveRuntimeProjectSnapshot`, word index, reverse deps) never observe a
+ stale body in the promotion window.
 
 - **Session warmup refreshes the word index incrementally** (refs #958) —
-	the persisted serializer now carries per-file mtimes. Startup still performs
-	the bounded source walk, but reuses unchanged postings, re-tokenizes only
-	stale/new files, and drops deleted files; legacy indexes, refresh failures,
-	and file-set churn above 30% fall back to a full rebuild. The current derived
-	file cap and `truncated` state are re-evaluated on every refresh, and
-	`warmup_word_index` telemetry records mode/refreshed/dropped/reused counts.
+ the persisted serializer now carries per-file mtimes. Startup still performs
+ the bounded source walk, but reuses unchanged postings, re-tokenizes only
+ stale/new files, and drops deleted files; legacy indexes, refresh failures,
+ and file-set churn above 30% fall back to a full rebuild. The current derived
+ file cap and `truncated` state are re-evaluated on every refresh, and
+ `warmup_word_index` telemetry records mode/refreshed/dropped/reused counts.
 
 - **Project scans feed compact structural IR into review-graph builds** (refs
-	#939) — each fully completed scanner file publishes content-hash-bound
-	imports, reexports, function summaries, symbols, and references. A following
-	or overlapping graph build reuses only exact-hash, successful entries;
-	stale, failed, absent, and cold one-shot paths parse normally. The handoff
-	retains neither source content nor WASM trees, and cancelled scans expose
-	only files completed before cancellation.
+ #939) — each fully completed scanner file publishes content-hash-bound
+ imports, reexports, function summaries, symbols, and references. A following
+ or overlapping graph build reuses only exact-hash, successful entries;
+ stale, failed, absent, and cold one-shot paths parse normally. The handoff
+ retains neither source content nor WASM trees, and cancelled scans expose
+ only files completed before cancellation.
 
 - **Session-start performance: LSP pre-warm, snapshot meta-gate, compact cached snapshot** (refs #947) — three
-	measured startup wins: (1) the dominant-language LSP pre-warm was gated on
-	full startup mode that the first-session heuristic never allows (82 quick
-	vs 0 full starts in 31k dogfood log lines), so it now runs inside the
-	quick-mode +2s background warmup pass — once per process,
-	generation-guarded, honoring subagent light mode, warm-attach, the
-	`no-lsp` flag, and the `canWarmCaches` guard, with a `warmup_lsp_prewarm`
-	phase record; (2) session start no longer sync-parses the whole
-	`project-snapshot.json` body (110-130ms at 40MB, ~0.5s at 112MB) before
-	checking freshness — the tiny `project-snapshot.meta.json` sidecar is read
-	first and a stale seq/version skips the body parse entirely
-	(`session_start_snapshot_load` records `skippedStale: true`), with
-	missing-meta installs falling back to the legacy parse; (3) the snapshot
-	is serialized compactly (~30% smaller) and its parsed body is cached
-	in-process per (path, mtime), so `saveRuntimeProjectSnapshot` and the
-	session-start/word-index/scan-context consumers no longer re-parse a file
-	pi-lens itself wrote seconds earlier.
+ measured startup wins: (1) the dominant-language LSP pre-warm was gated on
+ full startup mode that the first-session heuristic never allows (82 quick
+ vs 0 full starts in 31k dogfood log lines), so it now runs inside the
+ quick-mode +2s background warmup pass — once per process,
+ generation-guarded, honoring subagent light mode, warm-attach, the
+ `no-lsp` flag, and the `canWarmCaches` guard, with a `warmup_lsp_prewarm`
+ phase record; (2) session start no longer sync-parses the whole
+ `project-snapshot.json` body (110-130ms at 40MB, ~0.5s at 112MB) before
+ checking freshness — the tiny `project-snapshot.meta.json` sidecar is read
+ first and a stale seq/version skips the body parse entirely
+ (`session_start_snapshot_load` records `skippedStale: true`), with
+ missing-meta installs falling back to the legacy parse; (3) the snapshot
+ is serialized compactly (~30% smaller) and its parsed body is cached
+ in-process per (path, mtime), so `saveRuntimeProjectSnapshot` and the
+ session-start/word-index/scan-context consumers no longer re-parse a file
+ pi-lens itself wrote seconds earlier.
 
 - **Warm LSP names enrich tree-sitter read expansion** (refs #158) — partial
-	read expansion keeps tree-sitter's line boundaries authoritative, but an
-	already-open document with an already-active LSP can now replace the display
-	name/kind from `documentSymbol` (including `Class.method` ancestry) within a
-	150 ms best-effort ceiling. Cold, closed, unsupported, timed-out, or failed
-	servers retain the tree-sitter identity, and `ts_range_expanded` records
-	whether enrichment succeeded.
+ read expansion keeps tree-sitter's line boundaries authoritative, but an
+ already-open document with an already-active LSP can now replace the display
+ name/kind from `documentSymbol` (including `Class.method` ancestry) within a
+ 150 ms best-effort ceiling. Cold, closed, unsupported, timed-out, or failed
+ servers retain the tree-sitter identity, and `ts_range_expanded` records
+ whether enrichment succeeded.
 
 - **Installer subprocesses are lifetime-coupled** (refs #945) — npm, pip, gem,
-	and archive extraction now use the shared safe-spawn path, await full Windows
-	process-tree termination on timeout, and synchronously clean registered
-	installer children during parent exit/signals.
+ and archive extraction now use the shared safe-spawn path, await full Windows
+ process-tree termination on timeout, and synchronously clean registered
+ installer children during parent exit/signals.
 
 - **Managed tool installs are cross-process serialized** (refs #945) — a
-	dependency-free atomic lock protects the shared tools tree, verifies owners
-	before stale recovery, bounds lock waits with an honest error, and rechecks
-	discovery after acquisition to avoid duplicate package-manager runs.
+ dependency-free atomic lock protects the shared tools tree, verifies owners
+ before stale recovery, bounds lock waits with an honest error, and rechecks
+ discovery after acquisition to avoid duplicate package-manager runs.
 
 - **Ordinary tests never install managed tools** (refs #945) — Vitest sets
-	`PI_LENS_DISABLE_TOOL_INSTALL=1`, its prewarm step creates a local synthetic
-	oxlint probe-cache entry without networking, and one-shot analysis explicitly
-	awaits probe-cache persistence before exit.
+ `PI_LENS_DISABLE_TOOL_INSTALL=1`, its prewarm step creates a local synthetic
+ oxlint probe-cache entry without networking, and one-shot analysis explicitly
+ awaits probe-cache persistence before exit.
 
 - **Installer orphan/locking regressions are process-tested** (refs #945) —
-	fake package-manager coverage verifies Windows timeout tree-kill, exactly one
-	install across concurrent processes, explicit install-disable refusal, and
-	Vitest's default no-install environment.
+ fake package-manager coverage verifies Windows timeout tree-kill, exactly one
+ install across concurrent processes, explicit install-disable refusal, and
+ Vitest's default no-install environment.
 
-- **Downgrade TypeScript `unsafe-regex` to advisory and suppress escaped-before-
-  assignment false positives** (refs #932) — the coarse dynamic `RegExp`
+- **Downgrade TypeScript `unsafe-regex` to advisory and suppress escaped-before- assignment false positives (refs #932)** — the coarse dynamic `RegExp`
   heuristic no longer blocks edits and recognizes escape/replace calls in a
   same-file identifier initializer; structural ReDoS detection remains with
   the `redos-nested-quantifier` ast-grep rule.
 
-- **Review-graph persistence no longer serializes or compresses on the event
-	loop** (refs #939) — debounced snapshots are materialized in one lazy,
-	unref'd worker and streamed through gzip into the new canonical
-	`review-graph.json.gz` cache. The main thread promotes only the current
-	generation's atomic staged file, so the synchronous CLI/exit flush can
-	supersede an in-flight worker without a stale overwrite. Loads retain one
-	release of fallback support for legacy uncompressed `review-graph.json`
-	snapshots; worker failures are logged and degrade to a synchronous persist.
-	Persist telemetry now records element count, raw/gzip bytes, serialization
-	and write time, and whether the work was offloaded.
+- **Review-graph persistence no longer serializes or compresses on the event loop (refs #939)** — debounced snapshots are materialized in one lazy,
+ unref'd worker and streamed through gzip into the new canonical
+ `review-graph.json.gz` cache. The main thread promotes only the current
+ generation's atomic staged file, so the synchronous CLI/exit flush can
+ supersede an in-flight worker without a stale overwrite. Loads retain one
+ release of fallback support for legacy uncompressed `review-graph.json`
+ snapshots; worker failures are logged and degrade to a synchronous persist.
+ Persist telemetry now records element count, raw/gzip bytes, serialization
+ and write time, and whether the work was offloaded.
 
 - **Raise and make the review-graph persist ceiling useful** (refs #936) — the
-	default `GRAPH_PERSIST_MAX_ELEMENTS` cap is now 500,000 (still overrideable
-	through `PI_LENS_GRAPH_PERSIST_MAX_ELEMENTS`), matching measured startup
-	load/reindex costs and allowing the ~208,000-element #919 repository to
-	persist completely. Above the cap, persistence retains whole-file node groups
-	in existing reverse-dependency-centrality order plus induced edges that fit,
-	instead of dropping the snapshot. Exact total-versus-persisted node/edge
-	counts are stored and surfaced; read-only queries may use the partial graph,
-	while incremental builds reject it as a complete base.
+ default `GRAPH_PERSIST_MAX_ELEMENTS` cap is now 500,000 (still overrideable
+ through `PI_LENS_GRAPH_PERSIST_MAX_ELEMENTS`), matching measured startup
+ load/reindex costs and allowing the ~208,000-element #919 repository to
+ persist completely. Above the cap, persistence retains whole-file node groups
+ in existing reverse-dependency-centrality order plus induced edges that fit,
+ instead of dropping the snapshot. Exact total-versus-persisted node/edge
+ counts are stored and surfaced; read-only queries may use the partial graph,
+ while incremental builds reject it as a complete base.
 
 - **Logger hot paths now coalesce queued lines and rotate during long sessions** (refs #935) — contiguous NDJSON entries drain through one append up to each truncate boundary while retaining peek-then-remove exit safety and one-write cross-process atomicity. `sessionstart.log` now uses one shared asynchronous writer for ordinary diagnostics (with the crash-adjacent LSP launch write intentionally synchronous), and latency/cascade/tree-sitter/bus-event logs enforce the existing 10 MB cap in process.
 
-- **Incremental review-graph updates avoid redundant whole-graph copies and
-	index rebuilds** (refs #939) — file re-extraction now rebuilds derived indexes
-	once, immutable edges are array-copied without cloning every edge object, the
-	updated graph itself becomes the workspace snapshot, and debounced persistence
-	defers its O(graph) array materialization until the quiet-window flush.
+- **Incremental review-graph updates avoid redundant whole-graph copies and index rebuilds (refs #939)** — file re-extraction now rebuilds derived indexes
+ once, immutable edges are array-copied without cloning every edge object, the
+ updated graph itself becomes the workspace snapshot, and debounced persistence
+ defers its O(graph) array materialization until the quiet-window flush.
 
 - **Reverse-dependency indexes update at import-edge granularity** (refs #939)
-	instead of rebuilding from every graph edge after a one-file edit. Body-only
-	edits reuse the cached index without rewriting the project snapshot; import
-	changes patch only the touched `imports` and `importedBy` buckets.
+ instead of rebuilding from every graph edge after a one-file edit. Body-only
+ edits reuse the cached index without rewriting the project snapshot; import
+ changes patch only the touched `imports` and `importedBy` buckets.
 
 - **Review-graph file-cap degradation is now explicit and count-honest** (refs
-	#921) — `project_report` says a capped project has “more than N files” instead
-	of presenting the cap+1 early-exit sentinel as an exact count. `module_report`
-	now marks graph-backed `usedBy`, blast-radius provenance, and
-	`semantic.source` as `unavailable:file-cap` and emits an actionable warning
-	with the cap plus both `.pi-lens.json#maxProjectFiles` and
-	`PI_LENS_REVIEW_GRAPH_MAX_FILES` controls, keeping disabled data distinct from
-	a genuinely empty/cold graph.
+ #921) — `project_report` says a capped project has “more than N files” instead
+ of presenting the cap+1 early-exit sentinel as an exact count. `module_report`
+ now marks graph-backed `usedBy`, blast-radius provenance, and
+ `semantic.source` as `unavailable:file-cap` and emits an actionable warning
+ with the cap plus both `.pi-lens.json#maxProjectFiles` and
+ `PI_LENS_REVIEW_GRAPH_MAX_FILES` controls, keeping disabled data distinct from
+ a genuinely empty/cold graph.
 
 - **Project scans release every scan-local fact after each file** (refs #886,
-	#939) instead of retaining source content, imports, summaries, and other
-	derived per-file facts until the scan ends. The live dispatch store remains
-	untouched; only the scanner-owned store is cleared.
+ #939) instead of retaining source content, imports, summaries, and other
+ derived per-file facts until the scan ends. The live dispatch store remains
+ untouched; only the scanner-owned store is cleared.
 
 - Repair eight non-compiling Java, C++, CSS and PHP tree-sitter rules (refs #884).
 
 - Repair four non-compiling Go, Rust, and Kotlin tree-sitter rules (refs #884).
 
 - **Project diagnostics now use one file-major scan pass** (refs #896) —
-	tree-sitter rules, fact rules, and bundled ast-grep share each eligible
-	file's content read while retaining their individual extension/size gates,
-	diagnostic ordering, cancellation behavior, and latency telemetry. Full
-	review-graph builds likewise hash the bytes already read for extraction
-	instead of rereading every file after the graph is built.
+ tree-sitter rules, fact rules, and bundled ast-grep share each eligible
+ file's content read while retaining their individual extension/size gates,
+ diagnostic ordering, cancellation behavior, and latency telemetry. Full
+ review-graph builds likewise hash the bytes already read for extraction
+ instead of rereading every file after the graph is built.
 
 - **A project scan runs its rule set in one tree walk, not one walk per rule**
-	(refs #675) — `runQueriesOnFile` compiles a language's rules into a single
-	multi-pattern query and maps matches back to the owning rule, keeping per-rule
-	metavars, predicates, post-filters, caps and ordering. Measured at 3.3× on
-	identical matches; the scan's tree-sitter phase went **14.4s → 3.6s** and a
-	full `mode=full` scan of pi-lens **24.4s → 12.2s**.
+ (refs #675) — `runQueriesOnFile` compiles a language's rules into a single
+ multi-pattern query and maps matches back to the owning rule, keeping per-rule
+ metavars, predicates, post-filters, caps and ordering. Measured at 3.3× on
+ identical matches; the scan's tree-sitter phase went **14.4s → 3.6s** and a
+ full `mode=full` scan of pi-lens **24.4s → 12.2s**.
 
 - **Project scans parse each file once** (refs #675) — the tree-sitter rules and
-	the fact rules both tree-sitter-parse the same files, and running them as two
-	whole-project sweeps meant the second one re-parsed every file the first had
-	already parsed and evicted (357 of 357 first touches missed on capacity in a
-	500-file `mode=full` scan). They now share one file-major pass: **722 parses →
-	367, 892ms → 437ms of parse time, zero capacity misses**, same diagnostics in
-	the same order. The 50-entry cache is unchanged and was never the problem —
-	within a phase it already ran at a 96.8% hit rate, any capacity short of the
-	full working set saves nothing, and one big enough to hold it would cost
-	150-300MB of resident WASM trees.
+ the fact rules both tree-sitter-parse the same files, and running them as two
+ whole-project sweeps meant the second one re-parsed every file the first had
+ already parsed and evicted (357 of 357 first touches missed on capacity in a
+ 500-file `mode=full` scan). They now share one file-major pass: **722 parses →
+ 367, 892ms → 437ms of parse time, zero capacity misses**, same diagnostics in
+ the same order. The 50-entry cache is unchanged and was never the problem —
+ within a phase it already ran at a 96.8% hit rate, any capacity short of the
+ full working set saves nothing, and one big enough to hold it would cost
+ 150-300MB of resident WASM trees.
 
 - **Tree-sitter cache pressure is measurable** (refs #675): every production
-	consumer, including partial-read expansion, uses the shared process-wide
-	client, and scope-isolated cache counters plus parser timing are emitted for
-	project scans and full review-graph builds.
+ consumer, including partial-read expansion, uses the shared process-wide
+ client, and scope-isolated cache counters plus parser timing are emitted for
+ project scans and full review-graph builds.
 
 - **Dead incremental-parse cache API removed.** `TreeCache.incrementalUpdate`,
-	`calculateEdit`, and `invalidate` had no callers; the header's "10-100×
-	speedup on edits" was advertising a path nothing ever took.
+ `calculateEdit`, and `invalidate` had no callers; the header's "10-100×
+ speedup on edits" was advertising a path nothing ever took.
 
 - **Faster LSP teardown and tool probes** (refs #448) — `killProcessTree`
-	resolves on the child's exit event instead of sleeping the full 1.5s
-	SIGTERM→SIGKILL escalation window (saves ~1.5s per graceful client
-	shutdown); tool availability checks skip `--version` spawns for binaries
-	that aren't on disk and no longer re-verify a probe-cache-validated managed
-	install on every analyze.
+ resolves on the child's exit event instead of sleeping the full 1.5s
+ SIGTERM→SIGKILL escalation window (saves ~1.5s per graceful client
+ shutdown); tool availability checks skip `--version` spawns for binaries
+ that aren't on disk and no longer re-verify a probe-cache-validated managed
+ install on every analyze.
 
 ### Fixed
 
 - **Read-before-edit guard now survives a session resume (#1041)** — the
-	guard's read-set was in-memory only, so a `pi --session <id>` resume (which
-	resets the runtime to a fresh empty guard) falsely `zero_read`-blocked the
-	first edit of any file read in the prior session. The read-set now rides the
-	same #190 `PersistedSessionState` save/load path that widget diagnostics use:
-	`ReadGuard.exportState()`/`importState()` persist and rehydrate `reads`,
-	reconciling each read against current disk (line-hash verified) so a resume
-	drops any read whose file changed or vanished — a rehydrated read never masks
-	a real staleness. Forked sessions adopt the parent's read-set via the same
-	in-memory hand-off as widget state. Backward-compatible: the field is optional
-	and pre-#1041 persisted sessions load cleanly as "no prior reads".
+ guard's read-set was in-memory only, so a `pi --session <id>` resume (which
+ resets the runtime to a fresh empty guard) falsely `zero_read`-blocked the
+ first edit of any file read in the prior session. The read-set now rides the
+ same #190 `PersistedSessionState` save/load path that widget diagnostics use:
+ `ReadGuard.exportState()`/`importState()` persist and rehydrate `reads`,
+ reconciling each read against current disk (line-hash verified) so a resume
+ drops any read whose file changed or vanished — a rehydrated read never masks
+ a real staleness. Forked sessions adopt the parent's read-set via the same
+ in-memory hand-off as widget state. Backward-compatible: the field is optional
+ and pre-#1041 persisted sessions load cleanly as "no prior reads".
 
 - **`turn_summary_emit` quiet-window task no longer fails on a stale pi ctx (the #483 quiet window's most frequent live-dogfood error — 55×)** —
-	the `agent_settled` quiet-window task `turn_summary_emit` reads the
-	`lens-turn-summary` flag through `pi.getFlag()` (via `getLensFlag`). The task
-	holder's `pi` is refreshed on every activation, but the quiet window is fired
-	fire-and-forget from `agent_settled`, so an interim session
-	replacement/reload (`ctx.newSession/fork/switchSession/reload` — common in the
-	in-process subagent flow #473) invalidates that captured `pi`; the very next
-	`pi.getFlag()` then throws the SDK's stale-ctx guard. That throw sat OUTSIDE
-	the existing `sendMessage` try/catch, so it escaped the task and the scheduler
-	logged `quiet_window: task "turn_summary_emit" failed: … stale after session
-	replacement or reload` — 55 times across two weeks of dogfooding, the single
-	most frequent error in `~/.pi-lens/sessionstart.log`, and it fired even with
-	the feature OFF (the flag READ throws before the flag value is known). Fix:
-	the task now recognises the stale-ctx throw (new `isStaleExtensionCtxError`
-	message matcher) at both pi touch points (flag read + emit) and degrades to a
-	logged no-op — the session that run's summary belonged to is gone, so there is
-	nothing to emit into — while a genuine error still propagates to the scheduler
-	(recorded `ok:false`). User impact was minimal (a lost summary for the exact
-	settle that raced a session swap, plus log noise), not silent feature
-	degradation: in steady state the task runs `ok:true`. Separately, the
-	quiet-window runner now logs the failing task's **stack** (not just `${err}`'s
-	message) so the next failure is diagnosable from the log alone; it remains
-	strictly non-fatal (per-task try/catch, `runQuietWindow` never rethrows, and
-	`agent_settled` invokes it fire-and-forget — a failing task can never break the
-	turn). Regression test drives the registered task against a `pi` whose
-	`getFlag` throws the stale-ctx error and asserts a no-op (no throw, no emit);
-	it fails pre-fix.
+ the `agent_settled` quiet-window task `turn_summary_emit` reads the
+ `lens-turn-summary` flag through `pi.getFlag()` (via `getLensFlag`). The task
+ holder's `pi` is refreshed on every activation, but the quiet window is fired
+ fire-and-forget from `agent_settled`, so an interim session
+ replacement/reload (`ctx.newSession/fork/switchSession/reload` — common in the
+ in-process subagent flow #473) invalidates that captured `pi`; the very next
+ `pi.getFlag()` then throws the SDK's stale-ctx guard. That throw sat OUTSIDE
+ the existing `sendMessage` try/catch, so it escaped the task and the scheduler
+ logged `quiet_window: task "turn_summary_emit" failed: … stale after session
+ replacement or reload` — 55 times across two weeks of dogfooding, the single
+ most frequent error in `~/.pi-lens/sessionstart.log`, and it fired even with
+ the feature OFF (the flag READ throws before the flag value is known). Fix:
+ the task now recognises the stale-ctx throw (new `isStaleExtensionCtxError`
+ message matcher) at both pi touch points (flag read + emit) and degrades to a
+ logged no-op — the session that run's summary belonged to is gone, so there is
+ nothing to emit into — while a genuine error still propagates to the scheduler
+ (recorded `ok:false`). User impact was minimal (a lost summary for the exact
+ settle that raced a session swap, plus log noise), not silent feature
+ degradation: in steady state the task runs `ok:true`. Separately, the
+ quiet-window runner now logs the failing task's **stack** (not just `${err}`'s
+ message) so the next failure is diagnosable from the log alone; it remains
+ strictly non-fatal (per-task try/catch, `runQuietWindow` never rethrows, and
+ `agent_settled` invokes it fire-and-forget — a failing task can never break the
+ turn). Regression test drives the registered task against a `pi` whose
+ `getFlag` throws the stale-ctx error and asserts a no-op (no throw, no emit);
+ it fails pre-fix.
 
 - **Word index no longer serves stale postings after a case/separator-divergent edit (refs #1025, closes #1025 item #2)** —
-	the word index's `docLengths`/`forward`/`fileMtimes` maps are keyed on file
-	paths, but the full/incremental BUILD keyed on the on-disk casing the
-	`readdirSync` walk reports while the per-edit UPDATE seams
-	(`clients/dispatch/integration.ts`, `clients/mcp/analyze.ts`) key via
-	`path.resolve()` on the raw tool-input path. When those forms differed only by
-	separator (`\` vs `/`, always) or case (on a case-insensitive FS), the plain-`Map`
-	keying made `forward.has(doc.path)` MISS, so the stale build-form entry was never
-	removed — a duplicate doc entry with stale postings served until a full rebuild,
-	silently degrading `symbol_search` relevance (the path-key divergence class,
-	#1020/#210). Fix: a new typed **`PathKeyedMap<V>`** primitive
-	(`clients/path-keyed-map.ts`) folds every key through a caller-supplied
-	normalizer INTERNALLY, so keying a raw path is structurally impossible; the word
-	index now routes all three path maps through it using the shared, exported
-	`wordIndexKey` (= `normalizeEphemeralMapKey` — cheap slash-fold + win32-lowercase,
-	NO `realpathSync`, so the hot BM25 path adds no filesystem I/O), and the
-	token-keyed `postings` cleanup compares `WordHit.file` through the same
-	normalizer, and the incremental-refresh set-difference
-	(`refreshWordIndexIncrementally`) now computes its `current`/`oldSet` keys in
-	that same normalized space (previously raw-keyed — a file whose stored display
-	path became the edit form would have been double-counted as churn and
-	dropped-then-re-added, defeating the incremental path and opening a
-	drop-before-readd regression window). `PathKeyedMap` stores each value's
-	ORIGINAL display path, so `symbol_search`/rendering surfaces still see the
-	on-disk form, not the folded key. Build-form, edit-form, and refresh keys now
-	converge on ONE entry regardless of casing/separator. The runtime-coordinator suspect maps (#1025 item #4) are left
-	for a follow-up (unproven trigger, and their correct normalizer is the
-	realpath-based `normalizeMapKey` matching the file's own `_fileSeq` convention —
-	a larger, higher-risk change across the concurrent-session drain logic).
+ the word index's `docLengths`/`forward`/`fileMtimes` maps are keyed on file
+ paths, but the full/incremental BUILD keyed on the on-disk casing the
+ `readdirSync` walk reports while the per-edit UPDATE seams
+ (`clients/dispatch/integration.ts`, `clients/mcp/analyze.ts`) key via
+ `path.resolve()` on the raw tool-input path. When those forms differed only by
+ separator (`\` vs `/`, always) or case (on a case-insensitive FS), the plain-`Map`
+ keying made `forward.has(doc.path)` MISS, so the stale build-form entry was never
+ removed — a duplicate doc entry with stale postings served until a full rebuild,
+ silently degrading `symbol_search` relevance (the path-key divergence class,
+ #1020/#210). Fix: a new typed **`PathKeyedMap<V>`** primitive
+ (`clients/path-keyed-map.ts`) folds every key through a caller-supplied
+ normalizer INTERNALLY, so keying a raw path is structurally impossible; the word
+ index now routes all three path maps through it using the shared, exported
+ `wordIndexKey` (= `normalizeEphemeralMapKey` — cheap slash-fold + win32-lowercase,
+ NO `realpathSync`, so the hot BM25 path adds no filesystem I/O), and the
+ token-keyed `postings` cleanup compares `WordHit.file` through the same
+ normalizer, and the incremental-refresh set-difference
+ (`refreshWordIndexIncrementally`) now computes its `current`/`oldSet` keys in
+ that same normalized space (previously raw-keyed — a file whose stored display
+ path became the edit form would have been double-counted as churn and
+ dropped-then-re-added, defeating the incremental path and opening a
+ drop-before-readd regression window). `PathKeyedMap` stores each value's
+ ORIGINAL display path, so `symbol_search`/rendering surfaces still see the
+ on-disk form, not the folded key. Build-form, edit-form, and refresh keys now
+ converge on ONE entry regardless of casing/separator. The runtime-coordinator suspect maps (#1025 item #4) are left
+ for a follow-up (unproven trigger, and their correct normalizer is the
+ realpath-based `normalizeMapKey` matching the file's own `_fileSeq` convention —
+ a larger, higher-risk change across the concurrent-session drain logic).
 
 - **Cascade honesty: degraded/uncomputed impact no longer renders as clean (refs #1023, closes #1023)** —
-	the cascade impact subsystem previously emitted an all-clear that was
-	indistinguishable from "genuinely nothing impacted" whenever it could NOT
-	compute impact: the review graph was size-skipped (`too_many_files` over
-	`PI_LENS_REVIEW_GRAPH_MAX_FILES`) or root-skipped (`unsafe_root`), the changed
-	file had no graph node, or the deferred compute threw — a silent under-report
-	exactly where downstream breakage is most likely (large/over-cap monorepos)
-	(#533). Impact results now carry a first-class `indeterminate` marker
-	(`clients/review-graph/types.ts`) set ONLY on a degraded/cold/errored/
-	missing-node compute; the already-known degraded state is threaded from
-	`getLastGraphBuildInfo().mode`/`skipReason` at the compute call site (no
-	re-derivation), a `missing_node` marker comes straight from
-	`computeImpactCascade`, and a thrown compute is tagged in the pipeline catch. A
-	new `indeterminate` `CascadeSkipReason` flows to the EXISTING turn-end seam
-	(`clients/runtime-turn.ts`), which renders a short honest note in the ADVISORY
-	tier ("Cascade could not compute downstream impact … a clean cascade result
-	does not cover them") instead of silence. The advisory tier (not the blocker
-	tier) is deliberate: an over-cap monorepo skips the graph on every edit, so a
-	blocker would fire hard and never clear turn state every turn (over-escalation,
-	the mirror of the silent-all-clear bug). A HEALTHY graph with a genuinely empty
-	dependent set stays silent (keyed strictly off the degraded mode/marker, never
-	off `neighbors.length === 0` alone — no crying wolf). Companion: the Tier-3 quiet-window reconcile
-	(`clients/lsp/cascade-tier.ts`) now RE-INJECTS a `resolved-found` cold-neighbor
-	error through the same neighbor→turn-end formatting via an `onResolvedFound`
-	callback wired in `index.ts`, instead of leaving it logs-only. The
-	neighbor-touch/freshness pipeline (neighborTouchCache, recentlyCleanNeighborCache,
-	the 40-neighbor budget, tier-aware touch model, deferred cascade flow) is
-	untouched.
+ the cascade impact subsystem previously emitted an all-clear that was
+ indistinguishable from "genuinely nothing impacted" whenever it could NOT
+ compute impact: the review graph was size-skipped (`too_many_files` over
+ `PI_LENS_REVIEW_GRAPH_MAX_FILES`) or root-skipped (`unsafe_root`), the changed
+ file had no graph node, or the deferred compute threw — a silent under-report
+ exactly where downstream breakage is most likely (large/over-cap monorepos)
+ (#533). Impact results now carry a first-class `indeterminate` marker
+ (`clients/review-graph/types.ts`) set ONLY on a degraded/cold/errored/
+ missing-node compute; the already-known degraded state is threaded from
+ `getLastGraphBuildInfo().mode`/`skipReason` at the compute call site (no
+ re-derivation), a `missing_node` marker comes straight from
+ `computeImpactCascade`, and a thrown compute is tagged in the pipeline catch. A
+ new `indeterminate` `CascadeSkipReason` flows to the EXISTING turn-end seam
+ (`clients/runtime-turn.ts`), which renders a short honest note in the ADVISORY
+ tier ("Cascade could not compute downstream impact … a clean cascade result
+ does not cover them") instead of silence. The advisory tier (not the blocker
+ tier) is deliberate: an over-cap monorepo skips the graph on every edit, so a
+ blocker would fire hard and never clear turn state every turn (over-escalation,
+ the mirror of the silent-all-clear bug). A HEALTHY graph with a genuinely empty
+ dependent set stays silent (keyed strictly off the degraded mode/marker, never
+ off `neighbors.length === 0` alone — no crying wolf). Companion: the Tier-3 quiet-window reconcile
+ (`clients/lsp/cascade-tier.ts`) now RE-INJECTS a `resolved-found` cold-neighbor
+ error through the same neighbor→turn-end formatting via an `onResolvedFound`
+ callback wired in `index.ts`, instead of leaving it logs-only. The
+ neighbor-touch/freshness pipeline (neighborTouchCache, recentlyCleanNeighborCache,
+ the 40-neighbor budget, tier-aware touch model, deferred cascade flow) is
+ untouched.
 
 - **Disposition marks under a nested monorepo language root are no longer silently dropped (refs #1030, closes #1030; pairs with #1024)** —
-	a `false-positive`/`flagged`/`defer` mark recorded via `lens_diagnostic_mark`
-	was invisible to the per-edit dispatch filter for every file living under a
-	nested language-root marker (`packages/app/tsconfig.json`, a nested
-	`package.json`/`pyproject.toml`/`go.mod`/etc.) in a monorepo. The mark tool
-	writes dispositions keyed on the **project root** (`runtime.projectRoot`), but
-	`dispatcher.ts`'s `applyDispositions` read keyed on `ctx.cwd`, which
-	`createDispatchContext` resolves to the nearest **language root** via
-	`resolveLanguageRootForFile` (a dispatch-internal tool/config-resolution
-	detail). Because both the anchor AND the persisted store location
-	(`getProjectDataDir`, keyed on `cwd`) derive from that base, write and read
-	computed different anchors AND opened entirely different
-	`diagnostic-dispositions.json` files — a total, deterministic failure (not
-	probabilistic) for every file under a nested marker. The tool returned success
-	while dispatch never saw the mark (a #533 honesty failure); `suppress` survived
-	only via its independent inline `pi-lens-ignore` comment. Fixed by reading the
-	disposition layer from the project root (`ctx.projectRoot`, already computed in
-	`createDispatchContext`), matching the write side — anchor base and store base
-	now agree on both sides. `resolveLanguageRootForFile` is untouched and still
-	drives actual dispatch/tool-root resolution. Orthogonal to #1024 (which fixes
-	the path *form* of the anchor); the two compose for a monorepo-stable anchor.
-	No new dependencies.
+ a `false-positive`/`flagged`/`defer` mark recorded via `lens_diagnostic_mark`
+ was invisible to the per-edit dispatch filter for every file living under a
+ nested language-root marker (`packages/app/tsconfig.json`, a nested
+ `package.json`/`pyproject.toml`/`go.mod`/etc.) in a monorepo. The mark tool
+ writes dispositions keyed on the **project root** (`runtime.projectRoot`), but
+ `dispatcher.ts`'s `applyDispositions` read keyed on `ctx.cwd`, which
+ `createDispatchContext` resolves to the nearest **language root** via
+ `resolveLanguageRootForFile` (a dispatch-internal tool/config-resolution
+ detail). Because both the anchor AND the persisted store location
+ (`getProjectDataDir`, keyed on `cwd`) derive from that base, write and read
+ computed different anchors AND opened entirely different
+ `diagnostic-dispositions.json` files — a total, deterministic failure (not
+ probabilistic) for every file under a nested marker. The tool returned success
+ while dispatch never saw the mark (a #533 honesty failure); `suppress` survived
+ only via its independent inline `pi-lens-ignore` comment. Fixed by reading the
+ disposition layer from the project root (`ctx.projectRoot`, already computed in
+ `createDispatchContext`), matching the write side — anchor base and store base
+ now agree on both sides. `resolveLanguageRootForFile` is untouched and still
+ drives actual dispatch/tool-root resolution. Orthogonal to #1024 (which fixes
+ the path *form* of the anchor); the two compose for a monorepo-stable anchor.
+ No new dependencies.
 
 - **Disposition anchor path-form stability (refs #1024, closes #1024)** — the
-	`dd:`/`ddw:` disposition anchors (clients/diagnostic-dispositions.ts) are now
-	derived from a single canonical path form, closing a #533-adjacent
-	dropped-signal bug (sibling of #210/#1020). `relativeFile` — the chokepoint
-	both `computeStrictAnchor` and `computeWeakAnchor` route through — computed
-	`path.relative` on whichever raw path form the caller happened to hold: the
-	mark tool (tools/lens-diagnostic-mark.ts) passes a RAW `cwd` /
-	`path.resolve(cwd, arg)`, while the dispatch read side
-	(clients/dispatch/dispatcher.ts `createDispatchContext`) passes
-	`normalizeMapKey`-canonicalized (realpath'd) cwd/filePath. When the two forms
-	diverged (Windows drive/segment case, symlink/realpath), the agent's own
-	`false-positive`/`flagged` mark anchored under one id and the later
-	`applyDispositions` lookup under another, so the mark was invisible and the
-	"resolved" diagnostic kept re-firing / re-blocking every turn. Fix routes
-	BOTH `cwd` and `filePath` through `normalizeMapKey` inside `relativeFile`
-	(the same normalizer the read side already relies on — the #210 "every guard
-	map keys through `normalizeFilePath`" invariant), so write and read derive
-	identical anchors regardless of the form the caller passed. Anchor semantics
-	are unchanged: strict (`dd:`, line-hash) vs weak (`ddw:`) split, the prefixes,
-	and the `..`-escape fallback all behave exactly as before — only the path
-	component is now form-stable. Existing on-disk marks written under the old raw
-	form re-anchor to the canonical id; a stale orphan is re-derivable and simply
-	reappears once for the agent to re-mark (identical to today's pre-fix
-	behavior), so no read-time legacy fallback is needed.
+ `dd:`/`ddw:` disposition anchors (clients/diagnostic-dispositions.ts) are now
+ derived from a single canonical path form, closing a #533-adjacent
+ dropped-signal bug (sibling of #210/#1020). `relativeFile` — the chokepoint
+ both `computeStrictAnchor` and `computeWeakAnchor` route through — computed
+ `path.relative` on whichever raw path form the caller happened to hold: the
+ mark tool (tools/lens-diagnostic-mark.ts) passes a RAW `cwd` /
+ `path.resolve(cwd, arg)`, while the dispatch read side
+ (clients/dispatch/dispatcher.ts `createDispatchContext`) passes
+ `normalizeMapKey`-canonicalized (realpath'd) cwd/filePath. When the two forms
+ diverged (Windows drive/segment case, symlink/realpath), the agent's own
+ `false-positive`/`flagged` mark anchored under one id and the later
+ `applyDispositions` lookup under another, so the mark was invisible and the
+ "resolved" diagnostic kept re-firing / re-blocking every turn. Fix routes
+ BOTH `cwd` and `filePath` through `normalizeMapKey` inside `relativeFile`
+ (the same normalizer the read side already relies on — the #210 "every guard
+ map keys through `normalizeFilePath`" invariant), so write and read derive
+ identical anchors regardless of the form the caller passed. Anchor semantics
+ are unchanged: strict (`dd:`, line-hash) vs weak (`ddw:`) split, the prefixes,
+ and the `..`-escape fallback all behave exactly as before — only the path
+ component is now form-stable. Existing on-disk marks written under the old raw
+ form re-anchor to the canonical id; a stale orphan is re-derivable and simply
+ reappears once for the agent to re-mark (identical to today's pre-fix
+ behavior), so no read-time legacy fallback is needed.
 
 - **`lens_diagnostics mode=all` no longer replays a resolved blocker (refs #1020, closes #1020)** —
-	the widget-state `files` map was keyed by the raw, non-normalized path string,
-	so the SAME file could land under two different key forms in one session:
-	the forward-slash form (`C:/…/x.ts`) the LSP client + cascade fold produce via
-	`normalizeFilePath`, and the backslash form (`C:\…\x.ts`) that `mode=full`'s
-	clean reconcile (`result.filePath`) and `path.resolve`/event inputs produce on
-	Windows. A stale blocking entry and the fresh clean entry then coexisted as two
-	separate map entries. `mode=full` rendered clean because its merge re-keys every
-	summary through `path.resolve`, but `mode=all`'s `formatAllMode` reads
-	`getFileDiagnosticSummaries()` verbatim with no dedup, so it saw both and
-	rendered the stale entry's `blocking:1` as a 🔴 — a resolved state that replayed
-	as still-broken on every `mode=all` (worst on Windows + resumed sessions), and a
-	#533 honesty failure since the tool prompt tells agents to use `mode=all` to
-	verify no blockers remain. Fixed at source: every write/read seam on the `files`
-	map (and the `diagnosticsWriteGuard`) now folds its key through one normalizer,
-	`normalizeEphemeralMapKey` (slash-fold + win32-lowercase, no filesystem I/O —
-	chosen over the `realpathSync`-backed `normalizeMapKey` because this is a hot
-	write path), and `importWidgetState` folds persisted keys on rehydrate so a
-	`/`-key snapshot and a fresh `\`-key write collapse across a resumed session.
-	The human-readable display path on each record is preserved verbatim (rendering
-	and path-relative math unchanged). No new dependencies.
+ the widget-state `files` map was keyed by the raw, non-normalized path string,
+ so the SAME file could land under two different key forms in one session:
+ the forward-slash form (`C:/…/x.ts`) the LSP client + cascade fold produce via
+ `normalizeFilePath`, and the backslash form (`C:\…\x.ts`) that `mode=full`'s
+ clean reconcile (`result.filePath`) and `path.resolve`/event inputs produce on
+ Windows. A stale blocking entry and the fresh clean entry then coexisted as two
+ separate map entries. `mode=full` rendered clean because its merge re-keys every
+ summary through `path.resolve`, but `mode=all`'s `formatAllMode` reads
+ `getFileDiagnosticSummaries()` verbatim with no dedup, so it saw both and
+ rendered the stale entry's `blocking:1` as a 🔴 — a resolved state that replayed
+ as still-broken on every `mode=all` (worst on Windows + resumed sessions), and a
+ #533 honesty failure since the tool prompt tells agents to use `mode=all` to
+ verify no blockers remain. Fixed at source: every write/read seam on the `files`
+ map (and the `diagnosticsWriteGuard`) now folds its key through one normalizer,
+ `normalizeEphemeralMapKey` (slash-fold + win32-lowercase, no filesystem I/O —
+ chosen over the `realpathSync`-backed `normalizeMapKey` because this is a hot
+ write path), and `importWidgetState` folds persisted keys on rehydrate so a
+ `/`-key snapshot and a fresh `\`-key write collapse across a resumed session.
+ The human-readable display path on each record is preserved verbatim (rendering
+ and path-relative math unchanged). No new dependencies.
 
 - **Cache-friendly ephemeral context injection (refs #1016, closes #1016)** — the
-	`context` event handler in `index.ts` now splices pi-lens's ephemeral turn-end
-	findings in **immediately before the final message** instead of prepending them
-	at message index 0. Prepending flipped `messages[0]` every turn, which
-	invalidated the entire prompt-cache prefix on every prefix-caching provider
-	(Anthropic, Bedrock, and OpenAI — all key the cache on the exact token prefix).
-	Inserting before the last message keeps `messages[0]` (the real first user turn)
-	byte-stable so the prior conversation stays cached, while still keeping the real
-	user prompt as the trailing message — preserving the trailing-`user` cache
-	breakpoint and the historical `fe0ed5da` guarantee that input is never empty (the
-	existing transcript is always preserved, never dropped; an empty transcript falls
-	back to the prior prepend-only behavior). Because the `context` event fires
-	before **every** provider call (not just at turn boundaries), a trailing-role
-	guard (`isPlainUserPrompt`) only splices before the last message when it is a
-	plain user prompt; when the tail is a mid-loop `tool_result` (or assistant/tool
-	message) the findings are **appended** after the whole transcript instead — a
-	pure append that both preserves the `tool_use`↔`tool_result` adjacency all three
-	providers require (splicing between them is an HTTP 400) and keeps the entire
-	prior transcript as an untouched cache prefix. Changes shipped `dist` behavior
-	(the handler lives in the bundled dist path).
-
-- **Fixed: `ts-ssrf` no longer flags fixed/const endpoint URLs built with
-	`new URL(...)` as SSRF sinks, while still catching tainted URLs** (closes
-	#1000, refs #533, #963) — a project-wide pi-free scan flagged fixed outbound
-	OAuth/profile endpoints as SSRF: `fetch(authUrl.toString())` where
-	`authUrl = new URL("auth/authorize", \`${BASE_URL_CLINE}/\`)` with a fixed
-	(module-const or imported) base. The `ts_ssrf_sink` post-filter already
-	exempted a `fetch()` of a file-local `const` literal string (#963) but had no
-	awareness of the `new URL(literalPath, fixedBase)` shape, so
-	`url.toString()`/`url.href` fell through to the broad taint heuristic. Extended
-	the post-filter to also exempt `fetch(u.toString())`/`fetch(u.href)` when `u`
-	resolves (same file) to a clean `const u = new URL(<literalPath>, <fixedBase>)`
-	— literal path plus a base that is a literal, a file-local literal `const`, or
-	an import binding (the `URL` ctor may be aliased, e.g. `NodeURL`). Query params
-	added later via `searchParams.set(...)` don't control origin/path and never
-	taint the destination. Still fires (regression fixtures added) when the base
-	or path comes from a function parameter, `process.env`/config (including a
-	const initialized from `process.env`), request data, or a parsed
-	redirect/`location` value — a missed SSRF stays far worse than one FP.
-	Adversarial review then closed two bypasses in that exemption: (1) a
-	post-construction origin mutation (`u.host = req.x` / `u.href = …` /
-	`u["host"] = …`, incl. augmented assignments) now re-taints the receiver and
-	fails closed — only query-only writes (`u.search`/`u.searchParams`) stay
-	exempt; (2) a request-tainted function *parameter* base is no longer exempted
-	just because an unrelated same-named module-level `const` literal exists
-	(scope-aware shadow check; imported bases stay trusted).
-
-- **Fixed: `no-javascript-url`/`no-javascript-url-js` no longer flag defensive
-	`javascript:`-URL filters** (refs #533) — a dogfood run flagged code that was
-	*rejecting* `javascript:` links (e.g. `url.startsWith("javascript:")` inside a
-	guard) as if it were introducing one. The rule matched the `javascript:`
-	string literal alone with no way to tell "used as a sink" from "used to
-	detect/block it". Narrowed both rules to also exclude the literal when it's
-	the needle in `.startsWith`/`.endsWith`/`.includes`/`.indexOf`/`.search`/
-	`.match`, or one side of an `===`/`!==`/`==`/`!=` comparison — deliberately
-	NOT `.replace`/`.replaceAll`, since the literal there could be the malicious
-	replacement argument rather than the defensive search argument, and
-	excluding the whole call would hide that true positive. Both new exclusions
-	deliberately avoid `stopBy: end` (unlike the pre-existing test-literal
-	exclusion, which needs it) so the literal must be a DIRECT argument/operand
-	of the defensive call/comparison, not merely somewhere in its subtree — an
-	adversarial review caught that `stopBy: end` let a real sink smuggled
-	inside the call/comparison (e.g. `candidates.includes(link.href =
-	"javascript:...")`, a comma-operator sink, or `(a.href = "javascript:...")
-	=== expected`) go unflagged. Added valid fixtures reproducing the filter FP
-	and invalid fixtures for the replace-based sink and all three smuggled-sink
-	bypasses, confirmed against the real ast-grep 0.45.0 binary.
-
-- **Contained spawn/callback failures that could crash the host (pidusage bug
-	class)** (refs #533) — a best-effort telemetry sampler recently killed a live
-	pi host with `Error: spawn UNKNOWN` (uncaughtException) because a bundled
-	dep's `child_process.spawn(...)` threw SYNCHRONOUSLY with no try/catch, from
-	a detached context the caller's `try/await/catch` could not contain. Audited
-	every spawn/detached-callback site in `clients/` and hardened the at-risk
-	best-effort/background ones to the repo's existing guard shape (try/catch
-	around the synchronous `spawn` + resolve gracefully, matching the async
-	`'error'`-listener path): `safeSpawnAsync`'s core spawn (the shared wrapper
-	dozens of best-effort callers rely on to NEVER reject), its Windows
-	`killPidTreeSync` (runs from `process` exit/signal handlers, where a throw
-	becomes an uncaughtException during shutdown; the POSIX branch was already
-	guarded), `SgRunner.exec`'s three ast-grep spawn branches, all six installer
-	tool-discovery/verify probes, the PSScriptAnalyzer runner's `spawnPs`, and
-	the MCP `analyzeFileFresh` worker fork. A synchronous spawn throw now
-	resolves the operation's normal failure value instead of escaping as an
-	unhandledRejection/uncaughtException. Behavior-preserving otherwise.
-
-- **Fixed: opengrep security findings now surface project-wide in
-	`lens_diagnostics mode=full`** (refs #585, #584, #533) — opengrep's
-	whole-tree CLI scan ran at session-start and cached its findings, and the
-	cache-only extractor registry (`project-diagnostics/extractors.ts`) even
-	registered an `"opengrep"` row — but #585 replaced that registry in
-	production with `fetchFreshProjectDiagnostics`
-	(`project-diagnostics/fresh-fetch.ts`), whose `ANALYZER_IDS` list omitted
-	opengrep. Net: opengrep scanned + cached, yet nothing production read it
-	back, so semgrep-grade security findings (ERROR→blocking, CWE-tagged) never
-	reached the agent for unedited/project-wide files — a scan-and-orphan
-	honesty gap (#533). `fetchFreshProjectDiagnostics` now runs opengrep the
-	same way it runs gitleaks/trivy: an availability probe (opengrep is
-	structurally always-on, so no static project-type gate), then a fresh scan
-	that JOINS the session-start scan of the same root via
-	`SecurityScanClient.dedupeScan` rather than double-spawning a heavy scan,
-	with the result written back to cache and adapted to project diagnostics.
-	The per-edit aux-LSP push path (`clientScope: with-auxiliary`,
-	`AUXILIARY_LSP_PROFILES`) was verified already-working and is untouched;
-	opengrep stays excluded from the push-only LSP workspace sweep (#584). The
-	now-dead cache-only `extractCachedProjectDiagnostics` reader — the parallel
-	registry that shadowed `ANALYZER_IDS` and let opengrep silently diverge — was
-	removed so a single source of truth (#883) remains.
-
-- **Fixed: test-runner findings now surface project-wide in `lens_diagnostics
-	mode=full`** (closes #1004, refs #585, #533) — the same `ANALYZER_IDS`
-	omission #585/#1003 fixed for opengrep also orphaned test-runner: the
-	per-edit turn_end test fire (`runtime-turn.ts`) caches failures under
-	`"test-runner-findings"`, but `fetchFreshProjectDiagnostics`
-	(`project-diagnostics/fresh-fetch.ts`) never read that cache back, so test
-	failures never reached the agent for unedited/project-wide `mode=full`
-	calls. Unlike opengrep/gitleaks/trivy, this is wired as a CACHE-READ (not a
-	fresh scan): test-runner has no "whole project" run to trigger — turn_end
-	only ever runs the targeted, cascade-aware test files touched by that
-	turn's edits — so `fetchFreshProjectDiagnostics` now peeks at the same
-	`"test-runner-findings"` cache key (never re-running the suite, never
-	writing back) and adapts it via the existing
-	`testRunnerFindingsToProjectDiagnostics`. Added a coverage guardrail
-	(`tests/clients/project-diagnostics/analyzer-coverage.test.ts`) that greps
-	the real session-start (`runHeavyweightTask`) and EVERY turn_end
-	`cacheManager.writeCache` call site in `runtime-turn.ts` (excluding a
-	short, explicit bookkeeping exclude-list — `errorDebt`/`turn-end-findings`/
-	`turn-end-findings-last` — that isn't analyzer-shaped) and asserts every
-	remaining id is a member of `ANALYZER_IDS`, so this whole #585 bug class
-	can't silently regress again for a future analyzer added to EITHER writer.
-	Adversarial review also caught two honesty/fidelity gaps in the initial
-	fix: (1) test-runner is cache-read, edit-scoped (the targeted test files
-	touched by the most recent turn's edits), unlike every other analyzer's
-	fresh whole-project scan — `mode=full` now emits an explicit "coverage is
-	edit-scoped, NOT a full-project run" caveat whenever test-runner
-	contributed findings (not only when cold), and a `stale` cached result
-	(the turn advanced before the test run finished) is prefixed
-	`[stale — from a prior turn]` in its diagnostic message, matching the
-	one-shot turn-context message's own stale wording; (2) `TestFailure.location`
-	(`"file.ts:42"`, set by the vitest/jest JSON parser in
-	`test-runner-client.ts`) never reached `ProjectDiagnostic.line`, so every
-	test-runner finding rendered as `L?:` — `runner-adapters/runner-findings.ts`
-	now parses a numeric trailing `:line[:col]` out of `location` (left alone
-	for pytest/mix's non-numeric `location` strings, which carry a test name or
-	module, not a line).
-
-- **Guarded Windows CPU/RSS resource sampling so a best-effort sampler can no
-	longer crash the pi host** (refs #620, #533) — `clients/resource-sampler.ts`
-	sampled CPU%/RSS via `pidusage`, whose Windows path shells out to `gwmi`
-	through an internal `spawn(..., { shell: "powershell.exe" })` that has no
-	try/catch and runs from inside a ChildProcess `close` callback. Under real
-	Windows handle/commit pressure that spawn can throw `spawn UNKNOWN`
-	(errno -4094) **synchronously in that detached callback**, which the call
-	site's `try { await pidusage() } catch {}` cannot catch → `uncaughtException`
-	→ the whole host process dies (observed live). pidusage 4.0.1 offers no
-	option to avoid the gwmi path. The sampler now runs its OWN fully guarded
-	`Get-CimInstance Win32_Process` query on Windows (never calling `pidusage`
-	there), mirroring the existing `findDescendantPidsWindows` guard: a
-	synchronous spawn throw, a child `error` event, and a non-zero/garbage exit
-	all resolve to a partial/empty map — the sampler can now only ever lose a
-	data point, never throw into the heartbeat/spawn path. RSS comes from
-	`WorkingSetSize`; CPU% is preserved via the same KernelModeTime/UserModeTime
-	delta-over-elapsed-wall-time computation gwmi uses (a small per-pid history
-	tracks the prior cumulative CPU time). Linux/macOS keep using `pidusage`
-	(procfs/`ps` — not the crash vector) unchanged. A pid absent from the
-	returned map still means "unsampled this tick", never zero.
-
-- **Stabilized the two remaining flaky/environment-sensitive tests tracked in
-	#902.** LSP workspace-diagnostics sweep flush-count assertions
-	(`workspace-diagnostics-sweep-batch-open.test.ts`,
-	`workspace-diagnostics-sweep-preopen-chunk.test.ts`) pinned an exact flush
-	count, but the pre-open pass's real `fs.promises.readFile` genuinely races
-	the real 100ms `WatchedFilesQueue` debounce timer — under full-suite
-	scheduler contention that can legitimately fragment or merge a chunk's
-	flush by one. Replaced the exact-count assertions with invariant checks
-	(coalescing happened; nowhere near one flush per file; no lost/duplicated
-	URIs) that tolerate that jitter without losing the #608/#621 regression
-	coverage — a test-robustness fix, not a product bug. Separately, two
-	ast-grep dispatch test harnesses
-	(`ast-grep-rule-tests.test.ts`, `ast-grep-catalog-rules.test.ts`) shelled
-	out to the real `ast-grep` CLI via a raw `execFileSync(..., { shell: true
-	})` per call — an uncached cmd.exe wrapper on Windows whose own exit code
-	can mask the real child's and which can intermittently fail to spawn at
-	all under the process-creation pressure of a full parallel test run.
-	Switched both to the already-hardened `safeSpawn` (`clients/safe-spawn.ts`,
-	#817) — cached PATH+PATHEXT resolution, direct `.exe`/`.com` spawn with no
-	shell involved — the same deterministic resolution production dispatch
-	already relies on. The third tracked item
-	(`startup-overhead.test.ts`'s "quick mode self-reports within 100ms")
-	was already reworked to a generous fixed budget + `retry: 2` in an earlier
-	pass; confirmed still adequate, no further change needed.
+ `context` event handler in `index.ts` now splices pi-lens's ephemeral turn-end
+ findings in **immediately before the final message** instead of prepending them
+ at message index 0. Prepending flipped `messages[0]` every turn, which
+ invalidated the entire prompt-cache prefix on every prefix-caching provider
+ (Anthropic, Bedrock, and OpenAI — all key the cache on the exact token prefix).
+ Inserting before the last message keeps `messages[0]` (the real first user turn)
+ byte-stable so the prior conversation stays cached, while still keeping the real
+ user prompt as the trailing message — preserving the trailing-`user` cache
+ breakpoint and the historical `fe0ed5da` guarantee that input is never empty (the
+ existing transcript is always preserved, never dropped; an empty transcript falls
+ back to the prior prepend-only behavior). Because the `context` event fires
+ before **every** provider call (not just at turn boundaries), a trailing-role
+ guard (`isPlainUserPrompt`) only splices before the last message when it is a
+ plain user prompt; when the tail is a mid-loop `tool_result` (or assistant/tool
+ message) the findings are **appended** after the whole transcript instead — a
+ pure append that both preserves the `tool_use`↔`tool_result` adjacency all three
+ providers require (splicing between them is an HTTP 400) and keeps the entire
+ prior transcript as an untouched cache prefix. Changes shipped `dist` behavior
+ (the handler lives in the bundled dist path).
+
+- **Fixed: `ts-ssrf` no longer flags fixed/const endpoint URLs built with `new URL(...)` as SSRF sinks, while still catching tainted URLs (closes #1000, refs #533, #963)** — a project-wide pi-free scan flagged fixed outbound
+ OAuth/profile endpoints as SSRF: `fetch(authUrl.toString())` where
+ `authUrl = new URL("auth/authorize", \`${BASE_URL_CLINE}/\`)` with a fixed
+ (module-const or imported) base. The `ts_ssrf_sink` post-filter already
+ exempted a `fetch()` of a file-local `const` literal string (#963) but had no
+ awareness of the `new URL(literalPath, fixedBase)`shape, so
+ `url.toString()`/`url.href` fell through to the broad taint heuristic. Extended
+ the post-filter to also exempt `fetch(u.toString())`/`fetch(u.href)` when `u`
+resolves (same file) to a clean `const u = new URL(<literalPath>, <fixedBase>)`
+— literal path plus a base that is a literal, a file-local literal `const`, or
+ an import binding (the`URL` ctor may be aliased, e.g. `NodeURL`). Query params
+ added later via`searchParams.set(...)` don't control origin/path and never
+ taint the destination. Still fires (regression fixtures added) when the base
+ or path comes from a function parameter, `process.env`/config (including a
+ const initialized from`process.env`), request data, or a parsed
+ redirect/`location`value — a missed SSRF stays far worse than one FP.
+ Adversarial review then closed two bypasses in that exemption: (1) a
+ post-construction origin mutation (`u.host = req.x` / `u.href = …`/
+ `u["host"] = …`, incl. augmented assignments) now re-taints the receiver and
+ fails closed — only query-only writes (`u.search`/`u.searchParams`) stay
+ exempt; (2) a request-tainted function *parameter* base is no longer exempted
+ just because an unrelated same-named module-level`const` literal exists
+ (scope-aware shadow check; imported bases stay trusted).
+
+- **Fixed: `no-javascript-url`/`no-javascript-url-js` no longer flag defensive `javascript:`-URL filters (refs #533)** — a dogfood run flagged code that was
+ *rejecting* `javascript:` links (e.g. `url.startsWith("javascript:")` inside a
+ guard) as if it were introducing one. The rule matched the `javascript:`
+ string literal alone with no way to tell "used as a sink" from "used to
+ detect/block it". Narrowed both rules to also exclude the literal when it's
+ the needle in `.startsWith`/`.endsWith`/`.includes`/`.indexOf`/`.search`/
+ `.match`, or one side of an `===`/`!==`/`==`/`!=` comparison — deliberately
+ NOT `.replace`/`.replaceAll`, since the literal there could be the malicious
+ replacement argument rather than the defensive search argument, and
+ excluding the whole call would hide that true positive. Both new exclusions
+ deliberately avoid `stopBy: end` (unlike the pre-existing test-literal
+ exclusion, which needs it) so the literal must be a DIRECT argument/operand
+ of the defensive call/comparison, not merely somewhere in its subtree — an
+ adversarial review caught that `stopBy: end` let a real sink smuggled
+ inside the call/comparison (e.g. `candidates.includes(link.href =
+ "javascript:...")`, a comma-operator sink, or `(a.href = "javascript:...")
+ === expected`) go unflagged. Added valid fixtures reproducing the filter FP
+ and invalid fixtures for the replace-based sink and all three smuggled-sink
+ bypasses, confirmed against the real ast-grep 0.45.0 binary.
+
+- **Contained spawn/callback failures that could crash the host (pidusage bug class) (refs #533)** — a best-effort telemetry sampler recently killed a live
+ pi host with `Error: spawn UNKNOWN` (uncaughtException) because a bundled
+ dep's `child_process.spawn(...)` threw SYNCHRONOUSLY with no try/catch, from
+ a detached context the caller's `try/await/catch` could not contain. Audited
+ every spawn/detached-callback site in `clients/` and hardened the at-risk
+ best-effort/background ones to the repo's existing guard shape (try/catch
+ around the synchronous `spawn` + resolve gracefully, matching the async
+ `'error'`-listener path): `safeSpawnAsync`'s core spawn (the shared wrapper
+ dozens of best-effort callers rely on to NEVER reject), its Windows
+ `killPidTreeSync` (runs from `process` exit/signal handlers, where a throw
+ becomes an uncaughtException during shutdown; the POSIX branch was already
+ guarded), `SgRunner.exec`'s three ast-grep spawn branches, all six installer
+ tool-discovery/verify probes, the PSScriptAnalyzer runner's `spawnPs`, and
+ the MCP `analyzeFileFresh` worker fork. A synchronous spawn throw now
+ resolves the operation's normal failure value instead of escaping as an
+ unhandledRejection/uncaughtException. Behavior-preserving otherwise.
+
+- **Fixed: opengrep security findings now surface project-wide in `lens_diagnostics mode=full` (refs #585, #584, #533)** — opengrep's
+ whole-tree CLI scan ran at session-start and cached its findings, and the
+ cache-only extractor registry (`project-diagnostics/extractors.ts`) even
+ registered an `"opengrep"` row — but #585 replaced that registry in
+ production with `fetchFreshProjectDiagnostics`
+ (`project-diagnostics/fresh-fetch.ts`), whose `ANALYZER_IDS` list omitted
+ opengrep. Net: opengrep scanned + cached, yet nothing production read it
+ back, so semgrep-grade security findings (ERROR→blocking, CWE-tagged) never
+ reached the agent for unedited/project-wide files — a scan-and-orphan
+ honesty gap (#533). `fetchFreshProjectDiagnostics` now runs opengrep the
+ same way it runs gitleaks/trivy: an availability probe (opengrep is
+ structurally always-on, so no static project-type gate), then a fresh scan
+ that JOINS the session-start scan of the same root via
+ `SecurityScanClient.dedupeScan` rather than double-spawning a heavy scan,
+ with the result written back to cache and adapted to project diagnostics.
+ The per-edit aux-LSP push path (`clientScope: with-auxiliary`,
+ `AUXILIARY_LSP_PROFILES`) was verified already-working and is untouched;
+ opengrep stays excluded from the push-only LSP workspace sweep (#584). The
+ now-dead cache-only `extractCachedProjectDiagnostics` reader — the parallel
+ registry that shadowed `ANALYZER_IDS` and let opengrep silently diverge — was
+ removed so a single source of truth (#883) remains.
+
+- **Fixed: test-runner findings now surface project-wide in `lens_diagnostics mode=full` (closes #1004, refs #585, #533)** — the same `ANALYZER_IDS`
+ omission #585/#1003 fixed for opengrep also orphaned test-runner: the
+ per-edit turn_end test fire (`runtime-turn.ts`) caches failures under
+ `"test-runner-findings"`, but `fetchFreshProjectDiagnostics`
+ (`project-diagnostics/fresh-fetch.ts`) never read that cache back, so test
+ failures never reached the agent for unedited/project-wide `mode=full`
+ calls. Unlike opengrep/gitleaks/trivy, this is wired as a CACHE-READ (not a
+ fresh scan): test-runner has no "whole project" run to trigger — turn_end
+ only ever runs the targeted, cascade-aware test files touched by that
+ turn's edits — so `fetchFreshProjectDiagnostics` now peeks at the same
+ `"test-runner-findings"` cache key (never re-running the suite, never
+ writing back) and adapts it via the existing
+ `testRunnerFindingsToProjectDiagnostics`. Added a coverage guardrail
+ (`tests/clients/project-diagnostics/analyzer-coverage.test.ts`) that greps
+ the real session-start (`runHeavyweightTask`) and EVERY turn_end
+ `cacheManager.writeCache` call site in `runtime-turn.ts` (excluding a
+ short, explicit bookkeeping exclude-list — `errorDebt`/`turn-end-findings`/
+ `turn-end-findings-last` — that isn't analyzer-shaped) and asserts every
+ remaining id is a member of `ANALYZER_IDS`, so this whole #585 bug class
+ can't silently regress again for a future analyzer added to EITHER writer.
+ Adversarial review also caught two honesty/fidelity gaps in the initial
+ fix: (1) test-runner is cache-read, edit-scoped (the targeted test files
+ touched by the most recent turn's edits), unlike every other analyzer's
+ fresh whole-project scan — `mode=full` now emits an explicit "coverage is
+ edit-scoped, NOT a full-project run" caveat whenever test-runner
+ contributed findings (not only when cold), and a `stale` cached result
+ (the turn advanced before the test run finished) is prefixed
+ `[stale — from a prior turn]` in its diagnostic message, matching the
+ one-shot turn-context message's own stale wording; (2) `TestFailure.location`
+ (`"file.ts:42"`, set by the vitest/jest JSON parser in
+ `test-runner-client.ts`) never reached `ProjectDiagnostic.line`, so every
+ test-runner finding rendered as `L?:` — `runner-adapters/runner-findings.ts`
+ now parses a numeric trailing `:line[:col]` out of `location` (left alone
+ for pytest/mix's non-numeric `location` strings, which carry a test name or
+ module, not a line).
+
+- **Guarded Windows CPU/RSS resource sampling so a best-effort sampler can no longer crash the pi host (refs #620, #533)** — `clients/resource-sampler.ts`
+ sampled CPU%/RSS via `pidusage`, whose Windows path shells out to `gwmi`
+ through an internal `spawn(..., { shell: "powershell.exe" })` that has no
+ try/catch and runs from inside a ChildProcess `close` callback. Under real
+ Windows handle/commit pressure that spawn can throw `spawn UNKNOWN`
+ (errno -4094) **synchronously in that detached callback**, which the call
+ site's `try { await pidusage() } catch {}` cannot catch → `uncaughtException`
+ → the whole host process dies (observed live). pidusage 4.0.1 offers no
+ option to avoid the gwmi path. The sampler now runs its OWN fully guarded
+ `Get-CimInstance Win32_Process` query on Windows (never calling `pidusage`
+ there), mirroring the existing `findDescendantPidsWindows` guard: a
+ synchronous spawn throw, a child `error` event, and a non-zero/garbage exit
+ all resolve to a partial/empty map — the sampler can now only ever lose a
+ data point, never throw into the heartbeat/spawn path. RSS comes from
+ `WorkingSetSize`; CPU% is preserved via the same KernelModeTime/UserModeTime
+ delta-over-elapsed-wall-time computation gwmi uses (a small per-pid history
+ tracks the prior cumulative CPU time). Linux/macOS keep using `pidusage`
+ (procfs/`ps` — not the crash vector) unchanged. A pid absent from the
+ returned map still means "unsampled this tick", never zero.
+
+- **Stabilized the two remaining flaky/environment-sensitive tests tracked in #902.** LSP workspace-diagnostics sweep flush-count assertions
+ (`workspace-diagnostics-sweep-batch-open.test.ts`,
+ `workspace-diagnostics-sweep-preopen-chunk.test.ts`) pinned an exact flush
+ count, but the pre-open pass's real `fs.promises.readFile` genuinely races
+ the real 100ms `WatchedFilesQueue` debounce timer — under full-suite
+ scheduler contention that can legitimately fragment or merge a chunk's
+ flush by one. Replaced the exact-count assertions with invariant checks
+ (coalescing happened; nowhere near one flush per file; no lost/duplicated
+ URIs) that tolerate that jitter without losing the #608/#621 regression
+ coverage — a test-robustness fix, not a product bug. Separately, two
+ ast-grep dispatch test harnesses
+ (`ast-grep-rule-tests.test.ts`, `ast-grep-catalog-rules.test.ts`) shelled
+ out to the real `ast-grep` CLI via a raw `execFileSync(..., { shell: true
+ })` per call — an uncached cmd.exe wrapper on Windows whose own exit code
+ can mask the real child's and which can intermittently fail to spawn at
+ all under the process-creation pressure of a full parallel test run.
+ Switched both to the already-hardened `safeSpawn` (`clients/safe-spawn.ts`,
+ #817) — cached PATH+PATHEXT resolution, direct `.exe`/`.com` spawn with no
+ shell involved — the same deterministic resolution production dispatch
+ already relies on. The third tracked item
+ (`startup-overhead.test.ts`'s "quick mode self-reports within 100ms")
+ was already reworked to a generous fixed budget + `retry: 2` in an earlier
+ pass; confirmed still adequate, no further change needed.
 
 - **`pi-lens build-graph` honestly reports a capped, over-the-cap persist**
-	(closes #924, refs #936 limit 3) — the CLI's build-attempt check no longer
-	mistakes the benign "succeeded, but persisted a partial subgraph" reason
-	(#960's over-cap circuit-breaker) for a hard failure: it now exits 0 and
-	prints a `PARTIAL persist` line with `persistedNodes=X/Y`,
-	`persistedEdges=X/Y`, and the cap that was hit, instead of either silently
-	reporting "done" or failing loudly on a build/persist that actually
-	succeeded. `flushReviewGraphPersist()` now returns the persisted
-	`coverage` so any standalone caller can make the same distinction.
+ (closes #924, refs #936 limit 3) — the CLI's build-attempt check no longer
+ mistakes the benign "succeeded, but persisted a partial subgraph" reason
+ (#960's over-cap circuit-breaker) for a hard failure: it now exits 0 and
+ prints a `PARTIAL persist` line with `persistedNodes=X/Y`,
+ `persistedEdges=X/Y`, and the cap that was hit, instead of either silently
+ reporting "done" or failing loudly on a build/persist that actually
+ succeeded. `flushReviewGraphPersist()` now returns the persisted
+ `coverage` so any standalone caller can make the same distinction.
 
 - **`ts-ssrf` no longer trusts naming convention as proof of a fixed URL**
-	(fixes #963) — the post-filter now resolves a bare `fetch(IDENT)` argument
-	against the file's AST and exempts it only when `IDENT` provably resolves
-	to a single `const` declarator initialized with a string literal (or a
-	template literal with no `${...}` substitutions). SCREAMING_SNAKE_CASE
-	naming is no longer sufficient by itself: `const TARGET_URL = req.query.url`
-	still flags, since the identifier's *initializer* — not its name — is
-	what's checked. Ambiguous/shadowed declarations, `let`/`var` bindings,
-	reassigned identifiers, and unresolved identifiers all fall through to the
-	existing broad heuristic and keep being flagged.
+ (fixes #963) — the post-filter now resolves a bare `fetch(IDENT)` argument
+ against the file's AST and exempts it only when `IDENT` provably resolves
+ to a single `const` declarator initialized with a string literal (or a
+ template literal with no `${...}` substitutions). SCREAMING_SNAKE_CASE
+ naming is no longer sufficient by itself: `const TARGET_URL = req.query.url`
+ still flags, since the identifier's *initializer* — not its name — is
+ what's checked. Ambiguous/shadowed declarations, `let`/`var` bindings,
+ reassigned identifiers, and unresolved identifiers all fall through to the
+ existing broad heuristic and keep being flagged.
 
 - **Remaining test-suite spawns routed off `shell:true` to close the Windows-spawn flake class** (refs #902) —
-	`tests/clients/ast-grep-rule-precedence-followups.test.ts` (CLI probe + `runCli`),
-	`tests/clients/coderabbit-ast-grep-rules.test.ts` (vendored-catalog smoke),
-	`tests/clients/dispatch/runners/ast-grep-playground-verify.test.ts` (async `runVerify`),
-	`tests/clients/dead-code-client.test.ts` (vulture probe), and
-	`tests/clients/lsp/clangd-lazy-indexing.test.ts` (clangd `where`/`which` probe) now spawn
-	through the hardened `safeSpawn`/`safeSpawnAsync` (`clients/safe-spawn.ts`, #817) instead of
-	a raw `execFileSync`/`spawnSync`/`spawn`/`execSync` with a fresh, uncached `cmd.exe` wrapper
-	per call — the documented intermittent ENOENT/EAGAIN source under windows-latest CI's
-	parallel process-creation pressure. Completes the sweep PR #993 started for the two
-	ast-grep runner test files; `git` spawns are left as-is (no `.cmd` shim, so out of the flake
-	class) and the `mcp/*` and MCP harness spawns that need bidirectional stdin streaming are
-	left as-is (`safeSpawnAsync` only exposes a close-based result, not a live stdin/stdout pipe).
+ `tests/clients/ast-grep-rule-precedence-followups.test.ts` (CLI probe + `runCli`),
+ `tests/clients/coderabbit-ast-grep-rules.test.ts` (vendored-catalog smoke),
+ `tests/clients/dispatch/runners/ast-grep-playground-verify.test.ts` (async `runVerify`),
+ `tests/clients/dead-code-client.test.ts` (vulture probe), and
+ `tests/clients/lsp/clangd-lazy-indexing.test.ts` (clangd `where`/`which` probe) now spawn
+ through the hardened `safeSpawn`/`safeSpawnAsync` (`clients/safe-spawn.ts`, #817) instead of
+ a raw `execFileSync`/`spawnSync`/`spawn`/`execSync` with a fresh, uncached `cmd.exe` wrapper
+ per call — the documented intermittent ENOENT/EAGAIN source under windows-latest CI's
+ parallel process-creation pressure. Completes the sweep PR #993 started for the two
+ ast-grep runner test files; `git` spawns are left as-is (no `.cmd` shim, so out of the flake
+ class) and the `mcp/*` and MCP harness spawns that need bidirectional stdin streaming are
+ left as-is (`safeSpawnAsync` only exposes a close-based result, not a live stdin/stdout pipe).
 
 - **Tree-sitter post-filters no longer leave silently dead rules** (refs #879) —
-	the 25 unknown filter references were resolved by implementing eight bounded,
-	fail-open-on-filter-error AST checks, expressing two conditions directly in
-	their queries, and removing fifteen rules whose promised semantic/framework
-	analysis could not be supported honestly. Coarse resource, assertion, and
-	sensitive-`memset` heuristics are advisory rather than blocking.
+ the 25 unknown filter references were resolved by implementing eight bounded,
+ fail-open-on-filter-error AST checks, expressing two conditions directly in
+ their queries, and removing fifteen rules whose promised semantic/framework
+ analysis could not be supported honestly. Coarse resource, assertion, and
+ sensitive-`memset` heuristics are advisory rather than blocking.
 
 - **Capped word indexes disclose partial coverage** (refs #928) — snapshots now
-	persist indexed-file count and truncation state, and both `symbol_search`
-	surfaces report coverage instead of presenting capped zero-hit results as
-	authoritative.
+ persist indexed-file count and truncation state, and both `symbol_search`
+ surfaces report coverage instead of presenting capped zero-hit results as
+ authoritative.
 
 - **`pilens_health` keeps disabled LSP servers visible** (refs #927) —
-	permanently broken server/root pairs now render with their failure count, and
-	temporary circuit-breaker cooldowns expose their retry deadline.
+ permanently broken server/root pairs now render with their failure count, and
+ temporary circuit-breaker cooldowns expose their retry deadline.
 
 - **Cold `symbol_search` failures are now observable and honest** (refs #926) —
-	unavailable results distinguish an active build, a safety refusal, and the
-	last build's failure, while background build/persist errors reach a persistent
-	NDJSON log.
+ unavailable results distinguish an active build, a safety refusal, and the
+ last build's failure, while background build/persist errors reach a persistent
+ NDJSON log.
 
 - **Failed heavyweight analyzers no longer masquerade as clean runs** (refs #925) —
-	unsuccessful results are reported distinctly, omitted from cache so the next
-	session retries, and valid fix-worklog records survive neighboring corrupt lines.
-
-- **The footer refreshes as LSP servers come online during a cold
-	`lens_diagnostics mode=full` sweep** (refs #798), instead of showing
-	`LSP Inactive` until turn end. The repaint captures UI methods during the
-	active tool event, so async warm-up never touches a stale session context.
-
-- **Tree-sitter WASM aborts are now visible instead of silently disabling
-	structural analysis for the rest of the process** (refs #915). The shared
-	runtime records a process-wide, timestamped `restart_required` health state,
-	logs a one-time actionable error, exposes it through `pilens_health`, and
-	marks project-scan responses with `treeSitterStatus`. A poisoned scan remains
-	truncated and never replaces the last complete snapshot. In-process retry is
-	deliberately unsafe: every new client imports the same cached `web-tree-sitter`
-	ES module and therefore reuses its corrupted Emscripten heap; restarting the
-	host is the isolation boundary.
+ unsuccessful results are reported distinctly, omitted from cache so the next
+ session retries, and valid fix-worklog records survive neighboring corrupt lines.
+
+- **The footer refreshes as LSP servers come online during a cold `lens_diagnostics mode=full` sweep (refs #798)**, instead of showing
+ `LSP Inactive` until turn end. The repaint captures UI methods during the
+ active tool event, so async warm-up never touches a stale session context.
+
+- **Tree-sitter WASM aborts are now visible instead of silently disabling structural analysis for the rest of the process (refs #915)**. The shared
+ runtime records a process-wide, timestamped `restart_required` health state,
+ logs a one-time actionable error, exposes it through `pilens_health`, and
+ marks project-scan responses with `treeSitterStatus`. A poisoned scan remains
+ truncated and never replaces the last complete snapshot. In-process retry is
+ deliberately unsafe: every new client imports the same cached `web-tree-sitter`
+ ES module and therefore reuses its corrupted Emscripten heap; restarting the
+ host is the isolation boundary.
 
 - **`pilens_rebuild` can no longer destroy an npm-installed pi-lens** (refs
-	#920) — rebuilds are refused before spawning a package script unless the
-	package is a source checkout with `tsconfig.dist.json` outside
-	`node_modules`; installed servers also omit the tool from `tools/list`, so
-	subagent allowlists cannot discover it.
+ #920) — rebuilds are refused before spawning a package script unless the
+ package is a source checkout with `tsconfig.dist.json` outside
+ `node_modules`; installed servers also omit the tool from `tools/list`, so
+ subagent allowlists cannot discover it.
 
 - **Review-graph background failures are no longer silent** (refs #919) —
-	`project_report`/`pilens_project_report` now surface the most recent build
-	attempt and its terminal skip/failure reason, including the persistence
-	element circuit-breaker. A dedicated `~/.pi-lens/review-graph.log` records
-	build and persistence starts, successes, skips, and failures, so a rejected
-	fire-and-forget build or an over-cap graph cannot look perpetually in progress.
+ `project_report`/`pilens_project_report` now surface the most recent build
+ attempt and its terminal skip/failure reason, including the persistence
+ element circuit-breaker. A dedicated `~/.pi-lens/review-graph.log` records
+ build and persistence starts, successes, skips, and failures, so a rejected
+ fire-and-forget build or an over-cap graph cannot look perpetually in progress.
 
 - Resolve nested C# and F# project roots for dotnet builds (refs #895).
 
-- **A mid-scan tree-sitter WASM abort no longer replaces the authoritative
-	project-diagnostics snapshot with a silently truncated result** (refs #891).
-	The partial scan is returned with `scanTruncated`, logs its completed/total
-	file counts and abort point, and leaves the previous complete cache intact.
+- **A mid-scan tree-sitter WASM abort no longer replaces the authoritative project-diagnostics snapshot with a silently truncated result (refs #891)**.
+ The partial scan is returned with `scanTruncated`, logs its completed/total
+ file counts and abort point, and leaves the previous complete cache intact.
 
 - **Block-wrapped switch cases no longer report false fall-through errors**
-	(refs #910) — `switch-case-termination` now follows trailing statement
-	blocks to recognize a nested `break`, `return`, `throw`, or `continue`, while
-	still flagging empty and non-terminating blocks.
+ (refs #910) — `switch-case-termination` now follows trailing statement
+ blocks to recognize a nested `break`, `return`, `throw`, or `continue`, while
+ still flagging empty and non-terminating blocks.
 
 - **Project-wide enumeration now covers every registered file kind** (refs
-	#894) — `ALL_SCANNABLE_EXTENSIONS`, `WARMUP_SOURCE_EXTS`, and
-	`SUPPORTED_FILE_KINDS` now derive from the single `KIND_EXTENSIONS`
-	authority instead of three drifting language lists. TODO scans, symbol
-	search indexing, dominant-language LSP warmup, and language-profile
-	detection can now see Java, Swift, C/C++, PHP, and every other supported
-	kind. Code kinds keep priority over data/doc kinds (json/yaml/markdown/…)
-	inside the existing caps: the dominant-language LSP warm ranks code kinds
-	first, and the capped warmup/word-index walks fill code files before
-	non-code files, so a locale/fixture pile can't starve real languages.
-	Package-manager lockfiles (package-lock.json, pnpm-lock.yaml, …) are
-	filtered as generated artifacts, and the TODO scanner caps per-file reads
-	at 512 KiB. A coverage guard makes a newly registered kind automatically
-	enumerable — and classified as code or non-code — on both project-wide
-	paths.
+ #894) — `ALL_SCANNABLE_EXTENSIONS`, `WARMUP_SOURCE_EXTS`, and
+ `SUPPORTED_FILE_KINDS` now derive from the single `KIND_EXTENSIONS`
+ authority instead of three drifting language lists. TODO scans, symbol
+ search indexing, dominant-language LSP warmup, and language-profile
+ detection can now see Java, Swift, C/C++, PHP, and every other supported
+ kind. Code kinds keep priority over data/doc kinds (json/yaml/markdown/…)
+ inside the existing caps: the dominant-language LSP warm ranks code kinds
+ first, and the capped warmup/word-index walks fill code files before
+ non-code files, so a locale/fixture pile can't starve real languages.
+ Package-manager lockfiles (package-lock.json, pnpm-lock.yaml, …) are
+ filtered as generated artifacts, and the TODO scanner caps per-file reads
+ at 512 KiB. A coverage guard makes a newly registered kind automatically
+ enumerable — and classified as code or non-code — on both project-wide
+ paths.
 
 - **CMake files now reach a real LSP server** (refs #892) — the CMake policy's
-	previous `lsp` fallback had no registered server and silently produced no
-	diagnostics. `cmake-language-server` now covers both `.cmake` files and the
-	canonical `CMakeLists.txt` basename, with managed pip installation.
+ previous `lsp` fallback had no registered server and silently produced no
+ diagnostics. `cmake-language-server` now covers both `.cmake` files and the
+ canonical `CMakeLists.txt` basename, with managed pip installation.
 
 - **Fish LSP policy is no longer dead wiring** (refs #893) — `fish-lsp` is now
-	registered for `.fish` files and auto-installed through npm; `fish_indent`
-	continues to run alongside it.
+ registered for `.fish` files and auto-installed through npm; `fish_indent`
+ continues to run alongside it.
 
 - **Editing an inherited tree-sitter rule now invalidates the inheriting language's RuleCache** (refs #878) — the cache key fingerprinted only the language's OWN rules directory, but `tsx` also runs the `typescript` rule set (`queriesForLanguage`), so a typescript-rule edit left the tsx entry's hash unchanged and stale compiled rules kept being served from the on-disk cache until a tsx rule happened to change. The fingerprint now covers the full effective rule set via `ruleFilesForLanguage`, a new loader-owned seam that derives from the same rule-source composition as rule selection, so the cache key can't drift from what the runner actually runs. The runner's cache-miss path also forces the query loader past its in-memory memo (`loadQueries(root, { force: true })`) — a correct key alone wasn't enough: the memo ignores rule-file mtimes, so within one process a miss re-persisted the PRE-edit rules under the fresh fingerprint and the staleness then survived restarts. The client's compiled-batch cache is likewise now keyed on rule content instead of rule ids — ids are stable across edits, so the shared client kept serving the pre-edit compiled patterns (and messages) for the process lifetime even after the reload. `CACHE_VERSION` bumped to `v6`.
 
 - **Small edits no longer pay the entity-extraction cost** (refs #885) — the
-	<5-line skip threshold only guarded the zero-diagnostics early return; a
-	second `extractEntitySnapshot` block ran unconditionally, so trivial edits
-	still spent ~500-800ms per dispatch and, on unsaved buffers, parsed stale
-	disk content (thrashing the parse-cache entry). Extraction is now one
-	threshold-guarded block that receives the same `file.content` override the
-	diagnostics phase used.
+ <5-line skip threshold only guarded the zero-diagnostics early return; a
+ second `extractEntitySnapshot` block ran unconditionally, so trivial edits
+ still spent ~500-800ms per dispatch and, on unsaved buffers, parsed stale
+ disk content (thrashing the parse-cache entry). Extraction is now one
+ threshold-guarded block that receives the same `file.content` override the
+ diagnostics phase used.
 
 - **The per-edit tree-sitter runner walks the tree once, not once per rule**
-	(refs #888) — the dispatch hot path ran ~30-40 `runQueryOnFile` walks per
-	edit behind a concurrency limiter that could not parallelize synchronous
-	WASM. It now calls `runQueriesOnFile` once (#675 batching) and distributes
-	the per-rule results; the per-rule `maxResults(10)` cap and modified-ranges
-	gating are unchanged.
+ (refs #888) — the dispatch hot path ran ~30-40 `runQueryOnFile` walks per
+ edit behind a concurrency limiter that could not parallelize synchronous
+ WASM. It now calls `runQueriesOnFile` once (#675 batching) and distributes
+ the per-rule results; the per-rule `maxResults(10)` cap and modified-ranges
+ gating are unchanged.
 
 - **A transient grammar-load failure no longer disables batched rule scans for the process lifetime** (refs #889) — `compileQueryBatch` cached `null` on ANY `build()` failure, including a transient `loadLanguage()` miss (offline lazy grammar fetch, mid-scan load error), so every later scan fell back to the per-rule path and paid ~3.3× forever. Load failures are now distinguished from genuine batch-compile failures: they are not cached (the next scan retries the load and recovers), with retries bounded at 3 consecutive load failures per rule set before the miss is cached, so a grammar that never loads doesn't hot-loop. Deterministic compile failures still cache `null` permanently. The query/batch cache keys also switched from a collision-prone 32-bit hash to the full pattern text.
 
 - **module-report parses plain JS under the correct tree-sitter grammar** (closes
-	#887) — `tsLangForFile` hand-rolled a local extension map that sent
-	`.js`/`.mjs`/`.cjs` to the typescript grammar and `.jsx` to tsx, while every
-	other tree-sitter consumer resolves those extensions to `javascript` via the
-	shared `EXT_TO_LANG` (`clients/tree-sitter-shared.ts`), so each plain-JS file
-	was parsed and cached twice under two grammars (TreeCache keys are
-	`languageId:path`) and ran TS-grammar symbol queries on JS trees. It now
-	routes the extension-split kinds (jsts, and the c-vs-cpp split for cxx)
-	through the shared `resolveTreeSitterLanguage`, keeping the historical kind
-	default only for extensions the shared map does not cover (`.svelte`/`.vue`,
-	the C++ module-interface/Objective-C tail). The symbol extractor gains a
-	dedicated `javascript` defs/refs/import query set: the TypeScript symbol
-	queries do NOT compile against the javascript grammar
-	(`interface_declaration`/`type_alias_declaration`/`type_identifier` do not
-	exist there — a query naming them fails with "Bad node name"), so the
-	javascript set is the same queries minus the type-only patterns, with class
-	names matched as `(identifier)` instead of `(type_identifier)`.
+ #887) — `tsLangForFile` hand-rolled a local extension map that sent
+ `.js`/`.mjs`/`.cjs` to the typescript grammar and `.jsx` to tsx, while every
+ other tree-sitter consumer resolves those extensions to `javascript` via the
+ shared `EXT_TO_LANG` (`clients/tree-sitter-shared.ts`), so each plain-JS file
+ was parsed and cached twice under two grammars (TreeCache keys are
+ `languageId:path`) and ran TS-grammar symbol queries on JS trees. It now
+ routes the extension-split kinds (jsts, and the c-vs-cpp split for cxx)
+ through the shared `resolveTreeSitterLanguage`, keeping the historical kind
+ default only for extensions the shared map does not cover (`.svelte`/`.vue`,
+ the C++ module-interface/Objective-C tail). The symbol extractor gains a
+ dedicated `javascript` defs/refs/import query set: the TypeScript symbol
+ queries do NOT compile against the javascript grammar
+ (`interface_declaration`/`type_alias_declaration`/`type_identifier` do not
+ exist there — a query naming them fails with "Bad node name"), so the
+ javascript set is the same queries minus the type-only patterns, with class
+ names matched as `(identifier)` instead of `(type_identifier)`.
 
 - **A rule whose query fails to compile now warns once instead of silently reporting nothing** (refs #884) — both compile paths (`compileQueryBatch`'s per-rule drop and `compileRawQuery`, which every per-edit `runQueryOnFile` call falls back on) previously either `dbg()`-logged (invisible without verbose mode) or returned `null`/`[]` with no trail at all. They now call a shared `reportQueryCompileFailure`, mirroring the existing unimplemented-`post_filter` warning: one `console.error` per broken rule id, not per file. A new compile-guard test (`tests/clients/tree-sitter-rule-compile-guard.test.ts`) compiles every non-disabled shipped rule against its real grammar and caught the 32 rules #884 reports as currently broken (tracked there in a shrink-only `KNOWN_BROKEN` allowlist so follow-up fix PRs are forced to remove their entries, and the list can't grow or go stale unnoticed).
 
 - **TreeCache mtime false misses and FIFO eviction** (closes #890) — a content
-	hash match is now authoritative: a save-without-change (same bytes, newer
-	mtime) is a cache hit that refreshes the entry's stat metadata instead of
-	invalidating and re-parsing, and `get()` re-inserts hit entries so eviction
-	is true LRU — hot per-edit files are no longer evicted by scan traffic.
-
-- **Eight enabled typescript/javascript tree-sitter rules whose queries never
-	compiled** (refs #884) — each had been silently dead since authoring because
-	its query failed to compile against the real grammar, so it matched nothing
-	and reported no diagnostics. Repaired against the actual node/field names and
-	verified end-to-end (matches the bug, leaves correct code alone):
-	`empty-switch-case`, `switch-case-termination`, `switch-case-termination-js`
-	(switch cases carry their statements as direct `body:` children, not a
-	`consequence: (statement_block)`); `infinite-loop` (`while (true)` wraps the
-	condition in a `parenthesized_expression`; `for (;;)` has an `empty_statement`
-	condition, not `(null)`); `duplicate-function-arg` (typescript parameters are
-	`required_parameter`, not bare `(identifier)`; now also catches non-adjacent
-	duplicates); `mixed-async-styles` (no `async_modifier` node — match the `async`
-	token); `switch-non-case-labels` (JS) (a `labeled_statement` lives inside a
-	`switch_case`, not directly under `switch_body`); and `ts-insecure-random`
-	(the inline `(?i)` regex flag is invalid in JS `RegExp` — dropped the
-	redundant name predicate and let the post-filter do the case-insensitive
-	check, walking up from the `Math.random()` call so chained forms like
-	`Math.random().toString(36)` are still attributed to their binding). Also
-	implemented the four post-filters these rules referenced but that were never
-	defined (`is_empty_block`, `no_break_or_return_in_body`, `same_param_name`,
-	`no_terminating_statement`), which the batch runner had been failing closed on.
+ hash match is now authoritative: a save-without-change (same bytes, newer
+ mtime) is a cache hit that refreshes the entry's stat metadata instead of
+ invalidating and re-parsing, and `get()` re-inserts hit entries so eviction
+ is true LRU — hot per-edit files are no longer evicted by scan traffic.
+
+- **Eight enabled typescript/javascript tree-sitter rules whose queries never compiled (refs #884)** — each had been silently dead since authoring because
+ its query failed to compile against the real grammar, so it matched nothing
+ and reported no diagnostics. Repaired against the actual node/field names and
+ verified end-to-end (matches the bug, leaves correct code alone):
+ `empty-switch-case`, `switch-case-termination`, `switch-case-termination-js`
+ (switch cases carry their statements as direct `body:` children, not a
+ `consequence: (statement_block)`); `infinite-loop` (`while (true)` wraps the
+ condition in a `parenthesized_expression`; `for (;;)` has an `empty_statement`
+ condition, not `(null)`); `duplicate-function-arg` (typescript parameters are
+ `required_parameter`, not bare `(identifier)`; now also catches non-adjacent
+ duplicates); `mixed-async-styles` (no `async_modifier` node — match the `async`
+ token); `switch-non-case-labels` (JS) (a `labeled_statement` lives inside a
+ `switch_case`, not directly under `switch_body`); and `ts-insecure-random`
+ (the inline `(?i)` regex flag is invalid in JS `RegExp` — dropped the
+ redundant name predicate and let the post-filter do the case-insensitive
+ check, walking up from the `Math.random()` call so chained forms like
+ `Math.random().toString(36)` are still attributed to their binding). Also
+ implemented the four post-filters these rules referenced but that were never
+ defined (`is_empty_block`, `no_break_or_return_in_body`, `same_param_name`,
+ `no_terminating_statement`), which the batch runner had been failing closed on.
 
 - **A column-0 comment after a `query: |` block no longer breaks the rule**
-	(refs #884) — the query-block extractor kept every line more-indented than the
-	key (to preserve `#eq?`/`#match?` predicate lines) but did not stop at a
-	document-level `# …` comment sitting between the block and the next key, so the
-	comment was appended to the query and made it fail to compile. This is what
-	kept `mixed-async-styles` dead even after its query was otherwise correct.
+ (refs #884) — the query-block extractor kept every line more-indented than the
+ key (to preserve `#eq?`/`#match?` predicate lines) but did not stop at a
+ document-level `# …` comment sitting between the block and the next key, so the
+ comment was appended to the query and made it fail to compile. This is what
+ kept `mixed-async-styles` dead even after its query was otherwise correct.
 
 - **Seven ruby security rules never compiled and never produced a finding** (refs
-	#884) — `ruby-command-injection`, `ruby-eval`, `ruby-insecure-deserialization`,
-	`ruby-insecure-random`, `ruby-open-struct`, `ruby-string-eval` and
-	`ruby-weak-hash` were authored against JavaScript-grammar node names
-	(`call_expression`, `method_call`, `command`, `interpolated_string`) that do not
-	exist in tree-sitter-ruby, so every one failed to compile with a "Bad node name"
-	error and was silently skipped. Each query is rewritten against the real ruby
-	grammar (`call` with `method:`/`receiver:` fields, `scope_resolution` receivers
-	for `Digest::MD5`, `string` for interpolated literals), with `#match?`/`#eq?`
-	predicates moved inside the pattern's outermost parens. Per-rule positive and
-	negative fixtures (`system` vs `File.read`, `Marshal.load` vs `YAML.safe_load`,
-	`rand` vs `SecureRandom`, `OpenStruct.new` vs `Struct.new`, `Digest::MD5` vs
-	`Digest::SHA256`, string vs block `class_eval`) pin the security intent.
+ #884) — `ruby-command-injection`, `ruby-eval`, `ruby-insecure-deserialization`,
+ `ruby-insecure-random`, `ruby-open-struct`, `ruby-string-eval` and
+ `ruby-weak-hash` were authored against JavaScript-grammar node names
+ (`call_expression`, `method_call`, `command`, `interpolated_string`) that do not
+ exist in tree-sitter-ruby, so every one failed to compile with a "Bad node name"
+ error and was silently skipped. Each query is rewritten against the real ruby
+ grammar (`call` with `method:`/`receiver:` fields, `scope_resolution` receivers
+ for `Digest::MD5`, `string` for interpolated literals), with `#match?`/`#eq?`
+ predicates moved inside the pattern's outermost parens. Per-rule positive and
+ negative fixtures (`system` vs `File.read`, `Marshal.load` vs `YAML.safe_load`,
+ `rand` vs `SecureRandom`, `OpenStruct.new` vs `Struct.new`, `Digest::MD5` vs
+ `Digest::SHA256`, string vs block `class_eval`) pin the security intent.
 
 - **Six python rules never compiled or never fired** (refs #884) —
-	`python-empty-except` used a `body:` field that doesn't exist on
-	`except_clause`; `in-operator-unsupported` used bare `"in"`/`"not"` `"in"`
-	tokens the grammar doesn't expose that way (`not in` is a single token) and
-	only matched `identifier` targets, so `x in None` never matched at all;
-	`no-super-torchscript` looked for a `(call function: (identifier))` inside the
-	decorator (`@torch.jit.script` has no call — it's a bare `attribute`) and
-	expected the decorator directly on the method rather than the class;
-	`notimplemented-boolean-context` used `("and" | "or")` (not valid tree-sitter
-	query syntax — alternation is `[...]`) inside a non-existent `binary_operator`
-	form and `unary_operator operator: ("not")`, when python's logical `not` is
-	its own `not_operator` node with an `argument:` field;
-	`yield-return-outside-function` referenced a `yield_expression` node type that
-	doesn't exist in tree-sitter-python. All five queries are rewritten against
-	the real grammar (verified via AST dumps against `tree-sitter-python.wasm`);
-	`no-super-torchscript` and `in-operator-unsupported` gained
-	`torchscript_super_call` / `check_in_operator_types` post-filters
-	(`clients/tree-sitter-client.ts`) since neither had a working implementation
-	behind their declared `post_filter` name. `exit-signature-check` compiled
-	fine but its `@PARAM1?`/`@PARAM2?`/`@PARAM3?` captures never matched anything
-	— the `?` quantifier was written after the capture name instead of the node,
-	so the captured names were literally `PARAM1?`/`PARAM2?`/`PARAM3?` while the
-	post_filter read `captures.PARAM1`; fixed to capture the whole `parameters`
-	node and count named children instead (per-slot optional quantifiers turned
-	out to match every valid sub-alignment, not just the maximal one, producing
-	spurious duplicate matches for a fully-correct signature).
+ `python-empty-except` used a `body:` field that doesn't exist on
+ `except_clause`; `in-operator-unsupported` used bare `"in"`/`"not"` `"in"`
+ tokens the grammar doesn't expose that way (`not in` is a single token) and
+ only matched `identifier` targets, so `x in None` never matched at all;
+ `no-super-torchscript` looked for a `(call function: (identifier))` inside the
+ decorator (`@torch.jit.script` has no call — it's a bare `attribute`) and
+ expected the decorator directly on the method rather than the class;
+ `notimplemented-boolean-context` used `("and" | "or")` (not valid tree-sitter
+ query syntax — alternation is `[...]`) inside a non-existent `binary_operator`
+ form and `unary_operator operator: ("not")`, when python's logical `not` is
+ its own `not_operator` node with an `argument:` field;
+ `yield-return-outside-function` referenced a `yield_expression` node type that
+ doesn't exist in tree-sitter-python. All five queries are rewritten against
+ the real grammar (verified via AST dumps against `tree-sitter-python.wasm`);
+ `no-super-torchscript` and `in-operator-unsupported` gained
+ `torchscript_super_call` / `check_in_operator_types` post-filters
+ (`clients/tree-sitter-client.ts`) since neither had a working implementation
+ behind their declared `post_filter` name. `exit-signature-check` compiled
+ fine but its `@PARAM1?`/`@PARAM2?`/`@PARAM3?` captures never matched anything
+ — the `?` quantifier was written after the capture name instead of the node,
+ so the captured names were literally `PARAM1?`/`PARAM2?`/`PARAM3?` while the
+ post_filter read `captures.PARAM1`; fixed to capture the whole `parameters`
+ node and count named children instead (per-slot optional quantifiers turned
+ out to match every valid sub-alignment, not just the maximal one, producing
+ spurious duplicate matches for a fully-correct signature).
 
 - **Project scans run tree-sitter rules for every supported language, not just 10 extensions** (closes #882, refs #877, #880) — the scanner's `TREE_SITTER_EXT_TO_LANG` covered only ts/tsx/js/py/go/rs/rb, so files whose grammars and non-disabled rule dirs already exist (c, cpp, csharp, css, php, java, kotlin) were silently skipped by the tree-sitter phase of project scans. It now derives the shared per-edit resolver (`EXT_TO_LANG`) so c/cpp/csharp/php/css and the `.tsx`→tsx / `.jsx`→javascript nuances can't drift from the per-edit path, and layers java/kotlin on top (grammars + rule dirs exist but no per-edit `appliesTo`). A regression test asserts the map covers every non-disabled rule dir whose grammar is loadable.
 
 - **`.dart` files are now included in project-wide source enumeration** (closes #880, refs #876) — `ALL_SCANNABLE_EXTENSIONS` (`clients/source-filter.ts`) and `WARMUP_SOURCE_EXTS` (`clients/language-profile.ts`) were missing `.dart`, so Dart projects were fully supported per-edit (LSP, `dart-analyze`, `dart format`, autofix) but skipped by project-wide scans and cold-start language-profile warmup.
 
 - **Tree-sitter rules were compiled against the wrong grammar** — a compiled
-	query is bound to the language it compiled against, and running it on a tree
-	from another grammar returns zero matches silently. Rules now compile against
-	the language the file is parsed as. This is why the javascript→typescript rule
-	merge never fired a single diagnostic in its life. That merge stays off — the
-	rules are written against typescript node types and misfire on JS — but the
-	same fix is what makes `.tsx` work.
+ query is bound to the language it compiled against, and running it on a tree
+ from another grammar returns zero matches silently. Rules now compile against
+ the language the file is parsed as. This is why the javascript→typescript rule
+ merge never fired a single diagnostic in its life. That merge stays off — the
+ rules are written against typescript node types and misfire on JS — but the
+ same fix is what makes `.tsx` work.
 
 - **Project scans ran rules from `-disabled/` directories** — the per-edit runner
-	excluded them, the scanner read the raw loader map and ran them anyway.
-	**1,936 of a 500-file scan's 2,590 tree-sitter findings came from rules that
-	were explicitly switched off.** Rule-set selection now goes through one seam,
-	`queriesForLanguage`.
+ excluded them, the scanner read the raw loader map and ran them anyway.
+ **1,936 of a 500-file scan's 2,590 tree-sitter findings came from rules that
+ were explicitly switched off.** Rule-set selection now goes through one seam,
+ `queriesForLanguage`.
 
 - **`.tsx` parsed with the typescript grammar**, which produces ERROR nodes on
-	JSX, and under a different language id than the fact providers use — so every
-	`.tsx` file was parsed twice, once wrongly. It now parses as `tsx` and
-	inherits the typescript rule set, which is rule-for-rule identical on both
-	grammars. `.tsx` also gets those rules in the per-edit runner now, where it
-	previously saw only its own two JSX rules.
+ JSX, and under a different language id than the fact providers use — so every
+ `.tsx` file was parsed twice, once wrongly. It now parses as `tsx` and
+ inherits the typescript rule set, which is rule-for-rule identical on both
+ grammars. `.tsx` also gets those rules in the per-edit runner now, where it
+ previously saw only its own two JSX rules.
 
 - **An unimplemented `post_filter` reported every raw match instead of none.**
-	40 of the 84 filters rules reference have no implementation; the default now
-	drops the match and warns once. `duplicate-function-arg` (whose
-	`same_param_name` filter was never implemented) was reporting 59 phantom
-	duplicates across 60 files.
+ 40 of the 84 filters rules reference have no implementation; the default now
+ drops the match and warns once. `duplicate-function-arg` (whose
+ `same_param_name` filter was never implemented) was reporting 59 phantom
+ duplicates across 60 files.
 
 - **YAML scalars kept their trailing comments** in the rule loader's hand-rolled
-	parser — `post_filter: not_in_test_block  # skip test blocks` carried the
-	comment as part of the filter name, so the filter silently never applied.
+ parser — `post_filter: not_in_test_block  # skip test blocks` carried the
+ comment as part of the filter name, so the filter silently never applied.
 
-- **tree-sitter runner no longer double-increments already 1-indexed
-	line/column** (refs #448) — dispositions recorded against the old off-by-one
-	are anchored (`clients/diagnostic-dispositions.ts`) to the wrong physical
-	line's content and will resurface once after upgrading; this is expected and
-	one-time, not a regression.
+- **tree-sitter runner no longer double-increments already 1-indexed line/column (refs #448)** — dispositions recorded against the old off-by-one
+ are anchored (`clients/diagnostic-dispositions.ts`) to the wrong physical
+ line's content and will resurface once after upgrading; this is expected and
+ one-time, not a regression.
 
 ### Security
 
 - **Debug logs redact credential-shaped text before it reaches disk** (closes
-	#327). The shared NDJSON boundary scrubs private keys, provider tokens, AWS
-	access keys, and JWT/JWE compact tokens with deterministic linear scanners.
-	The synchronous crash-adjacent LSP launch diagnostic uses the same redactor.
+ #327). The shared NDJSON boundary scrubs private keys, provider tokens, AWS
+ access keys, and JWT/JWE compact tokens with deterministic linear scanners.
+ The synchronous crash-adjacent LSP launch diagnostic uses the same redactor.
 
 ## [3.8.73] - 2026-07-28
 
@@ -1133,15 +2617,15 @@ All notable changes to pi-lens will be documented in this file.
 ### Changed
 
 - **`@types/js-yaml` removed; js-yaml 5 migration complete** (closes #391) — with
-	js-yaml 5.2.2 in (#843) the package ships its own declarations, so the stub
-	types dev-dependency is gone and the lockfile regenerated. This completes the
-	v5 migration started with the namespace-import compatibility pass below.
+ js-yaml 5.2.2 in (#843) the package ships its own declarations, so the stub
+ types dev-dependency is gone and the lockfile regenerated. This completes the
+ v5 migration started with the namespace-import compatibility pass below.
 
 - **`js-yaml` imports are compatible with v5** (refs #391, #843) — use the
-	package's namespace exports so the central accessor and YAML rule tooling work
-	with both the current v4 dependency and the upcoming v5 release. `@types/js-yaml`
-	remains temporarily because js-yaml 4.3.0 needs its declarations; remove it
-	with the v5 Dependabot upgrade once the bundled declarations are active.
+ package's namespace exports so the central accessor and YAML rule tooling work
+ with both the current v4 dependency and the upcoming v5 release. `@types/js-yaml`
+ remains temporarily because js-yaml 4.3.0 needs its declarations; remove it
+ with the v5 Dependabot upgrade once the bundled declarations are active.
 
 - **`build:dist` now compiles with TypeScript 7.0.2** (refs #809) — the dist emit pin moves from `typescript@6` to the same major as the dev dependency (#600); emitted output was verified byte-identical across all 328 files before the bump.
 
@@ -1154,17 +2638,17 @@ All notable changes to pi-lens will be documented in this file.
 - **Missing tree-sitter defect-class metadata is now covered** (refs #863) — loop-termination and `finally` control-flow rules now declare their taxonomy classes, keeping the rule audit complete.
 
 - **MCP smoke deadlines scale under CI load (refs #860)** — the shared MCP
-	test harness keeps its 20s local default, accepts the
-	`PI_LENS_TEST_TIMEOUT_SCALE` multiplier, and the analyze-graph smoke pays
-	server startup through a throwaway health call before its assertions.
+ test harness keeps its 20s local default, accepts the
+ `PI_LENS_TEST_TIMEOUT_SCALE` multiplier, and the analyze-graph smoke pays
+ server startup through a throwaway health call before its assertions.
 
 - **TypeScript 7 compatibility fixes (refs #809)** — narrowed ast-grep search test details and made the LSP `workspace/applyEdit` response overload-compatible, unblocking Dependabot PR #600.
 
 - **ast-grep NAPI fallback now runs TSX-tagged rules and reports unsupported-language skips** (refs #282) — `.tsx` files use the `tsx` grammar for rule-language scoping, preserving the exact TypeScript/JavaScript twin behavior from #657; rules for languages the fallback cannot evaluate are logged once per rule instead of disappearing as zero matches.
 
 - **CSS server root-policy coverage is hermetic on Windows** (refs #855) — the
-	server-policy fixture now pins its nearest `package.json` inside the temporary
-	workspace, so a marker in the host user's profile cannot change the result.
+ server-policy fixture now pins its nearest `package.json` inside the temporary
+ workspace, so a marker in the host user's profile cannot change the result.
 
 - **Multi-client LSP shutdown no longer serializes the grace-period tail** (#851) — retiring clients now tear down concurrently while generation handoff still waits for every client to settle; instance-registry child removals serialize their read-modify-write without serializing process kills.
 
@@ -1368,6 +2852,8 @@ All notable changes to pi-lens will be documented in this file.
 - **`fact-rules` diagnostics now stamp `tool: "fact-rules"` instead of their own rule id, fixing scattered turn-summary grouping** (#578) — `clients/dispatch/types.ts`'s `Diagnostic` contract documents `tool` as "which runner produced this" and `rule` as "the specific check within it"; `ast-grep`'s runner follows it correctly (one `tool: "ast-grep"` value shared across every pattern), but all 13 rules under `clients/dispatch/rules/*.ts` (the `fact-rules` runner) stamped their own rule id into `tool` instead (`{ tool: "high-fan-out", rule: "high-fan-out" }`), so `clients/turn-summary.ts`'s collapsed one-liner — which groups by `event.tool` — scattered N fact-rule findings into N separate per-rule-name buckets instead of one clean `fact-rules N` bucket like every other runner. Fixed at the emission source in all 13 files (`async-noise.ts`, `async-unnecessary-wrapper.ts`, `cors-wildcard.ts`, `error-obscuring.ts`, `error-swallowing.ts`, `high-complexity.ts`, `high-fan-out.ts`, `high-import-coupling.ts`, `missing-error-propagation.ts`, `no-commented-credentials.ts`, `pass-through-wrappers.ts`, `placeholder-comments.ts`, `unsafe-boundary.ts`) — `rule` is untouched, so `detectFactRuleId` (`clients/dispatch/integration.ts`, rule-first with an id-prefix fallback) and `code-quality-warnings.ts`'s `warning.rule ?? warning.tool` grouping both keep resolving to the specific rule id. Also closed a latent gap the fix surfaced: `error-obscuring.ts` and `error-swallowing.ts` had no `rule` field at all (only `tool` carried the rule id), which would have made `code-quality-warnings.ts`'s `rule ?? tool` fallback collapse them into `"fact-rules"` too post-fix — both now set `rule` explicitly, matching the other 11 rules' existing shape. New test in `tests/clients/turn-summary.test.ts` constructs three fact-rule diagnostics with distinct `rule` values sharing `tool: "fact-rules"` and asserts they collapse into a single `fact-rules 3` bucket via `formatTurnSummaryLine`.
 - **`clientScope: "all"` (the standalone `lsp_diagnostics` tool and `lens_diagnostics_full`) now gets per-server-aware diagnostics timeouts instead of one flat cap for every spawned server** (#573, found investigating the #570 incident: a 150-file `lens_diagnostics_full` scan took 114s and saturated the TypeScript LSP server) — `LSPService.touchFile` (`clients/lsp/index.ts`) already computed a `perServerTimeout` that reads each server's own `aggregateWaitMs` budget from `server-strategies.ts` (TS ~1s, rust-analyzer 3s, opengrep 3.5s, …), but only wired it up for the single-server `"primary"` hot path (#203) and, later, `clientScope: "with-auxiliary"` (#242). `clientScope: "all"` fell through to the pre-#203 flat `callerCap ?? modeFloor` branch — a leftover from #203 explicitly deferring the "full/cascade path," never revisited when #242 added per-server budgeting for auxiliaries. Every server (fast primary, slow auxiliary) was held to one shared number, either wasting time on a fast server capped to a slow auxiliary's ceiling (multiplied across a full-workspace scan) or starving a slow auxiliary of the time its own strategy says it needs. Fix: `clientScope === "all"` is now included alongside `"with-auxiliary"` in the `perServerTimeout` branch, so each spawned server's individual `waitForDiagnostics` call is bounded by `min(callerCap, ownStrategyBudget)` rather than the flat number. The touch's overall detection deadline (used only for the `lsp_diagnostics_timeout` latency log) is unchanged — it's still `Math.max(...)` over every spawned server's timeout, so "all" still waits for the slowest server before logging a timeout; nothing about auxiliary coverage regresses. `envWait` (`PI_LENS_LSP_DIAGNOSTICS_MAX_WAIT_MS`) and the existing `"primary"`/`"with-auxiliary"` behavior are untouched — this is purely additive coverage of the previously-flattened `"all"` case. Evaluated whether the richer live capability-matrix data (`getCapabilitySnapshots()`'s push/pull `mode`, `diagnosticProviderKind`) should feed `perServerTimeout` beyond what `server-strategies.ts` already encodes; found no case in the current budgeting logic it would improve (the existing `aggregateWaitMs`/`silentOnClean` table already differentiates push vs. pull servers where it matters) — left as a documented non-integration rather than added complexity; `cascade-tier.ts`'s existing capability-matrix consumption is a separate lane (cascade-lane skip-decision, not touch-time budgeting) and is unaffected. New tests in `tests/clients/lsp/service-touch-collect.test.ts` (`#573`): each server on the `"all"` scope gets its own caller-cap-bounded deadline rather than a shared flat number; a fast primary's own wait isn't held to a slow auxiliary's larger budget; a tight caller cap still binds every server as a ceiling; the env override still wins; and a regression guard confirming `"primary"`/`"with-auxiliary"` per-server behavior is unchanged.
 - **A timed-out LSP diagnostics check no longer presents as a confirmed-clean result and no longer erases known-good diagnostic state** (#570, found via live log analysis on a dogfooding project) — `LSPService.touchFile` (`clients/lsp/index.ts`) already tracked `notifyWriteTimedOut`/`diagnosticsTimedOut` per touch (logged to `lsp_touch_file` latency events) but never used them to gate anything: an inconclusive empty `collected` result was cached and returned identically to a genuinely server-confirmed empty result. Concretely, a timeout unconditionally deleted `lastKnownDiagnostics`/`lastKnownContentHash` for the file (so a hot-path consumer like `actionable-warnings` at `turn_end` would see "no known diagnostics" for a file that may still have real errors), and callers of `touchFile` (the per-edit dispatch runner, the `lsp_diagnostics` tool) had no way to distinguish "confirmed 0" from "timed out, defaulted to 0". Fix: `touchFile` now computes `inconclusive = notifyWriteTimedOut || diagnosticsTimedOut` (deliberately touch-wide/conservative — `collected` merges diagnostics across every spawned server, so even a partial per-server timeout means the merge may be incomplete) and (1) skips the `lastKnownDiagnostics` set-or-delete block entirely when inconclusive, leaving whatever was cached from the last confirmed check untouched; (2) flags the returned diagnostics array with a non-enumerable `inconclusive: true` bonus field (a plain array otherwise — existing callers that only read it as an array are unaffected) so callers that care can check `.inconclusive` without a breaking return-type change across `touchFile`'s ~10 production call sites. Two consumers wired: `clients/dispatch/runners/lsp.ts` (the per-edit path feeding the footer/widget via `recordDiagnostics`) now returns `status: "skipped"` (same treatment as "no LSP client was ready") instead of `"succeeded"` with an empty diagnostics list when the touch was inconclusive — this automatically feeds the existing dispatcher coverage-notice mechanism (`getCoverageNotice`), so an inconclusive edit is flagged the same way a fully-skipped one is. The standalone `lsp_diagnostics` tool (`tools/lsp-diagnostics.ts`, and its `pilens_lsp_diagnostics` MCP mirror, which reuses the same `createLspDiagnosticsTool()`) now threads the priming `touchFile`'s `inconclusive` flag through `collectDiagnosticsForFile`/`collectFileDiagnosticResult` and folds a timed-out check into the existing #533 "unconfirmed" bucket (never a bare "0 diagnostics"), while distinguishing WHY in the rendered text/compact-render/batch-and-directory tallies ("N timed out" vs. #533's "cannot confirm clean — push-only, silent-on-clean") via a new per-result `timedOut` field and `timedOutFiles`/`unconfirmedReasonClause` aggregation, rather than collapsing the two distinct reasons into one misleading message. The non-timeout path is unchanged: a genuinely fast, confirmed empty result still clears the cache and reports clean exactly as before. New tests: `tests/clients/lsp/service-touch-collect.test.ts` (`#570` describe block — a timed-out touch does NOT clear a prior confirmed non-empty `lastKnownDiagnostics` record; a confirmed non-timeout empty result still clears it as before), `tests/clients/dispatch/runners/runner-status-semantics.test.ts` (the lsp runner returns `"skipped"` on an inconclusive touch), `tests/tools/lsp-diagnostics.test.ts` (`#570` describe block — single-file/batch renders distinguish timed-out from confirmed-clean/silent-unconfirmed).
+- **Turn-end inline blockers now reconcile against disk — a blocker recorded for a file that has since been deleted can never be cleared (clearInlineBlockers only fires on a later dispatch of the same path, which a deleted file never gets), so it re-surfaced as an "Unresolved from this turn" blocker every turn and could keep the #1063 git guard conservative for the whole session (closes #1245, refs #279/#297/#298 reconcile-on-display discipline)** — RuntimeCoordinator._pendingInlineBlockers (a PathKeyedMap) is now reconciled against disk at every read: getInlineBlockersSnapshot() drops entries whose file no longer exists (the map is tiny and reads are bounded — once per turn_end / tool_result — so the probe cost is negligible), and the git guard's aggregate _gitGuardHasBlockers check reads the reconciled snapshot instead of the raw map size, so a deleted file's blocker no longer counts. The empty-vs-stale distinction is preserved: a blocker for a live file still gates exactly as before. The reconcile rebuilds the map from existence-checked survivors instead of deleting in place — delete-time key normalization lowercases a gone file's tail on Windows while set-time realpaths it, so a delete-based reconcile missed mixed-case filenames (a verified live gap, covered by a dedicated regression test). Regression tests record a blocker for a temp file (lowercase and mixed-case), delete the file, and assert the snapshot and git-guard status both clear (fail pre-fix).
+
 - **`lens_diagnostics` mode=full and `lsp_diagnostics` now reconcile fresh scan results into the footer/widget-state cache** (#571) — `recordDiagnostics` (`clients/widget-state.ts`), the sole writer to the footer's `allDiagnostics` store, previously had exactly one caller: `pipeline.ts`'s per-edit dispatch. A `lens_diagnostics` mode=full workspace scan or a standalone `lsp_diagnostics` check fetches fresh, authoritative diagnostics for files it examines but, until now, only reported that data back to the caller — never reconciled it into the footer. Practical consequence: if file A's diagnostics only became stale/fresh because of a change in file B (e.g. a shared interface), and A itself was never directly re-edited, the footer for A could stay stale indefinitely even after a scan proved the fresher truth. Both tools now call a new shared choke point, `clients/widget-state.ts`'s `reconcileScanDiagnostics(filePath, diagnostics, confirmed, writeIndex?)`, for each file they get a result for; `index.ts` injects the same monotonic `RuntimeCoordinator.nextWriteIndex()` source `pipeline.ts`'s per-edit writes draw from, so the existing `WriteOrderingGuard` (#555/#560) can't be clobbered by (or clobber) a concurrent, genuinely newer per-edit write for the same file. Guardrail: a result the check can't vouch for is never reconciled. `#570` landed in the same window as this fix (see above) and its `inconclusive` signal (`touchFile`'s non-enumerable `.inconclusive` flag, set when the notify write or the diagnostics wait itself timed out) is what BOTH tools now key off: `lsp_diagnostics` reuses it directly (threaded from `collectFileDiagnosticResult`/`runFileDiagnostics`'s own `timedOut`/`confirmation` fields), and `lens_diagnostics` mode=full's per-file LSP sweep (`runWorkspaceDiagnostics`) reads the same flag off each `touchFile` call's result and ORs it with its own outer per-file deadline/throw (`LSPWorkspaceDiagnosticResult.timedOut`) — either reason skips reconciliation for that file. No new batching/throttling was added for full-scan bursts — `recordDiagnostics`'s render trigger is a standard TUI dirty-flag request (already exercised by today's per-edit multi-file cascades without dedicated batching) and each write is independent/synchronous, so a scan touching many files behaves the same as N sequential per-edit writes already do. New tests: `tests/clients/widget-state.test.ts` (`reconcileScanDiagnostics`'s confirmed/unconfirmed gating and write-ordering-guard interaction), `tests/tools/lens-diagnostics.test.ts` and `tests/tools/lsp-diagnostics.test.ts` (each tool's confirmed-vs-timed-out/unconfirmed reconciliation wiring, including batch mode).
 - **Native TS7 no longer inherits classic typescript-language-server's `silentOnClean` cascade fast path** (#558, reverts #541) — PR #541 (2026-07-11) classified TS7's native `tsc --lsp --stdio` launch variant (PR #526) as `silentOnClean`, letting the cascade lane (`clients/lsp/cascade-tier.ts`) skip its in-lane diagnostic wait for native-ts7 edits on the strength of a clean-signal probe run that appeared to show it silent, same as classic. A 2026-07-12 dual-environment re-measurement (nightly CI on Linux and a live local run on Windows dev, same `typescript@7.0.2` both times) found native-ts7 now publishes 2 version-less diagnostic sets on the clean transition (`cleanPubs=2(v:0)`) — it is NOT silent, a drift from the #541 measurement, and skipping the wait could miss or delay real diagnostics on native-ts7 edits. `cascade-tier.ts`'s classifier again routes a `launchVariant === "native-ts7"` snapshot through the fail-safe full-wait path; `server-strategies.ts`'s `silentOnClean: true` for `"typescript"` is effectively classic-only again. Classic typescript-language-server is unaffected — re-confirmed silent (`cleanPubs=0(v:0)`) in the same run. `scripts/probe-clean-signal.mjs`'s nightly drift check no longer routes native-ts7 rows through classic's shared marker; it now compares them against an explicit `false` expectation, so a future TS7 build that goes silent again surfaces as a `silent-not-marked` signal instead of being silently skipped.
 - **LSP diagnostics no longer briefly cache stale results after rapid edits** — `textDocument/publishDiagnostics` pushes were written into the diagnostics cache (`pushDiagnostics`) unconditionally, even when the server's own reported `version` field showed the push was computed against an EARLIER edit than the one currently in flight (e.g. the server was still finishing analysis of edit N when edit N+1 already landed). `isVersionStale()` (`clientWaitForDiagnostics`'s staleness check) only gated whether a diagnostics *wait* resolved early — it was never consulted by the plain read path (`client.getDiagnostics()`/`getAllDiagnostics()`/`pruneDiagnostics()`), so a late push could get cached and served as "current" until the next genuinely fresh push overwrote it: diagnostics would transiently show stale results right after a rapid edit, then self-correct a moment later once real analysis caught up. The `publishDiagnostics` handler in `clients/lsp/client.ts` now drops a push before it reaches the cache (no `pushDiagnostics.set`, no `diagnosticsVersion` bump, no `diagnostics` event emit) whenever the push reports a version that's behind the currently-tracked document version for that path — checked at write time (after the debounce timer fires, not at notification-receipt time) so a push that arrives fresh but whose debounce window straddles a later edit is still caught. Version-less servers (no `version` field reported) are unaffected — that remains an intentional, documented tradeoff, unchanged by this fix. A dropped push correctly emits nothing, so a pending `clientWaitForDiagnostics` call still falls through to its other resolution paths (a later genuinely-fresh push, or the existing timeout backstop) rather than resolving on stale data. Deliberately out of scope, left as known follow-ups: the pull-diagnostics path (`clientRequestPullDiagnostics`/`clientRequestWorkspaceDiagnostics`) has no version stamp to compare against in this codebase's current handling, so nothing analogous is applied there; and `diagnosticsVersion` remains a single global counter rather than per-path, so an unrelated path's fresh push can still satisfy a wait baselined on this path's version — both are separate, larger-blast-radius changes.