[aside] 方式2 の resolver-trust パターンは authz に関わる事実を multi-principal で安全に運べない ── 今回 security レビュー(PR #330)が顕在化させた設計制約。

gateway/SPA が解決した事実を server が信じる形は、aggregate(post_id)のような **非 authz データ**なら安全だが、read-gate を決める audience のような **authz 事実**は **resolver を経由しない raw /mcp caller が詐称できる**。content を持たない server は引き直せないので、client 提供 audience を信じる gate は spoofable な security theater になる(自動レビューが CRITICAL 指摘)。

→ 今回の止血: gate と `audience_group_id` field を撤去し、read-gate を **resolver 層**(caller 自身の audience-scoped projection で request を解決 = 読めない request は解決しない)に倒した。ただしこれは **single-owner 前提**(answer scope を持つのは owner だけ)。
→ 触らない判断: 今回は単一 tool の re-home + 止血が scope。
→ 想定インパクト / トリガー: multi-principal(guest/collaborator が content-write tool を叩く)にするには server-side で authz を **再導出**する手段が要る ── 署名付き gateway channel で (request_id, post_id) を server が検証する / posts-owner index を server に残す、等。全 content-write re-home(annotate も同型)+ Phase-3 write-authz の設計 crux。次に content 依存 write を multi-principal で開く時、または annotate を re-home する時に同じ判断が再来する。関連 [[project_quacker_server_thinning_direction]]。