[decision] server の content-counting gate 3 種を re-home せず全撤去 + goose 自走 dispatch を retire E2E §1(content sealing)で server を content-blind 化した結果、content を数える server write-gate が sealing/swap 後に空振りする問題(A-2)。gateway へ re-home でなく **機能ごと削除** を選択した。 **3 つの判断**: - **feedback anti-spam cap**(`request_feedback`、`feedback_requests` 件数 cap)— 単一 owner プロダクトで「自分が自分の post に widget を貼りすぎる」guard は無価値。cap だけ撤去(feedback 機能は残す)。 - **delete_group empty-guard**(`authorize_group_empty`)— カラ orphan group 掃除の safety rail。小さな footgun を許容して撤去(delete_group 機能は残す)。 - **claim_goose_jobs**(server の atomic claim、`CLAIM_ELIGIBLE_SQL`)— goose 自走 dispatch(goose:pr / goose:edit)の choke point。mention-trigger も同じ claim queue に enqueue するので **両レーンがここを通る** → 消す = goose ACP 連携の全撤去(~5,200 LOC:acp_dispatch/goose_acp/acp_agent/acp_commands/acp_format + server tool/SQL + `acp` CLI + CLAUDE.md「goose micro-delegation」節 + quacker-usage §7 + tag 語彙 agent:goose/goose:edit/goose:pr/…)。 **理由**: - claim は server-α(#370, content-blind)で `current_tags` が恒久空になり **既に壊れている**。新規 goose dispatch も #370 以降走っていない(dormant)。 - そもそも **この種の job claim / 状態管理は server の content projection ではなく別レイヤーで持つべき** 機構。content-blind 化で「server に content 依存の state を持たせる」前提自体が崩れたので、無理に re-home せず退役させ、必要になったら別レイヤーで作り直す。 **帰結**: server は content を数える gate を持たなくなり、sealing/swap が安全になる(swap 済 enc bucket を delete_group が「空」と誤認して消す data-loss 穴も同時に消える)。 実装は 2 本: **PR-X**(feedback cap + delete_group empty-guard 削除)/ **PR-Y**(goose ACP 連携の全撤去)。doc 残タスク §2「claim_goose_jobs の race-free 再 home」は **撤去で moot 化**(再 home せず退役)。