From the audit against the canonical REPO_POLICIES.md, verified against main at 61f42e6.
The policy requires:
> Database migrations live in internal/db/migrations/ ... 000_migration.sql — contains ONLY the creation of the migrations tracking table itself. Nothing else. 001_schema.sql — the full application schema.
EXISTING_REPO_CHECKLIST.md repeats it: "Go migrations in internal/db/migrations/ and embedded in binary".
The content is correct and needs no change: 000.sql contains only the schema_migrations table creation plus its bootstrap insert, and 001_initial_schema.sql is the full application schema. Migrations are correctly embedded (//go:embed schema/*.sql, internal/database/database.go:22) — that directive and any path constants would need updating alongside the move.
This is cosmetic today, but it is worth doing before 1.0 specifically because the same policy forbids editing migrations after a tagged release. Renaming files that are pinned as immutable post-1.0 is materially more awkward than doing it now, and this is the last window where it is a pure rename.
Definition of done
Files moved to internal/db/migrations/000_migration.sql and internal/db/migrations/001_schema.sql, preserving content byte-for-byte.
The //go:embed directive and any path constants updated; the package location (internal/database vs internal/db) resolved consistently — decide whether the whole package moves or only the migrations directory, and say which and why.
TestApplyMigrations_CreatesSchemaAndTables still passes unmodified.
A fresh database still initializes correctly, and an existing database is unaffected — the schema_migrations table tracks versions, not filenames, so verify the renamed files do not cause already-applied migrations to re-run. This is the one real risk in an otherwise mechanical change; cover it with a test that applies migrations twice.
make check green.
Coordination
001_initial_schema.sql is rewritten by PR #55 (it folds the eviction schema in, per that PR's round-1 review). Do this after#55 merges — attempting it now guarantees a conflict with a merge-ready PR.
From the audit against the canonical `REPO_POLICIES.md`, verified against `main` at `61f42e6`.
The policy requires:
> Database migrations live in `internal/db/migrations/` ... `000_migration.sql` — contains ONLY the creation of the migrations tracking table itself. Nothing else. `001_schema.sql` — the full application schema.
`EXISTING_REPO_CHECKLIST.md` repeats it: "Go migrations in `internal/db/migrations/` and embedded in binary".
Actual layout:
- `internal/database/schema/000.sql` — wrong directory, wrong filename
- `internal/database/schema/001_initial_schema.sql` — wrong directory, wrong filename
The **content** is correct and needs no change: `000.sql` contains only the `schema_migrations` table creation plus its bootstrap insert, and `001_initial_schema.sql` is the full application schema. Migrations are correctly embedded (`//go:embed schema/*.sql`, `internal/database/database.go:22`) — that directive and any path constants would need updating alongside the move.
This is cosmetic today, but it is worth doing **before** 1.0 specifically because the same policy forbids editing migrations after a tagged release. Renaming files that are pinned as immutable post-1.0 is materially more awkward than doing it now, and this is the last window where it is a pure rename.
## Definition of done
1. Files moved to `internal/db/migrations/000_migration.sql` and `internal/db/migrations/001_schema.sql`, preserving content byte-for-byte.
2. The `//go:embed` directive and any path constants updated; the package location (`internal/database` vs `internal/db`) resolved consistently — decide whether the whole package moves or only the migrations directory, and say which and why.
3. `TestApplyMigrations_CreatesSchemaAndTables` still passes unmodified.
4. A fresh database still initializes correctly, and an **existing** database is unaffected — the `schema_migrations` table tracks versions, not filenames, so verify the renamed files do not cause already-applied migrations to re-run. This is the one real risk in an otherwise mechanical change; cover it with a test that applies migrations twice.
5. `make check` green.
## Coordination
`001_initial_schema.sql` is rewritten by PR #55 (it folds the eviction schema in, per that PR's round-1 review). Do this **after** #55 merges — attempting it now guarantees a conflict with a merge-ready PR.
clawbot
added this to the 1.0.0 milestone 2026-08-09 07:03:39 +02:00
Plan (checked against current next, which still has the old paths; #55 merged long ago, so the coordination note no longer applies):
Only the migrations directory moves; the internal/database package stays. Moving the package would mean changing the import line of five existing test files in other packages, which the repo's rules do not allow without the owner's approval, and CONVENTIONS.md puts the database package at internal/database.
git mvinternal/database/schema/000.sql to internal/db/migrations/000_migration.sql and 001_initial_schema.sql to internal/db/migrations/001_schema.sql, contents unchanged.
//go:embed cannot reach a directory outside its own package, so internal/db/migrations gets a small Go file that embeds the SQL files and returns them from FS(), the same way internal/static does. internal/database reads the migrations from there.
Version numbers still come from the filename prefix (000, 001), so a database that has already recorded versions 0 and 1 runs nothing again. A new test applies the migrations twice to one database file and checks that the second run applies none. I will also open a database made by current next with the new code once by hand.
Model: opus-5-5
Plan (checked against current `next`, which still has the old paths; https://git.eeqj.de/sneak/pixa/pulls/55 merged long ago, so the coordination note no longer applies):
Only the migrations directory moves; the `internal/database` package stays. Moving the package would mean changing the import line of five existing test files in other packages, which the repo's rules do not allow without the owner's approval, and `CONVENTIONS.md` puts the database package at `internal/database`.
- `git mv` `internal/database/schema/000.sql` to `internal/db/migrations/000_migration.sql` and `001_initial_schema.sql` to `internal/db/migrations/001_schema.sql`, contents unchanged.
- `//go:embed` cannot reach a directory outside its own package, so `internal/db/migrations` gets a small Go file that embeds the SQL files and returns them from `FS()`, the same way `internal/static` does. `internal/database` reads the migrations from there.
- Version numbers still come from the filename prefix (`000`, `001`), so a database that has already recorded versions 0 and 1 runs nothing again. A new test applies the migrations twice to one database file and checks that the second run applies none. I will also open a database made by current `next` with the new code once by hand.
Model: opus-5-5
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.
From the audit against the canonical
REPO_POLICIES.md, verified againstmainat61f42e6.The policy requires:
> Database migrations live in
internal/db/migrations/...000_migration.sql— contains ONLY the creation of the migrations tracking table itself. Nothing else.001_schema.sql— the full application schema.EXISTING_REPO_CHECKLIST.mdrepeats it: "Go migrations ininternal/db/migrations/and embedded in binary".Actual layout:
internal/database/schema/000.sql— wrong directory, wrong filenameinternal/database/schema/001_initial_schema.sql— wrong directory, wrong filenameThe content is correct and needs no change:
000.sqlcontains only theschema_migrationstable creation plus its bootstrap insert, and001_initial_schema.sqlis the full application schema. Migrations are correctly embedded (//go:embed schema/*.sql,internal/database/database.go:22) — that directive and any path constants would need updating alongside the move.This is cosmetic today, but it is worth doing before 1.0 specifically because the same policy forbids editing migrations after a tagged release. Renaming files that are pinned as immutable post-1.0 is materially more awkward than doing it now, and this is the last window where it is a pure rename.
Definition of done
internal/db/migrations/000_migration.sqlandinternal/db/migrations/001_schema.sql, preserving content byte-for-byte.//go:embeddirective and any path constants updated; the package location (internal/databasevsinternal/db) resolved consistently — decide whether the whole package moves or only the migrations directory, and say which and why.TestApplyMigrations_CreatesSchemaAndTablesstill passes unmodified.schema_migrationstable tracks versions, not filenames, so verify the renamed files do not cause already-applied migrations to re-run. This is the one real risk in an otherwise mechanical change; cover it with a test that applies migrations twice.make checkgreen.Coordination
001_initial_schema.sqlis rewritten by PR #55 (it folds the eviction schema in, per that PR's round-1 review). Do this after #55 merges — attempting it now guarantees a conflict with a merge-ready PR.Plan (checked against current
next, which still has the old paths; #55 merged long ago, so the coordination note no longer applies):Only the migrations directory moves; the
internal/databasepackage stays. Moving the package would mean changing the import line of five existing test files in other packages, which the repo's rules do not allow without the owner's approval, andCONVENTIONS.mdputs the database package atinternal/database.git mvinternal/database/schema/000.sqltointernal/db/migrations/000_migration.sqland001_initial_schema.sqltointernal/db/migrations/001_schema.sql, contents unchanged.//go:embedcannot reach a directory outside its own package, sointernal/db/migrationsgets a small Go file that embeds the SQL files and returns them fromFS(), the same wayinternal/staticdoes.internal/databasereads the migrations from there.000,001), so a database that has already recorded versions 0 and 1 runs nothing again. A new test applies the migrations twice to one database file and checks that the second run applies none. I will also open a database made by currentnextwith the new code once by hand.Model: opus-5-5
Done as planned above, with no deviation: #155
Model: opus-5-5
clawbot referenced this issue2026-09-29 07:42:08 +02:00