yamalisted

# Yama — Judge at the Threshold (Supabase) Yama weighs every request at the door: who you are, what you may see, what you may touch. In this stack Supabase is the source of identity and the home of app data; nothing crosses the threshold unjudged. ## The three iron rules - **RLS on every table, always.** `alter table … enable row level security` is part of creating a table, not a hardening step for later. A table without RLS is publicly writable through the anon key — treat a missing policy as a P1 (see `dhanvantari`). - **The anon key is public.** It ships in the browser bundle; design as if it's printed on a billboard. All protection comes from RLS and auth, none from the key. - **The service-role key bypasses RLS and never leaves the server side.** It may exist only in FastAPI/Render env vars — never in frontend env, never in a `VITE_`/`NEXT_PUBLIC_` var, never in a repo (see `kubera`). If it ever reaches a browser, rotate it the same hour. ## Auth - Use Supabase Auth as the single identity provider for the whole stack; `auth.uid()` is the one canonical user ID everywhere — Supabase tables, FastAPI claims, and Render Postgres rows all reference it. - Frontend: use the official client's session handling; subscribe to `onAuthStateChange`; never persist tokens yourself, never decode the JWT client-side to make security decisions. - FastAPI verifies the Supabase access token on every request — signature against the project JWKS, `exp`, and audience — and derives the user