specsfy-specialist-supabase

Supabase

使用する場面

• プロジェクトに supabase/config.toml、supabase/migrations/ 内のマイグレーション、または @supabase/supabase-js クライアントがあり、タスクが RLS、Auth、Storage、Realtime、Edge Functions、または Supabase のローカル環境（supabase start）に関係する場合に使用します。
• アクセスポリシーのレビュー、RLS ポリシーの欠落や誤り、service_role の不適切な公開についても使用します。
• Supabase のコンテキストを伴わない、基盤の Postgres のインデックス／実行計画／分離レベルのみのチューニングには使用しません。$specsfy-specialist-postgres を使い、その結果をポリシーに反映します。
• レビューに JWT、カスタムクレーム、またはデータベース外の認可対象が含まれる場合は、$specsfy-specialist-application-security と組み合わせます。

フロー

1. 使用中の SDK（@supabase/supabase-js、ssr、特定のフレームワーク）、プロジェクト、API 経由で公開されるスキーマ、既存のマイグレーション、環境戦略（ローカル、プレビュー、本番）を特定します。
2. ID、テナント、ロール（anon、authenticated、カスタムロール）と、アクセス判断に使われる各クレームの出所（auth.uid()、auth.jwt()、メタデータ）を整理します。
3. まず Postgres でテーブル、関数、ビューをモデル化します。REST／GraphQL API と生成された型はスキーマから派生するものであり、その逆ではありません。
4. オブジェクトの権限（GRANT）と、各操作（SELECT、INSERT、UPDATE、DELETE）およびロールに対する RLS ポリシーを定義し、デフォルトで拒否します。
5. バージョン管理されたマイグレーションを実装し、anon でセッションがない場合も含め、各ロールを代表するユーザーでテストします。
6. Auth、Storage、Realtime、または Edge Functions は、プロジェクトで実際に使用している場合に限り検証します。アプリケーションが公開していない対象は設定しません。
7. 準備完了と判断する前に、生成された TypeScript 型、接続プーリング戦略（session と transaction）、ログ、バックアップ／ロールバックポリシーを確認します。

パターン

• API に公開されるスキーマのすべてのテーブルで RLS を有効にし、デフォルトで拒否します。RLS が無効な公開スキーマ内のテーブルは、名前を知っている任意の anon からアクセスできます。
• service_role をクライアント（ブラウザー、モバイルアプリ、公開バンドル）に決して公開しません。これは RLS を無視するため、信頼できるサーバー環境でのみ使用します。
• 各ポリシーを anon、authenticated、およびアプリケーションの各ロールで個別にテストします。制限しているように「見えて」も USING (true) を使うポリシーは、ポリシーがないのと同じです。
• 次の対象を重要な攻撃対象として扱います。SECURITY DEFINER 関数（呼び出し元ではなく所有者の権限で実行されるため、固定の search_path と独自の内部検証が必要です）、JWT のカスタムクレーム（信頼できないソースに由来する場合は改ざんされる可能性があります）、および公開として設定された Storage バケットです。
• スキーマの変更はすべてマイグレーション（supabase migration new）でバージョン管理します。本番ダッシュボードで手動編集すると履歴と乖離し、supabase db diff／CI が壊れます。
• プロダクトの認可（このユーザーがこのレコードに対して何をできるか）と、単なる認証（ユーザーが誰か）を分けます。前者は RLS が、後者は Auth が担います。
• ワークロードとドライバーに応じて、直接接続（永続接続数が少ない場合、マイグレーション）、セッションプール（幅広い互換性があり、PREPARE が動作）、またはトランザクションプール（高い並行性、サーバーレス）を計画します。

アンチパターン

• Policy USING (true)／WITH CHECK (true)を開発を進めるために「一時的に」残し、本番環境に移行する前に見直さないこと。これはRLSを無効化したのと同じです。
• クライアント側でのみテナントや所有権を確認し（フロントエンドでクエリをtenant_idでフィルタリングし）、データベースに対応するポリシーを設定しないこと。APIを直接呼び出せば、そのフィルターを回避できます。
• SET search_path = ''や固定スキーマを指定せずにSECURITY DEFINER関数を作成すること。呼び出し元のsearch_pathにある別スキーマの同名オブジェクトを使った関数の乗っ取りを許してしまいます。
• ダッシュボードから本番環境にMigrationを手動で適用し、バージョン管理された履歴と食い違わせること。次回のdb push／db diffでは実際の状態を調整できません。
• JWTのカスタムclaimの出所を検証せずに信頼すること（例：ユーザー自身が書き換えられるフィールドを認可ロールとして使用する）。

検証

• ロールごとに、テスト用の実際のIDを使って、アクセスが許可されるケースと拒否されるケースを検証します。セッションがない状態（anon）と、別のテナントの「隣人」も含めます。
• 本番環境に反映する前に、ローカル環境でsupabase db reset／lint／migrationsを実行します。ローカルプロジェクトで、本番環境のスキーマとポリシーを再現できます。
• 生成された型（supabase gen types）が最新であること、レプリケーション／Realtimeが同じテナントモデルに制限されていること、Storageのバケットごとにポリシーが設定されていること、Edge Functionsのシークレットがソースコードの外にあることを確認します。
• 管理されたバックアップだけに頼らず、データの復旧とエクスポートも評価します。自動バックアップが許容できるRTOを保証すると決めつけず、復元または完全なエクスポートをテストします。
• 否定テスト（失敗すべきアクセスが実際に失敗すること）を実施せずに、テーブルを「RLSで保護されている」と宣言しないでください。

関連するスキル

• $specsfy-specialist-dockerはローカルサービスと補助イメージを対象とし、このスキルはSupabaseプラットフォームの管理対象コントラクトを扱います。
• Supabaseの背後にあるスキーマ設計、インデックス、クエリプラン、分離については、$specsfy-specialist-postgresを参照してください。
• RLSを超えたJWT、claim、認可対象領域の脅威モデルについては、$specsfy-specialist-application-securityを参照してください。
• 同じプロジェクトに、Supabaseと同じPostgresを使用するLaravelバックエンドがある場合は、$specsfy-specialist-laravelを参照してください。

RLS、Auth、公開スキーマ、Storage、Realtime、接続方式を変更する前に、references/standards.mdを読んでください。