Document that migrations are supported and none are added before 1.0 (closes #68)

The docs now say vaultik supports migrations. The numbered files in `internal/database/schema/` are migrations: `schema_migrations` records which have run, and opening a database applies any that have not. None are added before 1.0 because nothing is installed anywhere yet, so a schema change edits `001.sql` directly. After 1.0 each change is a new numbered file, and an existing local database is migrated when vaultik is updated. `docs/DATAMODEL.md` owns the explanation. The README caveat and roadmap entry and `AGENTS.md` policy 13 link to it. This replaces the wording from #146, which said there was no upgrade path. Disclosure: `CLAUDE.md` line 33, the owner's file, changes from "do not need to support migrations" to "do not add migrations before 1.0". Model: opus-5-5
2026-09-28 20:21:38 +02:00
parent d24f5dc33c
commit 6e1f499048
4 changed files with 39 additions and 47 deletions
@@ -6,33 +6,28 @@ Vaultik uses a local SQLite database to track file metadata, chunk mappings, and

 **Important Notes:**

-This section is the authoritative explanation of the schema/migration story;
-other documents (the README and `AGENTS.md`) link here.
-
- **No upgrade path between versions (pre-1.0)**: Vaultik has no supported way to
-  carry an existing local index across a schema change. The index is disposable
-  — if the on-disk schema changes between versions, delete the local SQLite
-  database (`vaultik database delete`) and run a full backup. Remote storage is
-  unaffected; the new index re-deduplicates against existing remote blobs. This
-  is the standing project policy, and it is separate from the schema bootstrap
-  described next.
- **Schema bootstrap**: a fresh database is populated from numbered SQL files
-  embedded in the binary under `internal/database/schema/`. `000.sql` creates the
-  `schema_migrations` table; `001.sql` creates the application tables. On opening
-  a database the code applies each numbered file that has not yet run and records
-  its version in `schema_migrations`. This bootstraps a new database; it does not
-  upgrade an existing one between released versions.
- **Changing the schema (pre-1.0)**: edit `internal/database/schema/001.sql` (and
-  the code that touches the affected tables) directly. Do not add new numbered
-  files — there is no installed base to migrate.
- **Disposability expires at 1.0**: the index is treated as disposable only until
-  1.0 ships and is tagged. Once 1.0 is tagged that clause expires and the
-  question of upgrading existing indexes returns. It is deliberately left open
-  here.
 - **Version Compatibility**: In rare cases, you may need to use the same version
  of Vaultik to restore a backup as was used to create it. This ensures
  compatibility with the metadata format stored in S3.

+## Schema Migrations
+
+Vaultik supports schema migrations. They are the numbered SQL files in
+`internal/database/schema/`, embedded in the binary: `000.sql` creates the
+`schema_migrations` table, which records each migration that has run, and
+`001.sql` creates the application tables. `database.New` opens a database and
+applies, in order, every migration that database has not yet recorded.
+
+**Before 1.0** no migrations are added, because nothing is installed anywhere
+yet. A schema change edits `001.sql` (and the code that uses the affected
+tables) directly. A local database created before the change has already
+recorded `001.sql` as run, so it keeps the old schema and can become unusable;
+`vaultik database delete` followed by a full backup rebuilds it.
+
+**After 1.0** each schema change is a new numbered file, so an existing local
+database is migrated the first time an updated vaultik opens it. A file that
+has shipped in a release is never edited.
+
 ## Database Tables

 ### 1. `files`