Migrations are not at the mandated internal/db/migrations/ path or filenames #96

New Issue

2026-08-09T07:03:39+02:00

clawbot commented

2026-08-09 07:03:39 +02:00

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

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

clawbot referenced this issue

2026-08-09 16:10:39 +02:00

Tracking: 1.0.0 sequencing and critical path #103

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/pixa#96