supabaselisted

# Supabase Standards Supabase is Postgres underneath, so this domain co-loads with `database` (generic Postgres) and the `auth` / `security` concerns. It owns **only the platform contract**: RLS, the key boundary, Postgres/Edge function security, and the CLI migration workflow. Generic Postgres rules (types, constraints, indexing-in-general, expand-contract, N+1, transactions) live in `database`; auth flows (JWT verification, OAuth, password reset) live in `global/refs/auth.md` — this domain links to them rather than restating them. ## Priority: P0 — Row-Level Security - **RLS is OFF by default. Every table reachable through the API/PostgREST must `ENABLE ROW LEVEL SECURITY` in the same migration that creates it.** A table left unguarded behind a public `anon` key is a full data leak. Signal: a `create table` in `supabase/migrations` with no matching `alter table … enable row level security`. - **RLS-on denies by default — write an explicit policy per operation (`select`/`insert`/`update`/`delete`).** Don't rely on one `for all` policy where operations need different predicates. Signal: a table with RLS enabled and no policy, or a blanket `for all using (true)`. - **Pair every `UPDATE`/`DELETE` policy with a `SELECT` policy.** Postgres must read the existing row to evaluate the `USING` clause; without `SELECT` the row is invisible and the write silently affects nothing. Signal: an `update`/`delete` policy on a table with no `select` policy. - **Use `WIT