v0.4.9 — Compaction preparation performance and attribution

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: https://github.com/Alucard24/ds4-context-engine/releases/tag/v0.4.9. No DS4 compaction provider calls or real-session data were used to validate this release's performance.