refactor(db): move the authentication store into its own schema

[yufoxda]

⚠️ スタックPRです。ベースは refactor/reaction-payload-pii(#63)。マージ順は #61 → #62 → #63 → 本PR。

「auth を別スキーマへ。将来は別DBへ」という方針の実装です。

「移すだけ」では成立しなかった理由

テーブルを app_auth へ移すだけでは目的を達成できません。外部キーはDBを跨げないためです。同一DB内なら跨ぐFKはそのまま動いてしまい、別DBへ切り出す当日に初めて全部が壊れます。

跨いでいたFKは3本ありました:

public."user".member_id              → members.member_id
members.reviewed_by_user_id          → public."user".id
community_identities.user_id         → public."user".id
community_identities.auth_account_id → public.account.id   ← 追加した表明が検出

4本目(auth_account_id)は設計時に見落としていたもので、新しく追加した「跨ぐFKが存在しないこと」の表明が検出しました。

さらに、ドメインのトリガーが public."user" を読んで role を検証していました。トリガーは別DBを読めないため、これも解消が必要でした。

設計

app_auth スキーマ … user / session / account / verification（Better Auth が完全所有・外向き参照ゼロ）
        ↕ user_id は「値」で連携（FKなし）
public スキーマ  … app_accounts(user_id, member_id, role) + ドメイン各表

• role はドメイン側に置きました。メンバーシップのトリガーが role で認可判定しており、トリガーは別DBを読めないためです
• app_accounts もドメイン側です。承認処理が members と会員リンクを1トランザクションで更新しており、これが別DBに分かれると原子性を失うためです
• Better Auth の additionalFields を撤去。認証テーブルは完全にライブラリの所有物になりました
• 新規ユーザー作成時に databaseHooks.user.create.after でドメイン側の口座行を作ります(トリガーにすると認証スキーマがドメインに依存し直すため)

失うもの(正直に)

members.reviewed_by_user_id の on delete restrict(「レビュー履歴がある限りユーザーを削除できない」)が失われます。これが今回の対価です。

ただし既存設計と矛盾しません。member_status_history.changed_by_user_id は元々FKなしのスナップショット方式で、pgTAP にも表明がありました。同じ方針を reviewer と identity にも広げた形です。暗黙にせず、スキーマコメントと pgTAP の表明として明文化しました。

境界層

auth とドメインの両方を読むのは認証ミドルウェアだけです。JOINせず2クエリに分けてあるため、別DB化したとき1つ目がリモート呼び出しになるだけで2つ目は無変更で済みます。管理画面が表示する認証メールも同様にバッチ取得へ変更しました。

退行防止

再生テストで以下を表明しています(これが将来の別DB化を守ります):

• 4テーブルが app_auth にあり public に無いこと
• app_auth."user" にドメイン列が無いこと
• どちらの向きにも跨ぐFKが存在しないこと

検証

対象	結果
member	18 pass、tsc --noEmit クリーン
community	37 pass / 1 skip、クリーン
frontend	25 pass、lint エラー0、本番ビルド成功

pgTAP 3スイートと runbook 3件も新配置に追従させました。purge runbook は分離マイグレーションより前に実行される手順のため参照先は public のままが正しく、順序をコメントで明記してあります。

🤖 Generated with Claude Code