E2E 復号/暗号化が単一 chokepoint に無く、server 直結の各経路が個別に crypto を配線する必要がある ── 配線漏れが繰り返し出荷されている(create_post #250 / run_sql #251 / goose dispatch #268 で 3 例目)。

PR #268(encrypted goose dispatch)で crypto を e2e module に共有抽出した際に crystallize した構造観察。

- E2E の復号は元々 `bridge --proxy`(MCP gateway)の overlay にだけあった。だが server には複数の直結クライアント経路がある:① server 側 create_post tool(#250 で encrypted_payload 受理)② proxy run_sql overlay(#251 で VARCHAR string 復号)③ goose ACP dispatcher(#268 で job 復号 + reply 暗号化)。**proxy は単一の通り道ではなく**、各経路が server に独自 MCP 接続して body を read/write するので、**E2E crypto をそれぞれ手で配線しないと暗号化 post が素通り(NULL body / 平文)になる**。
- 毎回「両側 green なのに統合すると暗号化が抜けてた」が出荷されている(#250/#251 は merge 後の dogfooding で発覚、#268 は runbook を書く前に grep で発覚)。PR #268 の e2e module は crypto **コード**の重複は消したが「各経路が crypto を呼ぶのを忘れない」問題は残る(配線は依然 manual)。
- 今触らない理由: #268 は goose 経路の一点配線が scope。構造そのもの(chokepoint vs N 経路)は別軸の設計判断。
- 想定インパクト: 次に server 直結経路が増える(SPA write / 新 ACP adapter / 別 tool)たびに同じ漏れが再発する。E2E の保証が「全経路が行儀よく crypt する」前提に乗る(server enforce 不在 n_01KSZBYC3FR3EGWQTHBZZYS39Q と同根の「client/各経路任せ」構造)。
- 方向案:(a)E2E crypto を単一 gateway に集約(全 server access が必ず 1 つの暗号化境界を通る)= chokepoint 化、(b)無理なら新経路が crypto を配線したかを CI 検出する契約テスト(n_01KSZ9K8B4N1VPZ6F0TCGEJQ6F)、(c)最低限 server 直結で post body を read/write する経路の一覧を docs 化して checklist に。
- トリガー: 次に server 直結の post read/write 経路を足すとき、または E2E を本格運用に乗せる前。

server enforce 不在(n_01KSZBYC3F)/ 契約テスト不在(n_01KSZ9K8B4)と一連の「E2E が client/各経路任せ」構造。