🧊 Coldkeep v1.10.12 — Engine Boundary Readiness

[franchoy]

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.

---

This discussion was created from the release 🧊 Coldkeep v1.10.12 — Engine Boundary Readiness.