supabase-migrationlisted

# Supabase Migration Skill (v2, studio-wide) ## Step 1 — Read before writing - Read the project's `AGENTS.md` **Database rules** section — it defines this project's APPLY PATH (see Step 5) and any schema-specific invariants. - Read the project's `docs/DATABASE.md` and/or `docs/ARCHITECTURE.md` if present. - Run `supabase migration list` to confirm local/remote alignment. Diverged → STOP and escalate; do not "fix" by pushing. - Check the 2–3 most recent files in `supabase/migrations/` to match style. ## Step 2 — Create the file (CLI names it — never hand-name) ```bash supabase migration new <short_snake_case_description> ``` The CLI generates the timestamped filename. Hand-creating or renaming migration files breaks ordering guarantees and is a failed task. Write the COMPLETE SQL into the generated file. ## Step 3 — Migration file header ```sql -- ============================================================ -- MIGRATION: <short description> -- Date: YYYY-MM-DD -- What / Why / Affected tables / Rollback: -- ============================================================ ``` ## Step 4 — Checklist before applying (universal core) - [ ] New table's access model is explicit BEFORE writing RLS/grants: user-RLS, service-role-only, or schema-level revoked - [ ] Migration is additive (or has a rollback plan if destructive) - [ ] Any new table has RLS enabled - [ ] User-owned tables: policies cover all operations with both USING and WITH CHECK; indexes support RLS/