# Changelog All notable changes to pi-lens will be documented in this file. ## [Unreleased] ### Added ### Changed ### Deprecated ### Removed ### Fixed ### Security ## [4.1.3] - 2026-08-28 ### Added - **Record build identity at session start (refs #1775)** — `sessionstart.log` now logs one bounded line per session start with the serving checkout's commit hash, entry-file mtime, and package version, derived from the running build's own files rather than `process.cwd()`. The dirty flag is deferred (would require a spawn on the session-start hot path); see the issue for the remainder. - **Rerun externally killed CI Unit tests once (refs #2042)** — a completed CI run now classifies the failed Unit-tests log and reruns only failed jobs when the verdict is `infra-kill`. A per-head-SHA marker and the workflow run-attempt gate prevent rerun loops, while classification errors produce an explicit PR comment. - **Recover starved CI runs and merge train-approved PRs (closes #2184, closes #2185)** — the merge-train warden classifies every open PR head as runs-concluded-normally, starved-run, absent-run, in-progress, or unknown, re-runs a starved run once, and comments when GitHub drops a dispatch; a new label-gated merge lane lands a `train:approved` PR only when both required checks conclude success on its exact current head. - **Enable Kotlin structural linting (refs #2198)** — Add eight VTCode-derived Kotlin ast-grep rules (`kotlin-no-lateinit`, `kotlin-no-nullable-boolean`, `kotlin-no-println`, `kotlin-no-unnecessary-let`, `kotlin-no-unsafe-cast`, `kotlin-no-var`, `kotlin-prefer-data-class`, `kotlin-prefer-is-empty`). Kotlin delivers through the ast-grep CLI/LSP lane, because `@ast-grep/napi` 0.45.1 ships no Kotlin grammar. - **Enable C/C++ memory and I/O idiom rules (refs #2201)** — Add three VTCode-derived rules: `c-no-malloc-free`, `cpp-no-malloc-free`, `cpp-no-printf`. All detection-only, at `severity: warning`, and distinct from CodeRabbit's existing C/C++ security rules. - **Classify a red Unit tests run as infra-kill, infra-net, or real (refs #2103)** — `scripts/classify-ci-failure.mjs` reads a failed job's log, tells a SIGKILL/exit-137 kill (with or without the `with-memory-watch.mjs` wrapper surviving to report it) and a DNS/network failure apart from a genuine assertion failure, posts one sticky PR comment naming the verdict, and reruns the failed jobs once per SHA when the verdict is infra. Every recognized real-failure shape (a FAIL block, an inline test-failure marker, a file-level collection error, or the overall failed-test tally) wins over any infra signal in the same log, and an unrecognized shape defaults to real rather than infra — the classifier is only as good as the shapes it recognizes, so treat "real" as the safe default, not an absolute guarantee against every possible log shape. The "once per SHA" rerun guard is once per SEQUENTIAL invocation, not across concurrency: concurrent invocations for the same SHA may each attempt a rerun (GitHub answers a duplicate with 403, which the marker records as `failed:403` and a later invocation can retry). - **Port five codemod gallery candidates (refs #2195)** - add Python `Optional` detection, generator-expression, Ruby symbol-to-proc, Rust character-index, and constrained JSX SVG-attribute rules. Semantic rewrites remain detection-only; guarded Python and Ruby rewrites expose fixes. - **Enable Java structural linting (refs #2197)** — Add four VTCode-derived Java rules to the ast-grep CLI/LSP lane. The NAPI runner stays limited to its bundled grammars, because `@ast-grep/napi` 0.45.1 ships no Java grammar. - **Port VTCode's `no-important` CSS rule (closes #2199)** — flags `!important` declarations as a detection-only warning; a safe fix would need to know which selector should win, which the rule cannot infer. CSS and HTML roots are scoped in the napi fallback so language-tagged rules do not scan unrelated parsed roots. - **Port 5 VTCode Go idiom rules (closes #2200)** — `go-no-fmt-println`, `go-no-panic-in-lib`, `go-no-underscore-func-name`, `go-prefer-errors-is`, and `go-prefer-string-builder` flag `fmt.Println`-family calls, library `panic()`, snake_case function names, direct error comparison, and repeated string concatenation. All five ship detection-only at their triaged severity (warning for `no-fmt-println`/`no-panic-in-lib`, hint for the rest) — each rewrite needs project or call-site context ast-grep cannot verify, so no `fix:` ships. The `+=` arm of `go-prefer-string-builder` is limited to string-literal operands because ast-grep has no type information. `go-no-global-variable` is excluded per the #2195 triage: valid package globals (constants, synchronization primitives) make it too noisy without project-specific policy. - **Guard a shared checkout against branch switches that destroy another session's work (refs #2007)** — a new opt-in `--lens-checkout-guard` (`guard.sharedCheckout=true`) declines `git checkout`, `switch`, `restore`, `reset --hard`, `stash`, `clean`, `merge`, `rebase`, `pull`, `cherry-pick`, and `revert` when the checkout has uncommitted work and another live pi-lens session is registered on the same root. The refusal names the peer pids and tells you to commit or take a dedicated worktree, rather than moving anyone's work behind their back. Command classification reuses the existing git-guard shell analysis; peer liveness reuses the instance registry. > Refs #2007 ### Changed - **Split `loop_block` into compute and non-CPU stalls, and name the sweep that caused one (refs #1980, #1723)** — every `loop_block` record now carries `stallClass` (`below-floor`, `cpu-accounted`, `non-cpu-stall`, `system-stall`) and `cpuCoverageRatio`, derived from the `windowCpuMs` that has sat unread beside `durationMs` since #1122. Nine of sixteen genuine 5s+ blocks in a 23h window burned less CPU than the block lasted; those now read as parked, not as work. `suspectSystemStall` is unchanged. The LSP workspace-diagnostics sweep's per-file touch is also bracketed now, so a block inside it names `lsp_workspace_diagnostics_touch` instead of arriving anonymous. - **Cut the word-index per-edit seam's longest synchronous stretch (refs #2067)** — the cascade and MCP-analyze seams now replace a document through the cooperative primitive, serialized through the index's own operation queue, instead of holding the event loop for the whole replacement. On a 2,829-document, 2.38M-posting corpus the longest synchronous stretch on a large document drops about 3x. Cooperative removal staging now filters each token's postings with the same packed primitive the synchronous path uses, dropping a clock read per posting element. Search results and BM25 scores are unchanged. - **Bound memory accounting (refs #2132, #2114)** — Add measured byte estimates for review-graph and dispatch-cache residency to `memory_sample`, and keep the word-index persistence hook visible in sampler coverage. #2132 criterion 3 remains undelivered; the `runtime.wordIndex` to `memory_sample` seam can still report `wordIndex:null` and remains a named follow-up. - **Classify merge-train pagination truncation (closes #2134)** — the warden reports GraphQL pull-request pagination truncation instead of treating a partial population as complete. - **Gate word-index arena recompaction on a share of the vocabulary (refs #2246)** — the flat 64-store recompaction threshold was crossed by every edit, because one document replacement raises the backing-store estimate by the edited document's distinct-token count. The gate is now 10% of the live vocabulary above a 64-store floor, so fragmentation accumulates proportionally to the index. On a 2,844-document, 2.4M-posting corpus, 300 sequential edits recompact 14 times instead of 299, the per-edit cooperative block drops from mean 32.0 ms to 12.4 ms, and peak resident memory is unchanged (the recompaction share of per-edit CPU falls from 23% to 4%). Small corpora keep the pre-change behaviour: the floor governs any index whose vocabulary is under 640 tokens. - **Convert the word-index per-edit occupancy guard to a load-invariant work count (refs #2254)** — the per-edit seam's occupancy bound was a wall-clock max-block over a 401-document fixture with `retry: 2`, so it was both flaky and a noisy neighbour in the timing-sensitive test lane. It now asserts the seam's cooperative replacement reads the clock a number of times bounded by the old document's distinct tokens, not by the posting elements it walks, which is deterministic and invariant to runner load. The guard leaves the timing-sensitive lane, and that lane returns to `maxWorkers: 2` now that its one heavy neighbour is gone. The shared `countClockReads` helper moves to `tests/support/perf-harness.ts` so the incremental test and the seam test read one implementation. - **Weekly stale-issue report now flags missing priority labels (refs #1676)** — the scheduled detector's report on #1323 adds a Priority label coverage section, listing open issues with zero `priority:*` labels and open issues with more than one. Advisory only; the job still never edits an issue. - **Enforce client dependency boundaries and cycles in CI (refs #1844)** — dependency-cruiser now rejects client import cycles, declared leaf imports, and unapproved additions to the session-start eager graph. - **Add six test-authoring screens to AGENTS.md (refs #1829)** — Contributor doctrine now names the six ways a green test can assert nothing, each with its screen, a real PR example, and a detection step. - **Reorganize AGENTS.md for retrieval (refs #1829)** — a task-type index and reading modes up front, the scattered invariant paragraphs pooled into a grouped "Standing invariants" section, placement rules that end top-prepend and tail-append conflicts, the stale version section dissolved (CHANGELOG.md owns versions), and a small HISTORY.md for decision-inert records. Every invariant paragraph preserved verbatim. - **Contributor and reviewer discipline harvested from six external skill sets plus the 2026-08-26 arc** — AGENTS.md gains the minimalism ladder (climb before writing: exists → reuse → stdlib → dep → one line → minimum), a review materiality bar (no stylistic/hypothetical/line-count findings, nothing a required CI check already fails on, spec-vs-standards axes reported separately, restructure insights route to issues), the deletion test on consolidation verdicts, the exit-137 judgment recipe, and the mechanical-versus-intent rule for maintainer trailing commits; the investigator playbook gains a loop-first diagnosis discipline; the fixer playbook gains commit-before-checkout-proofs and the verbatim-evidence rule; the reviewer playbook gains the quoted-evidence audit and treats fix rounds as fresh PRs (refs #2128). - **PRs touching tests now carry a Test assessment, and the authoring screens grow to ten** — per touched test file, state what it uniquely pins and what became redundant; removal requires a named surviving test to red on the same mutations. The PR body lint enforces the section (advisory) when the PR touches `tests/`; candidates not deleted in-PR go to the corpus value ledger (#2123). AGENTS.md's test-authoring screens gain four classic vacuity shapes: all-mocks, not-throw-as-sole-assertion, implementation mirror, and snapshot-as-behavior (with the characterization-baseline carve-out). - **Name and pin the files-touched bus seam (closes #1966)** — Document the two publisher modules, the agent-nudge subscriber, payload and delivery contract, and outcome-level observability; add a source conformance test that fails when the bus surface changes without updating the declaration. - **Unify the pinned npm version across workflows (#2051)** — ci.yml and release.yml both pin npm 11.18.0 so a single lockfile-writer version governs CI and release installs. - **Single-flight availability probes (refs #2131)** — concurrent consumers now share one tool/root probe, joined decisions are observable, and budget overruns enter the bounded degradation ledger. - **Concise zero-read recovery (closes #2335)** — The read guard now delivers its edit-without-read instruction as a single paragraph instead of a three-paragraph block. The 🔄 RETRYABLE marker and the "in this conversation" scope are unchanged. - **Memoize compiled gitignore globs (closes #1976)** — Reuse compiled ignore patterns for each matcher instance, reducing the measured compile count from 500 to ≤6. - **Persist word-index changes incrementally off the hot path (refs #2068)** — packed posting lanes now reuse cached wire segments for untouched documents, so a per-edit persist rebuilds only dirty document contributions. Dirty files resolve through one wire-slot map, and each affected token lane flattens once per persist while the existing snapshot worker handles stringify and gzip. - **Shrink the word index's resident footprint by 4.6x (closes #2069)** — Postings and the forward index now live in packed `Int32Array` lanes over a dense file-id space instead of one boxed `{ file, line }` object per posting. On pi-lens's own 2,682-document tree the index measures 32.7 MB, down from 151.6 MB, and 15.1 bytes per posting entry, down from 70.2. Against the 186.6 MB the issue records before posting interning landed, the reduction is 5.7x. Search results, the persisted snapshot format, and incremental refresh behaviour are unchanged. The `full_rebuild`, `incremental_refresh`, `cold_build`, and `persist_succeeded` records in `word-index.log` gained a `residentBytes` field, and `memory_sample` gained `postingEntries` and `residentBytes`, so a heap census can be reconciled from the logs. - **Review-graph one-file rebuild (refs #2074)** — the incremental rebuild now reads the graph's own adjacency indexes instead of rescanning every edge. Restoring preserved incoming edges and reading a changed file's import targets both became bucket lookups, and the derived indexes stay live through the update instead of being rebuilt at the end. On a 1,600-file fixture a one-file rebuild drops from 48.0 ms to 33.6 ms median, with edge-metadata comparisons down from 9,600 to 4 and edge visits down from 19,200 to 8. The same fix makes `existedBefore` report the truth, which unblocks reverse-dependency index reuse on every incremental build. ### Fixed - **Identity-guard seven more in-flight promise caches against ABA eviction (refs #1968)** — `SecurityScanClient.dedupeScan` (gitleaks/trivy/govulncheck), `JscpdClient`, `DependencyChecker`'s per-file and per-project caches, the MCP Stop-hook's `runTurnEndForIpc`, `initLSPConfig`, and `ensureTool`'s per-tool install map all cleared their in-flight entry with a bare delete-by-key, same shape as the dead-code/knip sites #1968 already fixed. A late-settling run could evict a live successor a second writer registered under the same key, causing the next caller to start a duplicate scan/check/install. All seven now delete only when the map still holds their own promise. One sibling, `ast-grep`'s shared availability probe (`runner-helpers.ts`), was reachable TODAY (not latent): a session-boundary reset is itself the second writer, so the bug could fire in production, not only after a future code change. - **Stop the CI kill record from blaming memory it never ran out of (refs #2042)** — the `[mem-watch]` verdict asserted "the OS reclaimed memory" for every exit-137, including three real kills whose own low-water mark showed 13.0-13.3 GB of 16 GB still available. It now classifies from its numbers, emits a distinct `KILLED WITH HEADROOM` verdict when the box had room, and names the pid it was watching. A new failure-gated CI step captures the kernel's own `dmesg` and `systemd-oomd` records, so the next occurrence names the signal's sender. - **Re-resolve a runner-detection alias probed before its symlink existed (closes #2077)** — `TestRunnerClient` no longer memoizes a project root whose canonicalization failed, so an alias first probed while it was still missing now converges to the real root's runner verdict on the next probe instead of serving the fallback key's stale "no runner" answer for the client's whole life. Resolved spellings are memoized exactly as before, so the hot path is unchanged. - **Recompact churned word-index arenas (refs #2117)** — incremental replacements now recompact the posting arena once churn passes 64 backing stores. The per-edit gate is O(1) and the cooperative copy is serialized through the index's async queue and safe against a concurrent edit, so it cannot corrupt postings or stall an edit. Resident-byte estimates include abandoned arena slack, and the bounded refresh record carries before-and-after bytes and store counts. - **Dedupe review-graph edges after deferred symbol resolution (closes #2127)** — same-batch rebuilds no longer retain duplicate calls or references edges when placeholders converge on real symbols. - **Report every root a host serves in `pilens_health` (refs #2130)** — the resource footprint projected one scalar `projectRoot` per instance, so a host also serving a subagent's temp worktree read as single-rooted there while `instances.json` listed both. Each `resourceFootprint.perInstance` entry now carries `projectRoots`, resolved through `getInstanceRoots` (the single reader the shared-checkout guard already uses), with the pinned primary still in `projectRoot` for existing consumers. - **Count every LSP client, and stop leaking a subagent's temp root (refs #2130)** — `memory_sample.subsystems.lsp.clients` now counts clients across every module evaluation, so a host serving a secondary root no longer reports `clients: 1` beside `lspChildCount: 2`. `deregisterInstanceRoot` shares the registry mutation tail, so a short-lived subagent can no longer remove its root before its own queued add lands and leave the temp root in `instances.json` for the rest of the host's life. A host entry synthesized from an `lsp-fallback` guess now yields its primary slot to the session's real root instead of pinning the guess forever. - **Stamp classifiedBy on ok-path availability decisions (refs #2131)** — seven `logAvailabilityDecision` success-arm calls (biome, dead-code, formatters, jvm-runtime, package-manager, zizmor) omitted `classifiedBy`, so a `cause: "ok"` row could not be attributed to a probe or a caller-asserted repair from the log alone. All seven now stamp `"probe"` for a direct probe success or `"caller"` for an install/join-repaired one, matching their sibling failure arms. A sweep test pins every `cause: "ok"` emit site so the gap cannot recur unnoticed. - **Normalize review-graph.log's cwd to one form (closes #2141)** — `logReviewGraph` and `logWordIndex` now normalize `cwd` at their single emit seam, so the same project root no longer appears as both `C:\...\pi-free` and `C:/.../pi-free` in the same log. - **Repair escaped-newline flattened PR bodies in body lint (refs #2145)** — a body can arrive with the literal two-character sequence `\n` (or `\r\n`) standing in for a real line break, the sibling of the space-flattening shape #2149 already repairs. `detectEscapedNewlineBody`/`repairEscapedNewlineBody` restore it losslessly, but refuse outright when the body carries a fenced code block: a flattened fence's own delimiters can no longer be told apart from genuine content, so fence-safe repair stays deferred as recorded on the issue. - **Stop duplicate merge-train warden actions (closes #2150)** — the warden stops on a non-advancing GraphQL cursor and deduplicates PR records before applying actions. - **Bound language-server verification output (refs #2169)** — verification retains at most 64 KiB of child output with head-and-tail retention, so a late transport-required line can rescue a valid LSP probe. A truncated verification records one bounded degradation. - **Match the merge lane to live repository state (refs #2185)** — the lane updates a green branch that is behind instead of attempting a merge master protection would refuse, reads the `(advisory)` name suffix this repository actually uses, resolves duplicate check names to the newest run, requires the `train:approved` label to come from an approver, and deduplicates its merge-failure comment. - **Stop a routine paging repeat from reddening the merge-train warden (refs #2192)** — the warden's PR reader orders by `UPDATED_AT`, so a PR updated mid-pagination lands on the next page too. That boundary repeat was recorded as a fatal error, once per repeated node, so a fully shifted window could emit up to 200 identical red lines in one 10-minute run. It is now one record per page naming the count, classified by cursor: a repeat with an advancing cursor is benign, a repeat with a stalled cursor stays fatal because it is real truncation. `fetchOpenPullRequests` returns `{ message, benign }` records, so the warden and the merge lane read one classification instead of each deciding for itself. - **Correct the Java rule set's accumulator and raw-type detection (refs #2197)** — `no-string-concat-in-loop` now requires the accumulator to be a String, so it stops firing on numeric accumulation and starts catching `s += x`. `no-raw-types` skips `instanceof` and `.class`, which have no parameterized form, and reports raw types nested in type arguments. - **Deflake the output-cap tail-retention test (refs #2197)** — Let the child ignore SIGTERM so the cap's kill cannot settle it before it emits its last line. On POSIX a child's pipe writes are asynchronous, so the cap kill could destroy queued output the assertion needed. - **Move the dirty-fraction word-index guard off wall clock (refs #2202)** — the incremental word-index occupancy test asserted a same-run timing ratio (`dirty=750 ms < fullMs * 1.5`). Review replicated it 20x under 57-94% CPU load and measured a 0.436x-3.863x spread, wider than the 2x regression the guard exists to catch, and found `retry: 2` only escaped a calibrated 2x-work injection about two-thirds of the time. `serializeWordIndex` now records, per call, how many tokens it re-flattened and whether it took the incremental or full-rebuild path (`getLastWordIndexSerializeWork`, test-only). The guard asserts on that count directly: no timer, no retry, no runner-load dependence, and it fails deterministically on a synthetic work-doubling regression. - **Fix `playground-verify-rule.mjs` matching the wrong source (closes #2208)** — the harness wrote a caller's `--code` into the upstream ast-grep playground's `query` field, which only feeds its Pattern mode. Config mode (what this harness always uses) matches against `state.source` instead, so the URL hash carried no source and the playground silently fell back to its own hardcoded sample. Every run graded that fixed sample, not the caller's code, so `matches` never reflected the fixture under test. `source` now carries the code; a rule + known-matching snippet reports a real match count instead of a silent 0. Also adds a scrape-side sentinel that catches the same failure mode recurring through upstream schema drift alone (e.g. a future `state.source` rename), and fixes the reported match `lines` clamping to the match count instead of the source's own line count. - **Run the ast-grep in-process fallback on every JS/TS module extension, and record the languages it cannot serve (closes #2215)** — `.mjs`, `.cjs`, `.mts`, and `.cts` files reached the napi fallback and were dropped without running a single rule, because its extension allowlist was hand-maintained beside three other lists that described the same thing. All four now derive from one language matrix, so the ~470-rule catalog reaches those files. The twelve catalog languages `@ast-grep/napi` bundles no grammar for (python, java, go, ruby, cpp, rust, csharp, c, kotlin, swift, php, scala — 247 of the 470 rules) are recorded as ast-grep LSP/CLI-only rather than silently skipped, the skip telemetry now names each language's delivery route, and a file admitted for a grammar the loaded addon turns out not to have leaves an `ast-grep-napi-language-unavailable` degradation record instead of nothing. - **Derive the project scan's ast-grep kind per file instead of hard-coding jsts (closes #2217)** — The scanner passed the literal `"jsts"` to `evaluateAstGrepRules` for every napi-evaluated file, including `.css` and `.html`, so `suppressLinterOverlap` (and any future kind-gated ast-grep policy) evaluated non-JS files under a JS/TS linter-overlap decision. It also diverged from the per-edit dispatch path, which derives kind from `detectFileKind` — the same file could see two different kinds depending on which path evaluated it. The scan now calls `detectFileKind` (the shared `KIND_EXTENSIONS` resolver), matching the dispatch path exactly. - **Normalize the remaining NDJSON logger `filePath` fields (refs #2219, the #2141 class)** — `cascade.log`, `latency.log`, `read-guard.log`, `tree-sitter.log`, and `actionable-warnings.log` now normalize `filePath` once at each logger's single emit seam, so the same file no longer appears in two path forms across a log. Non-path sentinels (`""`, `""`, shell commands, coarse labels) mixed into the same field are left untouched instead of being resolved against the process cwd. - **Remove three real-timer races from tests that only pass under CPU contention (refs #2225, #2235, #2182)** — `safe-spawn.ts`'s cap-then-timeout/cap-then-abort tests raced a real child's stdout against a real 300ms timer (5/8 failures under 8 concurrent runs); they now mock the child so the cap trips before the timeout by construction, in a new `safe-spawn-cap-race.test.ts`. `spawn-timeout-cooldown.test.ts`'s markdownlint-fix guard paired real filesystem I/O with a heavy dynamic import inside vitest's 5000ms default, reproduced as a hard timeout under synthetic load; it now carries a 20s budget. `managed-tool-refresh-strategies.test.ts` had more instances of the dangling-promise-contamination shape #2216 first fixed for one test — a file-wide `vi.setConfig({ testTimeout: 20_000 })` replaces per-test patching. A residual shared-mutable-state race in the same file, independent of any timeout, is left open on #2182. - **Make a stale compiled `.js` beside a `tests/**/*.ts` file fail loudly (refs #2232)** — `tests/` is excluded from `npm run build`, so any `.js` sibling of a test-support `.ts` file is leftover residue from an earlier, differently configured local compile. Vitest's import specifiers end in `.js`, so that residue silently wins module resolution over the real source, running stale code with no warning. The build-freshness `globalSetup` now also flags this residue and aborts the run naming the file. - **Make the spawn-timeout cooldown regression test load-invariant (closes #2235)** — load the real pipeline during test-module setup so the 5000ms test budget measures cooldown behavior instead of contention during a heavy dynamic import. - **Bound the dispatch fact store (refs #2240)** — `FactStore`'s per-file records are now capped at 1024 with LRU eviction, so a several-hundred-file batch no longer retains one entry per distinct path until the heap is exhausted. The files being dispatched are pinned, so a background project walk cannot evict facts a live dispatch is still reading. - **Harden the dispatch fact-store pin against eviction (refs #2240)** — the debounced ast-grep warning scan is a dispatch entry point, but it never pinned its file or re-derived content, so a project walk in its 2-second window could evict `file.content` and make inline `pi-lens-ignore` suppressions silently stop applying. The scan now pins and re-derives like every other dispatch caller, via a new `beginDispatchFor` that pins WITHOUT clearing the file's already-fresh facts (the earlier clear-and-re-derive cost ~51ms of redundant re-parsing for a file already re-derived by the inline dispatch 2 seconds earlier). The pin is also released at dispatch completion, so the pin set tracks dispatches actually in flight rather than the last 16 files touched. Capacity-eviction telemetry is now labeled per store instead of one shared subject across all six production `FactStore` instances, so a session-start review-graph walk can no longer consume the dispatch store's once-per-session degradation record before a real dispatch runs. - **Bound retained FactStore content bytes (closes #2247)** — file-fact stores now evict least-recently-used records after retaining 64 MiB of UTF-8 `file.content`, as well as after 1,024 records. In-flight dispatch records remain pinned until settlement. A count-axis and a byte-axis eviction on the same store each get their own degradation record instead of sharing one dedupe key, and a pin whose content alone exceeds the byte budget stops evicting unpinned inserts instead of silently discarding every one of them, recording that state through its own degradation kind. - **Napi runner css/html admission (#2248)** — Route CSS and HTML files to the napi ast-grep runner when its bundled grammars support them. - **Anchor `.gitignore`'s scratch `test-*` patterns to the repo root (refs #2250)** — the unanchored `test-*.ts`/`.js`/`.py`/`.md`/`.sh`/`.mjs` rules matched the basename of any tracked file at any depth, silently hiding `clients/test-runner-client.ts` and several `tests/` files from `rg` and other ignore-respecting search tools. `git status` never flagged it because git still tracks the files. The patterns now only match scratch files dropped at the repo root, their original intent. - **Baseline the git-config contamination guard against pre-suite identity (refs #2251)** — the test-teardown guard no longer fails every local run for a maintainer whose real git identity happens to equal a fixture value (`user.name=t`, `user.email=t@t.local`). It snapshots the config before any test runs and flags only fixture values that appear during the run, so real contamination still fails loudly. - **Scope the playground source sentinel (refs #2253)** — the verifier now checks the caller's fixture inside the source pane's Monaco editor. A matching rule note in the config pane no longer masks upstream source drift. - **Bound every in-memory review-graph retention site (refs #2255, #2240)** — the live `ReviewGraph` grew with project size and had no size guard; only the persisted snapshot was capped. On a large repository it was the second unbounded dispatch store behind the multi-gigabyte OOM abort (`FactStore.fileFacts` was the first, bounded in #2243). Two sites retained a graph for the life of the process: the workspace cache and `session.reviewGraph` on a caller's FactStore, two of which are module-scope. Both now go through one memoized retention seam capped by estimated resident bytes (`PI_LENS_GRAPH_MAX_IN_MEMORY_BYTES`, default 512 MiB), evicting with the same centrality-ranked selection the snapshot uses. `memory_sample` counts every retention site instead of the cache alone, deduplicated by object identity, so the sample can no longer read clean while a full graph is resident. A trim never yields an empty graph, and a graph trimmed for size is now distinguished from one whose source walk was truncated: both report as partial, but only the size-trimmed one stays usable as an incremental base, so an over-budget repository is not forced into a full project walk every turn. That marker is process-local and never persisted. Each trim emits one bounded degradation record per workspace. - **Ast-grep YAML rule caches detect edited and nested files (closes #2262)** — the in-memory rules cache snapshots every YAML file with `mtimeMs` and size, re-checked at most once per 2-second cadence window. Editing an existing rule or adding a nested rule invalidates the cache even when the rule directory mtime stays unchanged; pickup lag is bounded by one cadence window. - **Topology-derived startup scan and language-profile memos re-arm with the workspace marker index at session start (closes #2263)** — `resetWorkspaceTopology()` walks one registered downstream-cache reset list, clearing `startupScanContextCache`, `languageProfileCache`, and tsconfig-path caches with the source index. Caches are cleared only at session start via the topology-reset registry; mid-session edits are not detected. - **Move three Java rules off an inert `files:` negation glob (fixes #2280)** — `no-raw-types`, `no-string-concat-in-loop`, and `no-system-out-println` used `files: ["**/*.java", "!**/test/**"]` to carve out test files, but ast-grep 0.45.1's `files:` field has no negation support, so the exclusion silently did nothing. All three now use the real `ignores:` field ast-grep's engine honors natively, restoring the test-file carve-out. - **Preserve latency logger exports in test mocks (refs #2281)** - **Detect different-size project-snapshot rewrites inside one mtime bucket (closes #2285)** — The authoritative in-process cache now validates both body mtime and size before serving its snapshot, so a hot project root cannot mask a different-length external write indefinitely. Same-size, same-mtime rewrites remain outside this metadata-only hot-path guarantee. - **Merge-train duplicate classification (#2289)** — The warden now treats a PR number repeated within one GraphQL page as malformed data and a fatal error. Genuine cross-page window slides remain benign notes. - **Add a size axis to five mtime-only content memos (closes #2300)** — The MCP warm-build staleness gate, the LSP diagnostic-binding content-hash memo, the workspace-diagnostics per-file freshness cache, the cross-process recent-touches watermark, and the installer's tool-path probe cache now all validate byte size alongside mtime, so an external rewrite landing in the same coarse-granularity mtime bucket with a different length is no longer served as unchanged. Every fix reuses a stat call already being made — no added per-edit I/O. - **Remove the redundant markdownlint autofix cooldown guard (closes #2301)** — `detectFileChangedAfterCommand` remains the single source of truth for autofix cooldowns, and its direct test owns that contract. - **ast-grep findings survive a silent auxiliary LSP (closes #2324)** — the napi fallback stays active until the ast-grep LSP completes its first diagnostic publication for the SPECIFIC FILE (not just anywhere on its client), closing the race where a sibling file's publication wrongly satisfied the gate. The fallback and the late-auxiliary delivery lane no longer both fire for the same file: a napi run consumes that file's pending late-auxiliary pair. The remaining narrow case — a server that published once but goes silent on a later touch of the same file — is now a bounded `aux-runner-findings-lost` degradation record instead of a silent drop. - Auto-repair clearly flattened pull request bodies before advisory lint validation. Repair only splits inline headings; duplicate or otherwise structurally inconsistent template headings refuse repair and preserve the original lint errors. - **Correct the vulture exit-code comment (closes #1765)** — The comment in `clients/dead-code-client.ts` now states the verified vulture 2.16 exit codes: 0 on a clean run, 3 with findings on stdout when dead code is found, and 1 with an error on stderr for invalid input or parse errors. - **Read-guard eviction paths now leave a trace (#1918)** — Whole-file eviction (file cap, idle timeout, external-delete cleanup) and the per-file edits-cap trim each emit a bounded, always-on `read-guard.log` record naming the file and which path evicted it, closing the gap #1915 left after fixing the record-cap path. - **Record formatter cache hits (closes #1940)** — Emit `formatter_selected` with `outcome: "hit"`, `reason: "cache"`, and `cached: true` on formatter detection cache hits, providing hit-rate observability with a single denominator in `latency.log`. - **Cap dependency-drift blocker re-serves (refs #1950)** — A demoted-but-confirmable inline blocker (`clients/blocker-freshness.ts`) now retires after 3 degraded deliveries with no re-run, instead of re-serving indefinitely. The retirement note says the record can still be confirmed by a fresh dispatch, distinct from #1944's past-EOF retirement, which means the finding is provably unconfirmable. - **Record message_end cache_usage attribution loss (closes #1956)** — A stale extension ctx now records a bounded `cache-usage-attribution-stale` ledger entry instead of silently writing the `cache_usage` row unattributed; the row still writes so provider token and cost data is never dropped. - **Gate nested LSP requests (closes #1971)** — Skip `workspace/willRenameFiles`, `workspace/didRenameFiles`, and `codeAction/resolve` unless the server registered them, matching each registration's scheme/glob/file-kind filters at the send boundary while preserving supported edits and unresolved-action fallbacks. - **Stop re-canonicalizing already-normalized dispatch paths (refs #2016)** — the dispatch context's `filePath`, `cwd`, and `projectRoot` are normalized once at construction, and seven downstream sites no longer pay a redundant `realpathSync` per dispatch. Scanner ids and the relative baseline key move to the cheap syntactic normalizer, which also fixes a key that resolved against the process working directory on Windows and stayed relative on Linux. - **Budget CI test workers against real memory, and name an OOM kill (refs #2042)** — Fork concurrency and the per-fork heap ceiling now come from one resolver that sizes them against the host's memory instead of two constants tuned on a dev host, and the CI suite runs under a memory watch that reports the low-water mark so exit 137 no longer reads as unattributable infrastructure noise. - **Retire deleted failed-first test targets (closes #2044)** — Test selection retires only confirmed-missing canonical paths with bounded work, then continues with valid failures or normal discovery. - **Bound markdownlint verification and preserve typed spawn failures (closes #2045)** — markdownlint-cli2 now verifies through its stdin mode without scanning project files, and verifier logs retain the effective check command and typed timeout or spawn failure kind. - **Canonicalize test-runner cache roots (refs #2048)** — Test-runner availability and Vitest glob caches now share project identity across path aliases, while positive runner verdicts expire when their supporting config disappears. - **Honor LSP file-operation filters (closes #2049)** — Send file rename requests and notifications only to servers whose validated scheme, glob, file/folder, and case filters match the renamed resource. - **Decline LSP roots outside every session project root (refs #2052)** — a file outside every initialized session cwd now receives an explicit outside-project-root skip and one bounded record per foreign root, instead of diagnostics computed under the wrong project context. The full sweep carries the skip into the unconfirmed lane, so a declined file is never reported or cached as clean. A process that initializes several project roots keeps serving all of them. > Refs #2052 - **Cover the whole failed-Git-integration family.** `git pull`, `git revert`, and `git am` now join merge, rebase, and cherry-pick when opaque recovery drops clean incoming index paths. Truncated `git status` output fails closed, and an undocumented porcelain status pair keeps its path instead of voiding recovery for every other file in the command. - **Make LSP spawn records count truthfully (closes #2064)** — `lsp_client_selected` reported `cold-spawn` for every caller that merely joined another caller's in-flight spawn, so the one metric that looked like a spawn count over-counted 3.0x in a 21.8 h field window, and one 29.3 s TypeScript spawn read as 39 spawns in 2 ms. The record now names the starter (`cold-spawn`, `spawn-failure`) apart from the joiners (`cold-spawn-joined`, `spawn-failure-joined`), on the same record with the same denominator. A new `lsp_server_spawned` latency record fires once per language-server process start for every server, so `latency.log` finally counts TypeScript spawns, which `lsp_launch_candidate_success` never covered. - **A crashed LSP client no longer pins its retained text forever (refs #2065)** — the client-count Set backing the incremental-text-retention telemetry only deregistered on a graceful shutdown; a crash (connection error, connection close, or an unexpected process exit) never removed the client, so its retained text stayed counted, and reachable, for the rest of the process lifetime. Deregistration now happens in the one place every death path already converges on, so a crash is cleaned up the same way a graceful shutdown is. The eviction scan that runs on every `didChange` past the retention cap no longer spreads and scans the full per-path map; it tracks text-bearing paths in their own recency-ordered auxiliary set instead, so the scan cost stays proportional to the 128-entry cap rather than to the number of open documents. That auxiliary set is now also cleared on `didClose`, closing a second, smaller instance of the same unbounded-per-path-store class: without it, a closed document that was never evicted by the cap left a stale entry behind on every open/close cycle. `pullGenerations`, a per-path pull-fan-out counter, is deliberately left uncleared on close, for the same reason the codebase already leaves `pullRequestSequences` uncleared: resetting it would let a stale in-flight pull's captured generation match the counter again after a close/reopen and be wrongly accepted. - **Incremental LSP document text is bounded and released on close (refs #2065)** — full text retained for incremental synchronization is capped at 128 paths and 64 MiB of UTF-16 data, evicts least-recently-sent paths, and is removed with the other per-document state on `didClose`. Periodic `memory_sample` records now expose retained entries and bytes. - **Per-send LSP document sync makes one JavaScript pass over the previous document instead of two, on `didChange` (refs #2066)** — the newline count behind `lsp_document_send`'s `contentLineCount` and the last-line position behind an Incremental `didChange` range now come from a single scan whose result rides on the existing per-path content-binding entry, so a change no longer splits the previous document into one substring per line to read one of them. Line-count semantics are unchanged: `contentLineCount` still counts `\n` only, while the range still treats `\r\n`, lone `\r`, and `\n` as terminators. The remainder of #2066 is its "one pass total" target: the #1095 sha256 content binding is a second, native full-document pass and still runs on every send. - **Intern word-index posting files (refs #2067)** — Per-edit document replacement now compares shared file identities instead of re-normalizing every posting element; build/refresh telemetry records posting-entry counts and per-edit replacement cost. This is the declared prerequisite for #2069's posting representation work. - **Nested `.gitignore` edits now refresh ignore verdicts (closes #2071)** — agent writes invalidate every cached project matcher containing the edited path, so its per-path memo cannot serve a verdict from an older ignore file. Root edits rebuild each affected matcher, while nested edits preserve compiled-glob reuse for sibling trees. - **Give nested ignore rules and path verdicts one freshness clock (closes #2071, closes #1976)** — a nested `.gitignore` edit no longer leaves two paths under the same rule disagreeing, and the ignore matcher stats a nested source once per cadence window instead of once per file. A 2000-file walk drops from 18,064 `statSync` calls (9.03 per file) to 192 (0.10 per file), and from 1,886 ms to 85-92 ms across runs. An externally edited nested ignore file is honored within one cadence window (2 s). - **Review-graph source-path normalization (refs #2072)** — reuse canonical paths across builds, remove redundant persist coverage normalization, and expose normalization and persist durations in telemetry. - **Clear outgoing idle-eviction timers on cache replacement (refs #2073)** — Review-graph, reverse-dependency, and authoritative project-snapshot cache replacements now release the prior entry's timer before installing the new entry, preventing one full payload from being retained per rebuild. Regression coverage asserts one live timer after twenty replacements for each cache family. - **Fail closed on truncated Git file lists.** Truncated `git ls-files` output now reports unavailable tracked and ignored sets instead of presenting partial sets as complete. - **Opaque-mutation exclusion counter overstated suppression (closes #2081)** — `excludedIncomingCount` incremented for every clean-index-only entry dropped by the failed-integration filter, even when the entry's mtime fell outside the recovery window and it was never going to be dispatched. It now counts an entry only when the mtime-freshness check would otherwise have included it, so the field means what its doc comment claims: dispatches actually prevented. Added a test asserting the `opaque_mutation_status_pair_unknown` latency record's emission and phase identity through the `logLatency` seam, alongside the existing `opaque_mutation_incoming_excluded` coverage — renaming either phase string now reds a test. - **PR-title checks now validate the live pull-request title (refs #2083)** — rerunning a failed check can recover after the title is fixed without requiring a new pull-request event. - **PR body lint now rejects unfilled templates and recognizes the fleet's section conventions (refs #1844)** — live body lookup uses the repository API endpoint with a bounded timeout and safe fallback. - **Read the live PR body in close-keyword syntax checks (refs #2086)** — Reruns now validate the edited PR body instead of replaying a stale event snapshot. - **Read the live PR body in close-keyword verification (refs #2086)** — a post-merge rerun of `--verify-merged` used to relint the closed-event payload's stale body and, in production, silently kept doing so because the workflow step never carried the `GITHUB_TOKEN` env var the live fetch needs. It now sets that var and fails the check loud on any fetch problem instead of falling back to stale data, so an edit that fixes or introduces a comma-separated close list is reliably seen on rerun. - **Close two named remainders from the #2088 sweep-floor fix (refs #2088)** — the sweep-floor meta-sweep now recognizes the `expect(x.length).toBe(0)` emptiness spelling (14 test files use it, previously invisible to the census), and `managed-tool-seam-coverage` gained a positive control on its `safeSpawnAsync(` detector so a regex that stops matching fails loud instead of reading as zero violations. - **Closed the managed-tool seam sweep's vacuous exemption (refs #2088)** — The meta-sweep exempted `managed-tool-seam-coverage.test.ts` with a false reason; the file walks `clients/` from a cwd-relative root and asserted zero violations with no floor, so blinding its walk to an empty array still passed. It now walks from a repo-root-derived path and carries its own scanned-files and detector-signal floors. Reworded two other exemption reasons that wrongly said "not a population sweep" when both carry their own hand-rolled floors. Added the `readdir` named-import spelling to the meta-sweep's enumeration regex, closing an async-walk evasion. Recalibrated the meta-sweep's `minFlagged` to the measured population (55) after the exemption-list growth made the prior figure stale. - **Governance sweeps now fail on empty populations (refs #2088)** — Added declared scan and finding floors, stale dynamic-runner checks, and a registered meta-sweep for hand-rolled governance scans. - **Tests that could not run reported as passed (closes #2089)** — Thirteen test bodies bare-returned before their first assertion, so Vitest counted them green while they asserted nothing. Each now skips visibly (`it.skipIf` or `ctx.skip(reason)`), the pnpm symlink case runs unguarded on every platform, and a new sweep over the whole `tests/` tree fails on the shape. - **Stop metrics-history's git probe from leaking stderr into the TUI (#2095)** — `getCurrentCommit()` now pipes `git rev-parse` stderr instead of inheriting it, so a failing probe reports "unknown" quietly instead of printing a raw `fatal:` line. The same fix applies to the LSP launcher's Windows registry PATH probe, the only other unguarded `execSync`/`execFileSync` call in the runtime. - Resolve metrics commit attribution against each target file's Git repository. (closes #2099) - **Truncated tool output is reported as truncated.** Several spawn sites (`git status` opaque recovery, oxlint, `helm lint`, `helm template`, and the shared-checkout working-tree probe) retained unbounded stdout and carried truncation guards that could never fire. Each now caps its output, and every truncation guard in the tree reads `truncatedByOutputCap` before failure or status handling. `safeSpawnAsync` now records `killedForOutputCap`, so callers handle cap termination without guessing from POSIX or Windows exit shapes. A run that hit the cap and then timed out or was interrupted still reports the timeout or abort. Also corrected the trivy scan, `sg` exec/scan, and ast-grep pattern validation. The shared runner ledger now says a tool was stopped at its output cap instead of blaming it for a kill pi-lens sent. - **Rename the CI classifier's kill label to infra-kill and read kernel evidence (refs #2103)** — every exit-137/SIGKILL kill used to post as `infra-oom` even with memory headroom; the classifier now labels it `infra-kill` and enriches the detail with the kernel kill-evidence step's dmesg/cgroup output already in the log. - **Fail loudly when the stale open-issues scan is truncated (closes #2104)** — the weekly detector proves exhaustion for the open-issue population, fails loudly when its safety bound is reached, and reports the scanned population. The master commit read remains a deliberately bounded recent window and reports commits beyond its detail cap. - Serialize overlapping per-path LSP `didChange` sends so Incremental payloads use the latest confirmed document content (closes #2113). - **Deferred runner results remain visible and actionable (refs #2122)** — Deferred runners now show a pending state at edit time, report failures at turn end, preserve freshness coverage, and bound handoff retention with degradation telemetry. - **Key session start and the host registry by project root (closes #2129, refs #2130)** — a subagent temp worktree no longer steals the process's primary session. Root identity is now an input to session-start classification, so a start in a different directory takes the reduced path instead of resetting the host's warm LSP fleet and re-running the whole startup battery over unchanged content. Two temp roots in one host previously cost about 50 seconds of opengrep and 53 seconds of word-index rebuild each, and drove host RSS from 290MB to 1.1GB in four minutes. The host registry entry in `instances.json` now holds a set of roots with the primary pinned, instead of one scalar every session start overwrote, so warm attach and the shared-checkout guard can see a peer working under any of its roots. The shared-checkout guard now confirms a peer against every root it serves, so a session working under a secondary root can no longer be missed and have its uncommitted work discarded. `memory_sample` carries the owning root and the distinct-root count of its live LSP clients, which makes a turn index attributable on a multi-root host. > Refs #2129, #2130 - **Scope availability probe flights per owner (refs #2131, refs #2140)** — Package-manager, dispatch, toolchain, checker, cwd, and security-scan availability owners now hold separate keyed flights, so an owner reset cannot tear down another owner’s probe. Release-managed binaries under `~/.pi-lens/bin` answer before PATH probing, and the resolved path reaches security scans. - **Resolve LSP-managed release binaries before PATH (refs #2140)** — Every GitHub-release-managed LSP server (clojure-lsp, cue, deno, expert, gleam, marksman, opengrep, rust-analyzer, taplo, terraform-ls, typos-lsp, zizmor, zls) now checks `~/.pi-lens/bin` before walking bare PATH candidates, same as the fast path PR #2148 already gave the CLI-scan side of opengrep/gitleaks/trivy/govulncheck. A managed binary with no PATH entry no longer ENOENTs a launch candidate before the installer step finds the same binary a moment later. For rust-analyzer and deno, this means a pi-lens-managed copy is now preferred over a developer-toolchain-managed one (rustup, `deno upgrade`) when both are present; the managed copy is kept from drifting too far via the existing 7-day managed-tool refresh cadence. - **Key process-unique state on `globalThis` so it survives a second module evaluation (refs #2146)** — pi evaluates the pi-lens module graph up to nine times per process, so the primary-session registration and the instance-registry mutation tail existed once per evaluation instead of once per process. The concurrent-session guard read an empty registration and ran the full session_start battery per subagent temp root, and concurrent read-modify-write cycles tore `instances.json`. Both now share one versioned process singleton, and `host_boot` records the evaluation ordinal. `session_shutdown` gained the same root discriminator `session_start` has, so a subagent's teardown no longer clears the shared registration and leaves the next subagent to run the full battery. - **Distinguish clean from absent auxiliary LSP results (closes #2151)** — Turn-end late-auxiliary harvesting now recognizes published clean results and retires stuck coverage pairs with bounded, reconciled telemetry. - **Adapt the first cold auxiliary wait to observed spawn cost (closes #2152)** — a cold auxiliary touch uses the larger of its declared wait and the server's last successful spawn duration plus a 500ms margin, capped at 8s. Warm touches retain the declared wait capped at 2s, and `PI_LENS_AUX_GRACE_MS` caps the budget (it never raises it). - **Identity-feeding sorts now use a code-unit comparator, not `localeCompare` (closes #2155, closes #2165)** — the availability-probe cache key in `runner-helpers.ts` sorted env entries with `localeCompare`, a locale-dependent comparator. Two processes (or one process under a changed locale) could order the same env set differently and mint different keys for identical state, causing a silent probe-dedupe miss. Fixed via a new shared `compareOrdinal` helper (`clients/string-utils.ts`), applied to every identity-feeding sort found in the class sweep: dependency-cycle and madge dedupe keys, review-graph signature/hash/cache keys, the Windows spawn cache key, the bounded-hash object-key order, the rule-cache content hash, the workspace-diagnostics scope key, the turn-end-findings signature, and the formatter-config signature. `localeCompare` sorts kept for user-facing display are left untouched. - **Share one LSP service across module evaluations (refs #2157)** — all evaluations now share one service, its generation handoff, workspace-sweep hold, and classic TypeScript repair guard through versioned process-singleton families. Incompatible live services shut down fast before replacement, and a secondary pipeline crash or a secondary session's idle-reset timer no longer tears down the primary fleet. - **Consumed `.gitignore` files refresh at matcher lookup (closes #2159)** — pi-lens detects external edits, git restores, and changes under ignored directories with a cadence-bounded freshness probe. - Use per-file diagnostic publication timestamps to distinguish a fresh clean primary LSP response from an absent response in the tsserver sync racer. - **Bound the stale-findings re-arm loop and count cap-evicted pairs (closes #2167, closes #2168)** — Late-auxiliary turn-end harvesting now caps a pair that keeps returning stale findings at `MAX_LATE_AUX_REARMS` re-arms, re-arms (instead of dropping) a pair after a transient probe-cache read failure, and counts a pending-coverage cap eviction with a dedicated `capEvicted` counter folded into the turn's reconciliation sum. - **Bound Svelte and Prisma language-server probes, and Vue's remaining dispatch-side budget (refs #2169, #2176)** — the Svelte and Prisma installer registry entries now carry their own cold-start `--version` verification ceilings (20s and 40s), matching real measured cold runs of 12.4s and up to 27.3s. Separately, Bash, JSON, Prisma, Vue, and Svelte language servers now raise the dispatch lsp-runner's 5-second cold-spawn wait floor to match their installer bounds, so a slow cold spawn cannot still read as unavailable after installer verification would have accepted it. - PR body repair keeps distinct numbered fix-round headings distinct, so legitimate multi-round bodies can be repaired while duplicate and corrupted headings remain protected. - **Preserve identity during concurrent instance registration (refs #2173)** — An adjacent O_EXCL lock serializes registry writers, reclaims stale ownership, and preserves session identity during child-first synthesis. - **Bound the Vue language-server verification probe (refs #2176)** — the managed Vue registry entry now gives its cold-start `--version` probe a 30-second per-tool ceiling, while all other tools retain the 10-second installer default. - **Migrate remaining Git-using smoke scripts to the scrubbed fixture environment (closes #2177)** — governance now detects fixture identity and path-exemption drift, and the JavaScript helper has direct wrapper coverage. - **Bound the JSON and Bash language-server verification probes (closes #2194)** — `bash-language-server` and `vscode-json-language-server` measured 9,667ms and 11,047ms cold `--version` starts with closed stdin, close enough to the 10-second installer default that host contention alone could trip a false verification degradation. Both now carry a 20-second `verificationTimeoutMs`, delivered through the managed-local, install, and refresh paths. The refresh delivery for the other five install strategies (pip, gem, github, maven, archive) is now covered by tests too, closing the gap the issue's follow-up comment flagged. - **Escalate workflow runs stuck queued (closes #2203)** — the merge-train warden classified a run that GitHub queued and never scheduled as `runs-in-progress` on every cycle forever, which read as healthy waiting. A tracked run that has executed zero steps for 60 minutes now classifies `stalled-run`: the warden names it in a PR comment, cancels it on the next cycle, and re-runs it once, bounded by GitHub's own `run_attempt`. A run with executed steps stays in progress however long it takes, and a cancellation the warden did not make is left alone. - **Stamp classifiedBy on every availability_decision failure arm (refs #2131, #2209)** — 12 call sites across formatters, the JVM runtime probe, zizmor's gh-token latch, PowerShell script analysis, govulncheck, and the shared runner-helpers/ast-grep seams now record whether a probe or the call site itself classified the outcome, closing the failure-arm half of the gap #2205 fixed for successes. - **Re-check test-runner negative verdicts instead of latching them (refs #2252)** — `TestRunnerClient.detectRunner` and `parseVitestTestGlobs` used to memoize "no runner"/"no config" for the process's whole life once probed. A config file added after the first probe (`vitest.config.ts` appearing, a project scaffolded mid-session) now converges on the same client instance instead of re-serving the earlier miss. - **Treat a null PR body as empty (closes #2268)** — Let PR-body and close-keyword checks report their actual validation results instead of treating an empty GitHub body as a fetch failure. - **Make the failed-target cap test load-invariant (closes #2290)** — Seed the real `TestRunnerClient` state with deterministic failed results instead of launching 33 child processes, so the cap assertion is independent of batch contention. - **Make cross-root eviction coverage load-invariant (closes #2305)** — Seed failed-target eviction state through `TestRunnerClient.recordResult` instead of spawning child processes, while retaining global ordering, root-map reacquisition, and telemetry assertions. - **Normalize tabs in playground-verify's sentinel comparison, and fail fast on a stable mismatch (closes #2306)** — a first source line with an internal tab (`const\tok\t= arr.indexOf(x) !== -1;`) burned the full 40s poll timeout and reported "likely upstream schema drift": Monaco doesn't render a tab as U+0009, so the raw-tab sentinel never matched, the same failure mode the existing nbsp normalization was added for. `buildScrapeExpr` now collapses every run of tab/nbsp/space to one space on BOTH sides of the comparison instead of hand-listing substitutions. The poll loop also tracks a stable, non-empty rendered-source length across polls and concludes as soon as it repeats unmatched for three consecutive polls, rather than always waiting out the full `--timeout`; the failure message now names both remaining causes (a sentinel-normalization mismatch in this harness, or upstream schema drift leaving the page's default sample rendered) instead of a bare schema-drift verdict. - **Pin the availability-probe cooldown consult (closes #2309)** — Preserve the transient timeout decision and skip redundant probes while a command is cooling down. - **Harden the CI classifier's automatic PR comment path (closes #2318, refs #2316)** — escape log-derived HTML comment delimiters, neutralize mentions, and accept only the final anchored classifier marker so failed test output cannot forge rerun suppression or ping users. - Schedule ast-grep NAPI rules for CSS and HTML edits, restore four sibling structural and IaC runner-kind pairs found by the class sweep, and guard every declared pair against dispatch-plan drift. (#2323; refs #2325) - **HTML ast-grep catalog coverage (closes #2325)** — Verify that every NAPI-routed language ships enabled rules and that HTML edits report plaintext HTTP links. - **Avoid unrelated diagnostics after a conflicted Git integration.** Pi Lens now excludes clean incoming index paths from failed Git integration recovery (merge, rebase, cherry-pick, pull, revert, am). - **Guard package-lock metadata during releases (#2043)** — Detect package identity, dependency, and peer-policy drift at CI, commit, install, and changelog release preflight boundaries. - **Attribute pi-lens writes and bound review-graph path normalization (refs #2070, closes #2072)** — drift correlation records identify pi-lens writes with bounded normalized paths, while the review-graph scale regression proves warm 8,000-file walks normalize only the changed-file bound. - **Prove idle-eviction replacements release graph memory (closes #2073)** — Add an enforced forced-GC test for twenty 2,000-node workspace graph replacements. The cache retains under 6 MiB after replacement, proving outgoing eviction timers do not retain prior graphs. - **Pin diagnostics bus publishers and subscribers (closes #2079)** — Add source-scan conformance coverage for the `pilens:diagnostics` event surface. - **Test-flakiness and hygiene residuals (refs #2090, closes #2139, refs #2182)** — `project-snapshot.test.ts` now restores its stubbed idle-evict env var so it cannot leak into later tests, and `project-report.test.ts`'s graph-cold assertion checks the cache stayed cold instead of a 22x-loose wall-clock bound. `session-lifecycle.test.ts`'s guard=0 reset test gets a 15s timeout, sized off a measured 5.4-7.2s honest cost under load instead of vitest's tight 5s default. `managed-tool-refresh-strategies.test.ts`'s cross-session re-arm test gets the same budget correction after reproducing its combined-run flake against the degradation-ledger suites. - **`vi.stubEnv` leak sweep undercount (refs #2090, closes #2223)** — `reverse-deps-cache.test.ts` now unstubs `PI_LENS_REVERSE_DEPS_IDLE_EVICT_MS` in its `afterEach`, the second live instance of the #2090 leak class that the original sweep missed. `check-pr-body.test.ts`'s "renames out of tests/" test unstubbed its GitHub env stubs only after its assertion, so a failing assertion would have left them stubbed for later tests; it now unstubs in `afterEach` like every other describe block in the file. - **Guard the warmed YAML rules cache with load-invariant work counts (closes #2292)** — assert that repeated cache hits perform no directory, metadata, or content reads inside the freshness cadence, and that the next cadence performs one metadata sweep without reading rule content. - **Close #2298's rules-cache work-count residuals (refs #2292)** — count the warmed cache's existence and content-open probes, and verify metadata sweeps across nested rule files. - **Isolate real-Git test fixtures and guard repository config (closes #2163)** — shared fixture environment hygiene, source governance, and a post-suite contamination guard prevent tests from mutating the checkout. ## [4.1.2] - 2026-08-24 ### Added - **Prompt-cache misses now say why, and mixed injections split by source (refs #1071)** — a `cache_usage` record carries `interTurnGapMs` and a `cacheMissCause` verdict of `ttl-expired`, `prefix-broke`, `partial-eviction`, or `unknown`, so the dominant cache cost is readable from `latency.log` instead of reconstructed by hand-joining timestamps. The gap is measured to request time, so a slow response is not mistaken for idle time; `gapBasis` names which endpoint produced the value. A `cache_context` record splits a mixed injection payload by contributing source, with per-source message count, characters, bytes, and an estimated token count. Token figures use a documented four-chars-per-token estimate and are never presented as provider-measured. The TTL threshold defaults to 60s and is overridable via `PI_LENS_PROVIDER_CACHE_TTL_MS`. - **Quick-mode session_start now logs which steps it skipped (closes #1911)** — quick mode silently skipped slow tool probes, language profiling, preinstall, startup scans, and the error-debt baseline, with no record either way. `session_start` now emits one bounded `session_start_skipped_steps` latency record naming the skipped step set, so a reader can tell "quick mode correctly skipped these" from "the probes silently never ran". - **Runner parsers are now held to real binary output (refs #1937)** — a parser written from documentation can be wrong in a way no hand-authored test sees, because the test asserts the same imagined shape. Captured real-bytes fixtures now live in `tests/fixtures/runner-output/`, each with a machine-generated provenance header naming the tool, version, and exact argv; a replay suite feeds those bytes through the runner, fails when the parser finds nothing, and fails when the runner's invocation drifts from the argv the fixture recorded. The sweep found four live instances: taplo spawned a `--output=json` flag taplo rejects, stylelint read stdout while stylelint 16+ reports on stderr, phpstan read the error COUNT as if it were the error array and discarded its file-independent findings entirely, and sqlfluff inserted `--dialect` between `--format` and its value so no unconfigured SQL project was ever linted. A scheduled `parser-smoke` lane now runs the tier-1 tools' real binaries over a planted violation, with a pass floor so a run that installed nothing cannot report green. - **A runner that reads nothing out of a failing tool's output now leaves a record (closes #1948)** — when a dispatch runner's tool exits nonzero, prints output, and the runner's parser extracts zero diagnostics, the degradation ledger gets a bounded `runner-parsed-nothing` row naming the tool, the exit status, the output length, and the first output line. Until now that case was byte-for-byte identical to a clean file in the worklog, which is how five parser bugs (vale, taplo, stylelint, phpstan, sqlfluff) reported clean files for months. A genuinely clean run records nothing, so the ledger does not fill up with one row per save. The gate lives in one shared helper, `parseToolRun`, that fourteen runners now share, and a sweep test keeps a new runner from silently opting out through any of the older spawn-outcome primitives. - **Mechanical lint batch: actionlint, PR-title lint, markdownlint, OSV scan (refs #1844)** — a new `lint.yml` workflow dogfoods actionlint against every workflow file, validates that every PR title carries a conventional prefix and an issue reference **in the title itself** (`scripts/check-pr-title.mjs` — a reference living only in the PR body no longer counts, since it never reaches the merge-commit subject), and lints Markdown docs with `markdownlint-cli2` under a repo-tuned config. A separate `osv-scan.yml` runs an advisory weekly `osv-scanner` sweep plus a scan on lockfile-touching PRs, writing results to the job summary. - **Vale prose lint with a vendored Google style base (refs #1844)** — `.vale.ini` at the repo root scopes Vale to `docs/`, `AGENTS.md`, `CLAUDE.md`, `README.md`, `CONTRIBUTING.md`, `.claude/agents/*.md`, and `.changelog/*.md`, using the Google style package vendored under `.vale/styles/Google/` (no `vale sync` at CI time) plus a `pi-lens/` style with three house rules: no `please` in instructions, an em-dash-density check, and a long-sentence check. A new advisory `vale` job in `lint.yml` runs it on every PR. Because the in-product `vale` runner (`clients/dispatch/runners/vale.ts`) activates on `.vale.ini` presence, dogfood sessions now surface Vale findings on doc edits too. - **Husky-managed local git hooks (closes #1804)** — `npm install` now wires a pre-commit hook (changelog fragment validation + `npm run lint`) and a pre-push hook (build + a capped, full-path-resolved targeted `vitest` selection for changed files, never the full suite; degrades to build-only past 25 matched test files or a 2-minute shared test-lock wait). Both are skippable with `PI_LENS_SKIP_HOOKS` set to any non-empty value, which agents and CI should set; humans leave hooks on. Hook install itself is skipped for CI and production/consumer installs, and never fails `npm install` on error. - **latency.log now says whether the LSP pool reused a client or spawned one (closes #1934)** — `lsp_client_selected` fired 5601 times in a 20.8h dogfood window carrying only `{serverId, candidateCount}`, so nothing in the log said whether the pool served a warm client or paid for a language-server spawn. This is the most expensive cache in pi-lens: a miss costs a process. The only estimate was a cross-record inference against `lsp_launch_candidate_success`, which counts something else, so a regression that halved pool reuse was invisible. The record now carries an `outcome` field with one of three values on the same record and the same denominator. `warm-reuse` means the pool served an already-connected client. `cold-spawn` means this selection waited on a spawn, whether it started that spawn or joined one already in flight, so a session-start burst where many files wait on the same spawn reads as several cold spawns and deflates the apparent reuse rate for that window. `spawn-failure` means a spawn ran and failed. Reuse rate is `warm-reuse / (warm-reuse + cold-spawn)`. A spawn failure is deliberately distinct from a clean decline: no root, a breaker already open, host trust refused, or a binary absent while installs are disabled. Declines emit no outcome record and keep their existing ones, so `lsp_client_unavailable` and the `outcome` field can both describe the same event and are counted separately. `getWarmClientForFile`, the warm-only lookup the cascade quiet window and read expansion call per file, previously returned `undefined` and emitted nothing; it now emits a bounded `lsp_warm_client_missing` record naming the candidate server and root, rising-edge per candidate set with the exact count in the degradation ledger. - **Dogfood sessions on pi-lens's own repo now activate the oxlint, spellcheck, yamllint, and taplo runner lanes (refs #1844)** — four new root config files (`.oxlintrc.json`, `typos.toml`, `.yamllint`, `taplo.toml`) opt pi-lens's own repository into linters it already ships for every other project. `.oxlintrc.json` pins `oxlint` as a new exact-version devDependency (1.79.0, matching the runner's tested fixture), makes oxlint this repo's sole preferred JS/TS lint runner (dropping the `biome-check-json` fallback — that IS the dogfood intent), and excludes the fixture directories that carry no config override of their own; oxlint's nested-config discovery still finds the two fixture directories that deliberately escalate severity for the runner's own smoke tests, so those stay as they are. The oxlint runner also now tells a config-excluded file (`number_of_files: 0`) apart from a genuinely clean one, reporting `skipped` instead of a false `succeeded`. `typos.toml` allowlists evidenced false positives (a routine "mis-" prefix, HashiCorp's brand abbreviation, and similar); its presence enables typos-lsp's blocking opt-in, but findings stay advisory in practice since typos-lsp's own default diagnostic severity is warning. `.yamllint` scopes yamllint to hand-authored YAML (GitHub Actions workflows, top-level config), downgrades line-length to a warning rather than raising its threshold, and defuses the `on:` truthy false positive. `taplo.toml` activates both the TOML linter and the `taplo fmt` autofix formatter, and this PR runs that formatter once so activation doesn't start the lane red. Markdown linting was already live via the pre-existing `.markdownlint-cli2.jsonc` (since #1917) — confirmed with a real `markdownlint-cli2` run, no new config needed. - **Memory-sample observability upgrades (refs #1999)** — The periodic `memory_sample` latency.log line gains three fields. `peakWorkingSetBytes` records the OS high-water working set from `process.resourceUsage().maxRSS`, so an idle-moment rss sample can be told apart from true growth (on Windows libuv backs both counters with one `GetProcessMemoryInfo()` call: rss reads current `WorkingSetSize`, maxRSS reads `PeakWorkingSetSize`). A rising-edge cadence tightens sampling from every 10 turns to every turn while heapUsed grows more than 20% between samples, reverting once growth stabilizes; the state resets at each primary session start. Each sample now also carries session age, session start time, and turn count, so growth-vs-age curves are plottable from logs alone. The `/lens-health` memory line shows peak WS when known. - **Opaque-write recovery for bash commands (refs #2000 phase 2)** — commands the path extractor does not recognize (python/node/perl/PowerShell internal writes) now get a bounded pre/post stat diff of the project source universe. Recovered files are attributed to the read guard as agent-authored and dispatched through the mutation seam, with explicit coverage-unknown telemetry instead of silent gaps. - **Collect-later delivery for slow auxiliary LSP servers (closes #2001, refs #2002)** — When an auxiliary scanner such as opengrep misses its aux-grace window, pi-lens now marks the file and server pair in a bounded pending store instead of dropping the scanner's eventual findings. The next turn end probes the auxiliary's client cache through a read-only seam, freshness-gates the result against the mark timestamp, and delivers survivors as a `Late auxiliary diagnostics` advisory. A cited file that was edited or deleted since the mark drops its findings, and both drop arms are counted in the new `late_auxiliary_findings` latency record. - **Freshness kernel: one comparator, one verdict type for staleness gates (closes #1739)** — `clients/freshness.ts` owns the mtime-vs-reference comparison and shared drift tolerance that six stores had independently reimplemented (three copies carried the identical #1710/#1711 tolerance defect). `freshnessFromMtime` returns an explicit verdict (`fresh` / `stale: modified-after-reference` / `indeterminate: no-mtime-evidence`) so each caller keeps its own no-evidence policy while sharing the comparison. A registered-or-fail sweep fails on any new out-of-kernel mtime-vs-reference comparison in `clients/`. - **Shared fault-injection test kit (closes #1838)** — `tests/support/fault-injection.ts` promotes the bespoke fault probes reviewers kept rebuilding by hand into four one-call primitives: `spawnWedgedChild` (a real child whose stdin pipe is genuinely full — the #1811 fixture generalized, with its fail-fast-instead-of-hang trap asserted against), `delayInside` (deterministic completion delay inside any mocked async seam), `fireResetAt` (fire a lifecycle hook from inside a seam's implementation at a chosen call — the #1746-R2-F1 shape), and `starveBudget` plus `gatedPromise` (the tiny-budget starvation repro). Every primitive carries its own fidelity test in `fault-injection.test.ts`, so a neutered primitive goes red in CI instead of silently weakening every consumer. - **Adversarial garbage battery for every CLI lint runner (closes #1839)** — Twenty runners now meet a 12-case battery of hostile outputs (truncated JSON, usage prose on the findings stream, unknown severities, hostile numbers) under format-blind invariants: never crash, never emit malformed diagnostics, never report clean on a nonzero exit carrying bytes. The first pass found 79 violations of that last invariant across 14 runners — all fixed by consolidating their identical tails onto one shared `finishParsedRun` seam. Also fixes htmlhint's `--rules` flag being fed JSON (the tool wants a ruleid list), which left zero rules enabled so every file read clean. ### Changed - **pi-lens formats its own TypeScript with oxfmt (refs #1844)** — The repository now carries an `.oxfmtrc.json` and an `oxfmt` devDependency, and an advisory `oxfmt --check` job runs in CI. Because `hasOxfmtConfig` gates the oxfmt formatter on exactly that config file, a pi-lens session opened on this repository now dispatches oxfmt as the format runner for edited TypeScript and JavaScript files. - **Opaque-write recovery goes git-first (refs #2000)** — inside a git worktree the pre side records only a timestamp and `git status --porcelain` plus an mtime window answers what changed, with no file-universe cap: recovery now works on any repo size, including large monorepos where the stat-walk previously degraded every command to coverage-unknown. The bounded stat-diff path remains for small non-git trees. - **ONE mutation seam: `RuntimeCoordinator.recordProjectMutation` (refs #2000 phase 1)** — the triplicated bump+change-log pairing (runtime-tool-result, runtime-agent-end, lsp-mutation) is consolidated onto one seam that bumps the seq store, appends a bounded attributed receipt ring (`getMutationsSince`, cap 512 with a surfaced dropped-count), and appends the durable change-log entry. Consumers derive touched-files answers from one store instead of three hand-copied pairings; phase 2's opaque-write recovery feeds the same seam. ### Fixed - **Search credit ignores pipe truncation (closes #1908)** — `grep -C2 pattern file | head -1` no longer credits context lines the pipe cut off. The read-guard now detects a truncating pipe tail (`head`, `tail`, `sed q`) downstream of a line-numbered grep and falls back to match-line-only credit, so a later edit to the uncredited context still requires a read. - **Cascade tier-3 registry now resets at session_start (closes #1910)** — the outstanding-touch registry and its sweep-scoped expired/evicted counters (`clients/lsp/cascade-tier.ts`) used to survive a session replacement, so a new session inherited the prior session's outstanding touches and a stray eviction or expiry landed on the next session's first reconcile gauge. `handleSessionStart` now clears both, primary-only, same as every other per-session latch in that reset block. - **Read-guard eviction telemetry is now always on (closes #1913)** — the first time a file's read-guard record cap trims in a session, it now emits a `read_cap_trimmed` log line (file, evicted count, credit-vs-genuine split, raw read count) regardless of `PI_LENS_READ_GUARD_VERBOSE`, so a live eviction regression is visible by default instead of only under verbose logging. Later trims on the same file keep updating the running totals (queryable via `ReadGuard.getTrimStats`, and via the degradation ledger's own tally) without flooding the log on every subsequent trim. - **agent_settled no longer crashes with extension_error when the session is replaced mid-run** — stale extension ctx reads are guarded and the ambient abort signal is cleared (closes #1924; thanks @Pluto-Yt). - **A session event on a replaced session no longer reports a pi-lens handler error (closes #1925)** — pi invalidates a captured extension ctx on `newSession`/`fork`/`switchSession`/`reload`, and an event already queued when that happens still reaches pi-lens carrying the dead ctx. `tool_result`, `turn_start`, `agent_end`, and `turn_end` each read a ctx property before any guard, so the SDK's `assertActive()` error was caught by `ExtensionRunner.emit` and reported as an extension error against pi-lens. That report named the wrong cause, said nothing about which handler was affected, and counted nothing. All five session-event registrations, including `agent_settled` (#1924), now go through one wrapper in `clients/session-event-guard.ts`: it probes the ctx once before dispatch, still classifies a stale error that arrives mid-handler, and records every skip in the degradation ledger under `extension-ctx-stale` plus a bounded `session_event_stale_ctx_skip` row in `latency.log`, keyed by event name. A new registered-or-fail sweep reds any future `pi.on` or `pi.on?.` registration that is neither wrapped nor given a stated reason. - **Git installs start about 750ms faster (refs #1926)** — pi supplies `typebox` and `@earendil-works/pi-tui` from its own runtime, but pi-lens declared both as runtime dependencies. A `git:` install therefore vendored a private second copy of each, and Node evaluated that whole extra module graph every time the extension loaded. Both are now optional peer dependencies, so nothing vendors them. The `PI_TIMING` module import for the dogfood git install drops from 941ms to 147-196ms, and the extensions block drops from 2165ms to 1449ms. One trade-off, stated plainly: because the bare specifiers no longer resolve on disk, pi loads the entry through jiti's transform path instead of a native import, so the FIRST start after an install, an update, or a jiti cache eviction is slower, around 5.6 to 8.2 seconds on the 4MB bundle. Every start after that is the fast one. - **Updating pi-lens no longer costs a five-second first session (refs #1926)** — pi loads the extension through jiti, which transforms the ~4MB `dist/index.js` bundle and caches the result. Every `git:` install or update produced a new bundle, so the next interactive session paid that transform: 4847ms of `module import`, against a 138ms steady state. The `prepare` chain now runs the transform itself, in `scripts/warm-loader-cache.mjs`, writing the same cache entry pi reads. The first session after an update is warm. The step runs last, is best-effort, and never fails an install; set `PI_LENS_SKIP_WARM_CACHE` to skip it. Each run appends one line to `~/.pi-lens/install.log`. - **A session swap that starves `session_start` or `context` is now counted, not misreported as a pi-lens crash (closes #1929)** — both handlers survived a dead extension ctx already, but each logged it as `session_start crashed: …` or `context event error: …` and recorded nothing, so a replacement that kept starving them was invisible in aggregate. Both now run through the shared stale-ctx wrapper and leave one bounded `extension-ctx-stale` record keyed to the event name. `context` uses a new value-returning wrapper variant that states its stale-path answer explicitly: `undefined`, pi's "this extension contributed nothing", so the host keeps its own message list rather than receiving a half-built injection. Seven of twelve `pi.on` registrations are now wrapped, up from five. - **Diagnostics scans stop logging a phantom ast-grep cache-stats record (closes #1935)** — `#1715` already grows the tree-sitter parse cache to span a project scan's file count, so the diagnostics-scan path does not run at the 50-entry interactive default; that part of `#1935` was resolved before this fix landed. What was still broken: every scan logged a second `cache_stats` record under scope `project_diagnostics_ast_grep_scan`, always all-zero, because ast-grep-napi parses through its own native engine and never touches the WASM tree cache that record claimed to measure. That vacuous record is now removed instead of wired to a cache it structurally cannot use; its one real value — ast-grep's own duration and file count, often a scan's most expensive phase — now rides an `astGrep` sub-field on the surviving `project_diagnostics_scan` record instead of disappearing. Added a memory-safety test pinning `treeCacheTotalBytes` at the existing 500-entry scan ceiling (`TREE_CACHE_SCAN_CAPACITY_CEILING`) using realistic, varying per-file sizes: worst case is 6-18MB of resident source bytes at that ceiling, and `TreeCache` enforces no per-entry byte cap of its own, only the entry count. A regression test pins the scanner to never emit the dead ast-grep scope. - **`cache_context` no longer logs an unusable `unknown` prefix pair on nearly every record (closes #1938)** — `prefixObservation` and `firstMessageChange` were computed from a hash of the pre-injection prefix capped at 64 messages / 2,048 characters. Any transcript past that cap set `prefixHashTruncated`, which forced both fields to `"unknown"`. Every real session outgrows the cap within the first few turns, so the pair reported `unknown` on 97.2% and 7.6% of records respectively — cost without signal. This PR removes the whole family that existed only to support that pair: `prefixObservation`, `prefixObservationUnknown`, `prefixBaseline`, `firstMessageChanged`, `firstMessageChange`, `firstMessageHashTruncated`, `beforeFirstMessageHash`, `afterFirstMessageHash`, `beforePrefixHash`, `afterPrefixHash`, `prefixHashTruncated`, `prefixMessageCountTruncated`, `prefixContentHashTruncated` — 13 fields in all. `cache_prefix_break` already tracks first-message stability with an unbounded hash and never truncates; it remains the source of truth for cache-prefix breaks. - **Review-graph Tier-3 build never grew the tree cache past the 50-entry default (closes #1941)** — `builder.ts`'s full-project rebuild parses every non-jsts file through the shared `TreeSitterClient`'s parse-tree cache but never called `ensureTreeCacheCapacity`, the #1715 fix already wired into the diagnostics scanner. A project with more than 50 non-jsts files evicted and re-parsed files past the 50th on every Tier-3 build. The build now grows the cache to its actual per-parse working set before extraction starts — the full file list on a cold build, or the checkpoint's remaining files on a resumed build, since resumed files are reused from the checkpoint graph and never re-parsed. - **A demoted blocker no longer shouts STOP, and it stops re-serving forever (closes #1944)** — the past-EOF gate moved a blocker whose file had shrunk past the cited lines into the advisory channel, but the advisory embedded the blocker body verbatim, so the agent still read "🔴 STOP — 11 issue(s) must be fixed" with line numbers the file no longer had. Nothing retired the record either, so it re-served on every turn end for the rest of the session (measured live at 80+ minutes). A demoted body now drops the STOP banner and the "must be fixed" imperative, renders a dead coordinate as `L (line no longer exists)`, and — when no re-run could ever confirm it — is delivered once and then retired, with the suppression recorded in the degradation ledger under `demoted-finding-retired`. `lens_diagnostics mode=delta` also stops printing 🔴 on a row whose coordinate it just replaced with the stale marker. - **The oxlint runner now surfaces warning-severity findings instead of discarding them (closes #1947)** — oxlint exits 0 whenever nothing at error severity was found, and warning is oxlint's own default severity. The runner treated any exit 0 as "no findings" and returned early, so a real capture of oxlint on an unused variable — a full JSON report, exit 0 — was thrown away. The runner now parses stdout unconditionally and decides on the parsed diagnostic count instead of the exit code: zero diagnostics is still a clean `succeeded`/`none`, one or more is `failed` with `semantic: "warning"` (or `"blocking"` when a diagnostic is error severity), matching the mapping the runner already used for the nonzero-exit case. A captured real-bytes fixture (`tests/fixtures/runner-output/oxlint/warning-exit-zero.captured.json`, oxlint 1.79.0, exit 0) pins the behavior. - **Merge-train warden's `update-branch` kick 403s under branch protection (#1959)** — the workflow's job permissions granted `pull-requests: write` but not `contents: write`. The PUT `pulls/N/update-branch` endpoint has GitHub create a merge commit on the PR branch, which needs write access to repository contents, not just to the pull request object; the inline comment attributing it to `pull-requests: write` was wrong. The warden also now tells apart the two reasons update-branch can 403: a fork-owned head PR records a distinct benign outcome (`update-branch-forbidden-fork`, logged, not a run failure), while an own-branch PR still fails the run loudly, since that case is a real permissions bug like this one. - **The blind review-graph read no longer drops a valid snapshot on a HEAD-only move (closes #1961)** — `getCachedReviewGraph` verified the persisted snapshot's git stamp against the current HEAD, so a plain `git commit` made every reader see "graph: cold" until something rebuilt in-process. Measured stamp lifetime across four workspaces was 737s to 1562s (median), and two of the four were already missing at probe time. The read path now verifies tree IDENTITY, never revision — the same policy the build path's tier-2 load has followed since #300. A snapshot stamped for a different worktree is still dropped, since nothing downstream of this read content-verifies it. A snapshot stamped at a different HEAD is served, and both `project_report`'s trust notes and `module_report`'s warnings say which commit it was built at. That caveat is derived per call from the snapshot's stamped commit and the worktree's HEAD right now, so it never names a commit that has stopped being HEAD and it clears itself when HEAD returns to the stamped one. The mid-build resume checkpoint carried the same defect and got the same fix: it hashes every processed file on resume, so revision equality proved nothing the hashes did not. Both read verdicts now write a bounded `review-graph.log` record (`snapshot_read_dropped`, `snapshot_read_drifted`), rising-edge per workspace off the `review-graph-snapshot-read` ledger kind — the drop used to be silent, which is why it hid for weeks. - **A settled review-graph build no longer suppresses every later build, and `project_report` only claims a retry when one started (closes #1962)** — `buildOrUpdateGraph`'s dedupe cache deleted its entry on rejection only, so a settled promise for a skipped or completed build answered every later call for the same key for the rest of the process. Only the dispatch pipeline's per-invocation `clearGraphCache()` ever removed it, and the background build `project_report` kicks off never goes through the pipeline: four calls over 37s produced one `build_started` record and three "A retry was started." messages with no retry behind them. The entry now lives only while its build is pending, so genuine concurrency still dedupes and a settled build never latches. `project_report` asks the builder whether a build is already in flight before it claims one started, and reports the current attempt rather than replaying the first one as if it were fresh. A `.pi-lens.json` at the repo root raises `reviewGraph.maxFiles` above the derived 1000-file cap this repo trips, so the tool works on this repo at all. - **A language server that dies mid-session now records why, and the liveness probe stops provoking the deaths (closes #1969)** — an ast-grep child closed with `code=1` and empty stderr 14 times in one day. The visible fallout was 19 `lsp_client_skipped_broken` cooldowns and 32 coverage gaps; the cause was recorded nowhere. Two changes. First, an unprompted process `close` now writes an `lsp-server-unexpected-close` degradation-ledger entry naming the server, the exit code, the signal, and whether stderr carried anything. It is written on `close` rather than `exit`, so "stderr was empty" is a fact about the server and not a race with the pipe, and it is gated on `shutdownRequested`, so evictions and ordinary teardown record nothing. Second, the `pingLiveness` round-trip (#1277) no longer hardcodes `workspace/symbol`. It picks a method the server advertised, best first: `workspace/symbol`, then `textDocument/documentSymbol` or `textDocument/hover` on an already-open document, then nothing. ast-grep's tower_lsp backend logged "got a 'workspace/symbol' request, but it is not implemented" on every probe; it advertises `hoverProvider`, so it keeps a real round-trip. When no probe is available the ledger records `lsp-liveness-probe-unsupported`, because liveness derived from process and connection state alone is the weaker verdict and must not pass as the strong one. Also fixed on the same path: `createLSPClient`'s initialize-timeout catch killed the hung child without claiming the kill, so its own teardown reported as a crash. That fabricated the exact `code=1 signal=none stderr=empty` signature this change exists to make trustworthy, and it had been writing a false `lsp_server_unexpected_exit` latency line on every failed handshake since the #615 follow-up. - **Log writer reopens and retries once on a failed write instead of dropping records silently (refs #1970)** — `ndjson-logger.ts` is the shared write-plumbing behind every NDJSON sink (`latency.log`, `extension.log`, `tree-sitter.log`, `cascade.log`, `word-index.log`, `review-graph.log`, and any other `createNdjsonLogger` caller). This hardens the sink against reachable `appendFile` failures (ENOENT after the parent directory is deleted, EBUSY/EPERM under a syncing OneDrive folder or antivirus lock, EMFILE, ENOSPC) — the specific `ERR_STREAM_DESTROYED` reports that motivated this issue were root-caused to a different process's persistent-stream logger, not this sink, but the reachable-failure classes above land here today with no recovery and no observability. A write that throws now gets one reopen-and-retry (re-verify the parent directory, then retry the write once) before it counts as a loss, matching the `pi-analyze#15` shape. An unrecovered write is counted in a per-sink, in-memory tally (`writeFailures`) rather than thrown or silently discarded, and `degradation-ledger.ts` folds that tally into `getDegradationSummary()` at READ time under a new `log-sink-write-failure` kind — so `pilens_health` names the sink and the dropped-write count. The fold happens by reading ndjson-logger's own tally, never by writing a durable ledger row back through the sink that just failed, so a permanently dead sink cannot recurse into an unbounded chain of self-reporting writes. The tally resets alongside the rest of the ledger at `session_start`. - **Warmup and workspace-scan walkers gate by file extension before consulting the ignore matcher, cutting a 31.7s stall to sub-second on repos with large ignored file piles (closes #1974, reported by @0xkite)** — `isIgnored` recompiles minimatch patterns per ancestor directory on every call; a runtime-output directory like `wal/` holding tens of thousands of `.log` files, gitignored only by a file-level `*.log` pattern (so the directory itself is never pruned), forced every one of those files through that cost. Six walkers checked `isIgnored` before their own cheap extension gate, paying the expensive check for files the gate would have dropped anyway: `collectSourceFilesForWarmup` (`language-profile.ts`, the reported 31.7s case), `JscpdClient.hasSourceFilesRecursive` (`jscpd-client.ts`), `classifyEntry` (`source-filter.ts`), `makeSourceCountVisitor` (`startup-scan.ts`), `getModuleSourceFiles` (`review-graph/workspace-modules.ts`), and `collectWorkspaceDiagnosticFiles` (`lsp/index.ts`). All six now run their extension (or LSP-server) gate first; output is unchanged, since both gates still have to pass to keep a file — only the order changed. A repo-wide sweep of all 14 files that call `isIgnored` found `tree-sitter-client.ts` and `tools/lsp-diagnostics.ts` already extension-first, and cleared the remaining per-event/no-ext-gate sites by construction; see the PR body for the full per-site table. - **oxfmt no longer fails on a file its own config ignores (refs #1844)** — pi-lens offers oxfmt for every extension oxfmt supports, so in a project whose oxfmt config carries `ignorePatterns`, oxfmt was selected for files it then refused to touch. It exits 2 with "Expected at least one target file", which the strict exit-code posture read as a formatting failure, so every edit to an ignored file surfaced an error. pi-lens now passes `--no-error-on-unmatched-pattern`, which makes an empty target set a clean no-op. Every other nonzero exit, including an unparseable file, still fails. - **ESLint warnings are no longer discarded (closes #1954)** — The eslint runner treated every exit 0 as "nothing found". ESLint exits 0 whenever no rule reaches error severity, so a run that produced only warning-severity findings was thrown away silently. The runner now parses stdout unconditionally and surfaces the findings; a clean file still reports clean, and exit 2 stays an unavailable skip. - **Registered tools now always have descriptions in child/subagent sessions (closes #1988)** — the final registration boundary fills missing, empty, and whitespace-only descriptions for active, lazy, activation, and wrapped tool definitions. - **mode=full no longer replays stale mid-edit blockers (refs #1993)** — a confirmed, fully-covered LSP sweep is now authoritative for its files: widget-store diagnostics captured from a since-fixed broken intermediate state are retired instead of rendering as current 🔴 blockers beside a clean sweep. Unconfirmed or timed-out sweeps keep the fail-open behavior. - **Cache-miss attribution stays useful in long sessions (closes #1996)** — classify full model/provider identities and split unexplained or malformed cache evidence by bounded reason, with fail-closed request hashing, activation-owned primary/secondary isolation, sanitized numeric metadata, and a per-session cause summary. - **Project snapshots no longer rewrite unchanged same-generation bodies (closes #1997)** — Persistence now coalesces concurrent requests and computes semantic identity on its worker before gzip or staging. Same-generation content changes and failed-write repairs still publish. - **Classify oxlint no-match results as expected skips (closes #1998)**. Oxlint now carries `no-files-matched` through runner telemetry without emitting an extension error or claiming the file is clean. A single fail-closed state machine validates process completion, exit status, stderr, the captured banner, and every JSON summary field's type and range; truncated, malformed, wrong-status, or error-bearing lookalikes retain failure or unconfirmed telemetry. - **Project-snapshot persistence validates gzip body integrity before skipping (closes #2008)** — The skip decision trusted the meta sidecar and a fingerprint match alone, so a torn or truncated gzip under an intact meta kept winning unchanged-dedupe and stayed canonical until the project sequence advanced. The meta sidecar now records the on-disk gz byte length (`gzBytes`) at every successful persist, and the dedupe baselines compare it against a live stat: a size mismatch, or a legacy meta without the field, withholds the dedupe fingerprints so the pending save republishes and rewrites the body. A skip that would honor evidence failing this gate between dispatch and promotion is refused and rewritten synchronously. Detections emit one `project_snapshot_body_integrity` latency record plus a bounded `snapshot-integrity` degradation-ledger entry per corrupted body path. The baselines read is also now a pure read: its in-process seeding write moved to the single dispatch seam that owns the persist lifecycle. - **Installer verify loop broken at the root (closes #2015)** — `verifyToolBinary` now spawns through `safeSpawnAsync` (tree-kill on timeout, typed kill-reason) instead of raw spawn whose SIGTERM orphaned grandchild node processes on Windows `.cmd` shims. A killed/inconclusive prober no longer counts as a verdict: the freshly installed binary is KEPT for cheap re-probe instead of deleted, ending the install/verify/reinstall churn (23 SIGTERMs and 4 cleanups observed in one day). - **Windows `.cmd`/`.bat` spawns no longer fail when System32 is absent from the child PATH (closes #2023)** — The cmd.exe wrapper prefixed every spawn with a bare `chcp 65001 &&`. When the child environment's PATH could not resolve `chcp.com`, the lookup failed and `&&` short-circuited, so the whole spawn exited 1 with empty output. chcp is now invoked via its pinned `%SystemRoot%\System32\chcp.com` absolute path and chained with `&`, so a code-page failure can never suppress the real command. - **Register remaining agent-facing delivery surfaces (#2028)** — The per-edit 🔴 STOP block now drops blockers whose cited file no longer exists, so a deleted file's stale blocker no longer re-blocks the agent with no remediation. All five previously unregistered surfaces (stop blocker, `lsp_diagnostics` output, git-guard verdicts, read-guard preflight errors, thrashing notices) are registered in the finding-delivery gate registry. - **Wall-clock budget tests get a quiet serial phase (closes #1920)** — Five test files asserting real elapsed-time budgets ran inside the default project's fork storm, measuring scheduler contention instead of code speed (`startup-overhead` measured 659-2321ms against a 500ms budget under load, green solo every time). They now run in a dedicated fully-serialized `wall-clock-budget` Vitest project that phases dead last on a quiet host. A coverage guard keeps the new include list from silently dropping renamed files. ## [4.1.0] - 2026-08-20 ### Added - **CUE code formatting support** — `.cue` files are now formatted with `cue fmt` through the standard formatter pipeline, with smart-default policy (no config required, `cue` binary on PATH). - **CUE tree-sitter grammar** — `.cue` files now parse under tree-sitter. No publisher ships a CUE wasm, so pi-lens builds one from a pinned upstream commit and commits it to `vendor/grammars/`; `scripts/check-grammar-provenance.mjs` re-hashes it against the pin in `scripts/grammars.lock.json` on every CI run, and the download path refuses a vendored grammar outright instead of retrying a URL that will never exist. This lands the parser only: no CUE symbol or import queries exist yet, so structural symbol search and import extraction still skip `.cue`, and search falls back to the word index. The query rules are tracked in #1522. - **CUE Language Server support** — `.cue` files now resolve to a dedicated `CueServer` LSP entry launched via `cue lsp serve`, with `cue-lang/cue` registered as a managed GitHub-release tool for auto-install fallback. CUE is a tracked `FileKind` with project/root markers (`cue.mod`), dispatch policy, and an LSP handshake fixture. Coverage is syntax and parse diagnostics only: `cue lsp` leaves conflicting values and failed constraints to `cue vet`. - **CUE symbol and import extraction (refs #1522, #1519)** — `.cue` files now get tree-sitter symbol (`#Definition`s as types, struct fields as properties, `let` bindings as variables) and import (`import "pkg"`) queries, so structural symbol search and import extraction cover CUE like any other language instead of falling back to the word index. Definitions are told apart from ordinary fields with a `#match?`/`#not-match?` text predicate on the `#`-prefix, since the grammar has no separate definition node kind. - **`cue vet` auxiliary runner for CUE evaluation errors (refs #1522, #1519)** — `cue lsp` reports load and parse errors as you type but deliberately leaves conflicting values and failed constraints to `cue vet`. A new `cue-vet` dispatch runner covers that gap, running alongside the LSP on every `.cue` edit (the same "lsp covers part, a CLI covers the rest" shape as terraform's `lsp, tflint, trivy-config` group). It vets the whole PACKAGE (the touched file's directory), not the file alone — CUE packages are directory-scoped, so a single-file invocation false-positives on the normative split-schema/values authoring style — then filters the reported errors down to the ones that name the touched file, always surfacing an error it cannot attribute to any file rather than silently dropping it. The touched file's own content is checked for a `package` clause up front: a package-less file goes straight to single-file scope, because a directory holding both a packaged file and a package-less one vets clean at the directory level (the loose file is silently excluded from evaluation, not a failure), so waiting for the directory vet to fail can never catch it. When the directory itself fails outright (two+ differently-packaged files sharing it — also legal CUE), the runner falls back to the touched file alone as well. The package-clause check skips leading blank lines, `//` comments, and file-level `@attribute`s alike (`@extern(embed)` is the documented real case) — treating an attribute-led file as package-less would have false-positived a clean cross-file reference as "reference not found". It runs with `-c=false` so an ordinary schema-only file — no concrete data, a common CUE authoring pattern — doesn't fail vet's default concreteness gate; a real type conflict still reports. Verified against a real `cue v0.17.1` binary end to end, including the tool-smoke fixture's binding diagnostic, a valid multi-file package, a package-less standalone file, a two-package directory, a mixed packaged/package-less directory, and a clean package where a file opens with an attribute before its package clause. - **Rendered-manifest validation for Helm charts, opt-in (refs #1283)** — `helm lint` checks a chart's source and cannot see what the chart produces, so a chart that lints clean can still fail to install. Setting `{"helm": {"renderValidation": {"enabled": true}}}` in `.pi-lens.json` makes pi-lens render the nearest chart with `helm template` into a scratch directory under the system temp dir and validate the output: a failed render (missing values key, nil pointer in a template expression, a dependency declared in `Chart.yaml` but absent from `charts/`) is reported as a blocking finding on the template that failed, every rendered document must declare `apiVersion` and `kind`, and — when `trivy.enabled` is also set — `trivy config` runs over the rendered manifests, which is the only way Trivy's Kubernetes policy checks can see a chart's real output. Findings map back to the source template through helm's own `# Source:` annotations. It is **off by default** because rendering executes chart-authored template code, and the switch is not sufficient on its own: rendering also requires host project trust, since `.pi-lens.json` is a tracked file that a cloned repository could ship pre-enabled, and the switch is read from the chart's own project root rather than the current directory. Nothing is written to the chart directory, and the scratch directory is removed on every exit path. A missing `helm` reports as runner-unavailable rather than as chart findings, and an IaC pass that could not run says so instead of reading as clean. - **ast-grep rule: ban bare `object` parameter annotations (Refs #1597)** — Add `no-bare-object-param` to the shipped rule catalog (TypeScript only — JavaScript has no type annotations to match). Fixes the one pre-existing hit, `clients/host-ports.ts:8`'s `HostLogSink` callback type, by narrowing it to `Record`. - **Ported anti-slop's AI-authorship rules into the shipped ast-grep catalog (refs #1718)** — a 2026-08-19 maintainer-supervised comparison against dmmulroy/anti-slop's 15 Oxlint rules found six already covered here and adopted the rest that ast-grep's structural matcher can express: `no-unsafe-dictionary-any`/`no-unsafe-dictionary-unknown` (the `Record` value-type arms, `error`/`hint`), `no-unknown-parameters`/`no-unknown-returns` (`hint`), `no-known-value-widening` (`hint`, narrowed to the annotated `const x: Record = { ... }` sub-case), `require-safety-comment-for-as-unknown-as` (`hint`, scoped to `as unknown as` chains), `no-runtime-typeof` (`hint`, with type-guard/naming/`.d.ts` exemptions), and `no-shape-in-symbol-names` (`hint`). `no-bare-object-param` and `no-chained-type-assertions` were promoted to `error`, and `no-chained-type-assertions` dropped its `as unknown as` exemption for the shipped catalog (users get the stricter upstream form; see the rule's note). `no-widen-then-assert` was not ported — its upstream implementation needs cross-statement variable-resolution data flow ast-grep doesn't have. Two `Record` production sites (`clients/cache/rule-cache.ts`, `clients/tree-sitter-query-loader.ts`) were narrowed to `Record` as part of the adoption. AGENTS.md's AI-authorship-smells section records the confirmed-clean counts and cites the anti-slop source. - **One primitive for "at most one execution per key" replaces ten hand-rolled copies (closes #1753)** — Ten sites wrote the same five lines by hand, and four bugs came out of the copies: a leak guard no test exercised (#1690), a late completion that evicted its own successor (#1674), a trailing-rerun bit that shipped unpinned (#1687), and a latch its own mutation matrix deleted as vacuous (#1722). `singleFlight` now owns the share, the clear on both settlements, the successor check, and the trailing-rerun coalescing, with a six-mutant matrix proving each guard reds a test. Biome and ast-grep availability are converted first; their existing tests, including #1690's leak proof, pass unchanged. A ratchet test fails any new hand-rolled in-flight state that does not carry a reason. - **Merge-train warden (refs #1844)** — A scheduled workflow now sweeps every open PR every 10 minutes and mechanizes what a human was doing by hand during the release drive: label and comment once (deduped) when a PR turns merge-conflicted (`mergeStateStatus: DIRTY`), call the native update-branch API when an armed auto-merge PR falls behind, and label and comment once (deduped) when a required check (`Unit tests`, `Lint & type-check`) fails on the current head. It never resolves conflicts, merges, or pushes to a PR branch. A new fast-fail CI job validates `.changelog/` fragments in under a second, ahead of the full Unit-tests lap, so a malformed fragment fails fast instead of after a full suite run. - **Add autofixes for mechanical ast-grep rules (refs #1850)** - **Record host-ready delay (refs #1859)** — Add latency telemetry for the monotonic interval from extension load-complete to the first `session_start`, including a host-stall suspicion flag. - **Three CI smoke lanes for the lifecycle/scope defect classes of the 2026-08 arc (refs [#1605](https://github.com/apmantza/pi-lens/issues/1605))** — a new nightly `.github/workflows/lifecycle-smoke.yml` runs the real production code path (no mocks) against a real spawned process for three shapes that #1531–#1604 shipped and no existing smoke lane could catch: (1) PSScriptAnalyzer real-host `-File` classification under a forced `PSExecutionPolicyPreference=Restricted` on a real Windows runner (`scripts/smoke-psscriptanalyzer-classification.mjs`, both a `pwsh` leg and a Windows PowerShell 5.1 leg), verifying #1540's fix and probing #1604's open pwsh-7-`ConciseView` worry; (2) the availability-lifecycle latch class (#1490/#1494/#1495/#1496/#1537/#1535), driving zizmor's real `gh auth token` probe through a fixture `gh` shim (never the real `gh` CLI) to prove a transient failure records one degradation-ledger entry, then genuinely recovers across a real ~30s cooldown (`scripts/smoke-availability-lifecycle.mjs`); and (3) gitleaks's scratch-tree exclusion scope (#1562/#1574) against a real gitleaks binary and a fixture repo with a fake secret in a tracked file and another under a gitignored secrets-lane scratch dir, asserting exactly the tracked hit surfaces (`scripts/smoke-gitleaks-scratch-exclusion.mjs`). Each script is proven capable of failing: a targeted mutation reinstating the mapped defect turns every lane red before the fix, green after (see the PR body for the red-proof transcripts). Lanes 3/5/6 from the #1605 umbrella are out of scope here and tracked separately. - **State-machine property tests for the availability latch (refs #1609)** — `tests/clients/dispatch/runners/availability-latch-properties.test.ts` runs a seeded, deterministic PRNG over random sequences of probe outcomes, time advances, session-start re-arms and caller retries against `createAvailabilityLatch`/`classifyProbeFailure`, asserting five invariants after every step: never durably latched on transient-only evidence, re-arm reachable at session_start, cooldown ladder monotone and capped, recovery reachable from every state, and degradation recorded exactly once per episode. - **Reset-interleaving test explorer (refs #1840)** — `tests/support/reset-explorer.ts` runs an async path under test once per await point it exposes, firing a session-reset hook at that exact point each time, and checks caller-declared invariants after every run. The session-straddling defect shape (a reset landing mid-await, a budget re-arming, a write landing in the wrong session) recurred five times in one review window and every instance was caught only because a reviewer picked one await point by hand; this makes that exhaustive instead of lucky. Adopted on `clients/installer/managed-tool-refresh.ts`'s walk (the #1746 R2-F1 shape) as the reference consumer. ### Changed - **Anti-slop rules: one promotion to `error`, six deliberate holds ([refs #1727](https://github.com/apmantza/pi-lens/issues/1727), [refs #1777](https://github.com/apmantza/pi-lens/issues/1777))** — `require-safety-comment-for-as-unknown-as` moves from `hint` to `error`, the tier that blocks a turn. Two changes earn that. The rule now excludes test paths structurally, because a four-corpus census (pi-lens, pi core, opencode, oh-my-pi) found 79–95% of `x as unknown as T` sites live in test doubles; and each of the 16 remaining `clients/` casts was read and given a truthful `SAFETY:` comment naming the invariant, with the one unjustified cast replaced instead (`clients/runtime-context.ts` no longer casts `null` into a cache entry's type). `no-chained-type-assertions` drops its `as unknown as` arm, so the two rules now partition the assertion space rather than both reporting the same site — every uncommented cast used to raise two diagnostics for one defect. Both rules are wired into the CI self-scan, which holds pi-lens's own tree at zero. The other six #1727 rules — `no-known-value-widening`, `no-runtime-typeof`, `no-shape-in-symbol-names`, `no-unknown-parameters`, `no-unknown-returns`, `no-unsafe-dictionary-unknown` — stay at `hint`. Structural narrowing was attempted on each and none reached a clean census; the residuals run from 3 to 3,239 legitimate hits per corpus. Every rule's note now carries its four-corpus numbers and the reason it stopped, and AGENTS.md's severity policy records the promotion procedure those censuses follow. - **Credit external contributors ahead of v4.1.0** — Add bcachet, EarthChen, Don-Yin, ELA718, sujeito-operator, and danblah to the contributors table, and restore six contributors (3choBoomer, white-hat, marvtub, mjfaga, aeturnal, floatGray) that the table listed but `.all-contributorsrc` had dropped. - **Docs: agent-guide reflects the stale-secrets ACTION NEEDED tier (refs #1522)** — `docs/agent-guide.md`'s honesty-contract table and blockers-vs-advisories section now describe the `🔑 ACTION NEEDED` tier #1627 added: a secrets finding whose cached file changed since the scan demotes to this tier, with its line number withheld, instead of dropping silently or reading as a plain advisory. CUE's LSP/formatter/tree-sitter documentation (`docs/features.md`, `docs/language-coverage.md`) was already brought current by #1520; this fragment covers the sweep verifying those pages and the wider today's-merges gap check, which found the rest of the surfaces (README.md, `docs/servercapabilities.md`'s generation note) already accurate. - **Codified live-binary discipline in AGENTS.md, per maintainer directive** — new defect shape 16 requires every claim about an external tool's exit codes, output shape, or severity vocabulary to be verified against a real run before it ships in code, comments, tests, or rule notes, and requires tool-output fixtures to be captured from real runs, never hand-written. The rule generalizes a pattern from six PRs caught by review in one window: trivy's `--no-progress` rejection breaking two lanes — one read the usage text as clean, the other failed on every run (#1757/#1781), vulture's real exit code 3 vs. the assumed 1 (#1765), rustc/clippy's six severity levels vs. an assumed two (#1802/#1809), mypy's exit-2 syntax diagnostics (#1822), and biome/pyright field-shape mismatches (#1810/#1809). Also added a one-sentence cross-reference in `skills/pi-lens-write-ast-grep-rule/SKILL.md`'s fixture-validation section. - **Ast-grep authoring skills now teach the `stopBy` boundary idiom, the four-tier severity policy, and suppression-fixture discipline** (refs #1794). - **Added the 2026-08-17 through 2026-08-20 recurring defect shapes to the agent catalog** — reconciled the review arc into the existing path-key, process-lifetime, freshness, vacuous-test, and class-sweep guidance, and added eight distinct screens for session latches, cooldown cadence, correlation, provenance, concurrent generations, session-straddling writes, walk cursors, and shared-field writers. - **docs: language-coverage lists mypy in the Python row** — mypy has been wired in dispatch (config-first, alongside pyright) since the plan.ts integration, but the coverage table never recorded it. The 2026-08-20 tool-gap survey's considered-and-skipped decisions (bandit, checkov, radon) are recorded in the table's notes so they are not re-litigated. - **AGENTS.md: six new PR-discipline rules from the v4.1.0 review arc** — mutation-proof guards, governance suites after every master merge, composition proven by evidence on overlapping PRs, deferrals re-homed to issues, `file:line` for cited precedents, and bounded observability records that preserve identity; the blast-radius rule now requires measured cost deltas on hot paths. - **One helper for bounded telemetry, and a sweep that keeps failure paths on it (refs [#1743](https://github.com/apmantza/pi-lens/issues/1743))** — four PRs in two days hand-built the same machinery: a failure path that needs a detailed `latency.log` record, an exact per-identity tally, and a bound so a storming subsystem cannot flood the log. `emitBounded`/`admitBounded` (`clients/bounded-telemetry.ts`) are now that machinery, and they are the intersection of those four, not a new framework. The rising edge is derived from the degradation ledger's own tally, so there is no second latch to re-arm at `session_start`. A per-turn cap carries the caller's turn index in the same object as the limit, so a cap nobody resets is unrepresentable. Every record stamps the discriminating identity into `metadata.identity`, so aggregating by phase still answers which file, method, or record is stuck. All four sites migrate behavior-identical: the orphan-forensics batch (#1705), the pull timeout and late-answer records (#1713), the navRequest rising edge per method and file (#1716), and the loop-block record (#1723). A new sweep, `tests/clients/bounded-telemetry-sweep.test.ts`, walks every `logLatency` call site and requires each failure-shaped phase to be either helper-emitted or listed with the mechanism that already bounds its volume, so a new unbounded failure-path record fails the build instead of shipping. Review round: the two per-file LSP skip records (`lsp_client_skipped_broken`, `lsp_client_skipped_unavailable_command`) also move to the helper — during an outage they fired once per file per touch, so a sweep over a few hundred files wrote a few hundred records describing one fact. They are now rising-edge per (server, file), with the exact totals in the ledger under the new `lsp-client-skipped-broken` and `lsp-client-skipped-unavailable-command` kinds. The sweep's predicate widened to catch them: outcome suffixes now include `_broken`, `_leak`, `_exit`, `_missing`, and `_abandoned`, and a new infix rule catches an outcome named mid-phase with its reason trailing, such as `lsp_client_skipped_unavailable_command`. `tools/` joined the scanned roots. The scanner uses #1755's shared `stripSource`, so a call named only in a comment is not read as a call. - **One generation guard instead of four hand-rolled ones** — Add `clients/generation-guard.ts`: a `GenerationSource` counter owned by the seam that resets a store, plus a handle whose `guardedWrite` drops a post-await write when the world it captured is gone, and records the drop in the degradation ledger under `generation-guard-stale-write`. A keyed `GenerationMap` covers stores invalidated per cwd or per request. Dispatch availability and the LSP workspace-diagnostics cache now guard through it; a test sweep requires every remaining hand-rolled generation compare to carry a written reason. - **Consolidated three duplicated test-fixture families onto shared support helpers (refs #1816)** — a 2026-08-20 survey found the same fixture hand-rolled dozens of times across the suite, each copy free to drift from the others and from the real interface it doubled. `tests/support/fake-child.ts` gives `safe-spawn.ts`'s child-process race tests one faithful `makeFakeChild` (a real `EventEmitter` with real `stdout`/`stderr` streams and a `kill()` that sets `killed = true`, matching Node's real behavior) instead of four separate copies, three of them hand-rolled `{on, emit}` objects that skipped the real `EventEmitter` seam the #1673 fidelity fix exists to exercise; `tests/clients/lsp/launch.test.ts`'s six verbatim `MockChildProcess` classes collapse to one parameterized by pid. Sixteen dispatch-runner test files' hand-rolled `createCtx` builders now delegate to `tests/support/runner-ctx.ts`'s `makeRunnerCtx`, resolving a `getFlag` divergence (`false` vs `undefined` across copies) by confirming — pre- and post-migration counts matched exactly (174 passed, 1 skipped in both) — that the only production read of `pi.getFlag` treats both as equally falsy. `tests/support/with-env.ts` gives `process.env` save/restore a single correct implementation (handles the "wasn't set before" case, unit-tested and mutation-proofed) and replaces four incompatible hand-rolled idioms across the `PI_LENS_DISABLE_TOOL_INSTALL` test files; two of those files' `afterEach` hard-restored the literal `"1"` instead of whatever was actually ambient before the file ran, correct only because `vitest-setup.ts` happens to default to `"1"` — `withEnv` fixes that as a side effect of the consolidation. - **Workspace-scope LSP queries identify their serving client ([refs #1854](https://github.com/apmantza/pi-lens/issues/1854))** — the existing `lsp_navigation_result` latency record now names the LSP server that answered each no-path workspace query. Aggregated operation support records a bounded per-capability contributor map, so multi-primary routing defects are visible without adding another log surface. - **Turn-end madge circular-dependency check is opt-in, default off (closes [#766](https://github.com/apmantza/pi-lens/issues/766))** — the per-turn-end madge pass only produced debug output while adding tail latency to every turn; it now runs only with `--lens-turn-end-madge` (or `turnEnd.madge.enabled: true`). User-facing madge diagnostics still come from the session-start project scan and `lens_diagnostics`. - **Narrow `no-non-null-assertion` false positives (refs #1777)** — `$M.get($K)!` guarded by `$M.has($K)` in the same function, and `$A.pop()!`/`shift()!` inside a `while`/`for`/`if` whose condition checks `$A.length`, no longer fire; both exclusions require the same receiver and key/array metavariable binding, so a check on a different key, map, or array still flags. The rule stays at `warning` — the re-census showed the residual is still idiom-heavy rather than dominated by genuine cross-boundary risk, so this is a precision fix, not a tier change. See the rule's `note:` for the full four-corpus census. - **A cascade that a slow prelude pushed out of the turn-end window now shortens its neighbour walk to land on time, when shortening it actually helps (refs [#1462](https://github.com/apmantza/pi-lens/issues/1462))** — the flat 40-neighbour cap and the 5000 ms turn-end settle wait were set in two different files with nothing relating them, and dogfood on 2026-08-15 measured what that costs: 50 cascades, median 30 ms, max 3.88 s at 40 neighbours, and a `reverse_deps_cache` refresh ahead of the graph build (2046 ms for `logger.ts`) put both tail runs past the cap. A run that misses the cap is not lost — `settleCascadeRuns` re-parks it, `agent_settled` gives it a second and more generous 15 s drain, and `beginTurn` keeps it pending until it resolves ([#1443](https://github.com/apmantza/pi-lens/issues/1443)) — so the finding arrives a turn late rather than never. That makes the real trade the full neighbour set one turn late against a shorter set on time with the remainder lost for good, and narrowing is only worth paying for when it genuinely converts a late run into an on-time one. The production pipeline now sizes the walk from the live `turn_end` settle clock when available; when that boundary is not observable, it keeps the flat cap, and direct legacy/test callers retain the old fallback. Budget-truncated runs are surfaced as incomplete advisories. In the production path, this gives three zones: the full walk still fits and nothing changes; the walk no longer fits but a shorter one does, which is the rescue band and the only place anything is narrowed; or not even a floor-sized walk fits any more, where the flat cap is kept and the carry-over delivers the whole set late — the cold-session case, since a fresh graph build measures up to ~19 s and a floor-sized stub there would drop 35 neighbours permanently and still miss. A fourth guard keeps `PI_LENS_CASCADE_SETTLE_WAIT_MS` from doubling as a neighbour-count knob: if the configured window could not fit a full walk even at zero prelude there is no late run to rescue, only every run to shrink, so the derivation stands down. At zero pre-turn gap the band is a settle-window elapsed time of 1.0–4.5 s, so the measured median 30 ms cascade is untouched and truncation stays confined to that band. [#1446](https://github.com/apmantza/pi-lens/issues/1446)'s `cascade_result` telemetry carries the evidence: `neighborBudget` is now the budget in force, alongside `neighborBudgetCeiling`, `budgetRemainingMs`, `budgetZone` (which of the four rules decided it) and `budgetDeliveryWindowMs` (the settle wait plus the quiet-window drain, so the whole deadline stack is on the record). Note when reading those rows that `budgetTruncated` inverts under a narrowed budget — it is eligible minus budget, so a smaller budget mechanically raises it; compare truncation within a zone, never across one. The per-neighbour cost the derivation divides by is an estimate (`PI_LENS_CASCADE_NEIGHBOUR_COST_MS`, default 100 ms against a measured 97 ms), and `npm run bench:cascade-budget -- --sweep` reports how the rescue degrades if that estimate is materially low. Maintainer follow-up: the settle clock now measures elapsed time against the coordinator's actual `turn_end` wait, not the compute's own age from the write, which could under-count by the full write-to-turn_end gap and narrow walks that had ample real headroom; raising `PI_LENS_CASCADE_NEIGHBOUR_BUDGET` far enough to silently disarm the rescue band now names itself once per session in the degradation ledger instead of failing silently. - **Promote laundering, unknown-return, and Reflect rules to errors (refs #1856)** — Clean the remaining named return boundaries and structurally exempt standard Proxy trap forwarding before making these rules blocking. - **Consolidate the registered-or-fail sweep machinery** — Add `tests/support/sweep-kit.ts`, one home for the four pieces every sweep in this repo hand-rolled: comment/string stripping with the string policy as a caller option, registry semantics (registered-or-fail, exemptions that require a reason, stale-entry self-detection), tag and evidence binding (one seam per tag, call-shaped needles, nearest-exclusive assignment), and the emptiness guard that fails a scan matching nothing. The kit's doc names the attack catalogue the finding-delivery gate paid four review rounds to learn, and its test suite carries one named fixture per attack. The session-state conformance sweep now runs on the kit. - **Turn-simulation harness and a session-state lifecycle registry (refs #1635)** — two pieces of test infrastructure for the two bug families that dogfooding still catches exclusively. The turn harness (`tests/support/turn-harness.ts`) scripts a sequence of edits, scans and turn ends against a real `handleTurnEnd`, on a logical clock and a temp-dir project, and returns what the agent actually sees at each turn end split into its real tiers — blocker, action-needed, advisory. Four incidents from 2026-08-18 land as its first scenarios. The gitleaks stale-replay scenario runs green and fails against the code from before #1627; the knip stale-cache scenario drives the real `KnipClient` against a real knip and passes now that #1637 has landed; the two whose fixes are not on master are skipped with the blocking issue named rather than rewritten to assert today's behavior. The session-state registry (`tests/support/session-state-registry.ts`) gives every session-scoped latch, hold, memo and dedupe set a declared reset policy, proves five of them re-arm when their reset runs, and checks each one's reset is genuinely reachable from `handleSessionStart` — derived from the source, not from a hand-kept list, because a reset nobody calls is exactly the shape of eight bugs in this arc. A derived sweep flags any `clients/` file holding module-level state paired with a reset seam that is neither registered nor exempted with a reason, and states plainly what its heuristic cannot see. - **Test fixtures now match the real host's `session_start`/`tool_result` event shape (refs #1681)** — `tests/index-wiring.test.ts` fired `session_start` with `{ sessionId: "wiring-session" }` as the event payload; the real pi host never puts `sessionId` on that event (`packages/coding-agent/src/core/extensions/types.ts:561-568` in the host source — only `type`, `reason`, `previousSessionFile`), and `index.ts`'s own handler already documents this ("the STABLE session id comes from the session manager — the event carries none"). Fixed to `{ reason: "startup" }`, host-faithful, with `sessionId` staying where it belongs: on the mock `ctx` via `makeCtx`. A new scan, `tests/support/host-event-shape-scan.ts` plus its conformance test, pins every `session_start`/`tool_result` fixture repo-wide against `sessionId`/`provider`/`model` ever landing on the event object again — the same drift the umbrella issue's earlier `#1680` fix round hit, now caught mechanically instead of by a human noticing. - **Pinned trivy's dependency-CVE disposition filter with a regression test (refs #1813)** — `trivyFindingsFiltered` (`clients/runtime-turn.ts:1516-1523`) filters trivy's CVE lane through the same `filterFindingsByDisposition` machinery as the five lanes #1798 already covered, but had no test proving it. The #1798 delta-verify neutered it back to the raw unfiltered cache read and 407 tests across 18 files stayed green. `tests/clients/runtime-turn-secrets-disposition.test.ts` now marks a CRITICAL trivy CVE false-positive through `markDisposition` and proves it stops rendering in the `handleTurnEnd` blocker tier, with the suppression staying visible as a `suppressed by disposition: ... (trivy 1)` trace. ### Fixed - **Reach never-swept monorepo caches on workspace refresh ([closes #1707](https://github.com/apmantza/pi-lens/issues/1707))** — a nested language-server root now clears its enclosing workspace-diagnostics cache through the bounded session workspace-root chain. - **LSP navigation verifies capabilities at the client boundary ([closes #1826](https://github.com/apmantza/pi-lens/issues/1826))** — definition, hover, rename, code actions, and the remaining file-scoped navigation methods now reject unsupported requests before dispatch. This second check preserves the tool-layer gate and distinguishes unsupported servers from supporting servers that return no results. - **Distinguish a slow LSP warm spawn from no clients ([closes #1875](https://github.com/apmantza/pi-lens/issues/1875))** — a read warm whose bounded wait expires now reports that its primary server is still spawning. A touch reports no clients only when no matching spawn remains in flight. The next read reuses the existing single-flight spawn. - **Avoid doomed waits for historically slow LSP spawns ([refs #1884](https://github.com/apmantza/pi-lens/issues/1884))** — a bounded warm touch now returns immediately when its matching server spawn is in flight and a prior successful spawn took more than twice the budget. Servers without history retain the existing bounded wait. - **Re-arm direct-LSP and installer availability caches ([closes #1897](https://github.com/apmantza/pi-lens/issues/1897))** — the primary `session_start` clears negative direct-LSP cooldowns and resolved installer paths, so tools added between sessions are probed again. - **Bound the cascade tier-3 reconcile backlog and drop the dead neighbour-touch cache ([closes #1899](https://github.com/apmantza/pi-lens/issues/1899))** — the outstanding-touch registry now caps its entry count and its entry age instead of growing until a quiet window arrives, every sweep writes a backlog gauge to `cascade.log`, and an unresolved touch says which of the five causes kept it unresolved. The same-write neighbour-touch cache is removed: its read gate could only pass inside a single write, so it measured 0 hits across 236 cold touches. - **Avoid false read-guard blocks after formatter writes ([closes #1903](https://github.com/apmantza/pi-lens/issues/1903))** — Bash-invoked in-place formatters and fixers now refresh explicit file write stamps. A uniquely resolved edit `oldText` also overrides coarse FileTime staleness, while missing or ambiguous content evidence remains blocked. - **Credit search hits with the lines the search actually showed ([closes #1904](https://github.com/apmantza/pi-lens/issues/1904))** — a bare `grep -n` hit registered as a 5-line read, so the read-guard let edits pass against lines the model never saw. A hit now credits its match line, plus the context the command printed when it carried `-A`, `-B`, or `-C`. Each record states the margin it credited and why. The range-snapshot ledger also reports the caller's outcome (enforced or bypassed by content match) instead of only its intent, and the per-file read store is bounded at 128 records. - **A size-capped write no longer says both "attached" and "too large to attach" ([closes #1590](https://github.com/apmantza/pi-lens/issues/1590))** — two layers used to phrase the post-autofix instruction. The pipeline claimed the attached content was authoritative whenever autofix changed the target file, and the tool-result layer, the only one that sees the 2 MiB attachment cap and the per-command aggregate budget, appended "you must re-read, the content is too large to attach" for that same file. A write whose post-fix content exceeded the cap carried both sentences, and a multi-file bash write past the shared budget did the same for the degraded path. The pipeline now returns the changed-file data instead of a verdict, and `handleToolResult` renders the one sentence from the one decision it owns. The shared budget is threaded into each synthetic per-file call, so a bash write decides each attachment once rather than attaching and then overruling itself. The telemetry follows: `authoritative_content_attachment_decision` logs one row per path, carrying `attached`, `size-capped`, or `aggregate-budget-degraded`, where a degraded path used to log two rows and rely on the later one winning. - **Preserve biome's info/hint severity in dispatch** — `biome-check` collapsed every non-error biome diagnostic to `warning`, even though biome's own JSON declares `information` and `hint` tiers. Biome findings now carry the same four-tier `Diagnostic.severity` ast-grep-napi adopted in #1787: `information` maps to `info`, `hint` stays `hint`. Only `error` still blocks. The on-demand ast-grep CLI path's `formatDiagnostics` summary also gained an `info(s)` bucket — an info finding was previously counted in the total but named in no tier line. - **cuelsp's silent clean-open no longer reads as inconclusive (refs #1522, #1519)** — Measured directly against the real `cue lsp serve` v0.17.1 binary: a cold `didOpen` on an already-clean `.cue` file publishes nothing at all inside the wait budget, so a touch used to time out and report `inconclusive`. `SERVER_DIAGNOSTIC_STRATEGIES.cue` now marks it `silentOnClean`, so the shared push-only clean-confirm gate reads "no publish, notify succeeded" as confirmed clean — matching the behavior already shipped for typescript and marksman. An edited document still publishes normally (both the error and the empty array that clears it), so this only changes the cold-open case. - **Preserve ast-grep rule severity tiers through dispatch** — The dispatch runner collapsed every `warning`, `hint`, and `info` rule severity to `warning`, so the quiet tier that 43 shipped rules declare did not exist downstream. All four tiers now reach `Diagnostic.severity`. The turn-end advisories say how many findings are hint or info, the code-quality report spends its cap on warnings before hints, and hint-tier rules that carry a fix still route to actionable warnings. The `lens_diagnostics` and TUI-footer tallies count hint and info alongside warning, so a hint-only file is never reported as clean. Only `error` blocks, exactly as before. - **Persist degradation-ledger decisions in `latency.log`** — every accepted once-record and every tally increment now writes a bounded `degradation_ledger` row with its kind, subject, and current count. Scanner coverage gaps and stalled LSP notify barriers now enter the ledger too, so a session remains auditable even when no degradation summary reaches the transcript. - **A write that already handed back its post-fix content no longer also tells you to re-read it (closes [#1464](https://github.com/apmantza/pi-lens/issues/1464))** — since #1414 a `write` whose immediate autofix changed the file gets the full authoritative content attached to its own tool result, but the next turn still opened with "N file(s) were autofixed after your last turn: a.ts — re-read before editing". The nudge's relevance filter admits any path with read or edit history, and a file the agent just wrote is in edit history by definition, so the one case where the agent demonstrably holds the current bytes was the case that nudged hardest. The write path now tells the nudge accumulator what it delivered (`noteAuthoritativeContentAttachment`), passing the same boolean that drove the attachment rather than re-deriving the size cap or the per-command budget in the nudge layer. Suppression is exactly as narrow as the delivery: a size-capped attachment, a bash multi-file write whose aggregate budget degraded a per-file "attached" back to a re-read warning, a side-effect file the autofix changed but did not attach, and deferred `edit` autofix at `agent_end` all keep nudging. A later touch of the same path re-arms it too — the default deferred format at `agent_end` makes those attached bytes stale, and stale bytes are worth a re-read. The `agent_nudge` phase gains `filesContentDelivered` so over-suppression is auditable instead of only showing up as silence. - **Knip's per-turn delta no longer reads a shifted finding as newly unused ([#1483](https://github.com/apmantza/pi-lens/issues/1483))** — the finding key included the line number, and the delta is filtered to exactly the files the edit touched, so lines shifted by that same edit landed right where the filter looks. A finding that only moved down now keys the same as before and drops out of the delta; a genuinely new finding still appears. The key now shares `stableFindingKey` with the dead-code delta ([#1477](https://github.com/apmantza/pi-lens/issues/1477)), which had the identical bug and the identical fix — one rule, one place, for both scanners. - **A stalled PowerShell check no longer disables PSScriptAnalyzer for the rest of the session (closes #1490)** — The runner ran its own child processes to find a PowerShell interpreter and check for the PSScriptAnalyzer module, and every failure looked the same to it: a timeout, a Windows spawn error and a genuinely missing binary all reported nothing at all. Any of them was remembered as "PowerShell analysis is not available" until pi-lens restarted. Both probes now go through the shared spawn layer, so a timeout is distinguishable from an absence, and the verdict is owned by the same availability policy as knip, madge, Go and Rust: a stall is retried after a short wait, and only a genuine absence sticks. Each decision lands in `latency.log` as an `availability_decision` entry with its cause and timing. - **A silent auxiliary no longer reads as confirmed clean (closes [#1493](https://github.com/apmantza/pi-lens/issues/1493))** — An auxiliary scanner that published nothing inside its own budget now narrows the touch's verdict to `confirmation: "partial"` and is named in `unconfirmedServerIds`, the same treatment #1470 gave a scanner cut off by the aux grace timer. Before this, silence only stayed honest when the scanner was the sole auxiliary and burned the whole touch deadline; with a second auxiliary answering fast, the wait settled early and the silence went unrecorded, so a touch claimed a clean bill of health for a server that said nothing. Both no-answer shapes now run through one policy, `auxiliaryCoverageGap` in `clients/lsp/diagnostic-binding.ts`. Genuinely clean files are unaffected: a scanner that ran to budget and published an empty set advances `diagnosticsVersion`, so it reads as `answered` and its touch stays `confirmed`. So does an unreporting scanner — silent or cut off — whose stored publication is already bound to the touch's exact content. Where the verdict does narrow, `pi-lens lsp-diagnostics` adds an "Auxiliary coverage INCOMPLETE" line naming the scanner, and the dispatch LSP runner reports an empty result as `skipped` rather than clean. `lsp_touch_file` carries the new `auxUnconfirmedServerIds` field, which joins to the `silent` rows in `lsp_aux_wait_outcome`. - **A stalled version check no longer disables eslint, credo or clippy for the rest of the session (closes #1494)** — The per-directory probe these three runners share cached its verdict forever, so a single `eslint --version` that timed out on the first JS/TS save silently dropped eslint for that project until pi-lens restarted. Credo's 10-second `mix credo --version` on a cold BEAM and clippy's 8-second `cargo clippy --version` had the same failure mode, and clippy went further by treating the timeout as grounds for an install attempt. The verdict now goes through the shared availability policy from #1467/#1476: only a genuine absence sticks, while a timeout, abort or host stall is retried after a short cooldown. ESLint autofix in the post-write pipeline carried its own copy of the latch and is fixed the same way. Every decision is recorded in `latency.log` as an `availability_decision` entry with its cause, timing and retry window. - **A stalled PATH lookup no longer disables a formatter until you edit a config file (closes #1495)** — Detecting rustfmt, shfmt, zig, dart, nixfmt, gofmt and about a dozen other formatters runs `which`/`where` on a 5-second budget. A single timeout dropped the formatter and then wrote that empty result into the detection cache, which is only invalidated when a formatter config file changes size or timestamp — so formatting stayed silently off for the rest of the session, looking to you like pi-lens deciding the file needed no formatting. PATH lookups now go through the shared availability policy: a timeout is retried after a short wait, only a genuine absence sticks, and an empty detection caused by a stalled probe is no longer cached at all. Editing a config file still re-checks PATH, so installing a formatter mid-session works as before. Each lookup is recorded in `latency.log` as an `availability_decision` entry with its cause. - **A stalled package-manager check no longer downgrades pi-lens's own managed installs to npm (closes #1496)** — Checking which package manager is installed spawned a `where`/`which` probe on a 5-second budget, and a timeout was remembered as "not installed" for the rest of the session. The blast radius was internal: the resolver only serves installs into pi-lens's managed tools directory and `pilens_rebuild` on a pi-lens source checkout, never a user project's lockfile. A timed-out check is now retried after a short wait instead of latching, matching the #1467/#1476 policy already used for knip, madge, govulncheck, vulture, biome, ast-grep, Go, and Rust. Each decision is recorded in `latency.log` as an `availability_decision` entry with its cause and timing. - **A repeatedly timing-out `go install` no longer re-compiles govulncheck every few minutes forever (closes #1497)** — #1489 rightly made a timed-out install transient, but it inherited the probe-class retry schedule (30 s doubling, capped at 5 min), calibrated for a 1.5–5 s version probe. On a host where the 60 s `go install` reliably exceeds its budget, steady state was a 60 s compile every 5 minutes with no terminal state. Install-class transient failures now escalate on their own two-rung ladder (5 min, then 10 min) and give up on the third attempt, spacing at most three ≤60 s compiles across ~15 minutes. Install-class failures also hold their own cooldown slot, so a cheap version probe failing in the meantime can no longer pull the next compile forward. The ceiling is terminal for the SESSION, not the process: it re-arms at the next `session_start` (or on a successful run), so a genuinely transient network failure still recovers without a host restart. When the ceiling is reached, the verdict says so — the degradation ledger records `install-retry-exhausted` (visible via `pilens_health`), the `availability_decision` row is marked latched with the install facts behind it, and the user-facing message reports a retry ceiling that clears next session instead of promising a retry that will not come. - **Tool-availability records now show what actually failed, and a failed auto-install is no longer a silent verdict (closes #1500)** — When pi-lens decides a tool is unavailable it writes one `availability_decision` line to `latency.log`. Those lines reported the verdict but not the evidence, so "the tool is missing" looked identical whether a probe returned "not found" or an auto-install had just failed for a reason that would clear on a retry. Each line now carries the raw spawn facts (exit status, failure kind, errno, whether an install was attempted) and says whether the classification was derived from a probe or asserted by the caller. Security-scanner clients — gitleaks, trivy, opengrep, govulncheck — used to latch "not installed" after a failed install without recording anything at all; that write is now recorded like any other decision. - **Transient security-scanner probe records now carry their retry schedule (closes #1501)** — When a `gitleaks`/`trivy`/`opengrep`/`govulncheck` version probe timed out, the `availability_decision` record in `latency.log` said the tool was off but not when it would be retried, because the record was emitted before the caller decided the cooldown. The shared seam now owns the transient cooldown and logs `retryAfterMs` alongside the existing outcome, cause, and timing fields, matching the shape the install and scan paths already emitted. Success and durable-absence records are unchanged. - **Venv-resolved tool paths are no longer wrapped in literal quotes (closes #1508)** — When a linter such as `ruff` resolved through a project virtualenv (`.venv/bin/ruff`), the availability seam returned the path wrapped in double-quote characters — a leftover from the `shell: true` spawn era. Every spawn now runs with `shell: false` (#817), so the quotes became part of the filename, the probe failed with ENOENT, and the runner silently reported no diagnostics. The path is now returned verbatim on every platform, and the resolved command is pinned quote-free by regression tests. Reported by @phionax. - **Auxiliary diagnostic waits and their outcome rows are now decided per file (closes [#1531](https://github.com/apmantza/pi-lens/issues/1531))** — `diagnosticsVersion` is a per-client counter that any file's publication advances, so on a client shared by two files in flight an unrelated publication both ended this file's wait early and read as evidence that the scanner had answered for it. Every store of fresh diagnostics now also stamps the path it was stored for (`diagnosticsVersionsByPath`, written by the new `bumpDiagnosticsVersion` seam and cleared with the rest of a path's state in `clearDiagnosticsForPath`), and both the `minVersion` freshness gate and the auxiliary evidence check read that per-path stamp. Direction was under-detection — a false `answered`, never a false finding — but it also skewed `lsp_aux_wait_outcome`, the rows used to reason about auxiliary health. Interleavings that used to record a false `answered` now record `silent` and demote the touch's confirmation to `partial`, so sweeps that touch several files against one auxiliary report a higher (and honest) partial rate. - **A silent auxiliary no longer reads as confirmed clean on batch scans either (closes [#1533](https://github.com/apmantza/pi-lens/issues/1533))** — #1493 narrowed the verdict for an unreporting scanner on the per-file lane; `clientScope: "all"` — the batch and directory scan surface — kept aggregating the same silence as `confirmation: "confirmed"`. Auxiliaries are spawned on that scope but it never enters the auxiliary grace wait, so no coverage evidence was ever derived and neither no-answer shape could be computed. A `"all"`-scope touch now derives the same evidence from post-wait state: every spawned auxiliary is recorded as `answered`, `silent`, or `deferred` through the one `auxiliaryCoverageGap` policy, so a scanner that said nothing about these bytes narrows the touch to `"partial"` and is named in `unconfirmedServerIds`. The evidence is read from a wait that already happened rather than from a second one, so the fan-out latency #1459's resync gate recovered stays recovered. `lsp_aux_wait_outcome` now covers this lane too, tagged `waitShape: "aggregate"` (versus `"aux_grace"` for the per-file producer) — `cut_off` cannot arise there because no ceiling is armed. A scanner the caller excluded by design (the workspace sweep's own opengrep exclusion) is never spawned and so is never reported as a gap. Where this changes a verdict: an auxiliary whose budget is the largest among the servers waited on (opengrep on every per-edit path) already left its touch unconfirmed by lapsing the aggregate deadline, so those results are unchanged; a faster scanner beside a slower primary — typos or ast-grep next to rust-analyzer — settles inside that deadline and now narrows a result that used to read confirmed, which costs a skipped cache seed for that file and buys an honest verdict. One further limit stated plainly: `diagnosticsVersion` is a per-client counter, so two concurrent touches sharing one auxiliary client can still cross-satisfy each other's evidence — the verdict then misses a silence rather than inventing one, and [#1544](https://github.com/apmantza/pi-lens/issues/1544)'s per-path counter closes it. - **A failed grammar download no longer disables a language for the rest of the session (closes [#1536](https://github.com/apmantza/pi-lens/issues/1536))** — `TreeSitterClient.ensureGrammar` deduped concurrent grammar fetches by keeping the SETTLED promise, so one offline moment (a DNS hiccup, a CDN blip) memoized `false` for the life of the process; symbol search, module reports, and structural rules for that language stayed degraded even after the network came back. The in-flight entry is now evicted on settle, and a failed download gets a bounded exponential cooldown (30s, 60s, 120s, capped at 5 min, the same `transientRetryDelayMs` shape `availability-policy.ts` already uses) instead of a permanent latch. A durable CDN verdict (404/410 — the wasm genuinely does not exist) still latches, since a retry cannot change that answer; every other failure (network error, timeout, 5xx) retries. The degradation message now says "will retry" instead of "reinstall" for a retryable cause, and the user notification fires once per session per distinct retry delay, so a continuing failure streak that survives a session boundary is announced again instead of going silent. - **A lazy install that dies on a network blip is retried instead of skipped for the session (closes #1537)** — the "we already tried this" key went in BEFORE the install ran and never came out, so a `gem install rubocop` or `rustup component add rustfmt` that failed on a transient error was never attempted again, and the tool stayed silently skipped. The storm guard stays — these spawns are up to 3 minutes and both entry points are reached per save — but it now keys off the attempt's OUTCOME: a transient failure is retried on #1497's install-class ladder (5 min, then 10 min, then the verdict is terminal for the session), while a durable one holds immediately. A missing package MANAGER is the durable case: no cooldown conjures a `gem`. The hold is released only at `session_start`, beside the other per-session availability resets. - The two copies of that guard became one. `formatters.ts` carried its own `_lazyInstallAttempts` Set duplicating `lazy-installer.ts`'s, and a fix in one was not a fix. State, classification, retry ladder and spawn options now live in `lazy-installer.ts`; `formatters.ts` keeps only the part that is formatter business (a fresh binary on PATH invalidates every "not found" verdict). Because these installs are machine-global, the two seams share one hold per tool: a runner and a formatter asking for the same `gem install rubocop` are asking for the same one thing. Callers that arrive while an install is still running now join it instead of starting a second one. - "We tried and the network failed" is now tellable from "this tool cannot be installed here". The lazy installers recorded nothing at all. Each attempt now produces an `InstallAttemptFact` in #1534's vocabulary; the rust-clippy runner reads it through `describeInstallAttempt` and puts it in the `availability_decision` record beside the verdict it produced, so a failed `rustup component add` reaches `latency.log` instead of looking like a silent skip. Each suppression also logs one `install`-subsystem line with the cause, the attempt count and the remaining cooldown. - **A stalled PATH probe no longer hands your project to its second-choice formatter for the session (closes #1539)** — `detect()` returned a plain boolean, so "rubocop is not installed" and "the probe for rubocop timed out" arrived at the selection pass as the same answer. The runner-up won, the result was non-empty so #1495/#1532's poison guard never fired, and `detectionCache` is invalidated only by a config file's mtime or size: standardrb owned the repo until you restarted or edited a config. Each candidate now carries a verdict read from the PATH latch — `available`, `missing`, or `unreachable` — so a selection whose preferred candidate was never asked is provisional: it is not cached, it re-detects once the cooldown expires, and `formatter_selected` records `reason: "preferred-unreachable"` with the candidates it could not reach instead of the config-shaped `"explicit-config"`. A genuine absence still caches exactly as before, because that is a real fact about the project. - The poison guard now sees every binary a detection probed, not just the formatter's own. It matched stalled probes against `command[0]`, and the extras were assumed harmless because "they run only after the primary answered". Not so: `rustfmt` genuinely absent plus a stalled `which rustup` skips the `rustup component add rustfmt` that would have fixed it, and nothing named `rustfmt` is transient, so the empty result cached for the session. The guard reads the real probe record now, which also covers the co-equal-alternative case (`pwsh` ?? `powershell`). - A formatter held off by a probe cooldown is visible in `latency.log` while it is off. The latch's memo branch returned before `logAvailabilityDecision`, so one record covered arbitrarily many decisions and anyone counting `availability_decision` rows undercounted the outage. Cache-served verdicts now emit one row per cooldown window, marked `servedFromCooldown: true` so they stay separable from real probes. - **An execution-policy-blocked PSScriptAnalyzer run no longer reports the file as clean (closes #1540)** — Both availability probes call PowerShell with `-Command`, which the execution policy does not gate, but the real analysis runs with `-File`, which it does. Under `Restricted`/`AllSigned` — the default on many corporate Windows hosts — the analysis exits nonzero with a `SecurityError` on stderr and nothing on stdout, and the runner read that empty stdout as zero diagnostics: a blocked analyzer reported as a clean file. A `-File` run is now verified directly: a nonzero exit or a crashed/signal-killed process (`status === null`) records a legible `availability_decision` (policy and interpreter included) and a `grammar-blocked` degradation-ledger entry instead of a silent pass or a silent skip, and only an actual exit-0 run is read as evidence about the file's diagnostics. Review round: a `status === null` spawn-UNKNOWN no longer latches `-File` off for the session (mirrors the nonzero-exit branch's own transient downgrade); both degradation-ledger calls use `incrementDegradationCount` so a retried block doesn't flood the ring buffer; the policy-block regex now requires the `SecurityError` + script-load pairing instead of a bare `unauthorizedaccess` match. A separate exit-0-but-empty-or-malformed-stdout gap is tracked as #1598. - **Fish had no LSP runner in the registry, and 21 extensions had no language id, because two seams were hand-copies of the language registry (closes [#1545](https://github.com/apmantza/pi-lens/issues/1545))** — `LANGUAGE_POLICY` decides which kinds are `lspCapable`, but the lsp runner's `appliesTo` and the LSP `LANGUAGE_EXTENSIONS` table each kept their own transcription of it, so a language could be registered and still miss either one silently. Both had drifted. `appliesTo` omitted `fish`, so `RunnerRegistry.getForKind("fish", …)` returned no LSP runner and `getAvailableRunners("/p/a.fish")` led with `fish-indent`. Routing was unaffected (main dispatch resolves group runner ids directly, and `PRIMARY_DISPATCH_GROUPS.fish` names `lsp`), and `getForKind`'s only callers today are `getAvailableRunners`, which nothing in production calls, and the `@internal` `dispatchLint`, which has no production caller either — so this was a latent wrong answer in the registry rather than lost coverage, and it would have become real the moment any surface started asking the registry what runs on a file. `LANGUAGE_EXTENSIONS` was the bigger gap: powershell had no entry at all (`.ps1`, `.psm1`, `.psd1`), cxx covered seven of its twenty-four registered extensions (`.c++`, `.cp`, `.hxx`, `.inl`, `.ipp`, `.tpp`, `.txx`, `.c++m`, `.cppm`, `.cxxm`, `.ixx`, `.cu`, `.hip`, `.m`, `.mm`, `.cl`, `.clcpp` all missing), and `.json5` was absent, so `didOpen` announced each of those as `plaintext`. How much that costs depends on the server, and the honest answer is "less than it looks for most of this list": driving real servers over raw LSP, vscode-json-language-server and yaml-language-server return identical diagnostics under `plaintext` (7/7 and 3/3), and clangd derives the language from the path, so the cxx entries are very likely no-ops too. A `DocumentSelector`-based server such as PowerShell Editor Services is the case where the announced id decides whether the document is handled at all. The table is now correct either way, and correct-by-construction rather than by transcription. Both seams derive from `getLspCapableKinds()`: `appliesTo` is the policy list itself, and `LANGUAGE_EXTENSIONS` is the curated per-extension table (which stays, because one kind can span several ids, `.ts` vs `.tsx` and `.c` vs `.cpp`, and because servers want `shellscript` rather than the registry's `shell`) filled in from `KIND_EXTENSIONS` for anything the curated table does not already name. Registering a language as `lspCapable` is now the only step either seam needs. Six structural guards plus two behavioral pins in `tests/clients/lsp-capable-seam-coverage.test.ts` hold that in place: `appliesTo` non-empty (`getForKind` reads an empty one as "every kind"), every `lspCapable` kind present in it, no non-capable kind claimed there, every `lspCapable` extension present in `LANGUAGE_EXTENSIONS`, every one of them resolving to something other than `plaintext`, and the set of reachable language ids pinned by hand so a kind whose registry label no server answers to needs a deliberate review decision rather than passing silently. Each guard is proven red under the mutation it exists to catch. Found during the adversarial review of [#1520](https://github.com/apmantza/pi-lens/issues/1520), which hit both seams at once; refs [#1519](https://github.com/apmantza/pi-lens/issues/1519). - **`biome-client-dedupe` test now isolates the in-flight probe dedupe from package-manager spawn count (refs [#1546](https://github.com/apmantza/pi-lens/issues/1546))** — `dedupes concurrent first-time callers to a single probe` armed `safeSpawnAsync` as a one-shot mock, assuming `probeBiome` calls it exactly once. Since #375, `getBiomeBinary` falls through to `findGlobalBinary` when no local or pi-lens-managed biome binary exists, and that helper legitimately probes every installed package manager's global bin dir (`where npm`, `npm config get prefix`, and so on) through the same `safeSpawnAsync` seam. On a machine without a local/managed biome binary — reproduced by moving both aside — those extra calls silently consumed the one-shot mock and `probeBiome` dereferenced the resulting `undefined`. The test now mocks `package-manager.js`'s `findGlobalBinary` to resolve `undefined` directly, the same isolation `biome-install-evidence.test.ts` already uses, so it stays scoped to `ensureAvailable`'s own in-flight dedupe (#120) instead of incidentally depending on how many package managers happen to be findable on the host. - **A captive portal can no longer poison a grammar file permanently (closes [#1548](https://github.com/apmantza/pi-lens/issues/1548))** — the runtime grammar download trusted `res.ok` alone, so an airport-wifi or corporate-proxy login page returned as 200 OK was written to disk as `tree-sitter-.wasm`. That counted as a successful download, so no cooldown was armed and nothing was recorded, while every later resolve found the garbage file and reported the language as available — `Language.load` then failed on every parse, with no path back to a re-download until someone deleted the file by hand. The downloaded bytes are now checked against the WebAssembly preamble (`\0asm`) BEFORE anything is written; a non-wasm body is a retryable failure, so it flows through the same cooldown, notification, and degradation-ledger path a network failure does, and the record names the real shape ("returned an HTML page — a captive portal or proxy intercepted the request") instead of blaming the package manager. Grammar resolution also rejects a non-wasm file that is already on disk, so a file poisoned before this fix shipped is ignored and re-fetched instead of degrading the language forever. An ignored file is recorded once per session rather than once per process, so a session that starts with the poisoned file still on disk still reports why the language is degraded. Separately, an exception thrown anywhere in the grammar-fetch task now arms the same cooldown rather than escaping with no retry state. - **A workspace sweep no longer speaks for a scanner that missed its deadline (refs [#1549](https://github.com/apmantza/pi-lens/issues/1549))** — when an auxiliary scanner misses the sweep deadline, the result now names the uncovered lanes instead of reporting the file as fully answered. A partially covered snapshot is never cached and never reconciled into the widget, so a later read re-asks the scanner that stayed silent. - **One slow scanner no longer discards every good answer in a cascade sweep (refs [#1549](https://github.com/apmantza/pi-lens/issues/1549))** — a neighbour touch attaches about five servers, and its verdict was `inconclusive = notifyWriteTimedOut || diagnosticsTimedOut` with both flags TOUCH-WIDE. The diagnostics deadline is the maximum over the servers waited on, so opengrep's 3500 ms budget set the deadline for the whole touch: a clean TypeScript answer that landed in 100 ms reported as "nothing is known about this file". Measured over 6,079 sweeps in eight days, 97.6% of neighbour touches read inconclusive, against 15% for ordinary edit-time touches in the same window; a dogfood session after the [#1528](https://github.com/apmantza/pi-lens/issues/1528) notify-write flood fix still showed 37 of 37 inconclusive, which confirmed the merge rule rather than queueing as the driver. The verdict is now decided from the PRIMARY population alone, through one pure policy (`resolveTouchVerdict`): a touch whose primary answered reports its findings as usable and names the auxiliary it does not speak for, using the existing `confirmation: "partial"` plus `unconfirmedServerIds` machinery from [#1470](https://github.com/apmantza/pi-lens/issues/1470)/[#1493](https://github.com/apmantza/pi-lens/issues/1493)/[#1533](https://github.com/apmantza/pi-lens/issues/1533). Every consumer that treats confirmation as proof of coverage therefore still fails closed — no cache seeding, no widget reconcile, no clean bill of health — while the findings reach the agent instead of being thrown away. An auxiliary can no longer make a touch inconclusive whichever deadline it missed; only a primary can, and the answer is decided from EVIDENCE (a per-path publication stamp advancing, or a fresh per-file cache entry), never from how a promise settled, so a client that exposes neither accessor keeps the pre-fix verdict. The capability-aware silent-clean confirm is primary-scoped for the same reason: a clean markdown file whose marksman silence IS the answer no longer stays inconclusive because an opengrep scan beside it had not finished. Two safety consequences ride along: an auxiliary whose notify write never landed has its stale findings dropped from the merged result (they describe the previous revision, and before this they were unreachable behind the blanket verdict), and the diagnostics-timeout degradation ledger now records only the servers that actually went unheard rather than every spawned server. That drop is judged on a merge-time content-binding read unioned with [#1493](https://github.com/apmantza/pi-lens/issues/1493)'s pre-notify snapshot, because the snapshot is captured before the write and cannot see the write that lands late and then publishes for these exact bytes — [#1459](https://github.com/apmantza/pi-lens/issues/1459)'s own documented signature. One predicate decides both the drop and the coverage naming, so a scanner is never named uncovered while its findings ride along in the result. Attribution is on the record: `inconclusiveServerIds` and `inconclusiveReason` (`notify-write`, `diagnostics-wait`, or `mixed`) on the touch result, in `lsp_touch_file`, and in the cascade's own `neighbor_touch` row; `lsp_diagnostics_timeout` gains `unansweredServerIds` plus `attributedToPrimary`; and `lsp_scanner_coverage_gap` gains `auxNoAnswerServerIds` so the record that proves a scanner blackout survives the verdict change. The issue's `latency.log` retention item (one rotation sibling keeps about two days) is deferred and re-homed on the issue, and the sub-30% rate gate is measured on the next dogfood. - **Cascade "could not compute impact" records now name the file that actually caused it (closes #1550)** — When a cascade run cannot enumerate a file's dependents, pi-lens writes one `cascade_indeterminate` line to `cascade.log`. That line labelled itself with the turn's first edited file and listed its reasons with no file attached — but the runs it summarises carry their own paths, and a run can be carried over from an earlier turn or belong to a file the turn never edited. So the log blamed the wrong file: a Markdown edit was credited with a missing graph node it could never have produced, and a plain source file was credited with the test-file-exclusion reason that only applies to tests. Each reason is now attributed to the file that produced it. A missing graph node also records what was looked up and what the graph held nearest to it — file-node count, surviving symbol nodes, known siblings in the same directory — so a cold graph, an unadmitted file, and a genuine graph inconsistency read differently in the log. Agent-facing advisories were already correct and are unchanged. - **The availability-policy coverage gate no longer waves through a verdict that dodges the word "boolean" (refs #1552)** — Routing inheritance decided whether a unit that delegates its spawn to a routed helper may borrow that helper's coverage. It worked as a blacklist: inherit unless the unit's own memo "looks boolean". A `Map` string-union verdict spells neither "boolean" nor a policy-factory name and slipped through, and a genuine boolean reached through a type alias slipped through the same way, since the word only ever appears in the alias's own declaration. The gate now works as a whitelist: a unit inherits routing only when its own memo is traceably a policy factory's handle, directly or through one hop of a module-local wrapper. An unrecognised shape defaults to unrouted instead of routed. - **A resolved blocker no longer re-appears as "Unresolved from this turn" after pi-lens has confirmed the file clean (refs #1561)** — When a blocker on file A is caused by something in file B, fixing B re-analyzes B, not A. A's stale verdict was invalidated only by a later dispatch of A itself or by A being deleted, so it kept being injected at every turn end for the rest of the session. In one dogfood session it was re-served six times, and the agent burned three turns proving it wrong. Worse, three of those re-serves happened after the agent ran `lsp_diagnostics` on the file and pi-lens answered "confirmed clean": that confirmed result corrected the widget footer and nothing else. It now also retires the file's stale blocker, and clears the `--lens-guard` commit gate that the blocker was holding — both the in-memory latch and the persisted record, so a retired finding stops blocking the commit instead of being quoted back as the reason. Retiring is deliberately narrow. It requires a fresh, content-bound result with nothing at the blocking tier; an unconfirmed answer, a silent server, a partial answer missing an auxiliary scanner, a cache replay, or a reconcile that threw all count as unknown, never as clean. It is ordered against the dispatch that recorded the blocker, so a slow old clean cannot erase a newer finding. And it must cover the tools that actually raised the blocker: inline blockers come from every runner, not just the language server, so an eslint, actionlint, biome-check or ast-grep security finding is never retired by a language-server check that did not consult those tools, and a record whose provenance is unknown is never retired at all. Each retire is logged, so the eviction is confirmable from the runtime log. Blockers that go stale before any fresh verdict exists need a dependency-aware staleness key and remain open in #1561. - **A truncated grammar download no longer poisons the file permanently ([#1564](https://github.com/apmantza/pi-lens/issues/1564))** — the #1548/#1560 wasm-magic check catches a captive portal's HTML, but a connection dropped mid-transfer still starts with a genuine `\0asm` preamble, so it passed. The runtime download path now verifies the full body against the pinned sha256 in `scripts/grammars.lock.json` (the same manifest the postinstall path already trusts), falling back to a Content-Length compare when no pinned hash is available. A `Language.load` failure on a file resolution just vouched for now also records a degradation naming the grammar and the loader's error, and invalidates the resolve memo so the next demand re-fetches instead of reusing the same broken file forever. - **Tests no longer reset a duplicate copy of the module state they are guarding (closes #1565)** — Vitest resolves an import specifier literally and this repo's runtime is the compiled output, so `x.ts` and `x.js` are two module instances. A test that imported a module's reset or inspection API through `.ts` held a private copy of that module's mutable state: the `beforeEach` reset cleared the copy, the code under test kept reading the compiled original, and the assertion passed without ever exercising the behaviour it claimed to guard. Seventeen test files were reaching the same module both ways, most of them around the availability latches. Every test now imports the compiled `.js` the runtime imports, a new structural guard (`tests/config/module-instance-coverage.test.ts`) fails CI on any new `.ts` specifier for a build-compiled module, and a live regression test proves the session availability reset actually clears the compiled latch. No shipped behaviour changes; the guarded behaviour is now genuinely guarded. - **The availability-policy coverage gate no longer inherits routing from a memo that merely mentions a policy handle's name (refs #1566)** — The #1552 whitelist checked whether a policy handle's name appeared anywhere in the memo's declared type or value. A memo typed `Awaited>>` unwraps a routed wrapper's return type down to a plain boolean, and a memo built by `emptyCache(makeToolProbe)` merely hands the wrapper to an unrelated helper as an argument — both spell the handle's name without holding the handle, and both inherited routing they never earned. The gate now requires the handle's name to be the memo's own un-nested `ReturnType` or its own direct `= name(...)` call, so a name present anywhere else in the text no longer counts. - **The ast-grep native-addon load no longer starves a concurrent caller or latches across sessions (refs [#1567](https://github.com/apmantza/pi-lens/issues/1567))** — `loadSg()` guarded the `@ast-grep/napi` load behind a plain "attempted" flag, set before the load began. The per-edit fallback runner and the session-start project scanner both call it and could race: a caller arriving while a load was already in flight read the flag as "already tried" and got back `undefined` for a load that was still pending and about to succeed — a false-negative starvation, not a duplicate load attempt. Any load failure then latched for the rest of the process, with no re-arm at session start, so a repaired install stayed invisible until the host restarted. The fix shares one in-flight promise across every caller, evicted on settle so a rejected load is never replayed (the `#1536` pattern); every failure now holds until `resetAstGrepNapiLoadState()` re-arms it at the next `session_start`. There is deliberately no in-process cooldown-then-retry for a transient failure: `@ast-grep/napi` loads via a dynamically imported `file://` URL, and Node's ESM loader permanently caches a module record that threw during evaluation, so a same-process retry would only replay the cached rejection. A classifier still distinguishes a narrow, positively-identified transient errno family from a genuine failure (an unrecognized error, including any real native-binding incompatibility, is genuine by default) so the degradation ledger — a held load now records an `ast-grep-napi-unavailable` entry, distinguishing a degraded scan from a clean one with nothing to report — says something honest about what happened. - **A stalled ast-grep binary no longer pins the whole session to `npx` (closes #1568)** — Both ast-grep availability sweeps walk an ordered candidate list — local `node_modules/.bin`, then PATH, then a package manager's global bin, then `npx --no -- ast-grep` — and stop at the first candidate that answers. A candidate that timed out was recorded, but the record was read only when *every* candidate had failed. So one busy second at warm-up, with a healthy ast-grep on PATH, ended with `npx` selected and cached as a durable fact: a Node process started for every ast-grep invocation for the rest of the session. A win reached while a preferred candidate was merely unreachable is now provisional — it is used immediately, and re-checked once that candidate's cooldown expires, so a recovered binary wins its place back without a restart. A genuine absence still caches, unchanged. And if the re-check itself times out on a host that is still busy, the command already proved working is kept rather than discarded — a timeout says nothing about a tool that ran 30 seconds ago. The `availability_decision` entry in `latency.log` says which case it was, carrying `provisional: true`, `unreachablePreferred`, `retained`, and `retryAfterMs`. - **A tool tier degraded by a transient stall no longer survives 24h across process restarts ([#1569](https://github.com/apmantza/pi-lens/issues/1569))** — `getToolPath`'s persistent probe cache (`~/.pi-lens/probe-cache.json`) recorded only the winning path, with no memory of whether a preferred candidate along the way had merely stalled rather than proven broken. A `--version` probe that timed out, was killed, or hit an unspawnable-process glitch (Windows `spawn UNKNOWN`, EAGAIN/EBUSY) fell through to a lower-priority tier exactly like a genuine absence, and that degraded selection was then trusted for the full 24h TTL — with no session reset touching it, since the cache outlives the process. The persisted entry now carries whether any candidate was transient at selection time, and a tainted entry ages out after the shared transient cooldown (5 min) instead of the full TTL, so a process restarting minutes later re-probes instead of inheriting the stall. - **A failed lazy-module load or classic-tsserver repair no longer stays broken for the rest of the process (closes [#1570](https://github.com/apmantza/pi-lens/issues/1570))** — `clients/lsp-lazy.ts`, `clients/formatters-lazy.ts`, `clients/dispatch/lazy.ts`, and `clients/mcp/session.ts` each memoized a lazy `import()`/session-context promise with `x ??= ...`, which keeps a REJECTED promise cached for the process lifetime: one transient module-load failure (EMFILE, a momentary fs error) permanently poisoned that seam for every later caller. A new shared `createLazyImport` helper (`clients/lazy-import.ts`) evicts the memo on rejection so the next demand retries; no cooldown, since module loads are cheap. `clients/bootstrap.ts`'s per-client-fail-soft bootstrap promise got the same defensive eviction, though it is not expected to reject in normal operation. Separately, the classic-tsserver repair guard (`clients/lsp/server.ts`) was a one-shot per-process flag with no re-arm — a repair that failed once (an offline install, a registry hiccup) stayed unrepairable for every later session in a long-lived extension-host process. `resetLSPService({reason: "session_start"})` now re-arms it on every session start. - **Formatter config-file cache now sees files created mid-session, for several formatters that previously missed it (refs #1572)** — the per-cwd formatter cache invalidates when a tracked config file's mtime/size changes, but `psscriptanalyzer-format`'s settings file, `google-java-format`'s marker, `cljfmt`'s bare `.cljfmt`, several `cmake-format` variants, sqlfluff's `setup.cfg`, oxfmt's `vite-plus.json`/extra `vite.config` extensions, and the Kotlin/Spotless gradle files were never in the tracked list — so adding one of them to a project after pi-lens had already looked at that directory kept returning the stale, pre-opt-in answer for the rest of the session. All are now tracked. - **`psscriptanalyzer-format` can now be selected for `.ps1`/`.psm1`/`.psd1` files, and honors its settings file (closes #1572)** — `.ps1`'s formatter policy required explicit project config before offering the formatter, but the formatter had no config check at all: no configuration of a PowerShell project could ever select it. A project with a `PSScriptAnalyzerSettings.psd1` (or `ScriptAnalyzerSettings.psd1`) now selects `psscriptanalyzer-format` the same way a `.clang-format` or `stylua.toml` selects its formatter — and the resolved settings file is now passed to `Invoke-Formatter -Settings`, so an opted-in project's declared rules apply instead of the stock ruleset. A new coverage guard asserts every registered formatter is selectable under some configuration, so this shape can't recur silently. `tryLazyInstall`'s unreachable `golangci-lint` arm — golangci-lint already auto-installs through the shared tool-installer seam — was removed rather than wired to a second, redundant install path. - **npm-global tool discovery now flags a stalled package-manager probe as transient (refs #1585)** — `isAvailable`'s bare boolean return could not tell a genuine "pnpm not installed" from a `where`/`which pnpm` probe that stalled, so `allAvailableGlobalBinDirs` silently dropped pnpm's global bin dir with no way to warn its caller. `findNpmGlobalToolPath`'s existing `onTransient` callback (from #1569) now fires for this case too, so `getToolPath` no longer caches a degraded npm-global selection untainted for the full 24h TTL. - **A scanner that answered while its resync sat queued is no longer reported as a blackout (refs [#1586](https://github.com/apmantza/pi-lens/issues/1586))** — the fan-out gate allows one outstanding `didOpen` resync per auxiliary, and a touch that queues behind another is DEFERRED. Whether a deferred scanner nonetheless covers the file is a content-hash question, and the deferred door asked it of the PRE-NOTIFY snapshot: a set captured before the write went out, which by construction cannot see the publication that arrives after it. So when the write the gate deferred behind landed and the scanner published for exactly the bytes this touch carries, the touch still dropped those findings from `.diags` and still named the scanner in `unconfirmedServerIds` — a scanner that had demonstrably reported reading as one that had gone silent, which is [#1549](https://github.com/apmantza/pi-lens/issues/1549)'s underclaim one door over. Coverage is now ONE rule (the pre-notify snapshot unioned with a live content-binding read, both going through a single content-match comparator so a door cannot acquire a rule of its own by writing the comparison inline) evaluated ONCE, as the last statement before the merge. Every door that shares the merge's consequences reads that frozen answer: the merge drop, the deferred door, the merged content binding — where a dropped contributor now loses its findings and its fingerprint together, rather than the fingerprint being filtered on the raw deferral set — and the result's own `unconfirmedServerIds`, which reconciles the auxiliary wait-outcome verdict (decided earlier, when the wait ended) against the merge before anything is claimed. Freezing it is what makes the fix safe in both directions: `touchFile` awaits after the merge, and asking the live rule again when the coverage gap is named let a publication landing in that window un-name a scanner whose findings the merge had already dropped — `confirmed` over a `.diags` missing the scanner's answer, which is the overclaim direction and the one that unblocks the last-known-diagnostics cache prime and the warm mark that the coverage gap exists to hold shut. The honest case is unchanged and still fails closed: a deferred scanner with no binding for these bytes keeps its stale findings dropped and stays named, and a scanner whose breaker was open never attached at all, so there is nothing to read for it and it stays named too. `lsp_scanner_coverage_gap` and `lsp_touch_file` report the deferrals the touch is actually uncovered for rather than every deferral; the gate's own action keeps its unconditional record in `lsp_notify_resync_deferred`. - **`TreeSitterClient.init()` no longer replays a dead `import()` on every file parse (refs [#1592](https://github.com/apmantza/pi-lens/issues/1592))** — `init()` called `loadWebTreeSitter()`, a dynamic `import()` of a fixed resolved `file://` URL, and only latched permanently on errors matching an Emscripten `Aborted`/`abort()` signature. Any other rejection — for example the module throwing during evaluation — left `initPromise` cleared, so the next `init()` call (one per file parse, via `withTreeSitterRoot()`) re-imported the same URL and replayed Node's cached rejection instead of re-attempting the load: a retry that looked like a retry and structurally could not be one. `init()` now classifies the rejection (`classifyWebTreeSitterLoadFailure`, mirroring `classifyAstGrepLoadFailure`): a RESOLUTION-shaped failure (`ERR_MODULE_NOT_FOUND`, a transient fs errno) still retries on the next call, because it can plausibly clear on its own; an EVALUATION-shaped failure latches for the SESSION and records a `web-tree-sitter-load-failed` degradation once. The latch is session-scoped, not process-lifetime — `resetLoadStateForSession()` on `TreeSitterClient`, exposed as `resetTreeSitterClientLoadState()`, is wired into `resetDispatchBaselines()` beside `resetAstGrepNapiLoadState()`, matching the `#1567`/`#1575` precedent — and stays distinct from the existing `wasmAborted` latch, which covers a corrupted heap from a runtime that DID load and deliberately stays process-lifetime. `clients/lazy-import.ts`'s docstring now states the underlying ESM-cache limit explicitly: eviction-and-retry recovers a resolution failure but replays the cached rejection for an evaluation failure, so callers must not read "retries" as "can recover from a broken compiled module mid-process." A class sweep of every dynamic-import retry/cooldown site in `clients/deps/*.ts` and its callers found no other dead-retry sites: the `@ast-grep/napi` loader already latches this way (`#1575`), and every other lazy `import()` in the codebase is either a one-shot local-module load (no retry ceremony to be dishonest about) or a network/filesystem-backed retry (grammar downloads, `Language.load` on WASM bytes) that is genuinely retryable and outside the ESM-cache class. The new session-scoped latch is registered in the `#1635` session-state registry (`tests/support/session-state-registry.ts`), replacing that file's prior blanket exemption for `tree-sitter-shared.ts`. - **The retained-winner arm no longer re-serves an ast-grep command this same sweep just proved gone** — both the shared `isSgAvailableAsync` sweep and `SgRunner.ensureAvailable()` retain a provisional winner across a stalled sibling tier, but neither checked whether the memoized winner itself was among the candidates that ENOENTed in that same pass. A previous provisional winner (say `npx`) that goes durably missing while an unrelated tier merely stalls used to still answer available with the dead command; the sweep now tracks which candidates it proved durably absent and skips the retained arm when the memoized command is one of them, falling through to the genuine-absence path instead (#1593). - **Basename-classified files (`Makefile`, `Dockerfile.`) reached `didOpen` as plaintext, invisible to the #1545 extension-seam guards (refs #1594)** — `clients/file-kinds.ts`'s `SPECIAL_FILENAMES` classifies `Makefile`, `Dockerfile(.)?`, and `CMakeLists.txt` by basename regex into `lspCapable` kinds, but `clients/lsp/language.ts`'s `getLanguageId` only resolved language ids through `LANGUAGE_EXTENSIONS`, a flat extension/literal-basename map. `Dockerfile` and `CMakeLists.txt` happened to work because two hand-kept literal keys covered their exact spelling; `Makefile` had no entry at all, and `Dockerfile.dev`/`Dockerfile.prod`-style suffixes never matched the literal `"Dockerfile"` key. `getLanguageId` now falls back to a `BASENAME_LANGUAGE_PATTERNS` list derived from the now-exported `SPECIAL_FILENAMES`, filtered to `lspCapable` kinds — the same single source of truth `detectFileKind` already uses, not a second hand-kept literal list. The two now-redundant literal keys (`"CMakeLists.txt"`, `"Dockerfile"`) were removed from `CURATED_LANGUAGE_EXTENSIONS` since the derivation covers them. `terragrunt.hcl`/`root.hcl` stay unresolved by design: `terragrunt` is `lspCapable: false`. - `clients/file-kinds.ts` — `SPECIAL_FILENAMES` exported. - `clients/lsp/language.ts` — `getLanguageId`, `BASENAME_LANGUAGE_PATTERNS`. - `tests/clients/lsp-capable-seam-coverage.test.ts` — basename-classifier coverage guards mirroring the existing extension-classifier guards 4-6. - **Seven more config-gated formatters were unselectable under any project configuration (refs [#1595](https://github.com/apmantza/pi-lens/issues/1595))** — same shape as [#1572](https://github.com/apmantza/pi-lens/issues/1572): commit `038cd1df` set `defaultWhenUnconfigured: false` for `csharpier`, `ormolu`, `taplo`, `terraform`, `swiftformat`, `fantomas`, and `mix` without adding a matching `hasExplicitFormatterConfig` check, so neither selection branch could ever pick them. Each now wires into `EXPLICIT_FORMATTER_CONFIG_CHECKS` against its real config-file convention — `.csharpierrc`, `.ormolu`, `taplo.toml`/`.taplo.toml`, `.swiftformat`, `.fantomasignore`/`.editorconfig`, `.formatter.exs` — or, for `terraform fmt` (which has no config file at all), the `.terraform.lock.hcl` manifest `terraform init` writes as an explicit per-project opt-in marker. `nixfmt` stays unreachable: it has no config surface and no manifest-marker equivalent, so a documented exception replaces the fix. - **An exit-0 PSScriptAnalyzer run with empty or malformed stdout no longer reports the file as clean (refs #1598, refs #1540)** — `PS_SCRIPT` always writes the literal `[]` marker or a diagnostics array before exiting 0, but `parsePSAnalyzerOutput` treated any unparseable stdout the same as that marker, so a lost or truncated write (a host quirk, not a real clean file) reported `succeeded` with zero diagnostics identically to a genuine clean run. The parser now returns `null` for empty or malformed stdout, distinct from a real `[]`; the runner reads `null` as an unreadable run, logs an `availability_decision` (tool `psscriptanalyzer-stdout`) and a `grammar-blocked` degradation-ledger entry, and skips without latching `-File` off — one bad read is not durable evidence the interpreter is broken, mirroring the nonzero-exit branch's own guard. #1540's fix covered the `-File` nonzero-exit and `status === null` paths in the same function; this covers the exit-0-but-unreadable-stdout gap its review flagged as out of scope. - **`BiomeClient`'s in-flight leak guard could not fail (refs #1601)** — the regression test for "the `ensureInFlight` slot doesn't leak after a failed probe" used a probe failure that latches durably, so the second `ensureAvailable()` call short-circuited on the availability memo and never reached the `ensureInFlight` check the test claimed to cover; removing the `finally`-clear it names left the test green. The suite now probes through the one path that actually reaches that check — a transient (timeout) verdict whose cooldown has expired — and is proven red against the described mutation. A second test covers the settled-slot-through-cooldown window directly: two callers racing in as the cooldown opens must share one fresh probe rather than one of them resolving off a leaked settled promise. A sweep of every other `ensureInFlight`-based client (`sg-runner.ts`, `dead-code-client.ts`, `knip-client.ts`, `dependency-checker.ts`, `security-scan-client.ts`, and the shared `toolchain-availability.ts` factory ruff and friends route through) found the same `finally`-clear on all of them; no production code changed. - **PSScriptAnalyzer's execution-policy regex tightening now has regression tests (refs #1604)** — the #1556 review round tightened `policyDenied`'s detection from a bare `securityerror|execution polic(y|ies)|running scripts is disabled|unauthorizedaccess` alternation to requiring `securityerror` paired with one of the other three, closing a false positive where a bare `UnauthorizedAccessException` (a file-permission error, unrelated to the execution policy) or a stray mention of "execution policy" in unrelated stderr latched `-File` off as a durable policy block. That tightening shipped with no test proving the false positive it closed. Two regression tests now pin it: reverting the regex to the pre-#1556 alternation turns both red, confirming the current AND-conjunction is load-bearing, not vacuous. - **Security scanners log a compensating `available` row when auto-install recovers a failed probe (refs #1606)** — gitleaks, trivy, and opengrep probe on PATH first and fall back to the pi-lens installer; govulncheck falls back to `go install`. When the probe failed but the install then resolved the binary, the probe's `unavailable` record stood alone in `latency.log`: nothing said the tool came back. An auditor reading the log concluded the lane was off when it was on. A second `availability_decision` row now fires on every recovery path, with `verdict: "available"`, `cause: "ok"`, `classifiedBy: "caller"`, and the binary's basename plus its install source in `evidence`. - **agent_end no longer misreads a disabled feature as a missing cache (closes [#1607](https://github.com/apmantza/pi-lens/issues/1607))** — The `actionable_warnings_autofix` reader at `agent_end` read the actionable-warnings cache on every call, but the cache is only ever written when the `lens-actionable-warnings` flag is on. In production that flag is off, so the read always missed and logged "cache missing or expired, skipping fixes" — 428/428 times in the retained log, per a maintainer-supervised forensics pass, always blaming a stale cache instead of the real cause: the writer is disabled. The reader now checks the writer's own flag before attempting a read, so a disabled writer produces no read attempt and no misleading log line. When the flag is on and a read does miss, `CacheManager.inspectCache` (already used by `git-guard.ts` for the same purpose) distinguishes "cache absent" from "cache expired," instead of collapsing both into one ambiguous message. - **`language: TypeScript` ast-grep rules now run on `.tsx` files** — the napi runner compared a rule's declared language against `.tsx`'s exact grammar name (`"tsx"`), so every `TypeScript`-tagged rule's language guard skipped it on React/TSX sources, leaving 120 of 263 shipped rules dark there. `.tsx`'s grammar is empirically a syntactic superset of `.ts`'s for every construct the shipped catalog's rules target, verified per rule (not assumed) by asserting each `TypeScript` rule's existing fixture-test `invalid:` snippet still matches parsed as tsx — so a `TypeScript`-tagged rule now also runs against a `.tsx` file's parsed root. A rule skipped purely for a language/file mismatch is now recorded in the same aggregated `astgrep_napi_unsupported_rules_skipped` latency telemetry the runner already emits for wholly-unsupported languages, so an empty result on a `.tsx` scan is distinguishable from "rules never ran" (#1608). - **Several installer writes and two persisted-state read paths did not survive a hard kill cleanly (refs [#1609](https://github.com/apmantza/pi-lens/issues/1609))** — a derived sweep test (`tests/clients/atomic-write-sweep.test.ts`, `tests/support/atomic-write-scan.ts`) that enumerates every raw filesystem-write call under `clients/` at test-run time (not a hand-maintained list) found `clients/installer/index.ts` writing several downloaded tool artifacts (bare-gzip binaries, bare binaries, Maven jars and launchers, archive-install shims, the npm bootstrap `package.json`, and a GitHub "extra asset" sibling file) straight to their final path instead of through the shared atomic tmp+rename seam (`clients/atomic-write.ts`, #762) — a process killed mid-install could leave a corrupt binary or launcher behind. All nine sites now go through `writeFileAtomicAsync`, which gained an optional `mode` option so the executable bit still travels with the staged file across the rename. The sweep itself judges each write call by its own TARGET argument and by each file's own `node:fs`/`node:fs/promises` import bindings — not by a whole matched line or a whole-file "imports the seam somewhere" check — so a scratch-named DATA argument or a differently-named `fs` import can't hide an unrelated violation. The `session_start` orphan-staging sweep (`clients/runtime-session.ts`) now also covers the installer's `bin/` and `tools/` directories, which it omitted entirely; `sweepOwnStagingFiles` doesn't recurse, so an orphaned staging file left there by a kill mid-install was never reaped and repeated kills would have accumulated full-size orphan binaries. Fault injection also found two read-side gaps: `clients/instance-registry.ts` degraded a corrupt/torn `instances.json` to empty exactly like a genuinely missing file, with no way to tell a real torn-write regression from a normal clean start — a non-`ENOENT` read failure (or a valid-but-wrong-shape file, which a torn tail can produce) now records one `instance-registry-corrupt` degradation via `recordDegradationOnce` (deduped per session, since the read path is called far more often than just at session start), while a missing file stays silent. And `deserializeProbeCache`'s locked write-side merge threw on a torn `probe-cache.json` instead of degrading like its sibling deserializers, so a torn cache file could never be repaired by a later successful flush — it now degrades to `{}` and logs the recovery, matching `diagnostic-dispositions.ts` and `actionable-warnings.ts`. - **~16 CLI runners now log recovery when auto-install fixes a failed tool probe (closes #1612)** — `resolveAvailableOrInstallUnshared`, the shared seam behind golangci-lint, ruff, shellcheck, pyright, knip, jscpd, and about a dozen other runners, wrote a latched `unavailable` `availability_decision` row when the PATH probe missed, then fell through to the pi-lens installer. If the installer resolved the binary, nothing recorded that recovery — the durable log kept saying the tool was off after it came back on. This is the same defect shape #1606/PR #1610 fixed in `security-scan-client.ts`'s `ensureViaInstaller`, on a seam with a much larger blast radius. A second row now fires on that recovery path, with `verdict: "available"` and an `evidence.source` tag DERIVED from the tool registry's own install strategy (`managed-dir`, `pip-user`, `github-release`, `archive-dist`, or `maven-jar` — never hand-mapped). The row fires once per correction, and its `install`/`resolved` evidence is read from the installer's own attempt record rather than assumed from a truthy result, so a cache-resolved recovery reads `install: "not-attempted", resolved: "cache"` instead of dishonestly claiming a fresh install on every dispatch. - **Marking a secrets/security finding false-positive or won't-fix now sticks, on every reporting lane (refs [#1617](https://github.com/apmantza/pi-lens/issues/1617))** — `applyDispositions` (the dispatch pipeline's agent/user mark filter) was only ever wired into the per-edit dispatch path; gitleaks, trivy, and govulncheck reported straight from their own scan caches with zero disposition wiring, so an agent-marked false-positive re-reported on every turn_end gate check and every `lens_diagnostics mode=full` scan. A new `applyDispositionsMultiFile` (`diagnostic-dispositions.ts`) extends the SAME anchor derivation dispatch already uses to lanes whose findings span many files in one report, grouping by each finding's own file and reading its current content once; a file that can't be read fails OPEN (still reported) for a false-positive's content-hashed anchor, while a weak-anchored suppress mark — which never looks at content — still applies. Wired into `lens_diagnostics mode=full`'s single `record()` choke point (covers knip, jscpd, madge, gitleaks, govulncheck, opengrep, trivy, dead-code in one place) and into turn_end's gitleaks secrets gate plus its govulncheck/trivy advisory sections, using each lane's existing `ProjectDiagnostic` adapter so a mark made against what `lens_diagnostics` showed the agent is honored everywhere. A disposition-dropped finding now surfaces a "suppressed by disposition: N" trace in both surfaces instead of silently vanishing (the #1616 suppressed-bucket rule). Trivy's *secret* findings (as opposed to its CVE findings, which are covered) have no existing `lens_diagnostics`-surfaced identity to anchor a mark against and are tracked as a follow-up rather than shipped with an unreviewed anchor shape. - **Idle-reset timer no longer destroys the LSP service mid-sweep (closes [#1618](https://github.com/apmantza/pi-lens/issues/1618))** — `handleTurnEnd` arms a detached idle-reset timer on a file-less turn, but `lens_diagnostics mode=full` grants its own workspace sweep a 300s wall-clock ceiling; a maintainer-supervised forensics pass found the timer firing mid-sweep and mislabeling ~81 service-destroyed files as budget exhaustion. `clients/lsp/workspace-sweep-hold.ts` adds a token-based hold that `runWorkspaceDiagnostics` acquires for its whole call (try/finally, so an overlapping sweep or a throw still releases correctly); the idle-reset timer now defers instead of firing while any sweep holds it, and re-arms a fresh delay once the last sweep releases. The delay on EVERY idle-reset path (base, subagent, and cross-process-budget-shortened) is now derived from the sweep's own wall-clock ceiling plus a safety margin, so the constants can't drift back into this relationship — an accepted, deliberate cost of a longer default idle residency (up from 240s to ~360s) for the derivation's coherence. A hold also clears at `session_start` and force-releases past its own max age (with a distinct log record), so a leaked hold can't permanently disable idle reset. `LSPWorkspaceDiagnosticResult` gains a discriminated `unconfirmedReason` (`budget` / `inconclusive` / `coverage_gap` / `service_destroyed` / `error` / `binding_mismatch`) so a destroyed service, a stale content binding, a real timeout, and a thrown error each render distinctly instead of collapsing into "within budget"; `touchFile`'s destroyed early-return now emits a cheap, local `lsp_touch_file` record instead of leaving zero trace; and `scripts/analyze-pi-lens-logs.mjs` (the forensics tool that found #1618) now reads the per-reason tally instead of blaming budget exhaustion for every unconfirmed file. - **LSP teardown no longer hangs on a wedged server, leaking the process (refs #1620, #1459)** — `clientShutdown` bounded the `shutdown` request but awaited the `exit` notification with no timeout. A notification write on a pipe that is not draining neither resolves nor rejects, so the await never returned. Everything after it was skipped: the connection was never disposed, no `lsp_client_shutdown` record was written, the child was never deregistered from the instance registry, and the process was never killed. The wedged-write breaker calls this teardown precisely when a server's stdin has already been proven wedged, so every demoted server leaked — three surviving `ast-grep` processes on one host, plus older orphans, with coverage degrading as the leak compounded. The `exit` notification now has its own ceiling (`PI_LENS_LSP_EXIT_NOTIFY_TIMEOUT_MS`, 1s, matching the request budget, so a healthy server still exits gracefully), and disposal, the record, the deregistration, and the process-tree kill moved into a `finally` block so they run no matter how either write behaves. The `lsp_client_shutdown` record gains `exitNotifyTimedOut` and a rolled-up `shutdownOutcome` of `graceful`, `forced`, or `fast`, so a forced teardown is countable from the log instead of showing up as a missing record. - **LSP teardown: live-wedged proof, precise failure attribution, and safe idempotent shutdown (refs #1620)** — closes out the residuals from #1624's bounded `clientShutdown` fix. Adds a real-child-process fixture (`FAKE_LSP_WEDGE_STDIN_AFTER_INIT`) proving the bound holds against a genuinely wedged OS pipe, not just a mocked connection — the prior unit-level test alone did not exercise real pipe backpressure. `lsp_client_shutdown` now distinguishes a real timeout, a genuine rejection, and a SWALLOWED stream error (`safeSendRequest`/`safeSendNotification` resolve instead of rejecting on EPIPE/disposed-connection, which previously reported a nothing-was-delivered teardown as `shutdownOutcome: "graceful"`) via `shutdownRequestUndelivered`/`exitNotifyUndelivered`, alongside the existing `*TimedOut` pair. `clientShutdown` is idempotent — two callers racing to shut down the same client (8 call sites can race the same state) share one teardown instead of each running the RPC handshake and inflating any `shutdownOutcome: "forced"` count — but ONLY when the in-flight teardown's options are at least as aggressive as the new call's; a `fast`+`processExiting` session-exit call no longer inherits a weaker in-flight graceful teardown's wait (or its `taskkill` spawn, which `processExiting` exists specifically to forbid while the event loop is closing). A rejected teardown also no longer latches a permanently-dead promise — it clears so the next call actually retries instead of silently giving up on the leak. - **Rename propagation no longer hangs on a wedged LSP server (refs #1621, #1620)** — `LSPService.renameFile` awaited `client.closeDocument` and `client.didRenameFiles` with no timeout. A notification write on a pipe that is not draining neither resolves nor rejects, so one wedged server stalled its `Promise.all` and blocked the rename for every healthy client alongside it. Both notifies now carry their own budget (`PI_LENS_LSP_RENAME_NOTIFY_TIMEOUT_MS`, 1500ms). Rename propagation is best-effort advice to servers, not a correctness gate, so a timed-out `didRenameFiles` notify is recorded in the existing failure ledger and the rename still completes; a timed-out `didClose` still aborts and resynchronizes the rename, matching the existing failure path. Each ledger entry now carries a `disposition` of `timedOut` or `rejected`, so an empty failure list still means clean and a stall is never indistinguishable from a genuine rejection. - **Cached secret findings no longer replay pre-edit line numbers (refs #1622)** — the turn-end secrets blocker cited a gitleaks line for the full 30-minute cache TTL even after the agent edited that file, because the delivery gate probed only whether the cited path still existed. Existence is not authority: the TTL says the cache is young and the stat says the file is there, and neither says the line number is still true. The gate now returns a three-way freshness verdict per cited path, from one memoized `statSync` per delivery. A deleted path still drops. A path whose mtime is newer than the store's `scannedAt` is **demoted, never dropped** — the finding is still surfaced, out of the blocker tier and without the line number the edit invalidated, because dropping it would let any edit, malicious or accidental, mute a real credential. An unmodified path delivers unchanged at full severity. Trivy's secrets lane gets the identical gate, and govulncheck drops the cached call-site line for an edited file while keeping the CVE. An unparseable or absent `scannedAt` disables the staleness arm rather than demoting a whole store on a clock anomaly. Each demotion writes one bounded `finding_stale_line_demote` record per store per delivery, mirroring `finding_dead_path_drop`, so the replay window is readable from `latency.log` instead of only inferable. What a deleted file means is now per-store: for secrets it drops, because a credential in a deleted file cannot be rotated; for govulncheck it demotes, because the CVE is pinned by `go.mod` and one deleted call site does not un-pin it. Demoted secrets keep their rule id and source (`src/config.ts — generic-api-key [gitleaks]`) so the agent can still triage them, and they render in their own tier with an imperative preamble rather than under the "no action required this turn" advisory label. A turn whose only finding is a demoted secret reports as `stale_secrets_pending` rather than `clean`. - `clients/advisory-provenance.ts` — three-way freshness verdict, per-delivery stat memo, the `gateFindingsByPathFreshness` delivery seam, and the per-store `onMissing` policy. - `clients/runtime-turn.ts` — gitleaks, trivy secrets, and govulncheck read through the gate; demoted secrets get their own tier, preamble, rule/source detail, and turn-result telemetry; the govulncheck header renders off the post-gate list so it can never print with zero rows. - `clients/latency-logger.ts` — `finding_stale_line_demote` excluded from `lastPhase` attribution, like its drop-record sibling. - **Fix "age unknown old" grammar in lens_diagnostics cache-age notes (refs #1623)** — the render call sites that report a lane served from cache in `lens_diagnostics mode=full` (test-runner findings, the cheap project scan under `refreshRunners=cached`) appended the literal word "old" after `formatCacheAge` unconditionally. When the underlying cache metadata had a missing or corrupt timestamp, `formatCacheAge` already degraded to "age unknown" instead of fabricating a NaN age (#1623 fix-round F4) — but the caller still glued "old" onto it, rendering the ungrammatical "test-runner (age unknown old)". A new `formatCacheAgeOld` helper (`clients/project-diagnostics/extractors.ts`) is the single place that decides whether "old" belongs on the string; both render sites now go through it instead of hand-rolling the suffix. - **lens_diagnostics now names every lane that did not run, instead of rendering silence as clean (refs [#1623](https://github.com/apmantza/pi-lens/issues/1623))** — `mode=full` without `refreshRunners` never ran the heavyweight analyzers (gitleaks, knip, trivy, govulncheck, opengrep, jscpd, madge, dead-code) or the cheap in-process project scan (tree-sitter/fact-rules/ast-grep), but said nothing about it — a result with no gitleaks section read exactly like "gitleaks ran and found nothing," per a maintainer-supervised dogfood forensics pass. Each lane now renders a "not run (\)" marker. Each gate captures its own specific reason at the exact point it decides, reusing the SAME availability taxonomy (`AvailabilityOutcome`/`AvailabilityCause`) dispatch-side messages already use — so a durable absence ("gitleaks binary unavailable"), a transient probe under its own retry cooldown ("retry cooldown (15s), not a missing install"), and a project-trust install denial for govulncheck are three different, honest sentences instead of one confident "unavailable" guess. That taxonomy is a single source of truth (`fetchFreshProjectDiagnostics`'s `coldReasons`, `clients/project-diagnostics/fresh-fetch.ts`) the render layer reads rather than re-deriving. A second dogfood pass reported the mirror problem for cache-served lanes (test-runner's cache-only findings, and the cheap project scan under `refreshRunners=cached`, including when nothing has been cached yet) being misread as a fresh run — all now render their status explicitly ("cached, 18m old — not re-run", or "not run (no cached scan; refresh to populate)"), guarding a corrupt/missing cache timestamp against rendering a fabricated "NaNh old". - **A blocking secrets finding can no longer be silenced by a loosely-matched mark (refs [#1617](https://github.com/apmantza/pi-lens/issues/1617))** — the disposition filter added for the secrets/security lanes let a WEAK-anchored suppress or defer (matched on file/tool/rule/message, no line content) drop a `"blocking"`-tier finding. Two distinct secrets sharing one gitleaks rule — two different AWS keys, say — collapsed onto the same weak anchor, so marking one false-positive silenced both. A blocking finding now drops only via the STRICT, content-bound false-positive anchor; a weak suppress or defer never touches it, in the dispatch filter, the cache-only instant filter, and the session-wide defer set alike. The suppressed-count trace (`lens_diagnostics mode=full` and turn_end) now also breaks its total down per analyzer ("gitleaks 2, knip 1"), and a per-project defer can no longer bleed into an unrelated project sharing the same relative file path. - **Trivy secret findings now honor dispositions (closes #1628)** — Trivy's own secret scan (`TrivyResult.secrets`) had no `ProjectDiagnostic` identity for an agent to anchor a `lens_diagnostic_mark` call against, so a false-positive mark could never suppress it — the same bug #1617/#1625 fixed for gitleaks, govulncheck, and Trivy's CVE lane, left open for Trivy's secret lane. A new `trivySecretFindingToProjectDiagnostic` adapter (rule id `trivy-secret:`, namespaced apart from the CVE lane's `trivy:`) now surfaces these findings in `lens_diagnostics mode=full` and routes them through `applyDispositionsMultiFile`/`turn_end`'s disposition filter, matching the existing gitleaks/govulncheck/Trivy-CVE wiring. - **`instance-reaper-prune-concurrency` no longer times out flakily under CI contention (closes #1629)** — root-caused, not just re-budgeted. Solo, the 40-iteration `#1217` concurrency test measured 1.7-3.3s against vitest's 5000ms default, but 8 runs alongside 5 contended sibling suites blew that budget 3/8 times (5.1-6.4s) — genuine test-budget starvation, not a `pruneDeadInstances` regression (the write path is unchanged fs I/O; #1738's registry-write serialization did not touch it). The describe block now declares an explicit 30s timeout (matching this repo's existing `HEAVY_IO_TIMEOUT_MS` convention), with the measurement in a comment. A second, independent defect surfaced under the old 5s budget: a timed-out test's `for` loop keeps running in the background (vitest's timeout races a timer against the test promise; it does not cancel in-flight work), and its next `pruneDeadInstances` call re-reads the now-repointed `PI_LENS_HOME` and writes its zombie staging file into the NEXT test's temp directory — failing that test's "leaves no staging files behind" assertion with the PRIOR test's litter. `afterEach` now drains the last-known in-flight prune promise before the next test's `beforeEach` repoints the env var, closing that window. Both the timeout comment and the drain are backed by controlled before/after measurement (N=8 contended local runs pre-fix: 3 failures; N=4 contended runs post-fix: 0 failures) and a mutation probe (forcing a real timeout at a 700ms budget: with the drain, only the timed-out test fails, cleanly; with the drain removed, the sibling test also fails on leftover `.tmp-` litter, 3/4 runs). - **knip no longer reports an export as unused after a new test imports it (refs #1630)** — pi-lens runs knip with its own `--cache-location`, and knip's glob cache only revalidates the directories that contributed a matched file. A directory that matched nothing when the cache was written is never recorded, so a consumer added to it stays invisible to every later cached run: knip keeps reporting the export as unused, and pi-lens renders that stale verdict as fresh. This is what made a dogfood session see an "unused export" warning that a direct `knip` run in the same project did not reproduce. pi-lens now deletes knip's glob cache before each run, which forces a fresh file walk while the module and plugin caches — which carry nearly all of the speed — survive. Measured on this repo with knip 6.4.1: uncached 3.3s, fully cached 1.3s, glob cache dropped 1.4s. Upstream knip fixed the glob cache in 6.28.0; the prune is unconditional because the managed install floats and older versions are still common. - **Cached cross-file blockers no longer replay for the whole session after the cause is fixed in a dependency (closes [#1631](https://github.com/apmantza/pi-lens/issues/1631))** — a blocker recorded on a file F is a verdict about F *and everything F imports*, but every existing invalidation path keyed on F alone. When the cause was fixed in a dependency G — especially out-of-band, where G is never dispatched — no event fired and F's stale verdict re-served at every turn end and on every `lens_diagnostics mode=all` for the rest of the session (the #1561 dependency-axis remainder, observed live four times). A turn-boundary freshness sweep now runs before a cached blocking finding is re-served: it stats F and its forward imports (resolved through the parse layer — no reverse-dependency index, so the tests-free-index blocker that holds #1561's full invalidation does not apply) against the verdict's timestamp. On drift the finding is DEMOTED, not dropped (#1419): the turn-end re-serve moves it out of the authoritative blocker channel into a `[stale — re-run to confirm]` advisory, and the widget store that feeds `mode=all` marks it stale so it renders as a non-blocking `[stale]` entry instead of a 🔴. The gate lives at the cache layer on both stores — `RuntimeCoordinator` inline blockers and `widget-state` — and never re-pulls LSP verdicts on its own, avoiding the document-resync hazard of re-querying an LSP whose in-memory dependency document is itself stale. Each turn logs a bounded `blocker_freshness_sweep` phase (and `mode=all` a `blocker_freshness_widget_gate` phase) naming the revalidated/kept/truncatedImports counts so a future replay is reconstructible from `latency.log` alone. The full dependency-axis invalidation (actively re-verifying consumers when a dependency is dispatched clean) remains deferred to #1561. - **Dependency-drift blocker freshness gate: review-round hardening (refs #1631)** — the read-time freshness gate from PR #1633 landed with issues found across two review rounds. The `+1ms` drift tolerance (borrowed from same-process single-writer reconciles) false-demoted a blocker recorded immediately after its own file write on Windows, where mtime measurably leads `Date.now()` by up to ~11.4ms; the tolerance is now `+50ms` at every comparison site, including a third site (`reconcileStaleWidgetFiles`'s own-file gate) found while red-proving a flaky-looking "control" test — the same host-clock skew, not cross-test state. Demotion is now narrowed to language-server-sourced findings (`sources`/`tool === "lsp"`): an ast-grep secret or a CVE finding doesn't stop being true because a file it imports changed, so it stays fully blocking through a dependency edit. A dependency-drift demotion no longer survives `exportWidgetState`/`importWidgetState` — the same #1348 shape as a failed-formatter entry, one field over — so a real blocking finding can't resume as permanently non-blocking after a session restore with the dependency pinned back into the past (`WIDGET_STATE_VERSION` bumped to 3). Round 2 found the fix itself restored `diagnosticCounts` verbatim from the snapshot instead of recomputing it from the migrated (stale-stripped) entries — a resumed record could report `isBlocking() === true` on an entry while its own `diagnosticCounts.blocking` still said 0, inverting the one predicate every consumer trusts; counts are now derived the same way every other write site derives them. Forward-import resolution is now memoized per turn (keyed on path+mtime, reset on `RuntimeCoordinator.turnIndex` advancing, not process-lifetime), covering both the turn-end sweep and the `mode=all` gate that were independently re-parsing the same files. Each `blocker_freshness_sweep`/`blocker_freshness_widget_gate` latency record now names how many entries had their import list truncated at the drift-check cap. The footer/red-dot render no longer silently drops a demoted finding — it now renders with a dimmed marker and the stale-marker text instead of vanishing from the list `isBlocking` was also gating the render loop against. `STALE_LINE_MARKER` moved out of the turn orchestrator into its own leaf module (`clients/stale-marker.ts`) after round 2 found the low-level widget store importing it from `runtime-turn.ts` introduced a new module cycle. The `retired` count in `BlockerFreshnessCounts`, always zero because the gate is architecturally demote-not-drop, is removed rather than kept as dead API surface (and the two remaining doc sites that still promised it are corrected); the module docs name the dynamic `import()`/`require()` resolution boundary as an honest gap. - `clients/blocker-freshness.ts` — `MTIME_DRIFT_TOLERANCE_MS = 50` (exported), `sources`-based LSP-only demotion gate, per-turn import-resolution memo, `ForwardImportMtimes.truncated`, `BlockerFreshnessCounts.truncatedImports`, `retired` removed. - `clients/widget-state.ts` — `reconcileStaleWidgetDependencyBlockers` narrowed to `tool === "lsp"` and returns `{ demoted, truncatedImports }`; `reconcileStaleWidgetFiles`'s own two tolerance checks widened to the shared constant; `migrateEntryStamps` strips `stale` on import; `importWidgetState` recomputes `diagnosticCounts` from the migrated entries instead of restoring the snapshot's counts verbatim; `WIDGET_STATE_VERSION` bumped to 3; `renderWidget`'s blocker-detail loop renders demoted entries instead of dropping them; `STALE_LINE_MARKER` now imported from `clients/stale-marker.ts`. - `clients/stale-marker.ts` (new) — `STALE_LINE_MARKER`, moved out of `runtime-turn.ts` to break a widget-state → runtime-turn module cycle (`madge --circular clients/widget-state.ts`: 45 → 44 cycles, the one involving `runtime-turn.ts` gone). - `clients/runtime-turn.ts` — imports `STALE_LINE_MARKER` from the new leaf module instead of defining it (resolving the merge conflict with master's #1627); `retired` dropped from, `truncatedImports` added to, the turn-end latency record. - `tools/lens-diagnostics.ts` — imports `STALE_LINE_MARKER` from the leaf module instead of a hardcoded literal; passes the runtime's `turnIndex` into the `mode=all` gate and logs `truncatedImports`. - `AGENTS.md`, `.changelog/fix-1631-blocker-freshness-gate.md` — `retired` replaced with `truncatedImports` in both doc sites that still promised the removed count. - **Every agent-facing finding surface now either routes through the shared freshness/disposition gate stack or explicitly states its cache age — no more silent third state (refs [#1634](https://github.com/apmantza/pi-lens/issues/1634))** — #1461/#1561/#1622/#1631 each converged the SAME freshness fix onto one store at a time (secrets, govulncheck, cached cross-file blockers), but nothing enumerated every surface that renders findings to the agent, so a new store could still bypass both the gate and any honesty about staleness. The trivy CRITICAL-dependency-CVE blocker, non-critical CVE advisory, and license-risk advisory in `clients/runtime-turn.ts` were exactly that gap: package-pinned findings with no cited file:line to freshness-gate, reading a session_start cache that can be arbitrarily old, rendered with zero age signal — a 🔴 STOP blocker from hours ago presented as current. `clients/finding-delivery-gate.ts` is the new single documentation home: a `DELIVERY_SURFACES` registry enumerates every render seam (turn-end blocker/advisory tiers, `lens_diagnostics` mode=full/all, the widget footer, agent nudges, the persisted project-diagnostics snapshot) as either `gated` (names the real gate call) or `labeled` (names a reason and an age source), and `assertNoDeliveryBypass()` rejects any third shape. The three trivy reports now carry a `formatCacheAgeLabel()` suffix (`"trivy, scanned 45m ago"`, degrading to `"scan age unknown"` on a missing/unparseable timestamp rather than fabricating a number) instead of no signal at all. `tests/clients/finding-delivery-gate.test.ts` ground-truths every registered surface's declared gate/label call against its actual source file, so a gate call removed from source without updating the registry — or a labeled surface silently losing its age string — fails the suite. - **markdownlint and 14 other CLI runners now log recovery when the install-fallback helpers fix a failed probe (closes #1636)** — `resolveToolCommandWithInstallFallback` and `resolveCommandArgsWithInstallFallback`, the seam behind actionlint, biome-check, hadolint, htmlhint, ktlint, markdownlint, mypy, oxlint, rubocop, sqlfluff, stylelint, swiftlint, taplo, vale, and yamllint, recovered a tool through the pi-lens installer after a checker had already latched it `unavailable`, but wrote no compensating row. The durable log kept saying markdownlint's lane was off while it ran and succeeded (live evidence from a dogfood session). This is the third site of the #1606 defect shape: #1610 fixed `ensureViaInstaller`, #1612/#1615 fixed `resolveAvailableOrInstall`. This fix reuses the exact `emitCompensatingAvailableRow` constructor #1615 landed rather than forking a third copy, so both seams share the once-per-correction memo and the same evidence derivation. Carried over from #1615's review: `resolved` now distinguishes `"cache"` (a session/probe cache hit), `"path"` (a plain PATH or managed-dir discovery, no install involved), and `"declined"` (policy refused the install and handed back whatever discovery found anyway) — collapsing all three into `"cache"` misread a project-trust decline as a resolved-and-trusted answer. `getInstallAttempt` is now a hard import (a removed export throws instead of silently reading as "not attempted"). - `clients/dispatch/runners/utils/runner-helpers.ts` — `emitCompensatingAvailableRow` (shared row constructor), `resolvedTagForAttempt`, `verifyOrInstallCommand` wiring. - `clients/dispatch/runners/utils/availability-policy.ts` — `ProbeEvidence.resolved` widened to `"cache" | "path" | "declined"`. - `clients/installer/index.ts` — `getLastEnsureResolutionSource`, the new signal that lets the compensating row tell a plain PATH/managed-dir discovery apart from a cache hit. - **`createVenvFinder` now checks the managed tools dir before falling back to PATH (closes #1638)** — the resolver behind `createAvailabilityChecker` (golangci-lint, ruff, shellcheck, pyright, shfmt, spotbugs, terragrunt, tflint, trivy, helm, jscpd, knip, ktfmt, madge, and others) checked venv paths, then fell straight to a bare-name PATH probe. A tool installed only into `~/.pi-lens/tools/node_modules/.bin/` (where `ensureTool` puts npm-strategy installs) never resolved there, so every dispatch re-probed PATH, missed, spawned a doomed `--version` process, and only then fell through to the installer's own cache a few lines later — one wasted spawn per dispatch, for the life of the session, on top of the availability noise that made #1615's compensating row re-fire on every call. `createVenvFinder` now checks `findManagedNodeToolBinary` — the same managed-dir lookup already used elsewhere in this file — between the venv paths and the bare PATH fallback. - `clients/dispatch/runners/utils/runner-helpers.ts` — `createVenvFinder`. - **TypeScript diagnostic-sequence records now report a real settle duration, a real version, and a distinct source for every settle shape (closes #1639)** — `lsp_typescript_diagnostic_sequence` had the same three bugs on BOTH its producers. The push-path producer, `logSequence` (the `textDocument/publishDiagnostics` handler), is the one that actually generated the issue's cited evidence: it put time-since-`didOpen` in the top-level `durationMs` field on every settled record instead of the settle operation's own time (147/239 records showed >60s "durations" for settles that took milliseconds), hardcoded `version: docVersion ?? null`, and logged its raw per-publication receipt with no `settleSource` at all — the exact "unsettled-then-settled" pair (~61ms apart, near-identical document age) the issue described as a double-emit is this function's own designed shape (a receipt record immediately followed by its eventual settle record), not the pull path. The pull-path producer, `logTypeScriptPullSettle`, had the identical durationMs/version bugs and a real (if rarer) double-settle: `ensureWarmForSweep`'s warm-up-only readiness probe and a sweep's real content-collecting touch both run a genuine pull round trip for the same file — both fixed here too. `durationMs` now measures the settle itself (the debounce wait for a `quiet-window` settle, 0 for an immediate `first-push` settle or a `pull`/`pull-warmup` request's own round trip); document age keeps its own honest name, `metadata.elapsedSinceDidOpenMs`. `version` never reports `null`: push settles report the real server-reported version or `"push-unversioned"`; pull settles report the real tracked value from `diagnosticsVersionsByPath` or `"pull-unversioned"`. Every settle shape now carries an explicit `settleSource` — `"first-push"`, `"quiet-window"`, `"publication"` (the raw per-publication receipt, not itself a settle), `"pull"`, or `"pull-warmup"` — so no two legitimate observations read as indistinguishable duplicates. - `clients/lsp/client.ts` — `logSequence` (push path) and `logTypeScriptPullSettle` (pull path) both take the settle's own `durationMs` and an explicit `settleSource`; the push handler's per-publication receipt is now tagged `"publication"` instead of logging with no source at all; both fall back to an honest `-unversioned` marker instead of `null`. - `clients/lsp/index.ts` — `touchFile`'s per-server wait tags `pullSettleSource: "pull-warmup"` when the touch's `source` is `"lsp_sweep_warmup"`. - Checked `scripts/analyze-pi-lens-logs.mjs` for consumers of the old `durationMs`/`version: null` semantics on this phase: none exist today, so nothing else needed updating. - **TypeScript diagnostics on files outside every tsconfig no longer block** — a file that matches no project's `include` is still checked by tsserver, but in a synthetic *inferred* project with default compiler options the project's own `tsc --noEmit` never uses. Those diagnostics now render as warnings labelled `not in any tsconfig project — checked with inferred settings; add /** to a tsconfig for authoritative checking` instead of unlabelled 🔴 blockers. They are demoted, never suppressed: the live report that prompted this found the batch was a mix of phantom errors and genuine ones the project's own gate cannot see. Detection asks tsserver directly (`projectInfo` → `configFileName`); when the probe cannot answer, nothing is demoted. - **Diagnostics no longer cite lines past the file's current EOF (refs #1641)** — a live session got errors at lines 407-410 of a file that was 402 lines on disk and unmodified: the LSP's in-memory document had drifted longer than disk with no write ever happening, so the mtime-based freshness gates (#1622/#1627) had nothing to catch. The fix is a structural, orthogonal check: a diagnostic whose cited line exceeds the file's CURRENT on-disk line count cannot be describing current content, regardless of any timestamp. The gate demotes the entry (`stale: true`), never drops it — the underlying issue may still be real, just at a coordinate this gate can no longer vouch for — and writes one bounded `diagnostic_past_eof` record naming the file, cited line, actual line count, and serving surface. `lens_diagnostics` (mode=all and mode=full, via `formatAllMode` — the single point both converge through) triggers a best-effort document resync on a demotion, so the desync heals instead of re-serving the same stale verdict on the next call; the TUI widget's higher-frequency render path demotes without resyncing, to avoid storming the LSP with didOpen calls from a loop that fires far more often than an agent's edit cadence. A new `lsp_document_send` record logs each didOpen/didChange's document version and content length at SEND time, so a later past-EOF citation can be paired with the send that produced it and the divergence moment reconstructed. The line-count check counts newlines in bounded chunks (never a full-file read) and memoizes the result in a shared, mtime-invalidated, size-bounded cache — see the review-round fragment below for the full cost story. - `clients/diagnostic-line-freshness.ts` — new: `demotePastEofDiagnostics` (the gate), `getCachedLineCount`/`createLineCountCache` (mtime-invalidated line count), `resyncDocumentOnPastEof` (best-effort didOpen resync via `LSPService.openFile`). - `clients/widget-state.ts` — `WidgetDiagnostic.stale`; `isBlocking`/`countDiagnostics` exclude demoted entries from the blocking/error/warning tallies; the gate runs in `getFileDiagnosticSummaries`, `getFileDiagnostics`, and the TUI's blocking-diagnostics render loop. - `tools/lens-diagnostics.ts` — `formatAllMode` gates the final merged summary set (covering both the cached mode=all path and mode=full's freshly-merged LSP results, since a "fresh" sweep's server can still be citing its own stale in-memory document); demoted lines render `PAST_EOF_STALE_MARKER` instead of a line number, and a file whose only findings are demoted stays visible with a "stale — re-run to confirm" note rather than reporting clean. - `clients/lsp/client.ts` — `recordSentContent` now logs `lsp_document_send` (version + content length) on every didOpen/didChange. Turn-end's "unresolved from this turn" inline blockers are NOT covered — that store only carries a pre-formatted summary string (`{ filePath, summary }`, `runtime-coordinator.ts`), with no structured line field for this gate to check, and #1633's dependency-freshness gate is already the active work on that exact structure. Composing a line-count check into it belongs with that PR, not duplicated here. - **Past-EOF diagnostic gate review round (refs #1641)** — six findings from adversarial review. The line-count convention was `wc -l` style, but `WidgetDiagnostic.line` is LSP `range.start.line + 1` addressing: a document with N newlines has N+1 addressable lines (the position after a trailing `\n`, or the single line of an empty document, is real, and servers anchor EOF diagnostics there — e.g. TS1005 `'}' expected`). A 2-real-line file with a trailing newline was demoting its OWN valid EOF error at line 3. Fixed the count to `newlineCount + 1` uniformly. The line-count cache was scoped to one render pass and re-created every call, which deduped nothing (each file appears once per pass) — every serving call paid a full synchronous file read, measured at 35.68ms/call across 40 files and 30.78ms per TUI frame on a 6MB file. Replaced the full read with a bounded chunked byte scan (raw file descriptor, no UTF-8 decode, no whole-file string) behind a 4MB size gate (matching `captureReadContentBinding`'s precedent), and made the cache shared and FIFO-bounded across calls instead of single-use — it still cannot go stale, because every read re-stats the file first and only trusts the memo when the mtime still matches. The store also used to latch: once a diagnostic was marked `stale`, the gate never re-checked it, so a transient shrink (a formatter pass, a checkout, a partial write) that later restored stayed permanently demoted. The gate now re-derives the verdict from current inputs on every call — the rising edge logs and resyncs, the healing direction is silent, and a restored line un-demotes on its own next read. The `lsp_document_send` telemetry record's line count used `content.split("\n")`, which both disagreed by one with the gate's pre-fix convention and allocated one substring per line (13.3ms/200k allocations on a 7MB send); it now counts newlines directly, matching the gate exactly. The gate now runs AFTER dispositions and rule policy in `lens_diagnostics`, so a policy-dropped or marked-suppressed finding never triggers a resync or a telemetry record for something that isn't actually being served. `PAST_EOF_STALE_MARKER` now composes with the shared `STALE_LINE_MARKER` base (extracted out of `runtime-turn.ts` into `clients/stale-marker.ts`) instead of duplicating the string. - `clients/diagnostic-line-freshness.ts` — `newlineCount + 1` line convention; chunked byte-level newline scan (`countNewlinesChunked`) replacing the full-file read; 4MB size gate; shared, FIFO-bounded, mtime-invalidated cache (`sharedLineCountCache`) as the default, with `createLineCountCache()` still available for test isolation; `demotePastEofDiagnostics` re-derives `stale` on every call instead of short-circuiting on an already-demoted entry, logging/resyncing only on the rising edge. - `clients/lsp/client.ts` — `recordSentContent`'s `contentLineCount` counts newlines directly instead of `content.split("\n")`. - `clients/widget-state.ts` — `applyPastEofGate` always persists the freshly re-derived array back into the record (not only when something newly demoted), so a healed entry's `stale: false` actually reaches the store. - `tools/lens-diagnostics.ts` — the past-EOF gate moved to run after `applyWeakDispositions`/`applyRulePolicy`. - `clients/stale-marker.ts` — new: `STALE_LINE_MARKER`, extracted from `runtime-turn.ts`. - **Verify round: line-count memo keyed on size too (refs #1641)** — moving the line-count cache to module scope (the review round's F2 fix) introduced a HIGH finding: the memo was keyed on `mtimeMs` alone, and this host's mtime resolution (~1ms) is coarse enough that two writes in the same tick collide — truncate-then-write, a formatter write-back, a checkout, or pi-lens's own auto-format immediately followed by the agent's write. Measured live at 207/300 shrink/restore cycles serving the wrong line count, including a first-read-of-cycle returning a stale count for an 11-line file — a false-demotion source in the same class as the review round's own F1 line-convention bug. `LineCountCacheEntry` now also stores `size`, and a cache hit requires both `mtimeMs` and `size` to match; a shrink/restore cycle always changes size, so this closes the collision with no added I/O (size is already on the same `fs.Stats` the mtime came from). - `clients/diagnostic-line-freshness.ts` — `LineCountCacheEntry.size`; `getCachedLineCount` compares both fields for a hit. - **Turn-end inline blockers now gate on past-EOF lines too (closes #1641)** — the "Unresolved from this turn" blocker re-served at `turn_end` (`RuntimeCoordinator`'s `_pendingInlineBlockers`) could still cite a line beyond the file's current on-disk line count, re-asserted at full blocking authority. #1664 wired the past-EOF gate into every `WidgetDiagnostic` surface (widget-state, `lens_diagnostics`, the TUI render loop) but deferred this one store to #1633, which merged without it. The record now carries the cited lines structurally (captured at write time from the same diagnostics the summary text was rendered from, not re-parsed from that prose later), and a new turn-end sweep (`clients/blocker-past-eof.ts`) demotes a record citing an out-of-bounds line to the `[stale — re-run to confirm]` advisory instead of the authoritative blocker channel — the same demote-not-drop precedent, re-derived fresh every turn end so a transient shrink-then-restore un-demotes on its own. It composes with #1631's dependency-drift gate on the same store via a shared `staleReason` field: each gate only heals demotions it made itself. - **A gitignored worktree edit could dirty the parent checkout (refs #1642)** — `tool_result` resolved a relative path against the project root instead of the cwd/worktree the call actually ran under, so a worktree edit could collapse onto a same-relative-path file in the parent checkout, which the deferred-format staleness fallback then formatted. `tool_call` now records the resolution basis (its own cwd) by tool-call identity (correlated via `toolCallId`/`callId`/`requestId`/`id`, whichever the host populates); `tool_result` resolves its own authoritative post-execution path against that basis instead of guessing. A relative path with no recorded basis fails closed (logged as `path_attribution_missing`) rather than falling back to a guess; a genuine call-time/execution-time divergence is logged (`path_attribution_refused`) as a diagnostic without gating the outcome. A blocked call's recorded basis is cleared immediately so it never leaks into the correlation cache. The deferred-format staleness fallback now also requires the queued record's true origin cwd (distinct from the workspace-root `turnStateCwd` used for bookkeeping) to match the claiming session's before treating an aged-out record as a recoverable orphan; a mismatched-origin record is left queued and logged, never formatted or deleted. - **The #1605 lifecycle-smoke lane's phase 5 now genuinely exercises an absent `gh`, and `safeSpawnAsync` decides a never-started spawn from the `close` event's own shape (refs #1651)** — phase 5 pinned outcome `"missing"` for a genuinely-absent `gh` binary, and passed on Windows but got `"non-installable"` on Linux CI. A debug pass added a raw `spawnSync("gh", ["auth", "token"])` probe right where the lane's own removal happens, and it answered `status: 1, stderr: "no oauth token found for github.com"` — a genuine, correctly-completed `gh` run. GitHub-hosted `ubuntu-latest` runners carry a *second* `gh` on PATH that `which gh` doesn't report first; the lane's PATH exclusion only stripped the one `which` did report, leaving the other one reachable the moment the fixture was deleted. Phase 5 was never testing a missing binary on Linux at all — it was asking the classifier to explain a real rejected-auth answer while asserting the missing-tool verdict. `classifyGhTokenFailure` was correct both times; the harness's setup was not. `findAllOnPath` (`which -a` on POSIX; Windows' `where` already lists every match) now finds every `gh` on PATH, and `pathWithGhMasked` swaps in a shadow directory — every OTHER file in that directory linked, `gh`/`gh.exe`/`gh.cmd` omitted — instead of excluding the whole directory: an earlier version of this fix excluded the whole directory and broke phases 1/2/4 instead, because GitHub-hosted `ubuntu-latest` keeps `getconf` in the same `/usr/bin` the second `gh` lives in, and pi-lens's own resource sampler shells out to it. Separately, this investigation also surfaced (and fixed) a genuine, narrower `safeSpawnAsync` hazard: Node's docs leave the `error`/`close` event order unspecified for a child that never launched, and the real shape for that case is a negative code (`-2` for ENOENT on Linux, `-4058` on Windows), with `error` sometimes landing a full tick later via `setImmediate`/`process.nextTick`. The `close` handler now decides straight from `code === null || code < 0` — a shape no completed process ever produces — independent of whether or when `error` fires, reusing `error`'s Error when it's already available and synthesizing an ENOENT-shaped one otherwise, with a single `resolved` flag so whichever handler decides first wins outright (including the inverse: a healthy `close(0, null)` is never downgraded by a late, unrelated `error`, e.g. a post-exit `kill()` failing with `EPERM`). `classifyGhTokenFailure` also gets a belt for the same reason: it no longer trusts a bare `!res.error` as proof `gh` ran and answered — a `null`/negative `status` alone (OS-independent, read off Node's own report) now routes through the missing/transient handling regardless of whether `error` happened to be attached. That spawn-race fix did not turn out to be what made phase 5 fail (the harness bug did), but it closes a real correctness gap this investigation surfaced. - `scripts/smoke-availability-lifecycle.mjs` — `findAllOnPath`, `pathWithGhMasked`, `maskedGhDir`, `shadowFile` (replace the single-match `findOnPath`/`pathWithoutDirOf`). - `clients/safe-spawn.ts` — the `close`/`error` handlers inside `safeSpawnAsync`. - `clients/zizmor-config.ts` — `classifyGhTokenFailure`'s `neverAnswered` guard. - `tests/clients/safe-spawn-close-before-error-race.test.ts` — regression tests for the `close(-2, null)`/`close(null, null)` shapes (with and without a delayed or absent `error`) and the healthy-run non-inversion case. - **Package-manager availability latches re-arm at `session_start` (closes #1653)** — `resolveNodePackageManager` keeps one `AvailabilityLatch` per pnpm/yarn/bun/npm in a module-local map, so a genuine "missing" verdict from one session stayed latched into the next: install pnpm mid-day, start a fresh session, pi-lens still reported it missing until a process restart. Same module-local shape as psscriptanalyzer's latches (#1490) and zizmor's `gh auth token` cache (#1535) — `resetDispatchAvailabilityState`'s generation counter never reached it because nothing called the module's own reset hook. `handleSessionStart` now calls `_resetPackageManagerCache()` in its per-session reset block, beside `resetZizmorTokenAvailability()` and `resetPsScriptAnalyzerAvailability()`. - `clients/runtime-session.ts` — `handleSessionStart`'s per-session reset block. - `clients/package-manager.ts` — `_resetPackageManagerCache`'s doc comment now records it as production wiring, not just a test hook. - Review round: making the reset a real production path exposed a latent race in `isAvailable`'s in-flight probe map — its `.finally` deleted the map entry by key rather than by identity, so a pre-reset probe that settled after a new session's own probe for the same manager was already in flight could evict that newer entry and cause a duplicate spawn. Fixed with the same identity guard `resolveMadge` in `dependency-checker.ts` already uses for the equivalent race. - **Deferred format/autofix drain no longer runs mid-run on auto-retry or overflow-compaction (refs #1654)** — pi's `agent_end` fires on every completion of `_runAgentPrompt`, including a run about to auto-retry or resume after overflow-compaction; pi computes `willRetry` only after emitting `agent_end` and never exposes it to extensions. Running the #1387 deferred-format/autofix drain there could format files the agent was still actively working on between retries, shifting lines under queued work and staling in-flight content bindings (the #1642 harm family). The drain now runs at `agent_settled` — pi's documented once-per-run signal ("no automatic retry, compaction, or queued continuation will run") — with a best-effort, time-boxed safety net at `session_shutdown` so a run that ends without ever settling does not strand queued work forever. - **Hardened pi-lens against five pi host-contract facts it mishandled (refs #1655)** — pi's `emitToolCall` is the one extension emit path with no per-handler `try`/`catch`, and its caller rethrows as "Extension failed, blocking execution", so any unguarded throw inside pi-lens's `tool_call` handler blocked the user's tool call outright; the handler now absorbs every throw, records one `tool-call-handler-throw` degradation per tool name, and lets the tool proceed. Telemetry identity no longer comes from `tool_result`/`session_start` event fields that pi never sets — it is read from `ctx.model`, so the reported model and provider stop being `"unknown"` for the whole session, and the seven vacuous fields plus the unreachable branch they fed are gone. A tool_call's edit batch width is snapshotted at handler entry instead of re-read from the live, mutable `input` object hundreds of lines later. pi-lens now resolves a tool path the way pi does, in both of pi's stages: the base resolution (unicode-space folding, `@` mention-prefix stripping, `~` expansion, `file://` conversion, Git-Bash drive paths) and then the fallback ladder (narrow no-break space before AM/PM, NFD, U+2019, NFD plus curly quote). A path pi opens — a macOS screenshot name, an `@`-prefixed mention, a `file://` URL, a non-breaking space — is no longer invisible to the read guard, the LSP warm, and the dispatch, and a path that still does not resolve records a `path-variant-unresolved` degradation instead of returning in silence. A blocked tool call also stays blocked when its own bookkeeping fails: the read guard's refusal is no longer discarded by a throw in the telemetry that follows it. The invariants behind the tool cwd basis and bash-side path attribution are pinned by tests against pi's own build. - **`safeSpawnAsync`'s post-exit pipe-idle wait no longer pays out its full 100ms grace window on every call (refs #1656)** — the wait now finishes as soon as Node's `close` event fires (the stronger, already-available signal that stdio is fully released), instead of always idling out the timer. A normal spawn, where nothing holds its pipes open, now settles in a few ms again; a daemonized descendant that never emits `close` is unaffected and still bounded by the existing grace/cap timers. - **`safeSpawnAsync`'s post-exit pipe-idle wait no longer lets a late, unrelated error steal an already-decided healthy verdict (refs #1656)** — the wait added to fix the daemonized-descendant hang left the outcome undecided across the whole (bounded, up to 2s) idle-grace window, widening a race a prior fix had closed down to a single microtask: a post-exit `kill()` failing with EPERM 10ms after a clean `close(0, null)` could flip a successful run to a spawn failure. The verdict is now latched immediately once the exit/close event decides it, before the idle wait runs, so a late `error` can never downgrade it. - **`safeSpawnAsync` no longer hangs forever on a daemonized descendant that inherits its stdout/stderr pipe (refs #1656)** — the async spawn path waited for Node's `close` event, which only fires once every file descriptor referencing the child's stdio has been released. A Windows-orphaned grandchild (no job object) can hold that inherited pipe open indefinitely, so `close` never fires even though the process we spawned is long dead — the caller hangs, and a hung prober silently loses its result rather than failing loudly. Adopting pi's `waitForChildProcess` construction: finalize off `exit` instead, then wait for stdout/stderr to fall idle (no data for 100ms, re-armed on every chunk, capped at 2s so a pathological never-quiet descendant can't extend the caller's overall budget). A quiet inherited handle now releases after one grace window; an actively-streaming child is still captured in full. - **A compensating `available` row that corrected nothing no longer silences the real one** — the once-per-correction memo now burns only when a latched `unavailable` row actually stood before it. Runners that reach the install seam with no probe of their own (biome-check, oxlint) emitted a row that pre-empted the next genuine latch-then-recover for the same tool and directory, leaving the durable log saying the tool was off while it ran. Managed-tool resolution also runs the installer's own `verifyToolBinary` check instead of a bare `existsSync`, so a broken shim no longer shadows a working PATH binary; a settled verdict is memoized per shim per session, a verification that never got to run keeps the optimistic answer under a bounded cooldown, and concurrent first touches share one probe (#1657). - **Pull diagnostics no longer miss whole categories on multi-source servers** (#1667) — a server that registers `textDocument/diagnostic` once per diagnostic source (Roslyn: syntax, semantic, analyzers; vtsls) had every `registerOptions.identifier` discarded, so pi-lens issued one bare pull and never asked for the other sources. The client now pulls every registered source in parallel plus the bare request, answers on the first source with findings for the file, and merges slower sources into the cache in the background. Result-id inheritance (`kind: "unchanged"`) is tracked per source, a source retired by `client/unregisterCapability` no longer leaves its findings in the cache, and workspace-pull support is read from the registration's `workspaceDiagnostics` flag instead of guessed from the method name. - **LSP servers now learn about files a bash command deleted, even though pi-lens never sends `workspace/didChangeWatchedFiles` type 3 anywhere (refs #1668)** — the only enqueue site for that notification (`handleNotifyOpen`, via the #271 `WatchedFilesQueue`) fires on a document's first open and can only emit type 1 (Created) or 2 (Changed). A turn that ran `rm`/`git rm`/`mv` on a file with no notification at all left gopls' package cache, rust-analyzer's vfs, and clangd's index stale, with diagnostics for the deleted module persisting forever. `bash-file-access.ts` gained `extractDeletedPathsFromCommand`, which proposes the explicit targets of `rm`, `git rm`, and the source side of `mv` — never a directory sweep or a `git clean`, since those don't name a file to confirm. `ReadGuard` gained `hasKnownPath`/`forgetPath` so the check only fires for a path pi-lens already has a read or write record for (never an unrelated `rm`), and only after confirming the path is actually gone from disk. A confirmed delete now reaches every already-active LSP client for that file's servers via `LSPService.notifyExternalFileChange`, routed through the same #271 debounced queue a burst of deletes still coalesces into one notification per server — this never spawns a server just to tell it about a delete. Bash-created/modified files that were never opened already got their type-1/2 notification through the existing first-open queue path once the dispatch pipeline's LSP runner touches them; that leg needed no new code, only regression coverage. A git-status delta at turn boundaries (to catch changes outside pi-lens' own write/edit/bash surface — external editors, other processes) was judged and scoped out of this PR as a separate, costlier mechanism. Re-opening an already-open document on a bash-authored change (type 2 on reopen) stays out of scope per the issue, pending a measured cost on gopls/rust-analyzer. - `clients/bash-file-access.ts` — `extractDeletedPathsFromCommand`. - `clients/read-guard.ts` — `ReadGuard.hasKnownPath`, `ReadGuard.forgetPath`. - `clients/lsp/client.ts` — `handleNotifyExternalChange`, `notify.watchedFileChange`. - `clients/lsp/index.ts` — `LSPService.notifyExternalFileChange`, `notifyExternalFileChange` cross-layer seam. - `clients/runtime-tool-result.ts` — bash delete detection wired into the tool_result handler. - **LSP client answers `workspace/diagnostic/refresh` and honors Incremental text sync (refs #1669)** — a server telling us its diagnostics are stale (`workspace/diagnostic/refresh`) previously got `MethodNotFound`; the client now replies `null`, drops every on-disk workspace-diagnostics sweep cache the process has swept under (not just the wrong per-server root marker), clears the same per-document pull state a normal resync already clears for every open document, and proactively re-pulls each open document under pull mode. A `workspace/diagnostic` sweep's `unchanged` report against a resultId basis the client no longer holds now falls back to a real per-file pull instead of silently reporting the file clean. Separately, the client always sent whole-document `didChange` events regardless of the server's negotiated `textDocumentSync.change` kind; an Incremental-only server now receives a single ranged edit spanning its entire previous document (counting CRLF/lone-CR line endings correctly), sent only once the notification is confirmed to have actually reached the transport. `Full`/`None` servers are unaffected. - **Monorepo Cargo and Maven projects no longer spawn one heavy LSP server per crate or module (refs [#1671](https://github.com/apmantza/pi-lens/issues/1671))** — rust-analyzer's existing workspace hoist walked up to an ancestor `Cargo.toml`'s `[workspace]` table without ever checking the session ceiling, so a hit above the session cwd could pick a root outside the project boundary; the walk is now bounded the same way `enforceLspRootCeiling` already bounds crate roots. jdtls had no hoisting at all: every Maven module spawned its own server even inside a declared parent build. It now walks up through a chain of `pom.xml` files, hoisting to a parent only when that parent's `` actually declares the child as a member — an undeclared sibling directory stays independently rooted, and the walk still respects the session ceiling. `NearestRoot`'s doc comment now says plainly that `excludePatterns` skip a directory and keep walking, rather than aborting resolution. - **Path-attribution follow-ups: bounded orphan degradation, documented id-fallback assumption, pinned reclaim test (refs #1678, #1642, #1648)** — A deferred-format record abandoned by its origin worktree used to log a full raw event on every subsequent `agent_end` forever. The raw, detailed event (file identity, origin, age) now fires only on the RISING edge — the first time a given record is observed as an orphan — and every later repeat of the same record is counted only by `incrementDegradationCount`, so the ledger holds one bounded entry with a running count instead of an ever-growing stream of log lines. `resolveToolCallCorrelationId`'s widest fallback (`event.id`) now documents the assumption it makes — a host that reuses one id per message, not per call, would cross two parallel tool calls in a turn — and notes that real pi's own tool events carry no top-level `id` field at all, making this rung dead code against today's host. Added regression tests pinning the rising-edge gating (exactly one raw event across 3 agent_ends on the same orphan) and the already-correct "mismatch-flush leaves queued, later match-flush reclaims and formats" reclaim path. - **Bound the playground rule verifier's child-process wait (closes #1679)** — `scripts/playground-verify-rule.mjs` spawned its CDP/Chrome helper scripts and waited on the child's `close` event with no timeout. A wedged or daemonized child hung the script forever. It now routes through the shared `safeSpawnAsync` (bounded timeout, tree-kill), matching the rest of the codebase's spawn discipline. - **The secrets and govulncheck gates' disposition filters are now proven, not just present (closes #1694)** — `filterFindingsByDisposition` was applied to both the live and stale arms of the gitleaks/trivy-secrets freshness gate since #1625/#1628, and to govulncheck's combined live+stale array, but none of those three had a regression test proving it. Mutating `trivySecretsStaleFiltered.kept`/`gitleaksStaleFiltered.kept` back to the raw pre-filter `.stale` array, or `govFiltered.kept` back to the raw `[...govGate.live, ...govGate.stale]` array, left the whole suite green. New tests in `tests/clients/runtime-turn-secrets-disposition.test.ts` mark a finding false-positive in each of the three lanes and prove it stops reappearing (the gitleaks/trivy-secrets cases use a stale finding — a scan whose cited file was edited afterward, routed into the 🔑 ACTION NEEDED tier; the govulncheck case mirrors the review round's own mutant), each going red against its own lane's mutant independently. `docs/dispositions.md` now documents the dual-scanner double-mark: gitleaks and trivy anchor the same credential under different `tool`/`rule` identities, so clearing a corroborated finding takes two `lens_diagnostic_mark` calls — expected defense-in-depth, previously undocumented. `trivySecretsToProjectDiagnostics` (no consumer outside its own file) is no longer exported. - **Give `findingPathFreshness` the same mtime-skew tolerance its sibling freshness gates carry (closes #1708)** — `findingPathFreshness` (`clients/advisory-provenance.ts`) compared a finding's cited-file mtime to the scan timestamp with zero tolerance. On Windows, a file's mtime can lead the immediately following `Date.now()` read by up to ~11.4ms, the same host skew `blocker-freshness.ts`'s `MTIME_DRIFT_TOLERANCE_MS` already covers. Without it, a file written and scanned within that window demoted a real secrets STOP blocker to an ACTION NEEDED tier, flaking `runtime-turn-secrets-disposition.test.ts`. `findingPathFreshness` now reuses the same `MTIME_DRIFT_TOLERANCE_MS` constant instead of a second hand-tuned number. - **Give `reconcileProjectDiagnosticsSnapshot` the shared mtime-skew tolerance, not a bare +1ms (closes #1711)** — `reconcileProjectDiagnosticsSnapshot` (`clients/project-diagnostics/cache.ts`) compared a diagnostic's file mtime to the scan timestamp with only a +1ms slack. PR #1710 measured the real write-then-scan skew at up to ~11.4ms on Windows and gave `findingPathFreshness` and `isEntryFresh` the shared `MTIME_DRIFT_TOLERANCE_MS` (50ms) for it, but deferred this consumer. It is the worse sibling: its stale arm DROPS diagnostics outright rather than demoting them, so a same-tick write silently lost a finding from the persisted cache. It now reuses `MTIME_DRIFT_TOLERANCE_MS` from `blocker-freshness.ts`, and the stale-boundary doc comment at `clients/advisory-provenance.ts:264` (and two other spots that had drifted the same way) now cite the tolerance instead of a bare `mtime > scannedAt`. - **Pull-diagnostic timeouts are observable again (refs [#1713](https://github.com/apmantza/pi-lens/issues/1713))** — the per-request `withTimeout` around `textDocument/diagnostic` and `workspace/diagnostic` pulls rejected on timeout, and the rejection skipped every settle emit, so a timed-out pull left no trace beyond a 10-entry `pullFailureHistory` ring buffer. `pullDiagnosticSource` and `clientRequestWorkspaceDiagnostics` now write an `lsp_pull_diagnostic_timeout` latency.log record on every timeout (file, identifier, effective budget, whether a `previousResultId` was echoed, elapsed), and attach a telemetry-only continuation to the abandoned request promise. If the server answers anyway after the caller gave up, that continuation records `lsp_pull_late_answer_discarded` and increments the `lsp-pull-late-answer` degradation-ledger kind (subject = the same file+identifier key the pull path already uses), so a chatty late-answering server's discards are counted, not spammed, and the identity survives aggregation. A late REJECTION is not an "answer" and is not recorded. No behavior change: the timeout path still abandons at budget exactly as before; the instrument only observes. Per-pull overhead is one extra `Date.now()` call (~60ns) on the success path — everything else runs only inside the timeout branch. - **Full-scan sweeps no longer out-run an auxiliary scanner (refs #1714)** — A `lens_diagnostics mode=full` sweep used to hand a single-threaded scanner more documents than it could read, which stalled ast-grep and forced a kill. Each auxiliary now holds a bounded number of unacknowledged `didOpen` notifies; past that, the next notify waits for a request round-trip proving the server drained its input. A file the throttle holds back is reported as uncovered rather than dropped, so it stays in the sweep's coverage gap. Tunable per server class via `LSPServerInfo.notifyInflightLimit` (default 8, ast-grep 4) and globally via `PI_LENS_LSP_AUX_NOTIFY_INFLIGHT`. - **`navRequest` timeouts are observable again (refs [#1716](https://github.com/apmantza/pi-lens/issues/1716))** — the per-request `withTimeout` around every hover/definition/references/signatureHelp/documentSymbol/workspace-symbol/call-hierarchy request rejected on timeout, and the rejection skipped every settle emit, so a timed-out nav request left no trace at all. `navRequest` is the highest-volume LSP call site (one call per turn, often several), so unlike the `lsp_pull_diagnostic_timeout` fix ([#1713](https://github.com/apmantza/pi-lens/issues/1713)), which logs every timeout, this fix bounds the detailed record to the rising edge — the first timeout, and separately the first late answer, per (method, file) each session — while the degradation-ledger counters (`lsp-nav-request-timeout`, `lsp-nav-late-answer`) still count every occurrence exactly, so a storming server floods neither latency.log nor memory. No behavior change: the timeout path still resolves `undefined` at budget exactly as before; the instrument only observes. Per-request overhead is one extra `Date.now()` call (~125ns) on the success path. - **The ast-grep self-scan now actually runs (closes [#1718](https://github.com/apmantza/pi-lens/issues/1718))** — `scripts/run-astgrep-pi-lens.mjs` hardcoded a single author's now-nonexistent machine paths (`C:/Users/R3LiC/Desktop/pi-lens[-rules2]`) as both the scan target and the rules source, so the dogfooded #1158 defect-shape rules (`no-raw-json-store-write`, `no-win32-isabsolute-for-qualification`, `no-bare-host-path-in-win32-branch`, now tagged `metadata.category: pi-lens-self-scan` in their YAML) never scanned pi-lens's own tree — not in CI, not on any contributor's machine. It printed an error internally but exited 0, so the failure was invisible. The script now derives its repo root from its own file location and reads the rule set from the shipped `rules/ast-grep-rules/.sgconfig.yml`, filtered to the tagged subset (scripts/lib/astgrep-self-scan.mjs). It runs in the `test` CI job (`npm run astgrep:self-scan`, ~3.5s over 1074 files in `clients/` + `tests/` — cheap enough for every PR) and fails on any finding outside the committed `rules/ast-grep-rules/self-scan-baseline.json` baseline, regenerable via `npm run astgrep:self-scan:update-baseline` after triage. Triage on this pass: production code (`clients/`) is clean; `no-raw-json-store-write` fired 200× in `tests/` on throwaway test-fixture JSON writes — not durable production state, so `tests/**` joins the rule's existing `ignores:` (build scripts, the atomic-write seam itself) rather than being silently baselined. The baseline ships empty. `tests/scripts/astgrep-self-scan.test.ts` is the registered-or-fail guard: it asserts a nonzero scanned-file count (an empty result must read as errored, not clean — AGENTS.md defect-shape 10) and runs the real scan against a synthetic violation outside pi-lens's own tree, so a future regression that silently kills the scan again fails there instead of shipping unnoticed a second time. - A cascade's neighbor re-check no longer notifies auxiliary scanners (ast-grep, opengrep, typos) for every changed neighbor. A neighbor's content did not change — only its import target did — so an auxiliary scanner's file-local verdict for it cannot have changed, and the cascade's own merge already discarded any aux re-derivation by construction. The touch now uses `clientScope: "primary"` (language server only), matching the sibling tier-aware touch. Measured on a representative slow-aux fixture: 0 aux notifies per neighbor (was 1 per configured auxiliary) and a ~850ms per-neighbor conclusive-latency drop (900ms to 50ms) when an aux scanner is slow to answer. (#1720) - **Knip now runs the project's own knip (refs #1721)** — When a project installs knip, the dead-code scan spawns that copy instead of pi-lens's managed one. A pinned-stale managed knip previously reported unused exports the project's own `npx knip` did not, and acting on those flags deletes live code. A project that installs knip also no longer needs pi-lens's managed copy at all. Each scan records the binary, its version, and the config it ran with in `~/.pi-lens/sessionstart.log`. - **`loop_block` now names a synchronous block still in progress** — every dispatch runner brackets its run with a start/finish marker (`clients/latency-logger.ts`), and an event-loop block attributes to whichever bracket — still running, or recently closed — overlaps the block's own time window the most, instead of only the previous, unrelated phase that had already finished (#1723). - **`loop_block` now records every block over the floor, not only the session's biggest (refs [#1723](https://github.com/apmantza/pi-lens/issues/1723))** — `turn_end` gated the `latency.log` write itself on `shouldLogWorstBlock` (a new-session-maximum test), so any block that did not beat the running high-water was silently dropped. In a session where an early large block set the bar, every later block — including the exact ones that could starve an LSP pull (#1549/#1713) — went unrecorded, making the loop-block-vs-pull-timeout correlation undecidable. `turn_end` now gates on a new floor-only `shouldLogLoopBlock` (still ≥60ms) and keeps `shouldLogWorstBlock` only to compute the `worstSoFar` metadata flag and to decide whether to advance the session high-water. Volume stays bounded by call cadence, not by the gate: the check runs at most once per turn (the histogram window resets every turn), so the cap is one `loop_block` record per turn. Attribution also widens from a single `lastPhase` pointer to a bounded `recentPhases` ring (last 3 of a 5-entry cap) via `getRecentLoggedPhases`, because the phase actually causing a synchronous block is often still in flight — and so unlogged — when the block fires, leaving the single last-*completed*-phase pointer aimed at unrelated prior work. No change to block *detection* (`isSuspendSuspectedBlock`, the histogram, or the per-turn window) — only to what gets persisted. - **A forced LSP shutdown could leave the dead pid registered in `instances.json` for the rest of the session (refs #1724)** — `recordLspChild` and `removeLspChild` each did their own unserialized read-modify-write of the registry file. A client-ceiling eviction's forced shutdown (`removeLspChild`) landing at roughly the same moment as the replacement client's spawn (`recordLspChild`) let the later write revert the earlier one: the replacement's write was built from a read taken before the removal landed, so it silently resurrected the just-deregistered pid alongside the new one. Dogfooding caught a 40-minute phantom this way — a force-shut `ast-grep` process stayed listed as alive across several heartbeats until session-end teardown finally cleared the whole entry. `recordLspChild` and `removeLspChild` now share one mutation queue, so a same-process record and remove can never interleave their read-modify-write against each other. `removeLspChild` also takes an optional spawn marker and refuses to drop a pid whose recorded marker no longer matches — defense against the pid being recycled onto an unrelated child in the (now much narrower) window before the deregistering write lands. - **Sweep the remaining author-machine paths baked into scripts/ and package.json (closes [#1728](https://github.com/apmantza/pi-lens/issues/1728))** — the class sweep from #1718 found three more hardcoded `C:/Users/R3LiC/...` literals. `scripts/run-ts-rules-pi-lens.mjs` now derives its scan root from its own file location (`import.meta.url`) instead of a dead absolute path, so it actually scans the checkout it runs from. `scripts/run-all-ts-rules-posthog.mjs` scans an EXTERNAL checkout rather than pi-lens's own tree, so there is no repo-relative default to derive; it now takes the target via `--posthog-dir`/`POSTHOG_DIR` and exits with a usage message instead of silently no-oping when unset. `package.json`'s `harness:*-poc` scripts dropped their hardcoded `--pi-bin "C:\Users\R3LiC\..."` flag entirely — `scripts/run-harness.mjs`'s own `$APPDATA`-derived PATH resolution already finds `pi.cmd`/`pi` for any contributor, so the literal was both wrong for everyone else and redundant. `tests/scripts/no-hardcoded-machine-paths.test.ts` is the registered-or-fail guard: it greps every script under `scripts/` plus `package.json` for a `C:\Users\` / `C:/Users/` literal, with a reviewed allowlist (currently one entry, tracking `scripts/run-astgrep-pi-lens.mjs` until #1718's own fix in PR #1729 lands) that must itself still contain the literal it excuses or the test fails. - **Managed tools now refresh instead of drifting stale (refs #1730)** — pi-lens installed each managed npm tool once and never re-resolved it, so the copy it ran could be many minor versions behind what its own recorded range permits. A managed knip 28 minors behind reported 62 unused exports on a tree the project's own knip reported clean, and acting on flags like those deletes live code. pi-lens now re-resolves one managed tool per session, at most once a week per tool, on a background timer that never blocks startup. Every refresh records the version it moved from and to in `~/.pi-lens/sessionstart.log`, and verifies the updated binary still runs before trusting it. A refresh that fails records one degradation and clears the cached tool path so the next probe re-checks the tree, rather than blocking the tool. Set `PI_LENS_DISABLE_TOOL_REFRESH=1` to turn it off. - **taplo, biome, stylua, and vulture now prefer the project's own binary and config over pi-lens's managed copy (refs #1731)** — The #1721 sweep found the same defect shape in six more runners. taplo's project-local check was unreachable whenever pi-lens's managed shim answered first, and even its fallback missed an npm-installed taplo on Windows (wrong extension). biome's client path returned the first session's auto-installed binary for every later project, no matter what that project shipped. stylua had no project-local check at all — PATH only. vulture never looked at the project's own `.venv`. jscpd and vulture also always passed `--min-lines`/`--min-tokens`/`--exclude` (jscpd) and `--min-confidence`/`--exclude` (vulture), silently overriding a project's own `.jscpd.json`/`[tool.vulture]` thresholds. biome's `--config-path` did the same to a project's own `biome.json`, blocking its nested-config resolution in monorepos. sqlfluff now spawns with the file's own `cwd` instead of the extension host's, so it resolves `.sqlfluff` against the right project. - **Runner exit codes now gate clean vs. errored (refs #1736)** — Knip, jscpd, and vulture no longer read an empty result on a nonzero exit as "clean." A broken shim, a crash, or a config-load error now reports as errored and records a bounded degradation entry naming the runner and its exit status, instead of silently showing zero issues. - **Managed tools from GitHub releases, pip, gem, archives and Maven now refresh too (refs #1747)** — #1730 unfroze the npm-installed tools. The other 39 managed tools stayed on whatever version pi-lens resolved the day it first installed them, because the installer only runs when a tool is absent. A stale ast-grep, ruff, gitleaks or terraform-ls produces exactly the wrong verdicts #1730 documented for knip. All five remaining strategies now share the same weekly per-tool cadence, the same one-refresh-per-session budget and the same degradation record as the npm path. GitHub tools re-resolve `releases/latest` with a stored `ETag`, so an unchanged release downloads nothing; archive and Maven tools compare the version pinned in pi-lens's own registry and touch the network only when it moved; pip and gem tools re-run their install command in upgrade form. A refreshed binary that cannot report a version is treated as a failed refresh, not a success. The refresh honors the same install kill-switch, project-trust gate and install lock as a normal install. On an EXISTING machine, GitHub tools have no recorded release tag yet, so each one's first refresh downloads its current release once before the ETag comparison starts paying off — roughly 27 sessions of one-time downloads at the one-per-session budget, spread over weeks, not a burst. Set `PI_LENS_DISABLE_TOOL_REFRESH=1` to turn the whole mechanism off. - **ruff `S` security rules now run by default; the IaC misconfig lane now actually scans (refs #1757)** — the bundled `config/ruff/core.toml` enables `S` (Bandit-equivalent), with the sub-rules that over-fired on real code (`S101`, `S311`, `S603`, `S607`) excluded and the exclusion reasons recorded in the config; a project-local ruff config still overrides the bundled one unchanged. Separately, two `trivy config` call sites — the per-edit IaC lane (`clients/dispatch/runners/trivy-config.ts`) and the Helm rendered-manifest pass (`clients/dispatch/runners/helm-render.ts`) — were passing `--no-progress`, a flag that subcommand rejects; every real invocation exited 1 with trivy's usage text on stdout instead of scanning anything. `trivy-config.ts`'s empty-output-only guard missed this entirely and reported a clean scan; `helm-render.ts` already checked exit status unconditionally, so it failed loud instead, but still never scanned a single rendered manifest. Both call sites are fixed, the trivy-config runner now treats any nonzero exit as an error regardless of stdout content (with a bounded degradation-ledger record so this can't go unnoticed again), and the lane now also covers CloudFormation templates (yaml and json). - **Tree-sitter grammar wasms now refresh when the pinned version moves (refs #1760)** — a grammar wasm downloaded once was never replaced when this repo bumped the version it pins, because the cached file's name carries no version. A future fix to a broken grammar build (the class #255 and #427 already hit) would never reach a machine that had already downloaded the broken one. pi-lens now compares each cached grammar's sha256 against the currently pinned manifest (`scripts/grammars.lock.json`) before trusting it, memoized per file so steady state costs no extra hashing and never touches the network. A mismatch is treated as a missing file: the existing lazy fetch re-downloads it, verifying and atomically swapping in the new build, so a failed re-download never destroys the working cached copy. This also catches on-disk corruption, which nothing detected before. - **LSP resync timeout no longer blames a server still spawning (closes #1766)** — When the pre-dispatch resync's wait budget expired while a language server's first spawn was still in progress, the log wrongly read "server slow/wedged" — a verdict about a running server, not a cold start. The record now emits `reason: "spawn-in-flight"` and says the server is still cold-spawning when that is the case, and keeps the "slow/wedged" wording only when no spawn is in flight. - **`runtime-session.test.ts` no longer flakes under CI contention (closes #1767)** — root-caused, not just re-budgeted. Every test in this file drives `handleSessionStart`, which does real synchronous fs work plus fire-and-forget background scans (`scheduleStartupScans`) that reach their mocks only after a real `setImmediate` tick and real per-file fs reads. Solo runs measured 8-13s for all 14 tests (well inside `vi.waitFor`'s 1000ms default and vitest's 5000ms `testTimeout` default), but 24 contended runs (this file run 6x in parallel) failed 8 times (33%) — some on individual `vi.waitFor` calls timing out, others on the whole test blowing the 5000ms default while `handleSessionStart` itself ran long. Confirmed deterministically too: `--testTimeout=300` failed 12 of 12 pre-fix runs, 0 of 14 post-fix. This confirms the reporter's own A/B finding that `clients/runtime-session.ts` is not the cause. Every `vi.waitFor` call in the file now uses an explicit 30s budget (`HEAVY_IO_TIMEOUT_MS`, matching `tests/clients/ast-grep-rule-precedence-followups.test.ts`'s existing convention), and the enclosing `describe`/`it` blocks use a 45s budget (`TEST_BUDGET_MS`) — kept deliberately larger so a genuine failure still surfaces `vi.waitFor`'s specific message instead of racing it against the outer test-timeout's generic one. Post-fix, 18 of 19 completed contended runs passed with zero genuine test failures (the 19th run hit an unrelated `npx` infrastructure error, not a test assertion). Test-only change; `clients/runtime-session.ts` is untouched. - **Genuine pull timeouts now count in the degradation ledger (#1771)** — `lsp_pull_diagnostic_timeout` previously wrote a detailed latency.log record but tallied nothing, so a storming server was invisible in aggregate. It now increments `lsp-pull-diagnostic-timeout` with a subject that preserves server and file identity. - **`index-loop-block-wiring` case (a) no longer times out flakily under load (closes #1772)** — pre-existing test-budget starvation, not a regression. Case (a) does a cold `await import("../index.js")` after `vi.resetModules()`; cases (b) and (c) also reset modules but reuse the already-warm transform cache from case (a)'s run, so only case (a) pays the full cost. That cost measured up to 9.2s solo on a busy box, already over vitest's 5000ms default (timeout, not an assertion failure). Two independent controlled A/B comparisons (#1743 builder, #1761 reviewer) showed `origin/master` fails at the same or higher rate as feature branches, and CI stays green on both heads, confirming this is environmental, not a code defect. The describe block now declares an explicit 30s timeout, matching the `HEAVY_IO_TIMEOUT_MS` convention (`tests/clients/ast-grep-rule-precedence-followups.test.ts`) and #1764's `instance-reaper-prune-concurrency` fix, instead of hoisting the import: the per-test isolation actually comes from the `beforeEach` mock clears, not the re-import, but hoisting would still order-couple case (c)'s `worstSoFar` assertions to whatever high-water state case (b) leaves behind, so the import stays per-test. A repo-wide sweep for the same shape (cold `import("../index.js")` + `resetModules`, no timeout budget) found four untouched siblings, one reproduced red in the same session — filed as #1778. - **Diagnostic pulls no longer dispatch once the caller's budget is exhausted (#1773)** — `textDocument/diagnostic` and `workspace/diagnostic` pulls used to send an unwinnable 1ms request when the remaining budget was 0 or negative, then log it as a genuine timeout. Below a 5ms usable floor the pull is skipped outright and recorded as `lsp_pull_skipped_budget_exhausted`, so `lsp_pull_diagnostic_timeout` only ever means a pull was really attempted. - **A pull timeout's abandoned request now traces server rejections, not just late answers (#1774)** — when an abandoned pull rejects (for example a permanent server error after the caller gave up) instead of answering or staying silent, it now emits a bounded `lsp_pull_late_rejection` record with the error code and elapsed time. The rejection is still swallowed; only the observability changes. - **Two more `index-*-wiring` test files budget their cold import (closes #1778)** — `tests/index-memory-sample-wiring.test.ts` and `tests/index-smells-rollup-wiring.test.ts` share #1772's flake shape: a cold `await import("../index.js")` after `vi.resetModules()` per test, racing vitest's 5000ms default `testTimeout`. Both describe blocks now declare an explicit 30s timeout, matching #1779's `index-loop-block-wiring` fix and this repo's `HEAVY_IO_TIMEOUT_MS` convention, instead of hoisting the import — hoisting would defeat the per-test module-state isolation these wiring guards check. `tests/index-integration.test.ts` and `tests/index-lsp-idle-reset.test.ts` (the other two files in #1778's sweep) already carry an equivalent per-test 45s timeout and needed no change. - **`session_start` self-heals cachedExports after a starved sequence read (closes #1785)** — under heavy load, `handleSessionStart`'s bounded change-log sequence read (#1162's 250ms budget) can time out even when the underlying log is empty, purely from CPU scheduling starvation. The freshness gate correctly refuses to trust a snapshot it can't validate yet, so `cachedExports`/`projectRulesScan` stay empty — but the deferred read that continues in the background only reseeded `runtime.projectSeq`, never re-checked snapshot freshness, so a project snapshot that really was current stayed unhydrated for the rest of the session even after the real answer arrived. Quick mode (the interactive hot path) now retroactively hydrates from the snapshot once the deferred read confirms it was fresh — a deterministic completion signal, not a sleep. Full mode is deliberately left alone: its cold path actively rescans instead of accepting an empty state, so retroactive hydration there risks overwriting fresher, actively-computed data. A `snapshot-sequence-read-timeout` degradation-ledger record now carries the project root and the on-disk snapshot's age/size whenever the budget is blown, so a real recurrence is diagnosable from the ledger alone. Characterization also corrects the issue's original hypothesis: the suspected `saveProjectSnapshot` worker-persist race does not reproduce — the in-process authoritative-snapshot cache (`clients/project-snapshot.ts`) already guarantees read-your-own-write consistency within a process. Review round found the first version of this fix could itself be defeated by quick mode's own cold-start warmup (2s later by default): the warmup saves a snapshot built from the still-cold live runtime, and a re-load at deferred-hydration time could read that emptied snapshot instead of the good one. The retroactive-hydration closure now captures the on-disk snapshot BEFORE the warmup timer is even armed and hydrates only from that captured value, immune to anything the warmup writes afterward. The hydration itself is now additive per field (`hydrateRuntimeFromProjectSnapshotIfIdle`): it never nulls a live `wordIndex` from a snapshot missing one, and never clears a live `cachedExports`/`projectRulesScan` — each field only hydrates from the snapshot while its own runtime copy is still idle. A second review round found that capture itself was too expensive to run unconditionally on the interactive hot path: it called the full `loadProjectSnapshot` (gunzip + parse the entire body, dominated by `wordIndex`'s postings graph) on EVERY quick-mode session start, bypassing the #947 skip-stale meta gate and briefly holding a second copy of the postings graph in memory (#1370). A new narrow loader, `loadProjectSnapshotExportsAndRules`, excises the heavy fields (`wordIndex`, `files`, `symbols`, `reverseDeps`) from the raw JSON text before `JSON.parse` ever sees them, instead of parsing everything and discarding the unwanted parts afterward. A third review round replaced even that narrow capture: it was still 210-289ms of synchronous read+gunzip+scan on every quick-mode session start, to guard a timeout that rarely fires. Quick mode's own cold-start warmup already loads the on-disk snapshot for its own purposes (reusing a cached `startupScan` verdict), strictly before any save the warmup itself might make — so the fix now has the warmup publish that already-loaded read (narrowed to exports+rules) for the retroactive-hydration path to reuse, at zero marginal cost, instead of paying for a second, separate read. This also closed a leftover retention bug the narrow loader's own test hook had reintroduced: an earlier observability hook held the full narrowed body text at module scope, unconditionally — the exact retention class the narrow loader exists to avoid. It's now a bounded `{length, containsHeavyKey}` digest instead. - **`workspace/symbol` no longer goes to LSP servers that never advertised it (refs #1789)** — without a `filePath`, `LSPService.workspaceSymbol` picked "the first active client" from the full spawned-client map, auxiliary scanners (ast-grep, opengrep, zizmor, ...) included, with no capability check of its own; a workspace whose only spawned client was an auxiliary sent every workspace-wide symbol query to it and ate a wasted round trip each time (2026-08-20 plegma dogfood: ast-grep). The gate now reads `client.getOperationSupport().workspaceSymbol` — the same source `lsp-document-symbols.ts`'s documentSymbol gate already reads, populated from the initialize result's `capabilities` — right at the point that resolves and calls the target client, for both the `filePath` and no-`filePath` branches. Caller-visible shape is unchanged: an unsupported server returned `[]` before (from a thrown/absorbed error) and returns `[]` now (from the short-circuit). A repo-wide sweep of every `navRequest`/`safeSendRequest` call site in `clients/lsp/client.ts` found one sibling with the same "chokepoint, not caller, decides the target and never checks" shape — `LSPService.incomingCalls`/`outgoingCalls` resolve their target server from the call-hierarchy item's own file, which can cross servers in a polyglot workspace — left open as a follow-up rather than folded into this contained fix. - **`blocker_freshness_sweep`'s population excludes cache-served diagnostic rows (closes [#1790](https://github.com/apmantza/pi-lens/issues/1790))** — the turn-end freshness gate (`clients/blocker-freshness.ts`, `sweepInlineBlockerFreshness`) built its population solely from `RuntimeCoordinator`'s inline-blocker map, a live-dispatch-only store. A workspace-diagnostics cache hit never touches that map — it writes straight into `widget-state.ts`'s `files` store (`reconcileScanDiagnostics`, called from the cache-serve branch of `tools/lsp-diagnostics.ts`). During the 2026-08-20 dogfood `blocker_freshness_sweep` logged `total:1 kept:1` while five stale cache-served blocking rows still rendered in the widget — the sweep's population never saw them, so its drift check never ran over them either. `sweepInlineBlockerFreshness` now accepts `options.additionalEntries`: widget-store rows fed in by `runtime-turn.ts` from the new `widget-state.ts` export `getWidgetBlockingFilesForSweep` (one entry per file with a currently-blocking, LSP-sourced diagnostic, baselined on the earliest `observedAt`), deduped by file path against the inline-blocker map so a file present in both stores is drift-checked once, not twice. Review round 1 found the dedup DROPPING the widget row on a duplicate path instead of also demoting it: a live dispatch writes both stores for the same verdict (`runtime-tool-result.ts`'s inline write, `pipeline.ts`'s widget write), and `markInlineBlockerStale` only ever touches `RuntimeCoordinator`'s map — so the widget's own `isBlocking` for the file stayed true even after the inline entry demoted, the exact ghost this issue exists to kill, just moved one store over. A duplicated path now CHAINS the widget demote onto the inline entry's demote instead: one drift check, both stores written. Review round 2 found the chain itself still ghost-prone: it fired even when the inline entry it chained onto was INELIGIBLE for the drift check (already latched `stale` from a prior turn's one-way demotion, an unstamped legacy record, or a non-LSP/mixed-sources entry like an unrelated ast-grep finding on the same file) — the sweep's own gate short-circuits before ever calling `demote()` on those, so the chained widget demote silently never fired, either as a permanent forever-ghost (the stale latch never re-arms) or reappearing the instant an unrelated inline blocker happened to share the file. A duplicate now only chains when the inline entry is itself eligible (`isEligibleForDriftCheck`, the same three gates factored out so this decision can't drift from the real ones); an ineligible duplicate gives the widget row its own separate population entry instead, so its own eligibility and its own baseline decide its own fate. The dedup key is `normalizeEphemeralMapKey` (cheap, no syscalls), not `normalizeMapKey` (measured ~313µs per deleted path via its `realpathSync`/walk-up fallback — a real cost on a turn-end hot path, and the wrong key besides: the widget store this population is deduped against keys on `normalizeEphemeralMapKey` itself). A widget-origin row that drifts is demoted through the new `markWidgetFileBlockersStale` — the same store and the same demote-not-drop write `reconcileStaleWidgetDependencyBlockers` already performs, just triggered by the sweep's own drift check instead of an explicit `lens_diagnostics mode=all` call; a comment at that write site pins the single-file-baseline assumption it currently relies on (safe today because every LSP-diagnostics writer replaces a file's errors wholesale with one `observedAt` per write) so a future mixed-stamp merge writer can't make it over-demote silently. The source defect — the cache serving genuinely stale rows in the first place — was fixed separately in [#1786](https://github.com/apmantza/pi-lens/pull/1786) (cache expiry + clean-answer eviction, closes [#1782](https://github.com/apmantza/pi-lens/issues/1782)); this is the defense-in-depth remainder, so a future cache-path defect cannot render invisible to the sweep again. Bounded cost: one extra pass over `widget-state.ts`'s per-turn file count (already bounded by `MAX_INACTIVE_FILE_RECORDS`), filtered to files with a live blocking diagnostic; the dedup key itself is now a pure string operation with no stat/realpath cost, and the per-file drift check is still bounded by the existing `MAX_DRIFT_CHECK_IMPORTS` cap and per-turn import-resolution memo. - **Clean workspace-diagnostics cache entries no longer replay across a dependency edit on a cold session** — A clean entry recorded while a reverse-dependency index was available now refuses to serve on a later session that has none, instead of falling back to mtime-only checking. The cache used to trust any clean entry's own mtime alone whenever this session's dependency graph wasn't built yet, so a dependency change (or a config change that flipped a file from clean to failing) went unnoticed for as long as the file's own bytes stayed untouched. Refused entries count toward the existing `lsp_workspace_diagnostics_cache_expiry` record in `latency.log` (`depIndexColdRefusals`). An entry recorded on an equally cold session keeps today's mtime-only behavior — it never claimed more than that check can verify. - **`lens_diagnostics` no longer double-counts error findings (closes #1799)** — The compact header and the mode=all/full summary printed the same error-severity findings twice, once as "blocking" and again as "errors", making three real problems read as six. `semantic === "blocking"` and `severity === "error"` always describe the same set of findings, so both surfaces now report blocking and warnings only. Also removed the always-zero `byTier.error` field from `clients/actionable-warnings.ts`, since error-severity diagnostics never reach the actionable-warnings path. - **`callHierarchy/incomingCalls` and `outgoingCalls` no longer go to servers that never advertised `callHierarchyProvider` (closes #1803)** — `LSPService.incomingCalls`/`outgoingCalls` resolved their target server from the call-hierarchy item's own file and called straight through, with no check of `getOperationSupport().callHierarchy`. Both now read `client.getOperationSupport().callHierarchy` — the same source `detectOperationSupport` populates from the initialize result's `callHierarchyProvider` (clients/lsp/client.ts:5253) — right before dispatch, mirroring the #1789 gate on `workspaceSymbol`. Because `lsp_navigation`'s shared capability pre-check only runs for path-based operations (`needsFilePath`, tools/lsp-navigation.ts:1099-1104 excludes call-hierarchy traversal), the service-only fix would have silently turned a live, user-visible unsupported-server error into a false "no callers found" clean empty — the review round caught this and added a matching pre-check in the tool layer's `incomingCalls`/`outgoingCalls` cases, so an unsupported server now reports the same discriminated `emptyReason: "unsupported"` shape every other capability-gated operation already uses, while a supporting server with zero callers still reports a clean empty. A pattern sweep of every `getClientForFile`-resolved navigation method in `clients/lsp/index.ts` found eleven more siblings with the same service-layer gap (`definition`, `typeDefinition`, `declaration`, `references`, `hover`, `signatureHelp`, `documentSymbol`, `codeAction`, `rename`, `implementation`, `prepareCallHierarchy`), all already gated at the `lsp_navigation` tool layer — filed as #1826 as defense-in-depth, not a live bug. - **Biome findings can now reach actionable warnings** — biome's real `lint --reporter=json` output (probed live against the shipped 2.5.x binary) carries no `tags` field and never did, so the old `d.tags?.includes("fixable")` check always missed and every biome diagnostic's `fixable`/`autoFixAvailable`/`fixKind` were permanently false. The parser now resolves each rule's real fix tier via `biome explain ` (the one place biome states fixability as structured text, sourced from the running binary's own rule registry), cached for the process lifetime since fix tier is a property of the rule, not the occurrence. Also aligned the diagnostic location field to biome's real `location.path` (the parser and its fixtures assumed `location.source`, a field that never shipped) (#1810). - **`workspaceSymbol`'s no-`filePath` branch now picks a client that actually supports it (refs #1812)** — without a `filePath`, `LSPService.workspaceSymbol` stopped at `state.clients`' first entry by insertion order, even after the #1789 capability gate. In a polyglot workspace where an auxiliary scanner (ast-grep, opengrep, zizmor, ...) spawned before a supporting primary server, every workspace-wide symbol query silently returned `[]` with zero requests, and the supporting primary never got a look-in. A new `selectWorkspaceScopeClient` helper scans the spawned-client map for the first LIVE client matching a predicate, preferring a primary (non-`"auxiliary"`) server over an auxiliary one — mirroring the `role !== "auxiliary"` preference `getClientForFile` already applies for `filePath`-scoped requests, and the `isAlive()` filter `getCapabilitySnapshots`'s own no-`filePath` branch already applies. Only when NO live spawned client supports the query does it fall back to `[]`. Swept and fixed the same "clients[0] by insertion order" shape at the other four no-`filePath` chokepoints in `clients/lsp/index.ts` — `getAdvertisedCommands`, `executeCommand`, `getOperationSupport`, and `getWorkspaceDiagnosticsSupport` — onto the same helper; `getCapabilitySnapshots`'s no-`filePath` branch was already correct (it iterates every client, not just the first). A follow-up review round found the multi-primary case where `getOperationSupport`'s own no-`filePath` probe (no predicate) can disagree with `workspaceSymbol`'s predicate-driven selection — filed as #1846, not fixed here. - **A warm session's dependency index no longer vacuously clears files it never scanned** — `isEntryFresh`'s per-file dependency check used to treat "this file is absent from the reverse-deps index" the same as "the index confirmed this file has zero imports": both returned an empty import list, so the freshness loop iterated zero times and reported clean. A session with a real index covering the rest of the project could still fail-open, with no signal at all, for the one file outside that index's own coverage. `getImports` now returns `undefined` for an uncovered file instead of silently coercing it to `[]`, and a clean entry stamped with dependency knowledge is refused and evicted for that file the same way #1793 already refuses one on a session with no index at all. Refusals from both cases share the existing `depIndexColdRefusals` counter in `latency.log`. The reverse-deps index itself carried the same masking one layer down — `clients/reverse-deps.ts` used to stamp an empty import list for a file it never scanned (known only as another file's import target, or recorded in the snapshot with no imports field at all); it now leaves that file's entry absent, matching the distinction `getImports` relies on. - **Actionable-warning and code-quality-warning ids now canonicalize the file path like disposition anchors already did** — `createActionableWarningId` and `createCodeQualityWarningId` hashed a RAW `relativeFile`, so a drive-letter-case or slash-variant file path produced a different id than `diagnostic-dispositions.ts` would compute for the same file (the #533 orphaned-record class, swept from 1 of 3 copies to all 3). Both now share `clients/finding-identity.ts`'s canonicalizing `relativeFile` and 12-char hash length; a warning already suppressed in `actionable-warning-state.json` under the pre-fix, 10-char id is still honored and migrated forward onto the new id (#1816). - **Session-state conformance coverage catches a new latch landing inside an already-registered file (refs [#1817](https://github.com/apmantza/pi-lens/issues/1817))** — `tests/clients/session-state-conformance.test.ts`'s coverage sweep audited FILES: once a module was registered or exempted, any NEW module-level `Map`/`Set`/`PathKeyedMap` added inside it was invisible, because the sweep never re-checked what was already inside a file it had already cleared. `#1801`'s review round 1 found this the hard way — `staleGrammarVersionAt`, a process-lifetime latch on the `TreeSitterClient` singleton, sat unregistered and unreset for a whole review round while the sweep stayed 55/55 green. `tests/support/sweep-kit.ts` gains `auditSymbolCounts()`, built on the existing `auditRegistry()` machinery: each flagged file's LIVE detected-symbol count is folded into its registry id (`file@N`), so a file whose count changes presents an id the pin does not name and reds as an ordinary unaccounted item — no parallel registry, no new exemption semantics. `tests/support/session-state-registry.ts` pins the current count for all 72 files the sweep flags today (`SESSION_STATE_SYMBOL_COUNTS`), and the conformance suite diffs it against a live scan on every run. Proven red-first by seeding an uncleared module-level `Map` into the already-registered `tree-sitter-shared.ts` (the `#1801` F1 shape exactly): the new pin test failed with `tree-sitter-shared.ts@1` unaccounted; reverting the seed restored green. Chose the cheaper of the issue's two options (a pinned per-file count) over full symbol-to-reset attribution — the registry's `state` field is free text that does not reliably map onto the scanner's detected identifier names across its ~30 entries, so attributing every symbol to a reset or a reason would be a real migration, not a rider on this fix. - **ast-grep-napi LSP supersede gate B tests now pin the gate, not the fallback (closes #1830)** — the two "skips ..." tests under `LSP supersede gate (#239 Phase 2)` mocked `@ast-grep/napi` with a bare `parse: vi.fn()`, so a neutered gate B still returned `"skipped"` by falling through to the load/parse skip path. `expect(result.status).toBe("skipped")` couldn't tell the two skip reasons apart, so the tests passed whether gate B fired or not. A `mockWorkingSgLoad()` helper now makes the NAPI fallback path succeed, so only gate B can still produce `"skipped"`. Neutering the gate's `.includes("ast-grep")` check now turns both tests red with `"succeeded"`, confirming the assertion is load-bearing. - **`require-safety-comment-for-as-unknown-as`'s `SAFETY:` valve no longer exempts every later cast in the same block (closes #1834)** — the backward comment scan now stops at the first non-comment sibling instead of walking unbounded to the top of the block. - **Workspace-wide capability checks now describe every live client, not just the first (closes #1846)** — `LSPService.getOperationSupport()` called without a `filePath` answers for the workspace, but it returned a single client's capabilities: whichever `selectWorkspaceScopeClient()` picked with no predicate. In a multi-primary workspace — a `json` server spawned before `typescript`, for example — the first client's missing `workspaceSymbolProvider` reported the operation unsupported even though the later client advertised it. `tools/lsp-navigation.ts`'s workspaceSymbol gate read that snapshot and threw `__UNSUPPORTED__`, so `LSPService.workspaceSymbol` — which #1812 taught to find the supporting client — was never reached, and the probe disagreed with the call it was gating. Each capability now resolves through `selectWorkspaceScopeClient` with a per-capability predicate, so the snapshot is ORed across exactly the clients that routing would consider. Aggregation inherits that helper's `isAlive()` filter rather than re-deriving one: a dead client cannot contribute a capability nobody can answer. The `filePath`-scoped branch is unchanged, a single-client workspace gets the same snapshot as before, and no active client still returns `null`. - **`require-safety-comment-for-as-unknown-as`'s `SAFETY:` valve now accepts a comment above an exported, class-field, or enum-member cast (closes #1847)** — the rule's `inside:` kind list was missing `export_statement`, `public_field_definition`, and `enum_assignment`, so a documented `export const`, class-field, or enum-member cast had no way to satisfy the ERROR-tier blocking rule. - **Resource sampling distinguishes failed process-table queries from empty samples (closes #1863)** — failed or timed-out Windows and POSIX resource queries now remain unknown, with bounded query-specific degradation telemetry, instead of being treated as clean zero-sample results. - **Ignore zero-byte freshness reads (refs #1865)** — Keep live diagnostics visible during truncate-then-write windows and record the observed file size for past-EOF demotions. - **Reuse knip results for unchanged project content** — Turn-end and startup scans now reuse the last successful knip result when the runtime project sequence has not changed. Telemetry distinguishes cached results from executed scans, and a new session re-arms execution. - **Identify TypeScript diagnostic sequence records** — Every `lsp_typescript_diagnostic_sequence` row now names its server and whether it records a publication or a settled answer, instead of leaving the minimum outcome identity implicit. - **Accept SAFETY comments on object-literal members (refs #1870)** — `require-safety-comment-for-as-unknown-as` recognizes the TypeScript `pair` node while keeping unrelated sibling comments scoped to their own member. - **javac fallback skips classpath-less compiles inside Maven/Gradle projects (closes #1877)** — when the Java LSP runner misses its wait budget, dispatch falls back to the `javac` runner, which compiles the single file with no `-classpath`/`-sourcepath`. On build-tool projects every non-JDK import becomes a blocking `package does not exist` false positive that gates agent edits and stays cached in session diagnostics after jdtls recovers. The runner now walks up from the edited file with the shared `hasJavaBuildDescriptor` seam (the same gate SpotBugs uses) and returns `skipped` when a `pom.xml`, `build.gradle(.kts)`, or `settings.gradle(.kts)` is present; the dispatcher's coverage notice reports the LSP gap honestly. Standalone `.java` files with no descriptor keep the javac fallback. - **Tally verified relative-path attribution guesses instead of logging one record per read (refs [#1884](https://github.com/apmantza/pi-lens/issues/1884))** — existing workspace-root guesses now increment one session counter and emit one `path_attribution_verified_rollup` latency row at shutdown; missing, ambiguous, or non-existent guesses retain the full `path_attribution_missing` record with its raw and guessed paths. - **Keep context-free compiler findings non-blocking ([closes #1885](https://github.com/apmantza/pi-lens/issues/1885))** — standalone javac, C/C++ syntax checks, Zig single-file builds, and direct elixirc runs still report useful compiler errors, but no longer stop an edit when missing project classpaths, build flags, modules, or dependencies could have caused the finding. A recovered Java LSP clean result also replaces any javac findings already held in session diagnostics. - **Unverified path guesses remain visible ([refs #1886](https://github.com/apmantza/pi-lens/issues/1886))** — a same-named workspace file no longer verifies a tool result when the execution target and cwd are unavailable for comparison. The full attribution record is retained, lifecycle rollups are tested through `session_start` and primary or secondary `session_shutdown`, and the session tally remains explicitly best-effort because a crash loses its memory-only count. - **The widget count now includes project self-scan findings** — `lens_diagnostics mode=full` projects its correlated cross-lane result into widget state, so `ast-grep-napi` findings remain counted when the ast-grep LSP lane is broken or unconfirmed (#1888). - **Formatter PATH availability re-arms at session start (closes [#1895](https://github.com/apmantza/pi-lens/issues/1895))** — formatter `which` latches now clear with the primary session reset, so a formatter binary installed or removed between sessions is detected on the next session instead of keeping the previous session's verdict. - **Coverage-marker dedupe key sorts with an explicit code-unit comparator.** SonarCloud S2871 flagged the bare `.sort()` in the silent-scanner set; the key now sorts locale-independently so dedupe identity cannot vary by environment. - **Stale workspace-diagnostics cache entries now expire** — A cached entry that asserts findings and predates the current session start, or that has aged past a four-hour in-session ceiling, is dropped at serve time and the file goes back through a fresh check. A cache hit used to skip that check, so an entry no newer pull re-answered replayed its diagnostics forever, across sessions, rendered as current blocking errors. Clean entries keep serving: their only claim is "nothing changed", which the existing mtime, dependency, and content-hash gates check. Each sweep that expires entries writes one `lsp_workspace_diagnostics_cache_expiry` record to `latency.log` with the count and the oldest age. - **A clean re-answer now clears a cached diagnostics entry** — A `workspace/diagnostic` pull returns a project-wide report, but pi-lens read only the part covering the files it had just asked about. An explicit zero-diagnostic answer for a file served from cache was discarded, so a server that re-checked a file and found it clean could not dislodge its stale blockers by any means available to a user. Those answers now flow through the sweep's ordinary result list, which overwrites the cache entry and clears the widget rows. - **Surface silent LSP scanners to the agent (refs #1867)** — Per-edit diagnostics now render a compact coverage marker when one or more auxiliary scanners did not answer. An empty partial result is labeled incomplete instead of looking like a clean pass, and repeated notices retain the existing per-file session dedupe. - **Heal the LSP view after an untracked disk edit** — An edit made outside the tracked write/edit path, such as a bash-tool bulk edit, sent no `didChange`, so the language server kept publishing pre-edit diagnostics indefinitely. pi-lens now records what content actually landed on each server and, on a bounded cadence, compares disk size and mtime against that record. A document whose bytes really changed is re-pushed within 10 seconds of the next LSP activity, to every server holding it — the primary language server and the auxiliary scanners alike. The sweep stats at most 64 documents per pass (1.7ms measured), reads only the ones whose stat diverged, and issues at most 4 resyncs per pass so a bulk edit heals in paced rounds. - **`no-non-null-assertion` narrows two more idiom shapes** — a `!` guarded by an identical truthy ternary condition, or re-asserted on a `.filter()`-checked property immediately chained into `.map()`, no longer flags. Both exclusions are scoped to the nearest enclosing ternary or arrow function and require the same metavariable binding, so a differently-bound guard still flags. Pi-lens's own residual drops from 36 to 27; the rule stays at `warning` pending the tier decision tracked in #1818. - **`no-unknown-returns` drops its callback/type-alias arm** — a `function_type` (`(x: T) => R`) is a type-position annotation, and a callback contract that returns `unknown` is legitimate, unlike a real function whose value-position return skipped parsing at a boundary. Dropping that arm takes pi-lens's own `clients/` + `index.ts` from 21 hits to 9 (#1824). - **Orphan backstop: off the session-start critical path, with verified kills ([closes #1857](https://github.com/apmantza/pi-lens/issues/1857))** — The registry-independent orphan sweep scanned the OS process table inline at session start. One dogfood session measured that scan at 9344ms, overlapping and starving language-profile warmup. The sweep now runs on an unref'd timer 30 seconds after session start, under a machine-wide 30-minute cooldown, with a 5-second hard timeout on the enumeration child. Session start pays nothing. Three correctness defects went with it. Kill outcomes were counted as successes: `killPidTree` returned no signal, so a permanently unkillable process reported as reaped and paid the full sweep again every session. Kills are now verified by a post-kill liveness poll, and a survivor is recorded by identity (`#`) through the degradation ledger. The sweep's only record used to be a `{scanned, killed}` count on the reaped path, so "ran and found nothing", "never ran", and "threw" were the same absence; every sweep now logs one of `clean`, `reaped`, `error`, `cooldown`, or `disabled`. And a name-matching process spawned seconds ago but not yet registered was kill-eligible the moment its launcher shim exited — a window measured at 890ms in the same session — so a process must now be at least 60 seconds old before the backstop will touch it. The registry-driven reaper carried the same attempt-counted-as-kill defect and gets the same verified accounting. Review round: the sweep runs under the repo's cross-process directory lock, so two sessions starting together cannot both pay for it. A candidate spared by the spawn grace arms exactly one follow-up sweep, instead of waiting for a next session that a long-lived host may never start. The scan timeout terminates the scanner child through the same tree-kill-and-verify path an orphan gets, rather than firing one unverified signal and walking away. And a sweep whose kills all failed reports `unverified`, not `reaped` — the same accounting defect this work exists to fix, reproduced one level up at the outcome surface. - **Preserve pyright's information severity and fix its diagnostic positions in dispatch (closes #1802)** — `pyright` collapsed every `"information"`-tier diagnostic to `warning`, even though pyright's own `--outputjson` output declares `error`/`warning`/`information`. Pyright findings now carry the same four-tier `Diagnostic.severity` biome-check adopted in #1791: `information` maps to `info`. Only `error` still blocks. The parser also read a top-level `start` field that real pyright output never sets — every diagnostic landed at line 0/column 0 — and now reads the documented `range.start.line`/`character` (zero-based, converted to pi-lens's one-based `line`/`column`). `rust-clippy`'s mapping got its own fix: rustc/clippy's `compiler-message.level` serializes six values, not two, and a top-level `"note"`/`"help"` message can carry a real primary span. `note` now maps to `hint`, `help` to `info`, and an internal-compiler-error (`"error: internal compiler error"`) is classified as blocking instead of silently falling through to `warning`. - **Eight ast-grep rules stop flagging correct code** — the 2026-08-20 severity audit found broken escape valves, patterns that crossed function boundaries, and content-shape gaps that fired on parameterized queries and static markup. A follow-up adversarial review then caught three of the fixes over-correcting (an escape valve exempting more than the false-positive case, or a narrowed match losing a detection class); those are fixed too. Per rule: `no-dupe-class-members`'s static-modifier check missed `static async` methods (false positive) and, in the first fix, over-exempted static members entirely, losing genuine `static foo(){} static foo(){}` duplicates (false negative) — both fixed, staticness is now compared BETWEEN the pair, not blanket-exempted. `no-return-value-in-generator` conflated yield/return across nested functions. `no-compile-call` now suppresses literal and same-scope `ast.parse`-derived sources, scoped to the nearest enclosing function (a first pass climbed past nested functions) and with the single-argument call form restored. `no-server-bind-wildcard`'s first fix anchored to `.run`/`.listen`/ `.serve` call targets, which missed `uvicorn.Config(...)`, bare `run(host=...)`, and other server-startup shapes — reverted to the original broad match with a narrow exclusion for the actual false positive (a pydantic `.model_construct()`/`.construct()` call). `no-sql-in-code`/`-js` now require string concatenation or template substitution, mirroring the already-correct Python sibling, and exclude literal-plus-literal concatenation (compile-time-constant text, nothing to inject); the residual corpus hits match the declared concatenation/substitution shape, though a few interpolate module-level constants rather than user input. `no-inner-html`/`-js` now exempt literal/empty-template RHS. `redundant-unsafe-function` now exempts a preceding `/// # Safety` doc comment, bounded to the comment block immediately above the function (an unbounded first pass let one `# Safety` comment anywhere earlier in the file exempt every later `unsafe fn`). `no-await-expression-member`/`-js` no longer recommend a rewrite that reads a property off the unresolved promise (prose only, no rule change; kept rather than retired — the corrected hint is not a no-op, though retirement stays available as a separate call). Refs #1806. - **Seven linters no longer report a clean file after a failed run** — `markdownlint`, `mypy`, `sqlfluff`, `stylelint`, `swiftlint`, `vale`, and `yamllint` read their tool's exit status zero times, so a rejected flag, an unreadable config, a crash, or a `SIGKILL` parsed to zero diagnostics and was reported as a clean file. All seven now route the spawn through a shared `classifyRunOutcome` primitive, return `skipped`, and record one bounded `runner-empty-result` row naming the tool, its exit status, and the signal. A shared `formatToolFailure` gives every runner one wording and one truncation, and `SpawnResult` now carries the signal as a field instead of burying it in an error message. Two bugs the same survey found are fixed alongside: the degradation ledger appended its repeat count before a second truncation at the same bound, so a 200-character reason lost the count; and the quarantine file lock required a finite `createdAt` before it would test PID liveness, so an owner record without one was never reclaimed and every caller burned its full wait. - **Project snapshot misses now name the rejecting gate (refs #1858)** — session-start diagnostics distinguish an absent body, stale meta gate, invalid body, and sequence-stale snapshot instead of reporting every null load as `missing`. - **Tree-sitter cache now spans a full-project scan** — the parse-tree cache grows to fit a scan's file count (capped at 500 entries, or `PI_LENS_TREE_SITTER_CACHE_SCAN_CAP`) instead of staying fixed at 50, so a repeat `lens_diagnostics mode=full` scan reuses trees from the first pass instead of re-parsing every file (#1715). - **Two error-tier ast-grep rules now run in the CI self-scan** — `no-unsafe-dictionary-any` and `no-bare-object-param` shipped at `error` without being wired into the `pi-lens-self-scan` category, so pi-lens's own tree was never actually audited by them. Both confirm clean (0 findings) on the full tree (#1825). ### Security - **A cascade sweep no longer blacks out the security scanner, and a blackout no longer reads as clean (closes [#1459](https://github.com/apmantza/pi-lens/issues/1459))** — A `clientScope: "all"` sweep used to fan a full-text `didOpen` resync at opengrep for every neighbour at once. Its stdin stopped draining, three per-server notify-write deadlines expired, and the #743 breaker opened for 15 s; every touch inside that window skipped the scanner and still resolved `confirmation: "confirmed"`. An auxiliary now gets at most one outstanding resync, as a bounded QUEUE rather than a drop: a healthy scanner accepts each write in milliseconds, so every neighbour of a sweep is still scanned, and only a scanner that cannot accept a write inside the budget makes a waiter give up and report itself uncovered. The slot is claimed synchronously, so waiters cannot all wake and write at once, and the queue wait is bounded by the caller's own budget rather than a flat write budget. A write that lands late but inside the wedge window retracts the timeout it was charged for; a write nothing accepts for the whole wedge window is demoted by its own timer, without waiting for a later touch to notice. A deferred auxiliary records a distinct `deferred` outcome in `lsp_aux_wait_outcome` rather than occupying the `silent` row, which stays reserved for a scanner that had the content and published nothing (#1493). #1493's content-hash exemption outranks a deferral: a scanner whose stored publication is bound to exactly these bytes stays covered, and its findings still reach the result. A deferred scanner is neither waited on nor read from, so it cannot burn its budget on a version that can never advance or contribute the previous content's findings. A scanner that never attached (breaker open) or never received the content (deferred resync) now lands in `unconfirmedServerIds`, narrows the touch to `"partial"`, and reaches the agent through `CascadeNeighborResult.unconfirmedServerIds` and an explicit "scanners did not cover" advisory line — so no consumer, and no agent, can read the gap as a clean bill of health. New `latency.log` records: `lsp_scanner_coverage_gap`, `lsp_notify_resync_deferred`, `lsp_notify_write_late_landed`. - **A stalled `gh auth token` probe no longer disables zizmor's online audits for the session (closes #1535)** — A timed-out or unspawnable `gh auth token` lookup used to be memoized as "no token" with no TTL, silently turning off zizmor's GitHub-aware audits (`known-vulnerable-actions`, `unpinned-uses`, `impostor-commit`) for the rest of the session while the scan kept reporting success. The lookup now routes through the shared availability policy: only a genuine answer (`gh` ran and returned an exit code — including a clean run with no token — or is proven absent) is cached — a timeout, host stall, or unspawnable probe expires on a bounded cooldown and is retried, with every offline spawn (including one served from a still-cooling cache) recorded as a degradation instead of silent. The verdict also resets at the start of every session, so running `gh auth login` and starting fresh is picked up immediately, not just after a cooldown. Caveat: this only decides the token a *new* zizmor process launches with — an already-running (warm) zizmor keeps the token it started with until it next respawns, so recovery from a transient failure takes effect on the next spawn, not immediately. - **Directory-scanning security lanes no longer scan pi-ecosystem scratch trees, and gitleaks recognizes placeholder secrets (closes #1562)** — `gitleaks`, `trivy fs`, and `opengrep` each hand their target directory to an external binary that does its own tree walk, bypassing pi-lens's own scratch/cache-tree exclusion (the same `.pi/`, `.claude/`, `node_modules/`, … list `knip`/`jscpd` already honor). In practice this meant a gitignored web-research cache (`.pi/greedysearch-sources/`) could serve a cached doc example's `YOUR_API_KEY` placeholder to the agent as a leaked secret — a false positive that cost a full turn to debunk. gitleaks excludes a NARROW pi-ecosystem/agent/cache-only tier (a review-round probe caught the first cut over-excluding real leak surfaces like `dist/`, `vendor/`, `.vscode/`, `build/` — those stay fully scanned), via a generated gitleaks config plus a TS-side backstop that demotes (never silently drops) a scratch-tree hit to an info-level, non-blocking finding with a `tracked`/`ignored`/`scratch`/`untracked` observability field. trivy/opengrep exclude the broader existing walker-parity list via their own native mechanism (`--skip-dirs`, `--exclude`). gitleaks also gets a placeholder-secret allowlist (`YOUR_API_KEY`, ``, `xxx`, …) and its generated exclusion regexes match both `/` and `\` path separators. An untracked `.env` with a real-shaped secret is still reported — the fix does not become a blanket "respect `.gitignore`". `dead-code-client.ts`'s `VULTURE_EXCLUDES` list, found independently drifted from the shared exclusion list during this sweep, is now derived from it too. ## [4.0.1] - 2026-08-16 ### Added - **Live native-TS7 diagnostic fixture (refs [#1412](https://github.com/apmantza/pi-lens/issues/1412))** — an opt-in (`PI_LENS_INTEGRATION=1`) integration suite launches the real `tsc --lsp` server against a Vitest-typed fixture, asserting no `Mock`/`mockResolvedValueOnce` false positives after settling while an intentional type-error control still surfaces, and recording the publication/settle sequence. - **Cascade injection, test-targeting, and cache-effectiveness telemetry (Closes #1446)** — `cascade_injected` (what text and how many neighbors/diagnostics reached `blockerParts` — i.e. were queued for the turn-end advisory, not confirmation of agent delivery, which can still be suppressed later; answering item 1) and `cascade_test_targets` (which tests were suggested for cascade neighbors, including the zero-suggestion case, answering item 2) are new `cascade.log` records. `cascade_result` now also carries `cacheHits`/`recentlyCleanHits`/`coldTouches`/`deferredTouches` (item 5's cache-effectiveness measurement, unblocked now that #1444 has landed) and `neighborBudget`/`budgetTruncated` (item 4's telemetry half). Item 3 (`lsp_diagnostics_timeout` server attribution) was already delivered by #1457. Item 4's budget-vs-settle-time sizing change is re-homed as #1462. - **Four ast-grep rules for the type-laundering smell family (Closes #1447)** — Add `no-unknown-laundering`, `no-conditional-empty-object-spread` (+ `-js`), `no-reflect-apply` / `no-reflect-get` (+ `-js`), and `no-chained-type-assertions` to the shipped rule catalog, alongside the existing `no-as-any` and `no-any-type`. - **Attribute worklog and disposition entries to the model/provider that produced them (closes #1448)** — `WorklogEntry` and `DispositionLogEntry` gain optional `model`/`provider` fields, populated at append time from the runtime's telemetry identity (`RuntimeCoordinator.telemetryModelId`/`telemetryProviderId`) and blank when the runtime doesn't know its identity. Provider is the host's explicit value when reported, else a conservative parse of the model id (`clients/model-provider.ts`: a single `/` or `:` separator, or a small known-prefix table; blank on ambiguity — never guessed). `npm run logs:smells` now prints a per-model rollup (rule × model counts, auto-fixed vs. agent-required rates) from `worklog.jsonl`. Old worklog/disposition-log entries stay valid; readers treat both fields as optional. - **Prefix filters for word-index queries: lang, file, ext (Closes #1450)** — `symbol_search`/`pilens_symbol_search` queries can now mix plain terms with composable `lang:`, `file:`, and `ext:` prefix filters, plus `-` negation, e.g. `lang:jsts file:clients/ -file:test rank`. A hand-rolled tokenizer (`parseWordIndexQuery` in `clients/word-index.ts`) splits filters from terms; `lang:` resolves through `KIND_EXTENSIONS` (`clients/file-kinds.ts`), the single source of truth, so there is no second, hand-maintained language list. Filters apply as a pre-ranking predicate, composing with the existing `paths`/`lang` structured options, before BM25/priors/centrality scoring runs. An unrecognized prefix or `lang:` kind throws a typed `WordIndexQueryError` naming the supported list instead of silently degrading to a literal search term. - **Live classic-TypeScript repair fixture (refs [#1436](https://github.com/apmantza/pi-lens/issues/1436))** — an opt-in (`PI_LENS_INTEGRATION=1`) integration suite stages a real managed-tools tree in the reported broken shape (TypeScript 7 with no `lib/tsserver.js`, cached by a prior probe) inside an isolated `PI_LENS_HOME`, then drives the production spawn through the real installer: it asserts the version-gated repair fires exactly once, the tree self-heals to the pinned classic compiler, and the classic launch serves diagnostics again. A negative control proves a disallowed-install spawn stays discovery-only and mutates nothing. ### Changed - **docs: document the per-edit autofix routing (refs #1414)** — `docs/agent-guide.md` and `docs/features.md`/`docs/usage.md` now describe the write-immediate vs. edit-deferred autofix split, the authoritative post-fix content attached to `write` tool results (with its size cap and shared multi-file bash budget), and the coalesced `{autofix, format}` deferred-mutation queue that drains at `agent_end`. - **Skill docs realigned with shipped behavior and split for token economy (closes #1424, refs #1423)** — `pi-lens-write-ast-grep-rule`'s stale `-js` twins gotcha now reflects the #657 NAPI runner grammar dedup (`ruleLanguageForFile` in `ast-grep-napi.ts`) instead of advising a fix that already shipped; its NAPI-runner-specifics and hard-to-express-pattern gotchas moved verbatim into a new `reference.md` behind a pointer, keeping `SKILL.md` to the minimal template, language list, rule-condition syntax, and the load-bearing `stopBy` warning. `pi-lens-ast-grep`'s Structural-intent parameters table now documents `hasKind`/`hasDescendantKind` per-tool (`ast_grep_search`'s `hasKind` is immediate-child only, with a separate recursive `hasDescendantKind`; `ast_grep_replace` has only the immediate-child `hasKind`) with a cross-tool divergence warning, and its Agent task recipes table is trimmed to entries not already covered by the Patterns table. A new `tests/skills/skill-doc-drift.test.ts` pins param names against real tool schemas, path references against the filesystem and `package.json`'s published files, both rule-writing skills' language lists against their `rule-schema.json` enums, and `` claim-comment format. - **Dead code reports the per-turn delta, not the whole project ([#1477](https://github.com/apmantza/pi-lens/issues/1477), refs [#127](https://github.com/apmantza/pi-lens/issues/127))** — turn_end used to re-inject the entire vulture cache every turn. A fixed list of pre-existing findings burned context, and the one actionable signal — a symbol the current edit just orphaned — never stood out. Dead code now follows knip's contract: a new `owns()` seam re-scans only when the turn touched a file of that language, and the result is diffed against the previous scan and filtered to the edited files. Only that delta is injected. It also feeds `projectDiagnosticsDelta`, and the block moved ahead of the delta-report write, so a dead-code-only turn persists a report `lens_diagnostics` can read. A timed-out or killed scan backs the runner off, and a failed scan never overwrites a good cached one. The project-wide list stays available on demand through `lens_diagnostics`. vulture also gets `--ignore-decorators`, so framework-invoked symbols such as fixtures and route handlers stop appearing as permanent noise. - **The auto-format nudge names the action, not the process** — a cross-process batch used to read "by another pi-lens instance (e.g. a subagent's)", which sent agents investigating what other instance was running. It now reads "by an automatic run outside your turn". Which process formatted the file is an implementation detail the reading agent cannot act on; the origin split stays exact in the telemetry. - **Word-index resume stats run through a bounded parallel walk (refs [#1409](https://github.com/apmantza/pi-lens/issues/1409))** — session-start incremental refresh now stats source files with a bounded indexed cursor pool (8 workers over libuv's 4-slot threadpool) instead of serial synchronous calls, while publishing metadata in original walk order so churn classification and rebuild preflight remain deterministic. Per-file stat failures retain the previous absent-file semantics, supersession stops new claims and settles in-flight work, and phase telemetry separates snapshot load, deserialize, source walk, stat walk, refresh reads, and the synchronous snapshot-save span. ### Fixed - **Timed-out pull diagnostics stop aging the LSP server (refs [#1889](https://github.com/apmantza/pi-lens/issues/1889))** — Document and workspace diagnostic pulls now send `$/cancelRequest` when their local deadline expires. Repeated native-TS7 touches no longer leave abandoned requests running and building a server-side backlog; an aging regression test holds outstanding pull work to one across repeated timeouts. - **TypeScript LSP roots follow governing configs (refs [#1412](https://github.com/apmantza/pi-lens/issues/1412))** — TypeScript and JavaScript files now prefer their nearest `tsconfig.json` or `jsconfig.json` (filtered by extension family — a `.ts` file skips a jsconfig-only directory) while preserving package-boundary client isolation, and classic servers emit bounded, read-only project-association telemetry after the first open. Classic-server tool discovery (`typescript-language-server`, `tsserver.js`) now walks up from a nested config root instead of only checking the root itself. Known accepted tradeoff: honoring nested config roots enlarges the population of roots subject to #1373's pre-existing open-order sensitivity. - **Post-fix decisions are observable (Closes #1432)** — Add bounded decision telemetry for advisory provenance, TypeScript project identity, deferred mutations, authoritative-content attachment, bus context resolution, and time-scoped smell rollups. - **Native TS7 diagnostic waits stabilize versionless publication bursts (refs [#1412](https://github.com/apmantza/pi-lens/issues/1412))** — TypeScript wait strategy resolution now follows the launched server variant: classic typescript-language-server retains authoritative first-push seeding, while native `tsc --lsp --stdio` debounces provisional pushes until a quiet window or advertised pull provides the settled result. Bounded latency telemetry records publication shape and settle source without diagnostic text. - **Stale advisories are historical, not current blockers (refs #1413)** — Turn-end and async test caches record immutable capture provenance and SHA-256-confirm every affected file at delivery. Changed, legacy, malformed, unreadable, truncated, and superseded findings remain non-blocking historical context; deleted per-file findings disappear, while unchanged findings retain live blocker framing across turn and project-sequence drift. Monotonic async-test generations prevent older batches from overwriting newer results, and MCP and in-process delivery share one classification without changing acknowledgement, one-shot consumption, or commit-gate state. - **Per-edit autofix no longer mutates files mid-turn (closes #1414)** — `edit` queues pipeline autofix for the owning `agent_end`, where autofix runs before the stable formatting pass; `write` keeps immediate autofix and returns authoritative post-fix file content, while write-then-edit paths stay demoted for the rest of the turn. Deferred mutation records coalesce both phases, preserve session ownership, deduplicate project-wide Rust/Dart fixers, and merge independently requeued phases. - **Bus publishers keep activation context ownership (closes #1415)** — Event producers pair each live emitter with its OWN activation's context (no fallback to a process-global "latest ctx", which could belong to an unrelated sibling activation) and guard lens events through the shared stale-session seam with the same occurrence-scoped failure gating every other producer uses. Lens emit failures now count toward the `bus-stale` degradation smell like every other producer's — intentional: a probe-undefined or resolve/emit race on the lens path is a genuine failure that should be visible, not silently excluded. - **`ast_grep_replace` now matches `ast_grep_search`'s `hasKind`/`hasDescendantKind` surface (closes #1423)** — `ast_grep_replace`'s `hasKind` param description wrongly said "contain a descendant"; it actually restricts to an **immediate child** (ast-grep default `stopBy: neighbor`), same as `ast_grep_search`. The description now matches the real behavior. `ast_grep_replace` also gained the `hasDescendantKind` param `ast_grep_search` already had — the explicit recursive form (`stopBy: end`) for when the target kind is nested below an immediate child; it's mutually exclusive with `hasKind`, surfaced as a clear synthesis error from both tools. `skills/pi-lens-ast-grep/SKILL.md`'s structural-intent table drops the now-obsolete "replace has no `hasDescendantKind`" divergence warning and documents both params as available on both tools. - **pi's own CLI output is no longer swallowed by the console guard (Closes #1434)** — The guard used to replace every `console.*` method globally and permanently once the extension loaded. pi's one-shot commands print through `console.log`, so `pi list` exited 0 with no output in any project whose directory loaded the extension first. The guard is now a dispatcher: it routes a write to the extension log only while pi-lens owns execution, and passes every other write to the original console method. Windows open around module evaluation, the extension activation, and every callback registered through the host API's `on` and `register*` members. `AsyncLocalStorage` carries the window across `await` boundaries. Terminal safety is unchanged for pi-lens code paths. One cost note for Node 22: an active `AsyncLocalStorage` adds per-`await` overhead process-wide on that runtime. `PI_LENS_CONSOLE_GUARD=0` disables the guard and avoids that cost entirely. - **Managed TypeScript self-heals the classic LSP fallback (closes [#1436](https://github.com/apmantza/pi-lens/issues/1436))** — Pi Lens now pins its managed classic compiler to TypeScript 5.9 and repairs existing managed TypeScript 7 trees when `tsserver.js` is absent, while leaving project-local TypeScript 7 on the native `tsc --lsp --stdio` path. - **Deliver late cascade results instead of dropping them (closes #1443)** — A cascade whose compute missed the turn-end settle cap, or whose neighbor diagnostics landed in the quiet window after the turn ended, was carried over and then discarded unread: the turn-end filter rejected every run stamped with an earlier turn, so the carry-over path was dead code (the two measured cases were the highest fan-out cascades of the day). Late runs now merge into the following turn's output, a run superseded by a newer write is dropped with a logged record instead of silently, and the carry is bounded to one turn. - **Settle native TS7 cascade checks (closes #1444)** — Cascade neighbor checks on native TS7 no longer burn the in-lane wait budget on a publication that only arrives later; the result is collected in the quiet window instead, and a late clean result now also clears the neighbor's stale footer errors. On the classic (full-wait) lane, a neighbor whose diagnostics wait lapsed used to produce no output at all — which read as "clean" — and now renders an explicit inconclusive note; unconfirmed checks are still never cached as clean. `cascade_result` records how many neighbors were deferred, so a fully-deferred cascade is distinguishable from a clean leaf. - **Cascade no longer blames the review graph for test-file edits (closes #1445)** — A `missing_node` cascade result had two causes that read the same but meant opposite things: a real gap in the graph, and a test file excluded from the graph by design (#260). Test-file edits now get a distinct `excluded_by_role` reason that stays in telemetry but never reaches the agent as a "review graph was unavailable" advisory. A genuinely missing source file still reports `missing_node` and still triggers the advisory. - **Test-runner results report a real duration and a real skip count (closes #1452)** — Every vitest and jest run logged `(0ms)`: `parseJsonTestOutput` hardcoded `duration: 0` and read `numSkippedTests`, a field neither reporter emits, so a file with skipped tests also always reported 0 skipped. Duration now comes from the per-suite `startTime`/`endTime` the reporters do emit (wall-clock span across suites, falling back to summed per-assertion durations), and skips come from `numPendingTests` + `numTodoTests`. PHPUnit's own `Time:` summary line — both the `00:00.123` clock form and the legacy `1.23 seconds` / `123 ms` forms — is parsed instead of discarded. An unparseable summary reports no duration at all rather than a wrong figure (see #1479 — this sentence read "still reports 0" until that landed, and both entries are still unreleased, so one release's notes would otherwise have contradicted the other). - **Keep the tool list stable across forks and reloads (closes #1453)** — When a session is forked, reloaded, or resumed, pi tells the model about every pi-lens tool again. Pi-lens now puts the list straight back to what it was, including the situational tools the model had activated, so the tool list the model sees does not change and your cached prompt still applies. Use `--no-lazy-tools` (or `tools.lazy: false`) to keep every tool active from the start instead. - **Auxiliary LSP scanners reach per-edit diagnostics (closes #1458)** — Auxiliary waits now use each server's declared budget within a 2-second post-primary ceiling, in both the touch push wait and the `getDiagnostics` aggregation lane. Late findings carry into the next unchanged-content read only when their SHA-256 content binding matches. Each touch logs a per-scanner wait outcome (answered, silent, or cut off — decided from evidence of an actual publication, not just promise settlement) with elapsed time and effective budget. Independently diagnosed by @snowyukitty, who reported the same root cause and both affected call sites in #1471. - **Secret blockers no longer name deleted files (refs #1461)** — Scanner result caches were valid on wall-clock age alone, so a gitleaks finding stayed a 🔴 STOP blocker for the rest of its 30-minute window even after the file it named was deleted. The advisory provenance guard did not catch it: it validates the files the agent edited, not the paths inside the findings. Provenance now also validates finding-cited paths, and gitleaks drops findings whose path is gone rather than demoting them — a deleted file offers no remediation. Findings on files that still exist are delivered unchanged; a finding with no path, an unreadable path, or a path past the stat budget is still delivered. Each drop writes one bounded `finding_dead_path_drop` record to `latency.log` naming the store, the count, and a sample of paths. - **A slow tool check no longer disables an installed tool for the whole session (closes #1467)** — When the check for knip, madge, govulncheck, or vulture timed out, pi-lens remembered the tool as unavailable until you restarted, and told you to install a tool that was already installed. Knip produced no findings for weeks because of this. A timed-out check is now retried after a short wait, the message says the check timed out instead of naming the wrong cause, a failed run keeps the last good cached findings instead of overwriting them, and each decision is recorded in `latency.log` as an `availability_decision` entry with its cause and timing. - **A cut-off auxiliary no longer reads as confirmed clean (closes #1470)** — When the aux grace timer cut off a scanner such as opengrep, the touch still reported an unqualified confirmation, so a hung security scanner produced a result that read as a clean bill of health. The confirmation is now narrowed rather than discarded: it names the servers it does not speak for, so `lsp_diagnostics` says which coverage is missing, the cascade no longer wipes a live finding on that evidence, the workspace sweep stops caching a partially covered result, and the per-edit lane stops reporting an empty result as checked — on both the incumbent-touch route and the warm-attach route a per-edit check takes in a live session. A primary that answered stays trustworthy — its findings still reach you. A related gap stays open: a scanner that answers within its budget but publishes nothing still reads as clean (#1493). - **A slow first probe no longer disables an installed tool (closes #1476)** — biome, ast-grep, Go, cargo and govulncheck now tell a probe timeout apart from a missing install, the way knip and madge already did. Before this, one stalled second at session warm-up latched "tool is not installed" for the life of the process, and biome and ast-grep also paid for an auto-install nobody needed. A transient verdict now expires and the tool comes back without a restart, its cooldown escalates on a host that stays sick, and every verdict is recorded in `latency.log` as `availability_decision` with its cause, timing and retry schedule. A structural coverage test parses `clients/` and fails when a new version probe parks its verdict outside the shared policy; the hand-rolled latches that predate it are listed in the test as named, shrink-only gaps rather than being quietly excluded. - **The turn-end log no longer prints `(0ms)` for a run it never timed (closes #1479)** — `(0ms)` was the string for a genuinely sub-millisecond run *and* for one nobody measured: a JSON payload with no suite timestamps, a pytest or ExUnit or PHPUnit summary the parser could not read, a runner error, or nothing run at all. A reader could not tell "measured 0" from "unmeasured", which is the confusion #1452 was reported for in the first place. `TestResult.duration` is now absent when the run was not measured — a present `0` means a real reading, because pytest does print `in 0.00s` — and the turn-end line renders `(unmeasured)` for the absent case. The agent-facing `formatResult` string is unchanged. - **Cargo, dotnet, maven, rspec and minitest runs report a real duration (closes [#1480](https://github.com/apmantza/pi-lens/issues/1480))** — `parseGenericRunnerOutput` read an elapsed time only for go, so the seven runner families behind it reported a hardcoded `0`. Each duration is now parsed from the summary block the runner already prints, and each pattern is applied only to the runner it belongs to, so no runner can be scored by another's output — gradle used to satisfy go's probe and report the whole-build wall clock as test time. Gradle stays unmeasured: its console summary carries no test elapsed time. Multi-module maven runs are scored by the sum of their surefire aggregates rather than by a single module, a runner that exits non-zero can no longer be reported as a pass, and the pytest and ExUnit summaries are rounded to whole milliseconds instead of logging `2009.9999999999998ms`. The "was this measured at all" rule now lives in one module (`clients/run-duration.ts`) that both the turn-end log and the agent-facing summary read, rather than being re-derived at each site. ## [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 (RSS 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..disable` / `rules..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 `` 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.` 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 (` — `) 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---` 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---` 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-` 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--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---`, 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-`, `.tmp--`, `.tmp---`). `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-` 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--`, the checkpoint stage, and either's persist-worker `.tmp-`), 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-` 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--`), 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-` (the pattern keeps the `` 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--` 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 `-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 `/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` 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 `/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-` 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 `::` 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 `_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 `, 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>` — 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 ` 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"` 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 - **🙏 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. - **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. - **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`. - **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`. - **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). - **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. - **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`. - **Standalone out-of-band review-graph build CLI** (refs #924) — `npx pi-lens build-graph [--cwd ]` 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. ### 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). - **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. - **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. - **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`). - **`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. - **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. - **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. - **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. - **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. - **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. - **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. - **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. - **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. - **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. - **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. - **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. - **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. - **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. - **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. - **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. - 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. - **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**. - **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. - **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. - **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. - **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. ### Fixed - **Read-before-edit guard now survives a session resume (#1041)** — the guard's read-set was in-memory only, so a `pi --session ` 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. - **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`** 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. - **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. - **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. - **`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. - **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(, )` — 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. - **`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. - **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). - **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. - **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. - **`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. - **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. - **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. - **`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. - **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. - 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. - **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. - **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. - **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. - **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. - **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. - **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. - **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)`. - **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. - **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. - **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. - **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). - **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. - **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`. - **`.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. - **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. - **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. - **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. ## [3.8.73] - 2026-07-28 ### Added ### 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` 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. - **`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. ### Fixed - **ast-grep Gate-B now follows LSP liveness and launcher resolution** (refs #868) — the NAPI fallback no longer runs beside a healthy ast-grep LSP when the bundled native binary is resolvable but `ast-grep` is absent from PATH; it still engages when neither resolution path nor a live client is available. - **NAPI fallback unsupported-rule skips no longer spam the session log** (refs #282) — the per-rule terminal lines (one for each of the ~30 non-jsts catalog rules) are replaced by a single aggregated `astgrep_napi_unsupported_rules_skipped` entry in `latency.log` carrying per-language counts and rule ids. - **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. - **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. - **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. - **LSP singleton resets no longer overlap live server generations** (closes #850) — `resetLSPService()` still returns synchronously and may allocate a replacement service immediately, but that replacement's first spawn now waits for every older generation's asynchronous teardown to settle. Repeated resets destroy an intermediate waiting generation before it can spawn, and post-root/post-client-cleanup guards prevent a retired service from starting a late process outside `state.inFlight`. The handoff is cleared after its first wait, preserving normal within-generation warm reuse and its hot path; concurrent-secondary sessions still skip destructive reset through the existing ownership guard. New deterministic coverage holds the old client's shutdown open and proves current `master`'s pre-fix second spawn/three-generation accumulation cannot recur. ## [3.8.72] - 2026-07-26 ### Added - **Subagent identity in the instance registry** (#822) — subagent sessions now persist their marker, agent type, parent PID, and run ID in `instances.json` for concurrency-profile analysis; primary and legacy entries remain unchanged. - **Same-workspace warm LSP attach (opt-in soak)** (#822) — with `PI_LENS_WARM_ATTACH=1`, a new session discovers a PID-confirmed, heartbeat-fresh incumbent for the same workspace root and routes per-edit and project-sweep LSP diagnostic touches through its PID-scoped, versioned IPC endpoint instead of spawning a duplicate fleet. Attached dispatch diagnostics now also request bounded code actions from the incumbent, preserving quickfix enrichment without creating a local client; enrichment failures skip quickfixes without promoting because the authoritative diagnostics already succeeded. Sweep warm-up, pre-open, and workspace-pull paths stay dormant while attached; a mid-sweep attach failure permanently promotes the session and resumes the remaining files locally. Content hashes and deadlines guard freshness; any IPC, schema, freshness, timeout, or incumbent-liveness failure permanently promotes the session to today's local LSP path. Decisions and per-file routing sources are logged as `lsp_warm_attach`. - **Resource-aware cross-process LSP budget policy** (closes #821) — budget pressure now shortens the current session's idle reset, lets pull-capable servers rely on pull diagnostics without a push-warm fallback, and can supplement the live-server ceiling with an opt-in aggregate RSS ceiling (`PI_LENS_LSP_BUDGET_RSS_MB`). Missing or stale resource samples fail open to count-only behavior; the existing kill switch disables every policy. - **Review-graph JavaScript/TypeScript import resolution now follows tsconfig project references** (#819) — a bare package import declared through `"references": [{"path": "../lib"}]` resolves to the referenced package's source entry after `paths` aliases and before workspace-package fallback, including transitive references with cycle protection and directory or direct-config targets. ### Fixed - **Markdownlint no longer passes the invalid `--disable MD013` CLI option** (closes #833) — unconfigured Markdown projects now use the package-owned default config, which disables MD013 and scopes MD024 to sibling headings so intentional repeated changelog category headings are allowed; project markdownlint-cli2 configs are preserved unchanged, including the CLI's JSONC/YAML/CJS/MJS filename variants. - **`safeSpawnAsync` (and the deprecated sync `safeSpawn`) no longer build a cmd.exe command line from caller-tainted input on Windows** (closes #817, CodeQL alerts #17/#18/#19, CWE-78) — after #815/#816 replaced `shell:true` with an explicit `cmd.exe /d /s /c ` invocation, CodeQL re-flagged the same spawn: the escaping was genuinely unsound (`%VAR%` expands even inside double quotes and cannot be escaped on a `/c` line; cmd's quote-state toggling can defeat `""` doubling), not just a taint false positive. `clients/safe-spawn.ts` now resolves `command` itself via a cached PATH+PATHEXT walk (`resolveWindowsCommand`, a `where`-equivalent, keyed by `command`+`PATH`+`cwd`; reset hook `resetSafeSpawnWindowsCommandCache()` wired into `runtime-session.ts`'s `handleSessionStart` alongside the repo's other session-lived caches). `.exe`/`.com` resolutions — the overwhelming majority of spawns (sg, biome, ruff, git, node, `where.exe`...) — now spawn directly with `shell:false` and a real args array: no command line is ever built, so there's nothing for cmd.exe to reinterpret. `.cmd`/`.bat` shims (npm-installed tool wrappers, the common case) keep the cmd.exe wrapper since they can't run without it, but the interpreter is pinned to `%SystemRoot%\System32\cmd.exe` (never `ComSpec`/`COMSPEC`, addressing alert #18 — the same pin `killTree` already used for `taskkill`) and args are VALIDATED instead of escaped: a value containing `"`, `%`, `!`, or CR/LF is rejected with a clear "Refusing to spawn... via cmd.exe" `SpawnResult.error` rather than spawned with an unsound escape — validated against the *resolved* path (what's actually interpolated into the `/c` line), not just the caller's original command string, so a resolved path itself containing `%`/`!` can't slip through unvalidated either. An unresolvable command now returns a synthesized `ENOENT`-shaped error (message/`code`/`syscall`/`path`) instead of letting cmd.exe report "not recognized" from inside a shell, preserving existing `err.message.includes("ENOENT")`/`err.code === "ENOENT"` tool-not-installed detection at call sites like `sg-runner.ts`. The `chcp 65001` UTF-8 console-code-page mutation is preserved for the tools that needed it (sg/biome/ruff CP850/CP936/CP932 mis-decoding): the `.cmd`/`.bat` wrapper keeps its `chcp` prefix as-is, and a new one-shot `ensureUtf8ConsoleCodePageOnce()` runs the same static, hardcoded `chcp 65001` via a pinned-cmd.exe spawn exactly once per process before the first direct `.exe` spawn (the console code-page mutation persists for the console's lifetime, so once suffices — a strict improvement over today's per-spawn re-run, not a regression). A code-review pass on the first version of this fix found the deprecated synchronous `safeSpawn` (today's only caller: `test-runner-client.ts`'s sync pytest-on-PATH probe) still had the identical `buildWindowsCommand`/`shell:true` sink — its Windows branch (and the now-dead `escapeWindowsArg`/`buildWindowsCommand` helpers it alone used) is reimplemented against the exact same seams (`resolveWindowsCommand`/`findCmdUnsafeValue`/`buildWindowsShellCommand`/`synthesizeEnoentError`) with `spawnSync(..., { shell: false })` throughout; `test-runner-client.ts`'s call site is unchanged (its `detectRunner`/`findTestFile` call chain is synchronous with many sync callers/tests — migrating to async wasn't a trivial, in-scope change here). New coverage in `tests/clients/safe-spawn-windows-command.test.ts` (Windows-conditional, real spawns), mirrored for both the async and sync entry points: direct `.exe` PATH resolution + spawn, a `.cmd` fixture round-tripping an arg with spaces through the pinned wrapper, `%`/`"`-bearing args rejected against a `.cmd` shim with nothing spawned, the same dangerous args passing through literally to a direct `.exe` spawn, an unresolvable command producing the ENOENT-shaped error, and (async-only) resolver-cache reuse/reset. `buildWindowsShellCommand` remains exported (existing #214 regression tests unchanged). Verified end-to-end against the built compiled output for BOTH entry points: a `.cmd` shim (`npx.cmd --version`) and a bare `.exe` (`git --version`) spawn correctly, a `%`-bearing arg to a `.cmd` shim is rejected with nothing spawned, and an unresolvable command yields the ENOENT-shaped error. Related pre-existing cmd.exe-command-line-building patterns found outside `safe-spawn.ts` (`clients/lsp/client.ts`'s PS1→PowerShell fallback shell path, `clients/sg-runner.ts`'s non-bash Windows fallback) are out of scope for this issue (#817 is scoped to `safe-spawn.ts`) and are noted for a follow-up rather than folded in here. - **Multi-server `clientScope: "all"` diagnostic touches now get the same silent-clean confirm #799 gave the single-server hot path** (closes #814) — `lens_diagnostics` mode=full's per-file sweep and `lsp_diagnostics`' `serverScope: "all"` both use `touchFile`'s `clientScope: "all"` path, which #799's clean-confirm gate never covered (it's scoped to `clientScope === "primary" && spawned.length === 1`), so a clean markdown file with marksman (push-only, `silentOnClean`) alongside other servers that all answered still burned marksman's own budget and reported the WHOLE touch `inconclusive`/`diagnosticsTimedOut`, blocking clean-caching and `demonstratedReady`. New `classifyServerWaitTier(serverId, snapshot)` in `clients/lsp/cascade-tier.ts` extracts the per-server classification rule `classifyCascadeWaitTier` (#458) already used for the file's primary server, so both share one classification, not two. `touchFile` (`clients/lsp/index.ts`) now runs a capability-aware aggregate gate after a `clientScope: "all"` touch's diagnostics wait times out: a spawned server counts as "still outstanding" when nothing landed in its per-file diagnostics cache for this touch (`getAllDiagnostics()` — cleared by this touch's own didOpen/didChange, so a present entry can only be a fresh answer, reusing the same #240 doctrine signal `cascade-tier.ts`'s Tier-3 reconcile already trusts); the touch is only resolved as CONFIRMED clean (0 diagnostics from the silent server(s), `diagnosticsTimedOut` cleared, not `inconclusive`) when EVERY still-outstanding server classifies `tier3-silent` (push-only + `silentOnClean`) AND its notify write actually succeeded. One ordinary push-only straggler (not marked `silentOnClean`) or a failed notify write keeps the touch cautious, matching today's behavior exactly. Fails safe (today's timeout/inconclusive behavior) on any classification error. Logs a distinguishable `lsp_silent_clean_confirm` phase with `aggregate: true` and the resolved `serverIds`. The pre-existing single-server `clientScope === "primary"` gate is left unchanged (a documented special case of this more general rule — a future cleanup could fold the two together once both have soaked). New coverage in `tests/clients/lsp/silent-clean-confirm.test.ts`'s "touchFile capability-aware AGGREGATE wait (#814)" describe block: one publisher + one silent server resolves early as confirmed clean with the publisher's findings kept; a failed notify write on the silent server still times out; an ordinary (non-`silentOnClean`) push-only straggler still runs to cap and stays inconclusive; every spawned server silent resolves at the max of their budgets as confirmed clean; and a classification-throwing failure falls back to today's timeout behavior. ### Added - **`getWorkspaceTopology` — shared, memoized workspace-topology marker index** (closes #806) — new `clients/workspace-topology.ts` consolidates the per-subsystem per-directory marker walks (`.pi-lens.json`/`pi-lens.json`, `tsconfig.json`, and the workspace-manifest markers `workspace-modules.ts` cares about — `package.json`, `pnpm-workspace.yaml`, `Cargo.toml`, `go.work`) into one shared seam: `getDirectoryMarkers(dir)` collects ALL markers for a directory in a single `readdir` pass, cached and invalidated per-directory by the directory's own mtime; `findNearestDirWithMarker` layers the shared upward-walk discipline on top (`walkUpDirs` + `isAtOrAboveHomeDir` ceiling, an explicit 64-deep cap that logs a `workspace-topology-walk-cap` latency phase instead of truncating silently). Three consumers migrated with zero resolution-semantics change: `project-lens-config.ts`'s `findPiLensConfigInDir` (the #804 nested mutation-control walk's per-dir discovery), `review-graph/tsconfig-paths.ts`'s governing-tsconfig discovery, and `review-graph/workspace-modules.ts`'s `detectWorkspaceType` manifest-presence probes (manifest CONTENT parsing is unchanged/unmoved). New `resetWorkspaceTopology()` is wired into `runtime-session.ts`'s `handleSessionStart` alongside `tsconfig-paths.ts`'s `clearTsconfigPathsCache()` — an added behavior improvement: a `tsconfig.json` edited mid-session is now picked up on the next session/reset instead of never (the matcher cache was previously session-lived with no reset hook at all, noted on #805). Root/language-root resolution is explicitly NOT migrated (#806 lists it as a later follow-up). New `tests/clients/workspace-topology.test.ts` (marker index correctness incl. both `.pi-lens.json` basenames, single-`readdir`-pass collection, mtime invalidation, the reset hook, the home-dir ceiling, and cap-trip logging). - **Root/language-root resolution migrated onto the workspace-topology index — second wave** (closes #807) — `language-profile.ts`'s `resolveLanguageRootForFile` now discovers its per-language-kind root marker (e.g. `tsconfig.json`/`package.json` for `jsts`, `Cargo.toml` for `rust`) via a new `findNearestDirWithAnyBasename(startDir, basenames, homeDir?)` in `clients/workspace-topology.ts` — the generalized, home-guarded/depth-capped/walk-cached counterpart of `findNearestDirWithMarker` for a per-call marker LIST rather than one of `DirectoryMarkers`' typed fields; each `DirectoryMarkers` entry now also carries a raw `entryNames` set (from the same single `readdir`) for this kind of type-agnostic, non-typed-field presence check. `resolveLanguageRootForFile`'s OWN policy is unchanged: it still clamps any discovered root back to `workspaceRoot` via its existing stricter workspace-relative check — the topology service supplies discovery only. `startup-scan.ts`'s `findNearestProjectRoot` now reads per-directory marker presence through `getDirectoryMarkers(dir).entryNames` (one cached `readdir` per directory instead of `PROJECT_ROOT_MARKERS.length` separate `existsSync` stats), but deliberately KEEPS its own hand-written, non-home-guarded walk-UP loop — its callers (`computeStartupScanContext`/`resolveStartupScanContextAsync`) need the actual marker location even at/above `$HOME` to distinguish the `"home-dir"` verdict from `"no-project-root"` (pinned by `tests/clients/startup-scan-home-ceiling.test.ts`); a home-guarded walker would silently misreport that case. A repo-root micro-benchmark (N=1000 resolutions over a synthetic 12-package, 8-levels-deep monorepo fixture) measured the migration as a net win on the hot per-edit path: ~68–75% faster spread across many files, ~79–82% faster for a repeated small working set (the realistic edit-loop pattern) versus the pre-migration hand-rolled `existsSync` loop. Sweep for remaining hand-rolled upward marker probes found several NOT migrated in this pass, each for a documented reason (see PR #807 description): `tool-policy.ts`'s `has*Config` family (already a documented exception, different shape — content-sniffing booleans); `dispatch/runners/{oxlint,vale,shellcheck,shfmt}.ts`, `dispatch/runners/utils/runner-helpers.ts`, `review-graph/git-identity.ts`, `file-utils.ts`, `metrics-history.ts`, `lsp/{config,server}.ts`, and `review-graph/import-resolvers.ts` (all currently un-home-guarded tool-config/VCS-root probes; routing them through the topology service would newly add a home-guard, a behavior change out of scope for an exact-semantics migration); `pipeline.ts`'s/`dispatch/runners/rust-clippy.ts`'s `findNearestContaining` calls for `Cargo.toml`/`pubspec.yaml` (already on the shared `path-utils.ts` primitive, same reasoning); `knip-client.ts`/`dead-code-client.ts` (already on the shared, guarded `findNearestMarkerRoot` primitive); `jscpd-client.ts` (explicitly does not resolve a project root, per its own comment); `package-root.ts` (resolves pi-lens's OWN installed package root from a module URL, a different domain than user-workspace discovery). `clients/project-scale.ts` was left untouched per this PR's constraints (concurrent work) and, on inspection, contains no such probe. Existing tests (`tests/clients/language-profile.test.ts`, `tests/clients/startup-scan-*.test.ts`) pass unmodified; new coverage lives in `tests/clients/workspace-topology.test.ts` for the added `entryNames` field/`findNearestDirWithAnyBasename` surface. - **Empirical monorepo test harness — Track B of the #775 root-resolution audit** (refs #775) — a reusable `makeMonorepo(opts)` fixture builder (`tests/monorepo/fixture.ts`) that builds a temp npm-workspaces repo (root `package.json#workspaces`, N packages with names/deps/files, optional nested `.gitignore`/`.pi-lens.json`, optional file-count padding) plus eight committed regression files (`tests/monorepo/*.test.ts`, 29 tests) covering the audit's test matrix: cross-package graph edges post-#777 (entry + subpath specifiers, non-workspace bare specifiers stay external, `module_report`'s `usedBy`/blast-radius and `computeImpactCascade`'s module-level downstream expansion actually see them); size-cliff behavior (startup-scan's verdict flips exactly at `maxSourceFiles`, sync+async; review-graph bails above its cap and — answering the audit's open question — `getCachedReviewGraph` returns `undefined` after a fresh size-skipped build with no prior warm graph, but keeps serving a now-STALE prior graph once one already existed, and `module_report` degrades identically to a cold cache either way); the post-#779 `maxProjectFiles` scale knob changing effective startup-scan/review-graph budgets end-to-end via `.pi-lens.json`; session-in-package-subdir root-resolution scoping; nested `.gitignore` + `.pi-lens.json` layering (root+package-local gitignore both honored; a package-local `.pi-lens.json`'s `maxProjectFiles` wins for a package-scoped cwd, but its `ignore` field is never consulted — only the root's is, since the ignore matcher always re-anchors to the git root first); diagnostics-scanner `scanTruncated` reaching `lens-engine.ts`'s `projectScan` seam unmodified; `computeImpactCascade`'s module-graph fallback requiring an explicit `cwd` (present on the primary per-edit cascade path, absent — though available in scope — on `runBlastRadiusInBackground`'s call site); and a pnpm-store-shaped symlink layout (junction-based, Windows-safe) extending #777's symlink-safety pinning to `source-filter.ts`'s walker, including `followSymlinks:true` being observably inert for a Windows junction. Two `KNOWN GAP (#775)`-marked tests pin current (unfixed) behavior rather than asserting an ideal outcome. Tests-only — no production code changed. - **New `project_report` registered tool (+ MCP mirror `pilens_project_report`)** (closes #773) — the top of the discovery funnel (`project_report` → `module_report` → `read_symbol`), answering "orient me in this project" purely from data the review graph already computes: a trust header (graph freshness, file coverage vs. the persisted project snapshot's file count, and the exact/import/receiver-type/name-only edge-resolution-quality mix, reusing `module_report`'s existing `resolution` tags), hubs (top fan-in files with `blastRadius` and a one-line role from their most-imported exported symbols), entry points (near-zero fan-in / high fan-out files), a directory-level subsystem map (first-path-segment clustering that collapses to a deeper segment only when one segment dominates the file set, directory-to-directory import edge counts, Tarjan-SCC cycle detection worst-first, and minority-direction layering violations for any directory pair with edges both ways), risk hotspots (fan-in × max per-symbol cyclomatic complexity), and suspected dead weight (zero-importer non-entry-point files, always shipped with a low-confidence disclaimer for dynamic-import/runtime-registration/test-only-reachability false positives). Every ranked list is capped by a single `limit` knob and re-rankable via an optional `focus` hint (module_report's `recommendedReads` ranking pattern). Read-only over the cached graph, mirroring `module_report`'s #256 no-build contract and `symbol_search`'s #348 cold-cache contract: a cold graph kicks off a single deduped background build (`buildOrUpdateGraph`, home-ceiling-guarded) and returns `available: false` with an actionable retry hint, never blocking the call. `view: "compact"` renders a line-oriented text summary instead of JSON, matching `module_report`'s convention. New engine module `clients/project-report.ts` (never imports from `tools/`, per the repo's layering rule) plus a thin `tools/project-report.ts` wrapper; registered as an always-active tool in `index.ts` alongside `module_report`/`symbol_search` (`tests/index-wiring.test.ts` updated), and mirrored in `mcp/server.ts` as `pilens_project_report` (schema/registration covered by `tests/mcp/server.smoke.test.ts`). Middle-man detection is deliberately NOT surfaced (a documented v1 deviation): the review graph doesn't persist that signal on symbol nodes today — `module_report` computes it per-file, on demand, from raw file content — and re-deriving it project-wide would mean re-scanning every class-bearing file on this never-blocks read path. New `tests/clients/project-report.test.ts` (cold path non-blocking + background build, all six warm-path section shapes, the `limit` knob scaling every cap, a synthetic-fixture directory cycle via Tarjan SCC, a synthetic-fixture minority-direction layering violation, the dead-weight disclaimer always present, and `focus` re-ranking hub order) and `tests/tools/project-report.test.ts` (cold/warm/compact-view wrapper behavior). ### Changed - **Explicit `lsp_diagnostics` file batches now expose a consolidated contract** (refs #837) — runtime path lists are normalized and rejected above the 100-file cap (never silently truncated), preserve input order, enforce bounded per-file deadlines and abort-aware completion, and return honest per-file outcomes (`clean`, `findings`, `unsupported`, `unavailable`, `failed`, `inconclusive`) with aggregate counts. Primary-language diagnostics remain separated from auxiliary findings, and incomplete batches are rendered as unconfirmed. - **Incumbent LSP wait policy now has one process-neutral module boundary** (#822) — per-server strategies, tier classification, and capability-snapshot types moved under `clients/lsp/wait-policy/` with compatibility re-exports at the old paths; this is an internal refactor with no behavior change. - **Review-graph file budget now tapers instead of scaling flatly or cliff-dropping above 1,000 files** (refs #775 R1) — `project-scale.ts`'s `getReviewGraphMaxFilesDerived` keeps today's exact 0.5× `maxProjectFiles` ratio (1,000 files at the 2,000 default base) unchanged for every project at or below a 4,000-file `maxProjectFiles` base, then tapers growth asymptotically toward a 5,000-file hard ceiling for larger bases instead of continuing linearly forever. The ceiling is bound FIRST by the review graph's own disk-persist circuit-breaker (`GRAPH_PERSIST_MAX_ELEMENTS_DEFAULT` = 200,000 graph elements in `review-graph/builder.ts` — above it the graph is never persisted, logged + skipped, so a repo over that line pays a full cold build every session instead of once): at ~30 elements/file for a symbol-dense repo, 5,000 files ≈ 150,000 elements, a ~25% margin below the persist cap (a 6,000-file ceiling considered during review left only ~10% margin — too little for a denser-than-average repo). SECOND and independently, it's consistent with the graph's measured per-file build cost (CHANGELOG 3.8.43: "2-4 s" full cold build at the then-1,000-file cap, ~2-4 ms/file; 5,000 files ≈ 10-20 s worst-case, one-time and disk-cached thereafter). New `.pi-lens.json#reviewGraph.maxFiles` knob (R2) lets a monorepo opt into a bigger graph explicitly, bypassing the taper (tolerant numeric parse, clamped to `[100, 20_000]`, warn-once on invalid — mirrors `maxProjectFiles`'s parsing); the pre-existing `PI_LENS_REVIEW_GRAPH_MAX_FILES` env override still wins outright over both. Truncation (files found over the cap) now always logs a `review_graph_size_skip` latency phase directly from `review-graph/builder.ts`'s skip branch (R3), independent of which caller triggered the build, instead of relying on `dispatch/integration.ts`'s cascade-only `graph_build` log — closing a silent-cap gap for the other four `buildOrUpdateGraph` call sites (`lens-map.ts`, `project-report.ts`, `mcp/analyze.ts`, `runtime-session.ts`, `dispatch/runners/tree-sitter.ts`). Documented in `docs/globalconfig.md`'s project-config section. New tests: `taperedReviewGraphMaxFiles` shape (below/at/above the linear boundary, half-gap-at-taper-scale property, ceiling asymptote, monotonicity), the config knob's parse/clamp/warn-once behavior, and the new latency phase. - **Review-graph JS/TS imports now honor `compilerOptions.baseUrl` and `paths` aliases, including relative `extends` chains** (refs #775) — aliased imports resolve to real workspace files before workspace-package/external fallback, with longest-prefix matching and existing extension/index probing. - **Nested mutation controls now layer per edited file** (refs #792) — monorepo package `.pi-lens.json` files use closest-wins resolution independently for `format.enabled`, `autofix.enabled`, and `actionableWarnings.autoFix.enabled`, with explicit CLI disables still highest precedence and mtime-keyed per-directory config caching. - **`symbol_search`/`pilens_symbol_search` gained `paths`/`lang` filters, per-hit `suggestedNext` discovery hints, and warm-review-graph annotations** (closes #771) — three additive ergonomics improvements over the registered tool (`tools/symbol-search.ts` → `clients/lens-engine.ts`'s `symbolSearch`, mirrored in `mcp/server.ts`), all reusing existing machinery: (1) optional `paths` (glob array, same shape/semantics as `ast_grep_search`'s `paths` — a bare directory/file entry scopes its subtree) and `lang` (same identifiers as `ast_grep_search`'s `lang`, mapped to extensions) scope the word index BEFORE ranking via a new `RankOptions.fileFilter` on `searchWordIndex` (`clients/word-index.ts`), so a surviving file's BM25/priors/centrality score is identical to an unfiltered run — omitting both params reproduces prior output byte-for-byte; (2) every hit now carries a `suggestedNext: { tool: "module_report", path }` hint (mirrors `ast-grep-search.ts`'s `suggestedDump` pattern), making the symbol_search → module_report → read_symbol discovery funnel machine-actionable instead of prose-only; (3) hits gain an optional `annotations: { fanIn, complexity }` — `fanIn` reuses the SAME reverse-dependency centrality value already computed for the ranking boost, `complexity` is the file's highest recorded per-symbol cyclomatic complexity from the review graph — populated only when `getCachedReviewGraph` (`clients/review-graph/builder.ts`, dynamic-imported to keep it off the hot path when unused) finds an already-warm graph; this accessor is READ-ONLY and never builds/blocks, so a cold graph simply omits `annotations` with no added latency. `symbolSearch` is now `async` (the dynamic import) — an additive signature change; both call sites (`tools/symbol-search.ts`, `mcp/server.ts`) now `await` it. New/extended coverage: `tests/clients/word-index.test.ts` (`fileFilter` score-preservation + omitted-filter equivalence), `tests/tools/symbol-search.test.ts` (paths/lang filtering, no-filter parity, per-hit `suggestedNext`, graph-cold no-annotation-no-build, graph-warm annotation presence), and `tests/index-wiring.test.ts` (asserts `paths`/`lang` are actually registered on the tool's parameter schema). - **New `lazyEnvNumber(envName, fallback)` factory in `clients/env-utils.ts`** (closes #763) collapses the repeated "lazy + memoized, `toPositiveFinite(process.env[name])`-or-fallback" getter triple — each instance was a module-level memo variable plus a `getX()`/`_resetXForTests()` pair, ~20 lines apiece — into one line per call site while keeping every exported name/signature unchanged so callers and tests don't churn: `clients/startup-scan.ts`'s `getStartupScanVerdictTtlMs`/`_resetStartupScanVerdictTtlForTests` and `getStartupScanMaxEntries`/`_resetStartupScanMaxEntriesForTests` now re-export `lazyEnvNumber(...).get`/`._resetForTests`. `runtime-config.ts`'s `getRunnerTimeoutFloorMs` (also reads a config-file value and takes `Math.max` of the two sources), `slow-fs.ts`'s threshold resolver (memoized per-cwd probe result, not per env-value, and recomputed on every probe rather than cached standalone), and `subagent-mode.ts`'s classification cache (boolean/string shape, not a number) were left as-is — none match the number-only lazy-memoized-getter shape the factory targets. No behavior change. New `describe("lazyEnvNumber", ...)` block in `tests/clients/env-utils.test.ts` covers default/override/non-finite-fallback/memoization-until-reset/no-env-read-at-construction/independent-instance-memo, mirroring `tests/clients/startup-scan-entry-budget.test.ts`'s existing getter tests (left unmodified and still passing). ### Fixed - **Windows subprocess arguments no longer pass through Node's `shell:true` concatenation** (CodeQL alert #17 / CWE-78) — `safeSpawnAsync` now invokes `cmd.exe` explicitly with `shell:false` and `windowsVerbatimArguments` so its manually quoted `/c` payload is not escaped a second time by Node. User-controlled paths and arguments remain arguments instead of becoming additional commands; regression coverage includes a shell-metacharacter argument and Windows command paths with spaces. - **CI drift alerts no longer interpolate third-party output into shell code** — compat-smoke passes layer outcomes and versions through environment variables, and install-smoke disables persistent checkout credentials before running package-install tests. Intentional pinned ad-hoc package installs are documented with targeted zizmor suppressions. - **Windows temp-dir teardown no longer fails tests with EPERM/ENOTEMPTY** (closes #810) — root cause of the deterministic `tests/clients/runtime-session.test.ts` failures (2 of 12, reproduced on clean master on this machine): in "full" mode with a `package.json` present, `scheduleStartupScans` (`clients/runtime-session.ts`) fires `todo` and `word-index` as fire-and-forget background tasks (`setImmediate`) that do REAL, unmocked fs reads against the test's temp project dir — unlike knip/jscpd/ast-grep-exports/etc, which the test stubs out entirely. The test helper's `runSessionStart` returned as soon as `handleSessionStart`'s own promise resolved, so the caller's `finally { env.cleanup() }` could run while those two tasks were still mid-read, racing the recursive `rm` against an open file handle inside the temp dir (deterministic here, not a load flake). Fixed by tracking the real in-flight-scan set (via `markStartupScanInFlight`/`clearStartupScanInFlight`, the same primitive production code uses) and having the returned `cleanup` wait for `todo`/`word-index` to settle before deleting the directory — `call-graph`/`codebase-model` are deliberately excluded since they're staggered 5+ seconds out by design and a stale/missing analysisRoot by the time they fire is a harmless no-op. Also added ONE shared hardened temp-dir cleanup helper, `removeTempDirSync` (`tests/clients/test-utils.ts`), implementing the #793 pattern (`maxRetries: 5, retryDelay: 200`) wrapped so a final failure warns via `console.warn` instead of failing the suite — a leftover temp dir is harmless, a red run from teardown is not — and swept every ad-hoc `fs.rmSync(dir, { recursive: true, force: true })` directory teardown across `tests/` onto it (~104 files), including two bespoke retry-and-swallow sites (`tests/clients/lens-map.test.ts`, `tests/clients/ast-grep-rule-precedence-followups.test.ts`) that had hand-rolled the same pattern locally. Single-file (non-recursive) `fs.rmSync` calls that delete one fixture file mid-test were left as-is (bespoke, not directory teardown). - **`lens_diagnostic_mark` no longer trusts a stale caller-supplied `line` verbatim — it verifies/reanchors against current diagnostics before writing anything** (closes #802) — the tool handler (`tools/lens-diagnostic-mark.ts`) previously hashed/wrote at exactly the `line` the agent passed, with no check that the file's CURRENT content still put that finding there. A stale line silently rotted `false-positive`'s strict content-hash anchor (it never matched the real finding again) and, worse, made `suppress` write the inline `pi-lens-ignore` comment above the WRONG statement — the self-inflicted case being a top-down batch-suppress in one file, where each inserted comment shifts every later line down by one and invalidates the batch's own remaining coordinates. New `verifyLine` cross-checks the caller's tool/rule/normalizedMessage against `clients/widget-state.ts`'s live per-file diagnostics (`getFileDiagnostics`, reusing `diagnostic-dispositions.ts`'s own now-exported `normalizeMessage` — not a second normalizer) and reanchors to the diagnostic's CURRENT recorded line when it differs (multiple same-rule/message matches on different lines pick the one closest to the caller's line, the conservative choice for suppress). When widget-state has nothing for this file/finding (e.g. a fresh session), a fuzzy fallback accepts the caller's line if it's in-bounds and non-blank, else searches ± 5 lines for the nearest non-blank line; if nothing plausible is found, the tool returns `isError` instead of guessing. `verifyLine` is internally defensive (never throws), and any unexpected failure degrades safely per-disposition: `false-positive`/`defer`/`flagged` fall back to trusting the caller's line (today's pre-fix worst case — a rotted anchor, not a corrupted write), while `suppress` refuses to write at an unverified position rather than risk a misplaced comment. The tool's description now documents line verification and recommends bottom-up ordering for multi-suppress in one file. New coverage in `tests/tools/lens-diagnostic-mark.test.ts`: stale-line-with-widget-match reanchoring (both for `false-positive`'s stored anchor and `suppress`'s comment placement), unchanged behavior when no widget state exists, out-of-bounds/all-blank-nearby lines erroring without writing, and a top-down two-finding batch-suppress in one file landing both comments correctly via reanchoring. - **Silent-clean workspace-indexing LSP warm-ups no longer pay the generic 20-second cold floor** (refs #832) — `ensureWarmForSweep` now uses the configured short strategy wait when live capability classification identifies a workspace-indexing push-only server that is silent on clean files, while TypeScript-like cold-indexing servers retain the longer budget; ambiguous capability data fails closed. - **Cold `lens_diagnostics` full sweeps no longer burn 2x20s on marksman for a clean markdown project, and no longer re-pay a failed warm-up on every retry sweep** (closes #799) — root cause was two compounding gaps: (1) marksman is push-only and publishes NOTHING on a clean file, so `ensureWarmForSweep`'s `warmupOverride` floor (`clients/lsp/index.ts`) guaranteed the full 20s warm-up budget on both the initial attempt AND its #744 retry, with zero diagnostics either time; (2) that inconclusive result never marked the server `demonstratedReady`, so a follow-up sweep in the same session re-paid the same 2x20s all over again. Fixed both: marksman now carries `silentOnClean: true` (`clients/lsp/server-strategies.ts`), and `touchFile`'s diagnostics wait gained a generic push-only clean-confirm fallback — reusing the existing `classifyCascadeWaitTier` (#458) capability-snapshot classification rather than typescript's TS-specific sync-command race — so a single-server primary-scope touch that times out with a successful notify write and a `silentOnClean` push-only server is now CONFIRMED clean (and marked `demonstratedReady`) instead of inconclusive. `ensureWarmForSweep`'s `warmupOverride` floor is now also scoped to the FIRST attempt only (`LSPTouchFileOptions.warmupAttempt`) — a retry no longer re-floors to the full cold-start budget, respecting the server's own (much shorter) strategy wait instead. Second: a new session-scoped negative cache (`LSPState.demonstratedCold`, keyed identically to `demonstratedReady`) records a server whose warm-up genuinely stayed cold after both attempts; a later sweep this session sees the cache and skips straight to the existing #744 group-skip accounting instead of re-running the warm-up round trip, logging a distinguishable `lsp_sweep_warmup_cached_cold` phase (and `skippedFromCache` metadata on the group-skip log) so this reads differently from a fresh failure. The cache clears automatically the moment a server demonstrates readiness through any path, and is discarded wholesale on `resetLSPService` (a fresh `LSPService` instance starts with an empty set) so a new session always retries fresh. New coverage in `tests/clients/lsp/sweep-warmup.test.ts` and a new `tests/clients/lsp/silent-clean-confirm.test.ts`. - mutation-control config follow-ups (#792): global `autofix.enabled` now honored (docs promised it, code ignored it), the MCP LSP-navigation tool now resolves project config from the request cwd, global+project config share one `{enabled}` parser with warn-once on invalid values, and mutation-skip debug lines name the deciding config source - deferred auto-format queue: records are now owned by the queuing session/turn — a read-only or concurrent-secondary subagent turn no longer flushes and formats another turn's pending files (#791) - compat-smoke behavioral harness: scratch-dir cleanup crash (ENOTEMPTY race) no longer discards assertion results and falsely reports Layer B contract drift (#785) - **A review graph no longer keeps serving a stale pre-cap snapshot once a repo grows past the review-graph file cap, and `project_report` now says so honestly** (closes #782) — the #775 harness pinned a `KNOWN GAP`: once a repo crossed `maxProjectFiles`-derived cap (`clients/project-scale.ts`)/`PI_LENS_REVIEW_GRAPH_MAX_FILES`, `getCachedReviewGraph` (`clients/review-graph/builder.ts`) kept indefinitely returning any graph cached/persisted from BEFORE the crossing — `usedBy`/`blastRadius`/fan-in silently reflected an old, smaller repo — and every consumer (`module_report`, `symbol_search` annotations, `project_report`) had no way to tell "graph disabled because the repo is too big" apart from "cold cache, build in progress"; `project_report`'s cold-path hint told the caller to "retry shortly", which is actively wrong when the build will never succeed at the current cap. The `too_many_files` skip branch now records a 15-minute-TTL'd size-skip verdict per cwd (`getReviewGraphSizeSkipVerdict`, TTL configurable via `PI_LENS_REVIEW_GRAPH_SIZE_SKIP_TTL_MS`, matching `project-report.ts`'s existing `STALE_THRESHOLD_MS`) — chosen over persisting the verdict to disk because every real caller either rebuilds within a session or restarts the process, unlike startup-scan's `too-many-source-files` verdict which is cached across process starts specifically to skip a slow walk. `getCachedReviewGraph` now consults that verdict before serving either cache tier, so a repo confirmed over cap gets a cold read instead of a silently stale one; a repo shrink or a raised cap clears the verdict immediately on the next successful build (or lets it lapse on TTL). `project_report`'s cold-path branches on the verdict to return `"review graph disabled: project has N files, cap is M — raise maxProjectFiles in .pi-lens.json or set PI_LENS_REVIEW_GRAPH_MAX_FILES"` instead of the generic retry hint, and skips kicking off another background build that would just re-hit the same cap. `tests/monorepo/size-cliff.test.ts`'s `KNOWN GAP (#775)` pinning test is flipped to assert the fixed behavior, plus new tests for verdict TTL expiry and the immediate clear-on-success path. - **Package-local `.pi-lens.json` `ignore` patterns are now honored — layered the same way nested `.gitignore`s are** (closes #783) — the walk-wide ignore matcher (`clients/file-utils.ts`'s `getProjectIgnoreMatcher`) re-anchors to the git root before loading `.pi-lens.json`, so a package-local config's `ignore` field was silently never consulted, even for files inside that package (found empirically by the #775 Track B harness and pinned as a KNOWN GAP in `tests/monorepo/nested-ignore-config.test.ts`). `buildProjectIgnoreMatcher`'s per-ancestor-directory pattern collection (`patternsForDir`, the same layering that already merges nested `.gitignore`s) now also loads a `.pi-lens.json`/`pi-lens.json` found directly in each ancestor directory between the git root and the target — via new no-upward-walk helpers `findPiLensConfigInDir`/`loadPiLensConfigInDir` in `clients/project-lens-config.ts` that reuse the existing path+mtime config cache, so no JSON is re-read per file — and merges its `ignore` patterns anchored relative to that config's own directory (same anchoring semantics as a `.gitignore` there), tagged with the `pilens` layer so #703's "tracked files are never rescued from pi-lens-native intent" rule applies unchanged. The per-directory nested cache key now includes the config file's mtime alongside the `.gitignore` mtime, so editing a nested config takes effect without a restart. Root-config `ignore` behavior, precedence (`global` → `gitignore` → `pilens`, closer directory wins), and `maxProjectFiles`' upward-walk discovery are all unchanged; a nested config's patterns never apply outside its own directory subtree. The pinning test is flipped to assert package-local patterns ARE honored, with new coverage for root-config patterns still applying project-wide and for a nested config's identically-named pattern NOT leaking into sibling packages or the repo root; `docs/globalconfig.md`'s `ignore` section documents the layering. - **Two Track B (#775) follow-ups from the empirical monorepo test harness** (closes #781, closes #784): (1) `runBlastRadiusInBackground` (`clients/dispatch/runners/tree-sitter.ts`) now passes `cwd` through to `computeImpactCascade` — `cwd` was already in scope (used the line above for `buildOrUpdateGraph`) but dropped at this call site, so the background blast-radius path's workspace module-graph fallback could never engage in a monorepo, unlike the primary per-edit cascade path (`clients/dispatch/integration.ts`) which already passed it correctly; the `tests/monorepo/impact-cascade-cwd.test.ts` pinning test that previously marked this a `KNOWN GAP` now asserts the fallback engages. (2) `scanTruncated` (the #760 scanner-budget flag) reached `lens-engine.ts`'s `projectScan` seam intact but nothing rendered it, so a capped scan read as a complete clean sweep to the agent/user — new `scanTruncationNotice(snapshot)` helper in `clients/lens-engine.ts` renders a one-line notice ("scan truncated at N file(s) — results are partial; raise maxProjectFiles in .pi-lens.json to scan fully.", matching the #777 warm-skip notify's style) that `mcp/server.ts`'s `pilens_project_scan` tool and `tools/lens-diagnostics.ts`'s `mode=full` renderer now both append; `tests/monorepo/diagnostics-truncation.test.ts` gained a test asserting the notice renders once truncated and stays silent otherwise. - **Three monorepo quick-wins from the #775 root-resolution audit** (refs #775): (1) a size-skipped warm pipeline (`too-many-source-files`/`too-many-entries` startup-scan verdict, `clients/runtime-session.ts`) now fires a single visible `notify` — mirroring the existing slow-FS notice's shape/severity — instead of only a debug-log line, naming the `PI_LENS_STARTUP_SCAN_MAX_ENTRIES` override when that's the tripped budget; fires once per session even though heavy scans, the TODO scan, and the dominant-language LSP pre-warm all skip off the same verdict. (2) the audit's suspected symlink-cycle hang in the startup-scan counting walk (`clients/startup-scan.ts`) is verified a NON-issue and pinned by tests instead of "fixed": `fs.Dirent` reports a symlink-to-directory as `isSymbolicLink()`/not-`isDirectory()` (junctions included), so the visitor's directory branch never traverses symlinked dirs at all and a cycle cannot hang the walk — the misleading "always follows symlinks" doc claim is corrected and new tests pin both boundedness and the symlinked-subtree-not-counted behavior so a future stat-through-symlinks refactor can't silently reintroduce the risk. (3) `resolveJsTs` (`clients/review-graph/import-resolvers.ts`) and the warm graph builder's `localImportToFile` (`clients/review-graph/builder.ts`) now resolve a bare specifier (`@scope/pkg` or `@scope/pkg/subpath`) that names a sibling workspace package — detected via the existing `workspace-modules.ts` npm/pnpm/cargo/go.work scanner, memoized per cwd by `buildModuleGraph` so the workspace scan costs one filesystem pass per graph build, not one per import edge — to that package's entry file (`package.json` `main`/`module`/`exports`-main, falling back to `index.ts`/`.js`/`src/index.ts`) or, for a subpath import, a file within the package resolved with the same source-twin-preferring extension probe the relative resolver uses; a specifier matching no known workspace package still returns `[]` (external), unchanged. New coverage: `tests/clients/runtime-session-warm-skip-notify.test.ts` (notify fires once on an over-budget seeded verdict, names the entries override, stays silent on a normal small project), `tests/clients/startup-scan-symlink-cycle.test.ts` (self-loop and mutual-symlink fixtures complete instead of hanging, sync + async), and workspace-package fixtures in `tests/clients/review-graph/import-resolvers.test.ts` and `tests/clients/review-graph.service.test.ts` (cross-package entry/subpath edges, non-workspace bare specifiers stay external). - **`collectSourceFiles`/`collectSourceFilesAsync` (`clients/source-filter.ts`) now bound the walk by directory entries VISITED, not just source files FOUND** (closes #760 — the #758 escape class at the remaining non-startup-verdict call sites) — the walks' only hard cap was the `maxFiles` RESULTS cap (#250), so a mixed tree with few source files but a huge pile of non-source files (the #758 reporter's shape: ~300 scripts among ~84k game-mod data files) never tripped it and still got a full-tree walk, dominated by one `ignoreMatcher.isIgnored()` call per entry — hitting the review-graph rebuild's per-edit hot path (`clients/review-graph/builder.ts`), the `lens_diagnostics` project scan (`clients/project-diagnostics/scanner.ts`), the SYNC caller-blocking todo scan (`clients/todo-scanner.ts`), and word-index build paths not gated by the #758 startup verdict (`clients/word-index.ts`). Fix mirrors #759's startup-scan shape and `jscpd-client.ts`'s `MAX_ENTRIES` prior art: a new `maxScanEntries` option (named consistently with startup-scan) charges one tick per entry TOUCHED — including ignored/skipped ones, since the per-entry ignore probe is the dominant cost — with a generous `DEFAULT_MAX_SCAN_ENTRIES` (200k: bounds the pathological misrooted/data-dominated case to seconds instead of an unbounded walk, while staying an order of magnitude above any healthy project's entry count so real repos never see truncation); when it trips the walk stops and returns the best-effort list collected so far. The existing `maxFiles` cap is unchanged and independent, exactly as in #758. Exposed non-invasively via new `collectSourceFilesWithBudget`/`collectSourceFilesWithBudgetAsync` cores returning `{ files, entryBudgetExceeded }` that the existing collectors wrap — the `string[]` contract of every current caller is untouched, and the default budget covers ALL callers automatically. Truncation awareness threaded per call site: the review-graph build logs a `review_graph_source_walk_entry_budget` latency phase (a truncated graph degrades like `maxFiles` trimming, so log-only); the project-diagnostics snapshot carries a new `scanTruncated` flag (surfaced like #747/#749's `unsafeRoot` but deliberately NOT a refusal — a truncated analysis is still useful, the flag only stops callers reading a partial result as a complete clean sweep) plus a `maxScanEntries` scan option; todo-scanner and word-index accept the default-bounded truncated list (comment-documented, no behavior change needed). New `tests/source-filter-entry-budget.test.ts` covers budget trip on a deterministic mixed tree, generous-budget completeness (no false positives), invalid-budget coercion to the finite default, sync/async flag agreement (and set-identical complete walks), `maxFiles` independence, and plain-wrapper equivalence; `tests/clients/project-diagnostics/scanner.test.ts` covers `scanTruncated` set-without-refusing and omitted-when-clean. - **The startup source-file count walk now stops after a bounded number of directory entries instead of traversing the entire project tree** (closes #758) — `computeStartupScanContext`/`resolveStartupScanContextAsync` (`clients/startup-scan.ts`) count source files under the project root to decide `canWarmCaches`, and the walk early-exited ONLY once it had seen more than `MAX_STARTUP_SOURCE_FILES` (2000) `.ts/.js/.py/.go/.rs/.rb` files. A repo with FEW source files but a huge pile of non-source files never trips that exit — the reporter's case was a Hearts of Iron IV mod with ~300 scripts among ~84k data/`.txt` entries — so the walk enumerated the WHOLE tree, dominated by one `ignoreMatcher.isIgnored()` call per entry, blocking `session_start` for seconds on the cold-start path. The walk now carries a second, independent bound: a `MAX_STARTUP_SCAN_ENTRIES` (50000, env-tunable via `PI_LENS_STARTUP_SCAN_MAX_ENTRIES`) total-entry ceiling — the same finite-walk-cap pattern already guarding `jscpd-client.ts`'s `hasSourceFilesRecursive`. When a walk hits that ceiling before crossing the source-file limit, the tree is large and dominated by non-source files, so it returns a new `too-many-entries` verdict (`canWarmCaches: false`) rather than trusting the partial count and warming caches on (then re-walking) an enormous tree. `too-many-entries` is TTL'd by `isStartupScanVerdictFresh` exactly like `too-many-source-files` (#699) so a shrunk repo auto-recovers on the next session. The public `countSourceFilesWithinLimit`/`countSourceFilesWithinLimitAsync` wrappers keep their pre-#758 contract (only the source-file limit bounds them); the entry ceiling applies solely to the startup-scan verdict path via the shared `walkSourceCount`/`walkSourceCountAsync` cores. New `tests/clients/startup-scan-entry-budget.test.ts` drives the `too-many-entries` verdict deterministically with a tiny mixed-repo fixture and a small `maxScanEntries`, covers the env-tunable getter, and pins the TTL behavior on both the sync and async paths. `runtime-session.ts`'s `useScanRootForSignals` treats the new verdict exactly like its `too-many-source-files` sibling — both found a real project root, so session signals stay anchored there rather than falling back to cwd — and the sync/async walk loops share a single `visitCountEntry` per-entry step so the two bounds live in one place. - **`writeState` in `clients/diagnostic-dispositions.ts` now writes the disposition store via tmp+rename instead of a plain `fs.writeFileSync`** (#690's rescope — a prerequisite for the cross-process review CLI, which will read/write this store from a second process) — a concurrent reader (`readState`) could previously observe a half-written file mid-`writeFileSync`, fail `JSON.parse`, and have its catch treat that as empty state, silently losing every disposition on that read. Now matches the repo's established `${target}.tmp-${pid}` atomic-write shape (`clients/instance-registry.ts`, `clients/recent-touches.ts`, `clients/review-graph/builder.ts`): `renameSync` replaces the destination atomically on both POSIX and Windows (libuv's `MOVEFILE_REPLACE_EXISTING`), so a reader now always sees either the fully-old or fully-new JSON, never a torn write. Unlike those best-effort writers, a rename failure here still throws (after best-effort tmp-file cleanup) rather than being swallowed — this store's writes are functionally load-bearing (a lost mark is a correctness bug, not a dropped observability sample), matching the pre-existing `writeFileSync`'s own no-catch behavior. No retry loop was added for transient Windows `EPERM`/antivirus contention on rename: none of this repo's other atomic writers retry either, and `renameSync`'s replace semantics already succeed in the common case. `readState`'s corrupt-JSON catch is now genuinely rare (a torn read can no longer trigger it) and its comment was updated to explain why caching `{}` against that stat is still safe rather than a permanent trap. New tests in `tests/clients/diagnostic-dispositions.test.ts` assert no `.tmp-*` file is left behind after a mark, that state round-trips through a cache reset (simulating a fresh process reading purely from disk), and that a 200-entry write is always fully parseable off disk. - **`lens_diagnostic_mark` dispositions now apply to the cached `lens_diagnostics` delta/all modes immediately, without waiting for the file to be re-dispatched** (closes #755) — the #690 disposition filter ran in exactly two places: the per-edit dispatcher (`clients/dispatch/dispatcher.ts`, filtering BEFORE results are cached) and `mode=full`'s merge (`applyInlineSuppressionsToSummaries`, `tools/lens-diagnostics.ts`). But `mode=delta` (the default) and `mode=all` re-served the `actionable-warnings`/`code-quality-warnings` reports, the project-diagnostics delta report, and the widget summaries VERBATIM from dispatch time — before any mark existed — and `lens_diagnostic_mark`'s suppress writes its `pi-lens-ignore` comment via raw `fs.writeFile`, not an agent edit, so no `tool_result` hook fires and no re-dispatch happens: a suppressed/deferred finding reappeared on the next `lens_diagnostics` call until the file was next edited. `formatDeltaMode` and `formatAllMode` now re-apply the disposition filter at read time. A new `applyWeakDispositions` (`clients/diagnostic-dispositions.ts`) drops only the WEAK-anchored dispositions (`suppress`, `defer` — `file|tool|rule|message`, no line-content hash), which by construction needs ZERO file I/O, so the "instant" cache-only modes stay instant: no unconditional reads are added. `false-positive` is deliberately NOT filtered in these modes — it is STRICT-anchored (needs the flagged line's own content to re-derive its hash) and still filters on the next per-edit dispatch and in `mode=full`, both of which already have file content in hand; the store's weak `suppress` entry mirrors every inline comment the mark tool writes, so store filtering already covers marks made through the tool (a hand-written inline-only comment on an un-redispatched file remains the documented corner case, converging at next dispatch / in `mode=full`). Project-delta findings are anchored via `projectDiagnosticToWidget` so the `(tool, rule)` a mark binds to matches `mode=full`'s own project-runner filter. No mark-time cache purge was added: read-time filtering is the single robust choke point that converges every `lens_diagnostics` consumer, whereas purging the two report-cache shapes plus the in-memory widget state at mark time would duplicate that logic across fragile shapes and risk drift. New end-to-end coverage (`tests/tools/lens-diagnostics.test.ts`) marks suppress/defer via the real tool and asserts the finding is gone from delta and all with no re-dispatch (and that `mode=full` is unaffected); unit coverage of `applyWeakDispositions` (`tests/clients/diagnostic-dispositions.test.ts`) proves it drops suppress/defer with no content passed, keeps `flagged`, and leaves `false-positive` for the content-based filter. - **Remaining cwd-rooted scan roots now carry the same `isAtOrAboveHomeDir` ceiling, and the source-file walk is capped structurally** (closes #751) — follow-up to #749, closing out the lower-exposure members of the #250/#253/#462/#747 escape class so no walker or scanner spawn can enumerate `$HOME` from a misrooted cwd. (1) `scanProjectDiagnostics` (`clients/project-diagnostics/scanner.ts`) — the cheap-tier project scan, reached from `lens_diagnostics mode=full` and MCP `pilens_project_scan` (cwd straight from tool args) — refuses to walk a cwd at/above home, returning an honest `unsafeRoot` snapshot (0 files, not "clean") that both callers render as a skip rather than a clean verdict. (2) `clients/source-filter.ts` `resolveCollectionConfig` no longer defaults an omitted `maxFiles` to `Infinity`: the new `DEFAULT_MAX_SOURCE_FILES` (20000) finite cap means no caller (`todo-scanner`, `scan-utils` pass-throughs, warm-path language ranking) can trigger an unbounded collection just by omitting the cap. (3) `ast_grep_search` (`tools/ast-grep-search.ts`) refuses only the *defaulted*-cwd case (`paths` omitted) when that cwd is at/above home — explicit user `paths` are never second-guessed. (4) the LSP workspace sweep (`collectWorkspaceDiagnosticFiles`, `clients/lsp/index.ts`) adds the home ceiling on top of its existing 5000-file cap, with `tools/lens-diagnostics.ts` rendering the refused sweep as a skip. (5) `JscpdClient.scan` (`clients/jscpd-client.ts`) gains an internal `isAtOrAboveHomeDir` guard (belt-and-braces — it resolves no marker root, so previously every caller had to guard for it). (6) `rules-scanner.ts` `findMarkdownFiles` gains a depth-8/500-file cap (it only ever walks `.claude/rules`/`.agents/rules` subtrees, so a depth/file bound is sufficient without the full home ceiling). - **A sweep warm-up that times out now retries once and, if still cold, skips that server's files for the rest of the sweep instead of letting a wedged server drag the whole run** (closes #744) — live dogfooding of a 119-file `lens_diagnostics mode=full` sweep found `ensureWarmForSweep` (`clients/lsp/index.ts`) doing a single one-shot warm-up `touchFile` per representative file bounded by `warmupTimeoutMs()` (20s floor); when that warm-up timed out (observed: marksman, a `workspaceIndexing` server, burned the full 20s and stayed cold) the server was left cold with NO re-warm, NO backoff, and NO skip, so every subsequent per-file touch in the sweep re-paid a full per-file budget against it and timed out again — the sweep launched ~59s after an `lsp_service_reset`, straight into freshly-relaunched servers, exactly the state where warm-up failure is most likely. **What/why/how:** (1) `ensureWarmForSweep` now measures per-non-auxiliary-server warm-up success via the SAME `demonstratedReady` signal `touchFile` already marks on a confirmed (non-inconclusive) diagnostics round trip — a server whose key is still absent afterward never warmed. On a failed first attempt it retries exactly ONCE after a short `warmupRetryBackoffMs` breather (`PI_LENS_LSP_WARMUP_RETRY_BACKOFF_MS`, default 500ms, abort-aware — the failure state is usually a server mid-relaunch/index that just needs a moment, not a second full budget), and returns any still-cold server ids in a new `failedServerIds`. (2) `runWorkspaceDiagnostics`' per-group worker skips a group whose primary server is in `failedServerIds` (the sweep groups by primary server, so that primary is precisely the one whose per-file touches would drag), recording each skipped file as UNCONFIRMED (`timedOut: true` + a new `skippedWarmupFailure: true` result field) — never as confirmed-clean `[]`, so the existing confirmed/unconfirmed reporting (#630/#646, `tools/lens-diagnostics.ts`) and the per-primary-server breakdown surface these files honestly as "NOT the same as 0 diagnostics" rather than "ran clean", with a dedicated `lsp_sweep_warmup_failed`/`lsp_sweep_group_skipped_warmup` latency-log trail in `~/.pi-lens`. **Design notes:** the skip is deliberately SWEEP-SCOPED (the caller discards `failedServerIds` when the call ends), NOT the global `broken` cooldown map — a server that is merely still indexing is not broken and must not be cooldown-banned across the whole session; the `broken` map's 15s-base/exponential cooldown is for genuine spawn/initialize failures, a different failure class. Warm-up stays `clientScope:"primary"` (not the sweep's `"all"`) on purpose: `"all"` would additionally spawn the sweep-EXCLUDED auxiliaries (`WORKSPACE_SWEEP_EXCLUDED_SERVER_IDS`), and because `touchFile`'s `inconclusive` flag is touch-wide, one slow advisory auxiliary would then suppress the `demonstratedReady` marking of a perfectly healthy primary and falsely condemn it — recording per-primary-server outcomes covers the servers the sweep actually gates on without that regression. The issue's optional third bullet (gating/delaying a sweep that starts shortly after an `lsp_service_reset`) is left as a follow-up: it needs a reset-timestamp seam the sweep doesn't have today and didn't fall out of this change. New tests in `tests/clients/lsp/sweep-warmup.test.ts` cover warm-up timeout → one retry; retry-still-failing → server reported in `failedServerIds` and its files skipped as `skippedWarmupFailure`/unconfirmed (not clean); a server that warms on the retry participates normally; and the already-warm no-op path is unchanged. - **A single backpressured LSP server no longer times out the didOpen/didChange notify write for an entire `clientScope:"all"` file touch, zeroing every co-touched healthy server's diagnostics** (closes #743 — observed live during a `lens_diagnostics mode=full` sweep on a 119-file project: writes split 20 ok / 16 timed out, the sweep appeared stuck at 20%, and touched files reported `notifyWriteTimedOut:true collectedDiagnostics:0` even for healthy servers). `LSPService.touchFile` (`clients/lsp/index.ts`) fanned the notify write across ALL spawned servers under one `Promise.all` bounded by a single `notifyWriteBudgetMs()` (2000ms) deadline, so one server that had stopped draining its stdin (backpressure — e.g. tsserver mid-recheck under load) timed out the write for the WHOLE file, flipping the touch to `notifyWriteTimedOut → inconclusive` for every server including perfectly healthy ones — contributing no diagnostics and marking nobody `demonstratedReady`. Fix, mirroring how the diagnostics wait already went per-server (#242/#573 via `perServerTimeout`): (1) each server's notify write now gets its OWN `notifyWriteBudgetMs()` deadline instead of one shared `Promise.all` deadline; (2) `notifyWriteTimedOut` is now per-server — a new `notifyWriteTimedOutServerIds` list records exactly which servers' writes did not land, the file-level `notifyWriteTimedOut` flag means "at least one server timed out" (kept for the conservative touch-wide `inconclusive` merge, since `collected` still merges across all servers), and the `demonstratedReady` gate now skips ONLY the servers whose own write timed out rather than gating the whole loop on the file-level flag — so a healthy server whose sibling's write stalled still becomes `demonstratedReady`; (3) a server whose notify write times out `NOTIFY_BACKPRESSURE_BROKEN_AFTER` (3) times in a row is demoted through the EXISTING `broken`-cooldown map (`recordNotifyWriteBackpressure` sets a `BROKEN_BASE_COOLDOWN_MS` cooldown and evicts the wedged client — an alive client is reused before the broken check in `ensureClientForServer`, so the cooldown only bites once the stale client is gone) so subsequent sweeps stop re-paying its notify budget on every file; a single successful write resets the consecutive-timeout streak. A write that REJECTS (not backpressure) still marks that server inconclusive but does not count toward the demotion streak. New `tests/clients/lsp/service-notify-per-server.test.ts` covers: a stalled sibling write not marking the healthy server timed out while the healthy server still reaches `demonstratedReady`; repeated timeouts tripping the broken cooldown and evicting the client; and a successful write resetting the streak so demotion needs a fresh consecutive run. - **`lens_diagnostics mode=full` no longer launches heavyweight analyzers from `$HOME` or above** (closes #747) — `fetchFreshProjectDiagnostics` (`clients/project-diagnostics/fresh-fetch.ts`) resolved the session cwd as `analysisRoot` with no ceiling, so a `mode=full refreshRunners=cheap` call issued while pi's cwd was the home directory started a whole-home `jscpd .`/knip/madge/gitleaks/govulncheck/trivy/dead-code walk (the explicit `paths` scope only filters *reported* results, never what the analyzers walk). Observed failure: a jscpd scan from a WSL `$HOME` reached 44 GB RSS, exhausted swap, and OOM-killed the entire WSL instance. The fresh fetch now applies the same `isAtOrAboveHomeDir` ceiling as `startup-scan.ts`/`resolveSnapshotRoot`/the review-graph builder (the #250/#253 escape class) and refuses before spawning anything, reporting a dedicated "heavyweight analyzers skipped" note plus a machine-readable `analyzersUnsafeRoot` details flag instead of seven misleading per-analyzer "not applicable" reasons. - **`symbol_search`'s cold word-index build no longer walks an unbounded tree from `$HOME`** (#747 hardening) — `triggerBackgroundWordIndexBuild` (`clients/word-index.ts`) was the one word-index build path with no `canWarmCaches` gate in front of it (cold in-process queries and MCP `pilens_symbol_search`, where cwd can be a raw tool argument), and `collectWordIndexDocs` ran `collectSourceFilesAsync` with no `maxFiles`, so the `WORD_INDEX_MAX_FILES` (6000) cap only trimmed results AFTER the entire tree had been enumerated — the same unbounded-walk-plus-in-memory-accumulation shape as the #747 jscpd OOM. The trigger now applies the `isAtOrAboveHomeDir` ceiling, and the cap is passed into the walk itself so every build path is bounded. - **`hasOxlintConfig` now detects `.oxlintrc.jsonc`, `oxlint.config.ts`, and `oxlint.config.mts`** (closes #745) — previously only `.oxlintrc.json`/`oxlint.json` were recognized, so projects using oxlint's TS-based config format (`oxlint.config.ts` + `defineConfig`) or the `.oxlintrc.jsonc` variant were treated as having no oxlint config at all, causing `getPreferredJstsLintRunners` to fall back to `["oxlint", "biome-check-json"]` instead of `["oxlint"]` and run `biome-check-json` as an uninvited fallback linter. New `OXLINT_CONFIGS` list (mirroring the existing `ESLINT_CONFIGS` pattern) covers all four oxlint-documented auto-discovery filenames alongside the legacy `oxlint.json` name. ### Changed - **Introduced a shared `writeFileAtomic`/`writeFileAtomicAsync` helper (`clients/atomic-write.ts`) and migrated four of the five hand-rolled `${target}.tmp-${pid}` + `renameSync`/`rename` writers onto it** (closes #762) — `instance-registry.ts`, `session-state-store.ts`, `recent-touches.ts`, `diagnostic-dispositions.ts`'s `writeState`, and `review-graph/builder.ts`'s sync exit-hook persist all independently hand-rolled the same tmp+rename shape, inviting drift (e.g. forgetting the tmp-cleanup-on-failure step); the helper takes a `bestEffort` option (default `true`, matching the majority: swallow write/rename failures after best-effort tmp cleanup) versus `bestEffort: false` (rethrow after the same cleanup — `diagnostic-dispositions.ts`'s #757 load-bearing policy, since a silently lost disposition mark is a correctness bug, not a dropped observability sample, preserved exactly). `session-state-store.ts`'s tmp file is now named `${file}.tmp-${pid}` instead of its former one-off `${file}.${pid}.tmp` — no observable behavior change, since nothing reads the intermediate tmp filename. `review-graph/builder.ts`'s OTHER writer (`writePending`, the debounced async persist) is deliberately left unmigrated: its callback-style `fs.mkdir`/`fs.writeFile`/`fs.rename` logs a distinct `console.error` per failing stage (mkdir vs write vs rename) that the shared helper's single swallow/rethrow outcome can't express without losing that diagnostic granularity or turning a non-blocking fire-and-forget write into an awaited promise chain. New `tests/clients/atomic-write.test.ts` covers both variants directly: successful atomic replace, no tmp file left behind on success or on a swallowed failure, `bestEffort: true` swallowing a rename failure, and `bestEffort: false` rethrowing it — rename failures are induced via a real filesystem obstruction (renaming onto an existing non-empty directory) rather than mocking `fs`, since this module's `import * as fs` style doesn't reliably re-bind under `vi.spyOn`. Existing suites (`tests/clients/instance-registry.test.ts`, `recent-touches.test.ts`, `session-state-store.test.ts`, and `diagnostic-dispositions.test.ts`'s no-tmp-left-behind/torn-read assertions) pass unmodified. - **Consolidated the repo's recursive tree walkers onto a shared bounded-walk engine in `clients/source-walker.ts`** (closes #761) — every walker hardening episode was costing O(number-of-walkers) because each walker re-implemented the same traversal skeleton: the home-ceiling class took #747 then #751/#754 (seven sites), the entry-budget class took #758/#759 then #760/#764 (five consumers), each hand-rolling the `readdir` + for-entry loop, the sync-recursion / async-stack shape, and the `setImmediate` yield cadence. `source-walker.ts` already held the shared `readDirEntriesSafe` + `shouldRecurseIntoDir`; it now also owns the LOOP via three drivers — `walkTreeStackSync`/`walkTreeStackAsync` (depth-first stack, with an optional per-directory `shouldStop` loop guard and, on the async twin, a `yieldEvery` `setImmediate` cadence + a `beforeWalk` hook for `ensureTrackedIndex` priming) and `walkTreeRecursiveSync` (immediate-descent recursion, preserving result-array order) — each parameterized by a pluggable per-entry `WalkVisitor` returning `"recurse"`/`"skip"`/`"stop"`, generalized from #759's `visitCountEntry` and #764's `chargeEntryBudget`/`classifyEntry`. Phase 1 migrates the two count walks (`walkSourceCount`/`walkSourceCountAsync` in `clients/startup-scan.ts`) onto the stack drivers via a shared `makeSourceCountVisitor`, `hasSourceFilesRecursive` in `clients/jscpd-client.ts` (its `MAX_ENTRIES` 6000 budget expressed as the per-directory `shouldStop` guard, its skip-all-symlinks/multi-language-regex policy kept caller-side), and the `collectSourceFilesWithBudget`/`...Async` cores in `clients/source-filter.ts` (sync onto the recursive driver, async onto the stack driver) — every public contract byte-identical: the `string[]` wrappers, `SourceCollectionResult`, `maxFiles`/`maxScanEntries` semantics, the slow-FS sync clamp, the artifact-probe cache, and #703 tracked-index priming. Classification/policy stays pluggable per walker BY DESIGN — the bounds arithmetic genuinely differs by an off-by-one between the count family (post-classify `visited >= max`, the maxEntries-th entry counted) and the collect family (pre-classify `visited > max`, the tripping entry refused), so the budget/results caps stay in each walker's visitor rather than being forced onto one shared comparison that would shift a cliff by one entry; `lsp/index.ts`, `rules-scanner.ts`, review-graph, `language-profile.ts`, and word-index are deliberately NOT migrated (deferred to opportunistic follow-ups per the issue). The existing equivalence suites are the safety net and pass unmodified — `tests/clients/source-walker-equivalence.test.ts`, `tests/source-filter.test.ts`, `tests/source-filter-entry-budget.test.ts`, and the startup-scan entry-budget/home-ceiling/verdict-cache and jscpd suites — plus a new `tests/clients/source-walker-engine.test.ts` pinning the three drivers' traversal order, `stop`/`shouldStop` halting, and async `setImmediate` yield cadence directly. - **Unified the five independently-hardcoded project-size budgets behind one configurable `maxProjectFiles` scale knob** (closes #776) — the project-diagnostics scanner (500 files), review graph (1,000 files), startup scan (2,000 source files), jscpd (6,000 dir entries), and word index (6,000 files) each degraded silently and separately as a repo grew, with no single lever to say "this repo is big; believe in it." New `clients/project-scale.ts` centralizes a `maxProjectFiles` base (default `2,000`) and a `PROJECT_SCALE_RATIOS` table (0.25×/0.5×/1×/3×/3× respectively) that reproduces today's five defaults exactly at the default base — a behavior-neutral refactor, no default value changed. Resolution order: each subsystem's PRE-EXISTING per-subsystem env override (`PI_LENS_REVIEW_GRAPH_MAX_FILES`, `PI_LENS_STARTUP_SCAN_MAX_ENTRIES`, etc.) still wins outright; below that, `getProjectScaleBase(cwd)` resolves `maxProjectFiles` from the project's `.pi-lens.json` (new field, extended schema in `clients/project-lens-config.ts`) → the new `PI_LENS_MAX_PROJECT_FILES` env var (via the house `lazyEnvNumber` pattern, #763) → the 2,000 default. Every call site with a `cwd`/`rootDir` in hand threads it through so a per-project override actually scales that subsystem (`project-diagnostics/scanner.ts`, `review-graph/builder.ts`, `startup-scan.ts`, `jscpd-client.ts`, `word-index.ts`); the old exported constants (`DEFAULT_MAX_FILES`, `MAX_STARTUP_SOURCE_FILES`, `WORD_INDEX_MAX_FILES`, `RUNTIME_CONFIG.reviewGraph.maxFiles`) are kept, deprecated in comments, for callers/tests that still reference the literals. Two entry-COUNT budgets (`startup-scan.ts`'s `MAX_STARTUP_SCAN_ENTRIES`, `source-filter.ts`'s `DEFAULT_MAX_SCAN_ENTRIES`) were deliberately left standalone rather than derived — they bound directory entries VISITED (a raw tree-walk safety valve), a fundamentally different quantity from source files KEPT whose healthy ratio varies wildly by project shape, and coupling them risked changing behavior on exactly the pathological-tree shapes those ceilings protect. New `tests/clients/project-scale.test.ts` covers the ratio table reproducing all five defaults at the default base, a `.pi-lens.json` override scaling all five derived budgets proportionally, per-subsystem env still beating the derived value, and `PI_LENS_MAX_PROJECT_FILES` beating the default but losing to both `.pi-lens.json` and per-subsystem env. Documented in `docs/globalconfig.md`. ## [3.8.71] - 2026-07-20 ### Added - **`ty` (astral-sh/ty) support as an alternative Python language server** (closes #717) — `PythonServer.spawn()` (`clients/lsp/server.ts`) now tries a bare `ty server` on `PATH` after the existing local `pyright-langserver`/`basedpyright-langserver` candidates fail, and before pyright's managed/auto-install fallback. Strictly opt-in and PATH-only: ty is deliberately NOT added to the installer registry (`clients/installer/index.ts`)/`ensureTool`, and the `resolveAndLaunch` call hardcodes `allowInstall: false`, so ty is only ever picked up when a user has already installed it themselves (`uv tool install ty` / `pipx install ty` / `pip install ty`) — it never displaces an already-installed pyright/basedpyright and never becomes the silently auto-installed Python LSP default (that stays pyright). ty's CLI invocation shape differs from pyright/basedpyright's shared `--stdio` flag — it's launched via the `server` subcommand instead — so it gets its own `resolveAndLaunch` call rather than joining the existing `localCandidates` array. No `initializationOptions` payload is sent to ty: it has no stable `pythonPath`-equivalent init option yet (astral-sh/ty#2032) and instead auto-discovers `.venv`/`VIRTUAL_ENV` relative to `cwd`. New tests in `tests/clients/lsp/server-policy.test.ts` cover the ty fallback tier (launched when pyright/basedpyright aren't found locally, `ty server` args, never triggers install, and pyright still wins when found locally). - **`/lens-map` command: a human-facing, self-contained interactive HTML project map rendered from the review graph** (closes #679) — a new `clients/lens-map.ts` aggregates the (symbol-level) review graph up to FILE-level nodes and deduped, weighted file→file edges, computes a deterministic force-directed layout (pairwise repulsion + edge-spring attraction + center gravity, seeded from a hash of each file's own path so re-running on an unchanged project reproduces the same map), and renders it to a zero-dependency HTML page — embedded JSON payload + vanilla JS/SVG, no CDN script, no npm deps. Interactions: pan (drag background), zoom (wheel), hover (highlights direct neighbors, dims the rest), click (fixed detail panel: path, symbol count, in/out degree, transitive dependents). Node radius scales with transitive dependents; fill is a neutral brand-blue intensity scale by dependents only (light `#2563eb` family / dark `#60a5fa` family) — complexity-aware coloring is explicitly deferred to #306, noted inline. "external" kind nodes (third-party/stdlib import targets) are excluded from the map; their count is surfaced in the header instead. Test files (per `detectFileRole` from `clients/file-role.ts` — `.test.`/`.spec.`/`__tests__/`/etc. path patterns) are ALSO excluded, along with their edges, and computed BEFORE degree/dependents/truncation ranking so they can never inflate a file's rank or count toward the node cap; their count is surfaced in the header too (`testFileCount`). Compiled twins are merged, not double-rendered: in compile-in-place projects the review graph's import resolution often lands on the compiled `X.js` sibling of an `X.ts` source, so when both exist the compiled node's symbols and ALL its edges remap onto the source node (`.js`→`.ts`/`.tsx`, `.mjs`→`.mts`, `.cjs`→`.cts`; edges that become self-referential after the merge collapse like other same-file edges; compiled files with no source twin — vendored deps, pure-JS projects — are untouched), with the merge count surfaced as `compiledTwinCount` in the header and command output. Untracked-gitignored files are excluded too — the set is computed by asking git itself (`ls-files --others --ignored --exclude-standard`, honoring git's semantic that a TRACKED file is never ignored, so committed vendored files matching an ignore pattern stay on the map; outside a git repo the filter degrades to a no-op), with twin-merge taking precedence over exclusion (an ignored compiled file whose source twin survives is merged, edges preserved, rather than dropped) and the dropped count surfaced as `ignoredFileCount`. The viewer ships four pure client-side interactions (no payload/schema changes, no CSP exceptions): search-to-highlight (case-insensitive substring over file paths, ring + dim-the-rest), a min-edge-weight slider (sub-threshold edges hide; nodes left with zero visible edges fade in place — positions never shift), label culling (labels render only when zoomed past 1.5× or for the top-25 files by transitive dependents), and path tracing (select a node, shift+click — or arm the "trace path" toggle and click — a second node to BFS their connection over UNDIRECTED edges, highlighting the chain; Esc/background-click clears). All four compose through one `recomputeVisibility` pass with documented precedence (trace > search > weight for opacity; culling only affects labels). A graph exceeding `PI_LENS_MAP_MAX_NODES` (default 500) files keeps only the highest-degree ones, with a visible truncation note in the page header. Security: every graph-derived string (file paths) reaches the page ONLY via a `