supabase

supabase — официальный навык Supabase для любых задач, связанных с Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues, Supabase CLI, MCP, клиентскими библиотеками и SSR-интеграциями. Он также охватывает login/logout, sessions, JWT, cookies, getSession, getUser, getClaims, RLS, migrations, declarative schemas, security audits и PostgreSQL extensions вроде pg_graphql, pg_cron и pg_vector. Главная граница навыка — Supabase быстро меняется, поэтому нельзя полагаться только на память: перед реализацией нужно получить актуальный changelog, найти breaking-change записи и сверить конкретную тему с текущей документацией. Исходный workflow начинается с проверки changelog.md, затем предлагает искать документацию через Supabase MCP search_docs, markdown-версию docs URL или web search. После любой исправляющей операции требуется тестовый запрос, подтверждающий результат. Если подход не сработал после двух-трёх попыток, навык советует остановиться, проверить ошибку, логи и другую документацию, а не повторять тот же вызов бесконечно. Это особенно полезно для CLI и миграций, где одинаковая команда может иметь разное поведение в зависимости от версии. Ключевое правило Data API — доступ к таблице и видимость строк через RLS не одно и то же. Если SQL создал таблицу, она может не быть автоматически открыта Data API; тогда ролям anon и authenticated нужны явные GRANT, а при публичном доступе одновременно должна быть включена RLS. В exposed schema, включая public по умолчанию, RLS следует включать на каждой таблице. Политики должны соответствовать реальной модели владельца, а не копировать один шаблон auth.uid() без проверки. Для UPDATE требуется не только UPDATE policy, но и SELECT policy, потому что сначала строка должна быть видима. Политика изменения должна содержать и USING, и WITH CHECK, иначе пользователь может переназначить user_id на чужую строку. Для авторизации нельзя использовать user_metadata: raw_user_meta_data редактируется пользователем и небезопасен для решений в RLS. Authorization data следует хранить в raw_app_meta_data или app_metadata, учитывая, что JWT claims могут быть не свежими до refresh. Удаление пользователя не отзывает уже выданные access tokens, поэтому для чувствительных операций нужны logout/revoke, короткий срок JWT и при строгих гарантиях проверка session_id через auth.sessions. service_role и secret key нельзя отправлять в публичный клиент; в Next.js любая NEXT_PUBLIC_ переменная попадает в браузер. Для views нужно помнить, что они по умолчанию обходят RLS: в PostgreSQL 15+ подходит security_invoker, а в старых версиях требуется закрыть доступ ролям или вынести view в непубличную схему. Навык отдельно предупреждает, что auth.role() устарел: вместо него следует указывать целевую роль через TO authenticated или TO anon. Но TO authenticated само по себе означает только роль, а не владение строкой; нужна ownership-проверка в USING, например сравнение auth.uid() с user_id. SECURITY DEFINER обходит RLS и не должен использоваться как универсальный способ устранить permission error. Если он действительно нужен, функция должна находиться вне exposed schema, иметь проверку auth.uid() и проходить security advisors. Для Storage upsert требуются сразу INSERT, SELECT и UPDATE; одного INSERT недостаточно. При установке Supabase packages версии нужно фиксировать и коммитить lockfile. Команды CLI нельзя угадывать: сначала запускаются supabase --help и help для каждой группы. В исходном SKILL.md отмечены version-specific ограничения: supabase db query требует CLI 2.79.0+, а db advisors — 2.81.3+, при отсутствии этих версий используются MCP или psql. Для imperative migrations новые файлы создаются через supabase migration new, а для declarative schemas сначала меняется состояние в supabase/schemas и только потом генерируется migration. apply_migration не следует использовать как итерационный механизм локальной разработки, потому что он сразу пишет migration history. Перед готовым изменением запускаются advisors, затем генерируется migration и проверяется migration list. Для Supabase MCP сначала проверяется curl к mcp.supabase.com/mcp: HTTP 401 без токена означает, что сервер доступен, а timeout или connection refused — инфраструктурный blocker. Затем проверяется .mcp.json, запускается OAuth-аутентификация и перезагружается сессия агента. Так supabase помогает не только писать запросы, но и удерживать границы безопасности, версий, RLS, auth, миграций и проверяемого результата.