better-auth

Better Auth のプロシージャ選択

template-ts アプリで使用されている Better Auth と TRPC のパターンに基づいて、認可の境界を選択します。

プロシージャ選択表

プロシージャ	アクセスレベル	提供されるコンテキスト
publicProcedure	認証不要	{ db, session?, headers }
protectedProcedure	認証済み	{ db, session, userId, headers }
adminProcedure	管理者ロール	{ db, session, headers }
protectedOrganizationMemberProcedure	組織メンバー	{ ..., member, organizationId }
protectedOrganizationAdminProcedure	組織管理者／オーナー	{ ..., member, organizationId }
protectedProjectMemberProcedure	プロジェクトへのアクセス	{ ..., project, projectRole, orgRole }
protectedProjectAdminProcedure	プロジェクト管理者	{ ..., project, projectRole, orgRole }
protectedProjectEditorProcedure	プロジェクト編集者以上	{ ..., project, projectRole, orgRole }

ルーターのロジックを記述する前に、この表を主な選択基準として使用します。

このスキルを使用する場面

• 組織／プロジェクト／メンバー／管理者へのアクセスに適切な保護プロシージャを選択するとき。
• TRPC プロシージャ内に Better Auth の認可チェックを実装するとき。
• 既存ルーターの認可境界を確認するとき。

次のワークフローに従う

1. プロシージャ選択表から必要なアクセスレベルを特定します。
2. 一致する基本プロシージャを起点に実装します。
3. 表だけではアクセスルールを満たせない場合に限り、より厳格なミドルウェアをチェーンします。
4. 詳細な例とそのまま使用できるスニペットについては、references/better-auth-examples.md を読み込みます。
5. コンテキストの構造を安定させ、ルート固有のフィールドのみを追加します。

主なルール

1. 必要な権限に一致する、最も限定的なプロシージャを選択します。
2. コンテキストから継承した値（userId、organizationId、project、ロール）を再計算せずに再利用します。
3. 組織管理者には自動的にプロジェクト管理者としての権限を付与し、重複したチェックを避けます。
4. サーバーから auth.api.* を呼び出す際は、ctx.headers を渡します。
5. ビジネスロジックを追加する前に、各ミドルウェアで変数のオリジン（opts.ctx、opts.input）を検証します。

参考資料

• references/better-auth-examples.md — 認証設定、コンテキストのセットアップ、ミドルウェアの例、クライアント認証の使用方法、管理者 API のパターン。