The 0002_admin_password.sql migration referenced a 'users' table that
no longer exists — auth moved from Auth.js Credentials to Neon Auth
(Better Auth), which owns its own neon_auth.user schema.
The migration was being recorded in _migrations to skip, but a fresh DB
or new environment would fail with 'relation users does not exist'.
scripts/migrate.js already had an ensureTracked() repair path that
auto-marks 0002 applied when the users.password_hash column exists,
so legacy DBs still work. For fresh DBs, this rewrite replaces the
broken ALTER with a no-op SELECT 1, preserving the 0002 slot so
0003_*.sql onward numbering is unaffected.
Also add .gitignore entries for local-only QA artifacts:
- db/migrations/0000_qa_*.sql (Neon Auth stub for local audit)
- db/seeds/2026-qa-*.sql (production-scale audit seed)
- docs/qa/ (local audit plan/inventory/bugs)
These files should never apply to production (the migration stub
would conflict with real neon_auth.user; the seed is 1000s of rows).
Tracking progress in /tmp/refactor-routecomm.md.
The "Run migrations" job (and thus the whole deploy) was failing on every push after the first successful bootstrap with:
✗ 0001_init.sql failed: relation "admin_users" already exists
Root causes:
- 0001_init.sql used plain CREATE TABLE/INDEX/TRIGGER despite the header comment claiming "CREATE TABLE IF NOT EXISTS".
- The _migrations tracking row for 0001_init.sql was never recorded on the prod DATABASE_URL (tracking logic landed after initial apply, or apply happened outside the runner).
Fix (3 layers of defense):
* db/migrations/0001_init.sql: every CREATE TABLE now uses IF NOT EXISTS (63 tables), CREATE INDEX uses IF NOT EXISTS (49), all CREATE TRIGGER wrapped in safe DO $$ IF NOT EXISTS (pg_trigger join check) THEN ... END IF; $$, removed the file's own BEGIN/COMMIT so the runner's transaction is authoritative. RLS drop+create and CREATE OR REPLACE FUNCTION were already safe.
* scripts/migrate.js: added ensureTracked() right after loading the applied set. For 0001/0002, if the core objects (admin_users table, password_hash column) already exist in information_schema but the tracking row is absent, INSERT the filename (ON CONFLICT DO NOTHING) and log "repaired tracking". Then the normal skip path handles it.
* .gitea/workflows/deploy.yml: added an inline node -e pre-repair (same admin_users existence check → force _migrations row) immediately before `npm run migrate:one`. This protects even on an older checkout of the runner. The neon_auth preflight and post-apply "admin_users must exist" hard gate are untouched.
* Minor: cleaned 0002_admin_password.sql tx wrapper for consistency; updated MEMORY.md with the incident + resolution.
Result: deploys (and any server-side `node scripts/migrate.js` recovery runs) on an already-initialized prod DB will repair/skip 0001 cleanly, pass the verification query, and continue to build/deploy. The scp of scripts/ + db/migrations/ in the Deploy step now carries the fixed versions.
See the plan note in deploy.yml and MEMORY.md for background.
- Migration 0002 adds nullable password_hash to users (idempotent)
- src/lib/passwords.ts: encode/verify with self-describing format
(algo$N$salt$hash) so we can migrate to a stronger KDF later
- Schema adds passwordHash column; OAuth-only users leave it null
Nora
Tyler
tyler