🧊 Coldkeep v1.10.12 — Engine Boundary Readiness
v1.10.12 — Engine Boundary Readiness
v1.10.12 prepares Coldkeep for v1.11 behavior-preserving engine-boundary work.
This release is documentation, release-readiness, and transition-planning focused. It does not change runtime behavior, repository format, CLI behavior, JSON contracts, database defaults, CI, scripts, tests, or dependencies.
Highlights
- Closed stale v1.10.11 release evidence and started v1.10.12 from a clean release-history baseline.
- Defined the v1.10.12 engine-boundary scope contract.
- Added a v1.10.12 Copilot prompt for controlled follow-up work.
- Inventoried CLI/business-logic coupling.
- Inventoried direct DB, filesystem, and storage-context access surfaces.
- Inventoried future operation contract candidates for v1.11+.
- Mapped correctness-invariant ownership.
- Defined no-behavior-change migration rules for future engine-boundary work.
- Inventoried SQLite/PostgreSQL assumptions and compatibility constraints.
- Prepared the v1.11 transition checklist.
- Completed the v1.10.12 release-candidate gate.
Affected invariants
v1.10.12 does not change runtime behavior, but it prepares future protection for:
- data safety;
- deterministic restore;
- GC safety;
- integrity verification;
- crash/recovery behavior;
- snapshot immutability;
- catalog consistency;
- packed/legacy parity;
- JSON stability;
- repository lifecycle behavior;
- filesystem failure safety;
- SQLite/PostgreSQL compatibility.
Explicit non-goals
v1.10.12 does not:
- implement engine extraction;
- implement an engine facade;
- implement catalog abstraction;
- decouple CLI from business logic;
- move runtime logic into new architecture packages;
- change runtime behavior;
- change CLI syntax;
- change CLI exit-code behavior;
- change JSON output contracts;
- change repository format;
- change container format;
- change database schema;
- change migration behavior;
- change the default database backend;
- implement SQLite-first behavior;
- remove PostgreSQL compatibility;
- add daemon/API/UI/product features.
v1.11 handoff
v1.11 should start with behavior-preserving wrapper/facade work only.
The first v1.11 implementation phase must preserve:
- CLI syntax;
- CLI exit codes;
- JSON output shape;
- validation-before-mutation ordering;
- restore behavior;
- GC behavior;
- verify behavior;
- snapshot behavior;
- recovery behavior;
- transaction behavior;
- SQLite/PostgreSQL compatibility.
Before lifting logic, v1.11 should prove parity for the affected command paths and explicitly record:
- affected invariant;
- affected operation candidate;
- before/after CLI behavior;
- before/after JSON behavior;
- before/after exit-code behavior;
- tests run;
- backend compatibility status;
- reason behavior is unchanged.
Notes for maintainers
v1.10.12 is intentionally conservative. Its purpose is to avoid starting v1.11 engine-boundary work with unclear ownership, unclear database assumptions, or hidden behavior drift.
Catalog facade work, deeper catalog contracts, SQLite-first local repository preparation, PostgreSQL centralized/server catalog planning, and daemon/local productization remain explicit follow-up work after this readiness release.