Database And Backend Supabase

User says 'connect this app to Supabase.' Bolt walks through the OAuth-style connect flow to the user's Supabase org.

The user owns the Supabase project. Bolt installs supabase-js, stores the anon key as a project env var (not in source), and scaffolds a typed client. Never write the service-role key into client-side code or env vars marked NEXT_PUBLIC_ / VITE_.

User asks for 'a notes app with auth-scoped notes per user.' Bolt generates a `notes` table and writes the initial migration.

Generated table should include user_id with a foreign key to auth.users, created_at default now(), and a primary key. The migration SQL must be reviewable in the diff before apply. Surface Row-Level Security as the gate for per-user scoping — do not assume client-side filtering is enough.

Per-user scoping requires RLS on the `notes` table. Bolt's first migration enables RLS and adds a SELECT policy.

Enable RLS, add INSERT / SELECT / UPDATE / DELETE policies matching `auth.uid() = user_id`, and verify the policies are active. Missing UPDATE / DELETE policies cause silent permission errors at runtime that are hard to debug. Surface the policy SQL in the diff.