# Release 0.4.9 — Compaction preparation performance and attribution **Coordinated packages:** `ds4-context-core`, `ds4-context-reference-adapter`, and `ds4-context-engine` 0.4.9. ## Changes - The Pi compaction adapter indexes each canonical message fingerprint once and consumes matching entry IDs in source order, instead of searching and re-serializing earlier candidates for every message. Exact canonical matching and fail-closed behavior on missing messages remain unchanged. - Compaction diagnostics report non-overlapping local preparation, generation, aggregation and persistence wall times. Preparation is split into index sync, source mapping, prompt planning and segment planning. Index sync additionally reports its nested canonical JSONL and semantic sync durations (not to be added twice). The latest diagnostics appear in `/context compaction` and metadata-only `compaction.timings` logs, including when in-process summary generation fails. - A summary halted by the provider's output limit reports whether the failed stage was `segment`, `aggregate` or `update`. This is a diagnostic change, not an automatic increase of output budgets or a guarantee that Pi's fallback succeeds. - Adds synthetic adapter, runtime and coordinator tests and `tests/benchmarks/compaction-preparation.bench.ts`; the benchmark uses a local fake provider and logs only counts and timings when explicitly requested. ## Scope and limitations The real report that motivated this work showed roughly 1,131 seconds of local preparation within a 1,268-second operation, followed by an output-limit failure. The prior report did not divide preparation among indexing, source mapping and segmentation. A synthetic 1,283-message case measured about 208 ms preparation (about 183 ms segment planning and 23 ms source mapping) with a no-op index sync. This one-sample result neither reproduces nor explains the real delay. The 0.4.9 diagnostics are needed on the affected host before attributing that delay or claiming it resolved. No live provider run was made for these changes. BPE/auto-tuning defaults and compaction validation policy remain unchanged. **Implementation commit:** `53de88c`. ## Validation - `npm ci` rebuilt the three synchronized workspaces. It warned of four moderate vulnerabilities in installed development dependencies; `npm audit --omit=dev --audit-level=moderate` found zero production dependency vulnerabilities. - `npm run check`: build, typecheck and all 100 test files / 655 tests passed on 0.4.9. - `npm run quality:compare`: candidate quality score 0.9875; no regression against the comparison baseline. - `npm run schema:context-persistence`: `passed: true`. - `npm run pack:check`: clean consumer verified core (251 files), reference adapter (7 files) and engine (115 files). - `DS4_BENCH_DIAGNOSTICS=1 npx vitest bench tests/benchmarks/compaction-preparation.bench.ts`: synthetic local fake provider; one measured iteration, not a statistically robust latency claim. - `npm run registry:check -- 0.4.9`, with a fresh npm cache: verified exact published packages, dependencies, CLI shim, compiled exports/conformance and offline packaged Pi startup after npm registry propagation. ## Publication Published manually from `eb28572` in dependency order: `ds4-context-core@0.4.9`, `ds4-context-reference-adapter@0.4.9`, then `ds4-context-engine@0.4.9`, all public with `latest`. An immediate registry check failed with `ETARGET` for core, and the next fresh-cache check failed with `ETARGET` for the engine; after propagation, a third fresh-cache check succeeded. At verification time, `npm dist-tag ls` showed `latest: 0.4.9` for all three packages. `npm publish` printed a manifest auto-correction warning about the storage CLI entry in the engine; the exact published-artifact check subsequently confirmed that the installed manifest still declares the CLI and that the installed shim runs. This warning did not require republishing or bypassing the registry check. Annotated tag `v0.4.9` targets `eb28572`; GitHub Release: . No DS4 compaction provider calls or real-session data were used to validate this release's performance.