maint: squash migrations into a v1 baseline before first release - #34
Merged
Conversation
Replace the eight development-time migrations (0001..0008) with a single 0001_initial_schema.sql. The store never shipped, so no external database depends on the old chain; the immutability rule protects released users and its scope begins at this first release (ADR 0012). 0005/0007/0008 recreated whole tables to alter CHECKs, so the old chain's final schema was scattered and carried quoted rename artifacts in sqlite_master. The baseline was derived from the applied v8 schema (reconstructed from sqlite_master, not transcribed) and is schema-identical to it. A load-bearing test (tests/schema_equivalence.rs) builds one DB from the legacy chain (preserved verbatim under tests/legacy/) and one from the shipped baseline and asserts identical normalized sqlite_master plus per-table table_info / index_list / foreign_key_list pragmas. A pre-release adoption shim recognises the one known legacy database (v8 with the full eight-row ledger and matching checksums) and, on open, rewrites the ledger to the single v1 baseline row and resets user_version to 1 in one transaction — never touching a table, since the schema is already identical. Any other unexpected version still errors (DatabaseTooNew). A second open is a no-op. The shim and its embedded checksums are marked for removal post-adoption. macOS knownSchemaVersion -> 1; a not-yet-adopted v8 database classifies as newer-than-known and reads read-only until the CLI adopts it. Verification: mise run check (exit 0), mise run demo (green), swift test (36 passed). Against a copy of the author's real v8 database: adoption succeeded to schema v1, all counts preserved (69,400 events, 320 sessions, 2 candidates, 34,911 signatures), second open idempotent; copy deleted, real DB untouched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015LY7xtercMc3NtLeX2z4YV
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Claim
Autophagy has never shipped. This replaces the eight development-time SQLite migrations (
0001..0008) with a single squashed0001_initial_schema.sqlv1 baseline, so the first release presents one clean origin schema rather than eight fossilized diffs (three of which —0005,0007,0008— recreate whole tables to alterCHECKconstraints). The "migrations are ordered and immutable" rule protects released users; its scope begins at this first release. See ADR 0012.The equivalence proof
The baseline was derived from the applied v8 schema by reconstructing DDL from
sqlite_master(formatting normalized, good comments kept) — not transcribed from memory — then given clean unquoted table names in place of the quoted rename artifacts the old recreate-copy-rename chain left behind.tests/schema_equivalence.rsis load-bearing: it builds one database from the eight legacy migrations (preserved verbatim undertests/legacy/) and one from the shipped baseline, then asserts:sqlite_master(every table, index, trigger, virtual table, and FTS5 shadow table), normalized (whitespace collapsed, identifier quotes stripped); andtable_info/index_list/foreign_key_listpragmas.No drift is tolerated.
CHECKexpressions live only in the SQL text, so the normalized-DDL comparison is what pins them.The adoption story
Exactly one database exists in the wild — the author's own, at v8 with the full eight-row
schema_migrationsledger. A pre-release courtesy shim inmigration.rsrecognises that exact ledger (each of the eight checksums verified against embedded constants) and, on open, adopts it in one transaction: the eight ledger rows become the single v1 baseline row (with the baseline's real checksum) anduser_versionis reset to 1. Because the schema is already identical, adoption never touches a table — only the ledger. Any other unexpected version still errors (DatabaseTooNew); a second open is a no-op. The shim and itsLEGACY_V8_CHECKSUMSare documented for removal post-adoption (ADR 0012).The macOS app's
knownSchemaVersiondrops to 1; a not-yet-adopted v8 database classifies as newer-than-known and reads read-only until the CLI adopts it.Verification
mise run check— exit 0mise run demo— greenswift test(apps/macos) — 36 passedstatusadopted it to schema v1; all counts preserved (69,400 events · 320 sessions · 2 candidates · 34,911 signatures); ledger collapsed to one v1 row; second open idempotent. Copy deleted; the real database was never opened by this build and remains at v8.Privacy
Local-only; touches no event, mutation, or audit data. Adoption rewrites a handful of ledger rows in place on the user's own database, copies nothing off the machine, and refuses any ledger it does not recognise byte-for-byte.
🤖 Generated with Claude Code