[regression] Local main is unrunnable: unapplied migration plus a dev DB that points at Supabase

[zacgoodwin]

Repro

Check out main at 608ed6b and start the dev server. Every request 500s on ActiveRecord::PendingMigrationError because 20260721120000_add_chapter_to_campaigns is unapplied, and the development DB targets the live Supabase project which has no campaigns.chapter column. Tlc::Warnings#campaign_chapter does @character.campaigns.pluck(:chapter), so a TLC sheet would 500 on PG::UndefinedColumn too. CLAUDE.md forbids running db:migrate against Supabase, so there is no sanctioned local path to a runnable main. Production is fine -- the Fly release_command applies it on deploy -- but nobody can run main locally until then.

First suspect

config/database.yml

Filed by /z-loop end-of-loop (regression), loop 2.

[zacgoodwin]

Deploy 2026-07-22 applied 20260721120000_add_chapter_to_campaigns to Supabase via the release command (image deployment-01KY5Z95A5B0WJHWMZA32B23J8). The PendingMigrationError on local main is gone — campaigns.chapter now exists in the shared dev DB. The remaining ask in this ticket (a sanctioned local-dev path that never needs db:migrate against Supabase) still stands; only the immediate blocker is cleared.

[zacgoodwin]

Triage: ready-for-human -- this is a dev-environment policy call, not a code fix. The report is accurate: 20260721120000_add_chapter_to_campaigns is unapplied against the database the development environment points at, so every request 500s on PendingMigrationError, and Tlc::Warnings#campaign_chapter (app/lib/tlc/warnings.rb:224) would hit PG::UndefinedColumn on a TLC sheet even past that. Production is fine -- the deploy's release command applies migrations. What blocks an agent is that CLAUDE.md forbids running db:migrate against the hosted database and prescribes schema-load-plus-seed instead, so there is no sanctioned path an unattended agent may take; picking one is the decision. The three options worth weighing: (a) point local development at a local Postgres and make schema-load-plus-seed the documented bootstrap, which makes local main runnable offline and independent of any hosted project; (b) keep pointing development at the separate dev project and sanction db:migrate against that project only, narrowing the CLAUDE.md rule to production; (c) leave the policy alone and document that local development tracks the dev project's schema only after a deploy has applied migrations there. Whichever is chosen, the follow-through is mechanical and can be handed to an agent: update the README bootstrap section, narrow or restate the CLAUDE.md rule so it names exactly which database the prohibition covers, and leave a one-command path that produces a runnable local main from a clean checkout.

[zacgoodwin]

Do (b) keep pointing development at the separate dev project and sanction db:migrate against that project only, narrowing the CLAUDE.md rule to productio