Skip to content

Coldkeep v1.13.6 — Catalog Contract Expansion and Backend Parity Review

Choose a tag to compare

View all tags
@franchoy franchoy released this 15 Jun 08:11
· 262 commits to main since this release
v1.13.6
ba89aa7
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Coldkeep v1.13.6 — Catalog Contract Expansion and Backend Parity Review

Coldkeep v1.13.6 completes the catalog/backend contract review release train.

This release clarifies the catalog and backend contract surface across snapshot membership, logical/physical mapping, placement and restore-plan assumptions, reachability and GC eligibility, and SQLite/PostgreSQL compatibility posture.

Highlights

  • Added the v1.13.6 catalog/backend contract review record.
  • Documented snapshot membership ownership and consumers.
  • Documented logical/physical mapping expectations.
  • Documented placement and restore-plan assumptions.
  • Documented reachability and GC eligibility boundaries.
  • Reviewed SQLite/PostgreSQL schema and query parity posture.
  • Classified existing catalog/backend test evidence.
  • Recorded that no additional Phase 8 catalog/backend guard tests were justified.
  • Prepared the v1.13.7 handoff toward SQLite-first repository portability while preserving PostgreSQL compatibility.

Test and CI hardening

During the final release gate, the AES-GCM short integration suite exposed a repo-owned integration harness issue.

The remediation was test-only:

  • In-process integration paths now receive deterministic AES-GCM test key setup consistently.
  • The Phase 2 post-migration store/restore/snapshot regression test now uses the store response file_id directly.
  • Hardcoded AES test-key complaints from Codacy were resolved by moving the key handling into CI/test configuration instead of keeping literal keys in test files.

Runtime impact

None.

  • No production behavior changed.
  • No CLI behavior changed.
  • No human output changed.
  • No JSON output changed.
  • No JSON error envelopes changed.
  • No exit codes changed.
  • No routing changed.
  • No schema or migration changed.
  • No storage or repository format changed.
  • No backend defaults changed.
  • No runtime behavior changed.

Compatibility

SQLite-first direction remains a roadmap posture, not a SQLite-only decision.

PostgreSQL compatibility remains preserved and mandatory in the release gate.

Assets 2
Loading
0 Join discussion