docs: schedule closing the role-grant escalation gap before U-3

[yufoxda]

U-1（#73）のレビューで見つかった不足を、作業単位として記録します。あわせて U-1 自身の誤りを2点訂正します。

前提: 20260904000000_add_role_tables.sql はまだ本番に適用していません。適用済みマイグレーションを書き換えているわけではないため、この修正は安全です。

見つかった不足 — ロール付与が申告だけで通る

U-1 が入れたポリシーは、アプリが申告したロールだけを見ています。

with check ((select current_setting('app.current_user_role', true)) = 'admin')

members はこの守り方をしていません。 RLS に加えて app_private.enforce_member_workflow が、申告されたロールを app_accounts の実値と突き合わせます。アプリ層が侵害されても権限を偽装できないようにするためで、これが制約 C-4 の趣旨です。

member_roles は全権限の源泉であり、members より価値の高い標的でありながら、2つのうち弱いほうの防御しかありません。

現時点の危険はありません。 U-3 で判定を移すまで誰もこのテーブルを読み書きしないためです。ただし U-3 がまさにその境目なので、U-2.5 として U-3 の前に置きます。

U-1 → U-2 → U-2.5 → U-3 → U-4
              ↑ ここで閉じる

U-1 の訂正2点

① 要件範囲の過大申告

FR-4.1「ロールを作成・変更・削除できる」を実装したと書いていましたが、していません。app_roles には select しか付与しておらず、ロールを作る経路がありません。ロール管理は U-5 の範囲です。正しくは FR-4.2・4.3・4.6 です。

② コメントが存在しない強制を主張していた

is_system に「管理者が削除できない」と書いていましたが、強制していません。現状 delete 権限自体がないため実害はありませんが、コメントを実態に合わせ、U-5 で守るべきものとして書き直しました。

あわせて、管理者バックフィルの on conflict do nothing を削除しました。app_accounts.member_id が unique なので到達しません。前提が崩れた場合は黙って飛ばすより止まるほうが安全です。

🤖 Generated with Claude Code