0.5.0 — History Recall and recoverable Session Rebase

0.5.0 — History Recall and recoverable Session Rebase

Coordinated stable release of ds4-context-core, ds4-context-reference-adapter and ds4-context-engine. Both adapters depend exactly on ds4-context-core@0.5.0; Pi compatibility remains 0.84.3 and Node remains >=22.19.0.

Changes

• Explicit context_history_recall, context_history_read and context_history_status tools reuse DS4's canonical session index and exact/FTS retrieval. Branch/type/date/role filters apply before SQL LIMIT; summaries and trusted project scope require explicit permission.
• Bounded original-source reads verify canonical byte locations and SHA-256. Opaque references expire and are reauthorized. Historical content remains quoted evidence, with privacy checks at tool and provider egress; recall output and queries are not recursively re-indexed.
• Manual /context rebase --dry-run, /context rebase and /context rebase --recover <operationId> use deterministic bounded checkpoints, verified lineage, canonical target staging, an inter-process lock and recoverable journal. Recovery validates the staged target prefix before activation; the original session is never deleted or truncated.
• Curated memory/pins carry forward with original provenance, existing mutation/confirmation requirements and continuation lifecycle overlays. SQLite migrations 17–18 add rebuildable source-locator, checkpoint, lineage and operation projections.
• History Recall and Session Rebase are enabled by default, as explicitly requested by the user. Configure or disable them through Pi's /context config set historyTools.enabled false and /context config set sessionRebase.enabled false; saved settings apply at the next session start. Existing explicit overrides take precedence. Rebase never runs automatically or as a model-callable tool.

Scope and limitations

• No session-generation provider calls are needed for recall or rebase. Source data and crash tests use isolated synthetic sessions; existing user sessions/settings are not changed by release preparation.
• The default recall scope remains current-branch. Use explicit current-lineage scope to search verified ancestors after rebase; project-scope permission remains off by default. Rebase reduces the active session, not total archive/storage size.
• A handoff that exceeds the checkpoint budget fails closed rather than inventing a summary. Windows crash/filesystem behavior has not been executed on this Linux host.
• Semantic retrieval, chars-v1, BPE, auto-tuning, compaction validation and native continuation defaults are unchanged. The separate real-context BPE/auto-tuning objective remains unverified; synthetic tests do not complete it.
• Details: feature contract, implementation record, ADR 074.

Validation

On final 0.5.0 source after the acquired-policy reload:

• npm ci completed successfully on supported Node 22.23.1.
• jev_verify all passed node-typecheck, the complete node-test scope and git-diff-check after installation. This includes canonical recall/scope/privacy/budget tests, compatibility goldens, subprocess crash recovery at every rebase boundary, target-corruption rejection, inter-process lock recovery and the installed Pi 0.84.3 offline spike.
• npm run quality:compare completed successfully.
• npm run schema:context-persistence passed: 1,266 bytes / 317 estimated tokens; the existing memory-tool schema remains unchanged.
• npm run pack:check passed on Node 22.23.1: core 275 files, reference adapter 7 files, Pi extension 135 files, all exercised in a clean consumer.

The Windows and additional Node CI matrix were not executed locally. Subsequent publication-record edits are documentation-only; reuse the source/behavior results only while code, tests, dependencies and configuration remain unchanged.

Publication and registry verification

Published manually to npm on 2026-10-05 by alucard_24, in dependency order:

1. ds4-context-core@0.5.0
2. ds4-context-reference-adapter@0.5.0
3. ds4-context-engine@0.5.0

All publication commands succeeded. Initial fresh-cache registry checks returned ETARGET for the newly published core; a delayed fresh-cache npm run registry:check -- 0.5.0 then verified all three exact artifacts on Node 22.23.1. Separate npm dist-tag ls checks confirmed latest: 0.5.0 for every package.

The annotated v0.5.0 tag was created at release-preparation commit 7ee50a9 and pushed to origin after registry verification. GitHub Release v0.5.0 was created from that verified tag. CI remains validation-only with no publishing credentials.