Docs-only reconciliation of the schema/migration story with the code
(#68).
What changed
docs/DATAMODEL.md now owns the explanation. It separates the unchanged
policy (no supported upgrade path between versions — delete the local index
with vaultik database delete and re-back-up) from the schema bootstrap
that does exist: numbered files in internal/database/schema/ (000.sql
creates the schema_migrations table, 001.sql the application tables),
applied to a fresh database and recorded in schema_migrations.
README.md (the caveat and the roadmap entry) and AGENTS.md are reworded
to match and link to docs/DATAMODEL.md. AGENTS.md now names the real file
to edit (internal/database/schema/001.sql) instead of the nonexistent schema.sql, and notes the pre-1.0 disposability clause expires on tagging,
so the upgrade question returns at release.
No document asserts the schema_migrations table is absent. Policy unchanged;
no code changed.
Disclosures
Judgement call: schema.sql still appears as a substring in two files I did
not touch. REPO_POLICIES.md names 001_schema.sql, but it is cross-project
policy marked "kept in sync with the authoritative source" — editing it would
change org-wide policy, out of scope. internal/database/database_test.go
uses schema.sql as an invalid-filename test fixture; done-item 6 restricts
this change to docs only. I read done-item 1's "anywhere" as the
contributor-facing prose that misdirects, which item 6 makes the only
reachable scope.
model: claude-opus-4-8
Docs-only reconciliation of the schema/migration story with the code
(https://git.eeqj.de/sneak/vaultik/issues/68).
## What changed
- `docs/DATAMODEL.md` now owns the explanation. It separates the unchanged
policy (no supported upgrade path between versions — delete the local index
with `vaultik database delete` and re-back-up) from the schema *bootstrap*
that does exist: numbered files in `internal/database/schema/` (`000.sql`
creates the `schema_migrations` table, `001.sql` the application tables),
applied to a fresh database and recorded in `schema_migrations`.
- `README.md` (the caveat and the roadmap entry) and `AGENTS.md` are reworded
to match and link to `docs/DATAMODEL.md`. `AGENTS.md` now names the real file
to edit (`internal/database/schema/001.sql`) instead of the nonexistent
`schema.sql`, and notes the pre-1.0 disposability clause expires on tagging,
so the upgrade question returns at release.
No document asserts the `schema_migrations` table is absent. Policy unchanged;
no code changed.
## Disclosures
- Judgement call: `schema.sql` still appears as a substring in two files I did
not touch. `REPO_POLICIES.md` names `001_schema.sql`, but it is cross-project
policy marked "kept in sync with the authoritative source" — editing it would
change org-wide policy, out of scope. `internal/database/database_test.go`
uses `schema.sql` as an invalid-filename test fixture; done-item 6 restricts
this change to docs only. I read done-item 1's "anywhere" as the
contributor-facing prose that misdirects, which item 6 makes the only
reachable scope.
model: claude-opus-4-8
Four documents implied vaultik has no schema-application mechanism and
told contributors to edit a nonexistent `schema.sql`. The code does have
numbered files in `internal/database/schema/` (`000.sql` creates the
`schema_migrations` table, `001.sql` the application tables) that
bootstrap a fresh database.
docs/DATAMODEL.md now owns the explanation, distinguishing the unchanged
policy (no upgrade path between versions; delete the local index and
re-back-up) from the bootstrap mechanism that does exist. README (caveat
and roadmap) and AGENTS.md are reworded to match and link there. AGENTS.md
now names the real file to edit and notes that the pre-1.0 disposability
clause expires on tagging.
Policy is unchanged; docs only.
model: claude-opus-4-8
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Docs-only reconciliation of the schema/migration story with the code
(#68).
What changed
docs/DATAMODEL.mdnow owns the explanation. It separates the unchangedpolicy (no supported upgrade path between versions — delete the local index
with
vaultik database deleteand re-back-up) from the schema bootstrapthat does exist: numbered files in
internal/database/schema/(000.sqlcreates the
schema_migrationstable,001.sqlthe application tables),applied to a fresh database and recorded in
schema_migrations.README.md(the caveat and the roadmap entry) andAGENTS.mdare rewordedto match and link to
docs/DATAMODEL.md.AGENTS.mdnow names the real fileto edit (
internal/database/schema/001.sql) instead of the nonexistentschema.sql, and notes the pre-1.0 disposability clause expires on tagging,so the upgrade question returns at release.
No document asserts the
schema_migrationstable is absent. Policy unchanged;no code changed.
Disclosures
schema.sqlstill appears as a substring in two files I didnot touch.
REPO_POLICIES.mdnames001_schema.sql, but it is cross-projectpolicy marked "kept in sync with the authoritative source" — editing it would
change org-wide policy, out of scope.
internal/database/database_test.gouses
schema.sqlas an invalid-filename test fixture; done-item 6 restrictsthis change to docs only. I read done-item 1's "anywhere" as the
contributor-facing prose that misdirects, which item 6 makes the only
reachable scope.
model: claude-opus-4-8
PASS
model: claude-opus-4-8