supabase

Supabase

マイグレーションに基づく型付きの Supabase 統合を、明示的な認可境界を設けて構築します。

ワークフロー

1. supabase/、マイグレーション、生成済みの型、インストール済みの Supabase パッケージとバージョン、フレームワークとランタイム、環境変数名（値は出力しない）、認証／セッションフロー、Data API を通じて公開されるスキーマ、既存の GRANT と RLS を確認します。
2. ドメインモデルからテーブルの所有権とテナント関係を推測します。所有権、共同作業、削除、保持、外部認証の動作が曖昧な場合に限り質問します。すべてのテーブルに機械的に user_id や 4 つの CRUD ポリシーを追加しないでください。
3. 各テーブルに適したキー、外部キー、制約、インデックス、タイムスタンプ、ライフサイクル／削除動作、サーバー生成の所有権デフォルト値を設計します。ローカルの ID マッピングを意図的にモデル化しない限り、外部プロバイダーの subject ID には text を使用します。
4. 名前付きのマイグレーションを作成します。ローカルの変更には supabase migration new またはレビュー済みの db diff を使用し、ローカルのリセット／テスト用データベースで検証して、db push --dry-run を確認します。リモートへのデプロイが明示的に対象となっている場合に限り、db push を使用します。migration up はリモートへのデプロイの代わりにはなりません。
5. 公開されるすべてのオブジェクトを、Postgres の GRANT と RLS の両方で保護します。ポリシーの対象ロールを限定し、インデックス付きの述語を使用して、挿入／更新には with check を追加します。ビュー／関数は個別に確認し、security definer 関数には安全な search_path を設定します。
6. 認証戦略を適合させます。
   • Supabase Auth：auth.uid()／auth.jwt() と、現在の SSR セッションに関するガイダンスを使用します。
   • Clerk またはその他のサポート対象のサードパーティープロバイダー：ネイティブ統合を設定し、プロバイダートークンをクライアント経由で渡して、実際の JWT sub／claims を使用します。RLS 式だけでトークン検証も設定されると想定しないでください。
   • サーバー管理：認可を明示した、サーバー専用の専用クライアントを使用します。シークレット／サービスの認証情報は決して公開しないでください。
7. 現行の @supabase/ssr では、リクエストごとにクライアントを作成し、サポート対象の Cookie getAll／setAll アダプターを使用して、非同期のフレームワーク Cookie API を await し、必要なプロキシ／ミドルウェアの更新フローを追加します。レガシーの単一 Cookie アダプターは使用しないでください。
8. マイグレーションを生成先のターゲットに適用した後で TypeScript 型を生成し、型チェックを実行して型付きクエリを更新します。any は避け、{ data, error } を明示的に処理します。

検証

ローカルでのマイグレーションのリセット／適用、スキーマ／型のドリフトチェック、リポジトリの lint／型チェック／テスト／ビルドを実行します。各ポリシーについて、許可された所有者／メンバー／管理者／サービスのアクセスと、拒否される匿名ユーザー／他ユーザー／他テナントによる読み取りおよび変更（所有権の変更を試みるケースを含む）をテストします。ターゲットランタイムでセッションの更新／有効期限切れと外部プロバイダーのトークンをテストします。

出力

変更したテーブル／関数／ストレージ、マイグレーションファイル、認証戦略を含む GRANT と RLS ポリシー、クライアント／セッションの変更、型生成コマンドと結果、認可を拒否するテスト、残っているリンク済みプロジェクト／ダッシュボード／本番環境での手順を報告します。