Severity: Low
Labels: tech-debt, backend, infrastructure, P3
Location: all backend/db/migration_*.sql (headers: "Run once in Supabase SQL editor"); ordering dependencies only in prose, e.g. migration_drop_legacy_grade_tables.sql:9, migration_gradebook.sql (needs documents to exist first)
Description
There's no migrations table, no numbered ordering, and no runner — files are applied by hand and ordering is conveyed only in comments. Dependent files (gradebook references documents(id); drop-legacy must precede gradebook) can fail or silently skip FKs in a new environment applying files alphabetically. This is the root drift risk behind the schema↔migration discrepancies elsewhere in this audit.
Suggested fix
Introduce a schema_migrations(version, applied_at) table + a small ordered runner, or adopt Supabase CLI supabase/migrations/ with timestamped filenames so ordering/idempotency are enforced, not commented.
Acceptance criteria
- Migrations apply in a deterministic, idempotent order via a runner; a fresh environment reproduces the schema without manual ordering.
Severity: Low
Labels: tech-debt, backend, infrastructure, P3
Location: all
backend/db/migration_*.sql(headers: "Run once in Supabase SQL editor"); ordering dependencies only in prose, e.g.migration_drop_legacy_grade_tables.sql:9,migration_gradebook.sql(needsdocumentsto exist first)Description
There's no migrations table, no numbered ordering, and no runner — files are applied by hand and ordering is conveyed only in comments. Dependent files (gradebook references
documents(id); drop-legacy must precede gradebook) can fail or silently skip FKs in a new environment applying files alphabetically. This is the root drift risk behind the schema↔migration discrepancies elsewhere in this audit.Suggested fix
Introduce a
schema_migrations(version, applied_at)table + a small ordered runner, or adopt Supabase CLIsupabase/migrations/with timestamped filenames so ordering/idempotency are enforced, not commented.Acceptance criteria