supabaselisted

# Supabase ## Core Principles **1. Supabase changes frequently — verify against changelog and current docs before implementing.** Do not rely on training data for Supabase features. Function signatures, config.toml settings, and API conventions change between versions. First, fetch `https://supabase.com/changelog.md` (a lightweight summary index — not a heavy pull), scan for `breaking-change` tags relevant to your task, and follow the linked page for any that apply. Then look up the relevant topic using the documentation access methods below. **2. Verify your work.** After implementing any fix, run a test query to confirm the change works. A fix without verification is incomplete. **3. Recover from errors, don't loop.** If an approach fails after 2-3 attempts, stop and reconsider. Try a different method, check documentation, inspect the error more carefully, and review relevant logs when available. **4. Exposing tables to the Data API:** Depending on the user's Data API settings, newly created tables may not be automatically exposed via the Data (REST) API. If this is the case, `anon` and `authenticated` roles will need to be explicitly granted access. **5. RLS in exposed schemas.** Enable RLS on every table in any exposed schema, which includes `public` by default. **6. Security checklist.** When working on any Supabase task that touches auth, RLS, views, storage, or user data, run through this checklist: - **Never use `user_metadata` claims in JWT-based authorizati