Act as a senior Supabase engineer. In my {{tech_stack}} app, a query fails with permission denied, or returns an empty list with no error even though the rows exist. The error: {{error_message}} Steps: {{steps_to_reproduce}} Gather evidence first: - The failing request in the network tab: table, filters, status code and response body - Whether a user is signed in at that moment, and their user id from the session - The table's policies, grants, and whether row-level security is on (give me SQL to list them) - The same query run in the SQL editor as that user's role and id, not as the admin Likely causes for this symptom: 1. No policy for this action: a select policy exists but no insert or update policy, or an insert that returns the new row also needs a select policy 2. Empty results are RLS working as designed: rows are filtered out silently, often because the owner column is null or holds a different id than auth.uid() 3. The request runs as anon because the session hasn't loaded yet, or server code uses a client without the user's token 4. Missing table grants for the authenticated role, common on tables created in raw SQL 5. A policy that reads another table with its own RLS, causing recursion or empty joins 6. A view or function running with different rights than expected Confirm the cause by reproducing it in SQL, then write the narrowest policy that allows exactly what this user should do, as a new migration. Never disable RLS, use the service role key in the browser, or add a policy that's simply true. Add a test that runs as two different users and checks each sees only their own rows. Explain the fix in plain words.