refactor: adopt in-TS startup-migrations as schema convention (PR #88 Phase 3)

[petterlindstrom79]

Summary

• Phase 3 Harden of the PR refactor: scheduled_testing_eligible column + derivation bridge (PR A) #88 bug fix. Codifies the in-TS-block convention that's already running in prod, retires the misleading Drizzle SQL surface, closes the deploy-order regression class.
• Block 0066 now owns the scheduled_testing_eligible column lifecycle: ALTER TABLE ADD COLUMN IF NOT EXISTS + existing reconciliation UPDATE. Renamed runMigration0066_ensureEligibilityColumnAndReconcile. Idempotent on existing prod; functional on fresh DBs.
• Deleted: apps/api/drizzle/ (63 SQL files + meta + README), apps/api/drizzle.config.ts, check-migration-prefixes.mjs, verify-migration-rename.ts, the matching CI step, db:* package scripts, drizzle-kit devDependency. Updated schema-validator.ts fix hint and schema.ts external-managed comment.

Why now

PR #88 (commit cb4e8c1) added apps/api/drizzle/0063_decouple_scheduled_testing_eligibility.sql expecting the file to apply at deploy time. The Dockerfile CMD runs node dist/index.js → runStartupMigrations() (in-TS blocks) → never invokes drizzle-kit migrate. Deploy healthcheck-failed when in-TS block 0066 referenced the missing column. Phase 1 (Contain) applied the column manually via railway ssh; Phase 2 (Journal course-correction) named the failure pattern. This PR closes the class.

Audit-phase correction (vs Phase 2 finding)

Phase 2's stated reason ("__drizzle_migrations doesn't exist in prod") was wrong — the table EXISTS under the drizzle schema (not public) with 60 historical entries; last applied ~2026-04-04. The conclusion (Drizzle SQL files not part of deploy pipeline; in-TS is the working convention) was correct; the reason for it was wrong. Corrected understanding actually strengthens Option B: the SQL files were a manual-run footgun (npm run db:migrate against prod would have hit non-idempotent DDL errors). Detailed in the handoff note.

Notion

• New: DEC-20260511-C — In-TS startup-migrations as the official schema-change convention. Refines DEC-20260420-A (preserved); does not supersede. Rule 11 does not fire.
• P1 follow-up To-do Harden schema-migration deploy pipeline → status moved to Done.
• Working rules page header updated with DEC-20260511-C pointer.
• Petter's local Downloads/closing-steps-checklist.md Rule 8 text updated. Chat-environment skill files (/mnt/project/SKILL.md family) need a separate re-sync — not reachable from this Claude Code env. Documented in handoff.

Verification

• Type-check: clean (pre-existing routes/mcp.ts strale-mcp/tools errors unchanged).
• vitest: 540 passing / 11 skipped / 1 pre-existing failure (app.classify-error.test.ts).
• BLOCKS-list canonical test passes with renamed block.
• Block 0066 idempotency: ADD COLUMN IF NOT EXISTS is no-op on existing prod (column exists from Phase 1 manual recovery); reconciliation UPDATE filters IS DISTINCT FROM so re-runs match zero rows.

Closing-steps rule walk

• Rule 1 (Audit-first): present and corrected mid-stream when README evidence contradicted the prior session's Phase 2 finding.
• Rule 3 (Local vs structural): this IS the structural fix. No further follow-up named.
• Rule 7 (Bug fix framework): Phase 3 Harden of PR refactor: scheduled_testing_eligible column + derivation bridge (PR A) #88. Phases 1+2 shipped earlier; structural gate produced here.
• Rule 8 (Schema-change deployment): this PR amends Rule 8 itself — convention is now in-TS blocks; no ## After deployment migrate step.
• Rule 11 (DEC supersession): does NOT fire — DEC-20260511-C refines DEC-20260420-A and DEC-20260420-B without superseding.
• Rule 14 (Deploy mechanism verification): post-deploy verify by reading Railway boot logs and confirming block 0066 fires with its expected outcome.
• Rule 16 (Self-merge): enabled. Will self-merge on CI green.

Test plan

• Block 0066 modified, BLOCKS-list test updated
• Full vitest pass (540 tests; pre-existing failure unchanged)
• DEC + To-do + Working rules page updated in Notion
• After Railway deploy: boot logs show block 0066 fires with "column ensured; no rows to reconcile (already aligned)" (column already exists in prod from Phase 1)
• After Railway deploy: /health/deep returns 200

🤖 Generated with Claude Code