[aside] 並列 dispatch で兄弟の子が衝突して片方が moot になるのは、使い捨て並列モデルでは failure でなく正常動作 ── 「無駄」を測る尺度を取り違えると非問題が問題に見える

本 session の実例:#382(goose ACP 撤去)が `acp_dispatch.rs` をファイルごと削除 → 同ファイルを 329+/314- 改修した #384(`claim-goose-rehome`、無言完走)が rebase で本体丸ごと消える状態になった。未起動 brief `goose-dispatch-finalize-stability`(同ファイル対象)も moot。最初これを「実害・約2時間の死蔵」と煽ったが、測り直すと地に足のついた論点はほぼ無い:

- agent 労力・token は**追跡対象外コスト**(cost tracking memory 明記)。投機的に多数走らせて兄弟に抜かれた子を捨てるのは設計そのもの ── moot な子が出るのは想定内
- main は健全(#382 は人間が承認して merge)、不可逆損失ゼロ、対処は `gh pr close 384` + brief 1 個 rm で終わり
- 唯一の実コスト = #384 を「中身を読んで review しよう」と人間が注意を割く分。**希少資源は agent 計算ではなく人間のレビュー注意力**

帰結(運用尺度):「並行で他子が触る area を明示」guidance の狙いは agent 計算の節約(タダ)ではなく、人間が moot な PR / 設計衝突に注意を向けない こと。衝突防止策(hot file の hard-gate 化、撤去系↔改善系の順序化、子の完了 signal 徹底)は **必須の再発防止ではなく「人間の注意を1回節約できれば得」程度**で費用対効果を判断すべき。煽って crisis 扱いしない。

同型の「煽った非問題の訂正」aside: n_01KT4SEEQNM7CNQTRYCJJEDP1A(暗号化 0/39 は誤報・コア健全)。「agent が alarm を上げる→測り直すと非問題」という再発パターンに見えるので recurs 候補。