[aside] 方式2 resolver-trust の安全性 litmus:gateway 解決の事実は「server が **その security 判断を今も持つ data(authz projection)から再認可できる**」なら trust 安全、できないなら不可 ── PR #331 で n_01KT3WWGF を refine。

具体例:
- **answer_feedback(#330)**: audience は「target を読めるか」の **読み取り gate の代理**。content-less server は target の真の audience を引けず、詐称 audience で gate を通せる → 検証不能 → 撤去(read-gate を resolver 層へ)。
- **annotate_post(#331)**: audience は **comment 自身の書き込み先**。server は authz projection(group_members)から「actor がその group に書けるか」を独立に検証できる(`authorize_group_visibility`)→ 詐称しても actor が書けない group には注入不可 → trust + verify が成立(create_post の top-level と同じ)。

litmus = 「その fact が決める security 判断を、server が今も持つ data(authz projection の membership / ownership)から再導出できるか」。**Yes** なら hidden field で受けて server 側で再認可すれば足りる。**No**(読み取り可視性=他 post の content に依存する gate)なら署名付き channel / posts-owner index が要る(= n_01KT3WWGF の Phase-3)。つまり n_01KT3WWGF の「multi-principal には署名付き channel が要る」は **全 fact ではなく『読み取り可視性に依存する gate』に限定**される ── 書き込み先 group の membership 系は今の authz projection で足りる。

触らない判断: 今回は 2 tool の再ホームが scope、この litmus の体系化は別。トリガー: 次に content 依存 write を再ホーム / multi-principal を開くとき、各 gateway-resolved fact をこの litmus で分類する。関連 PR #330 #331、n_01KT3WWGF / [[project_quacker_server_thinning_direction]]。