brake adjudication by resumed author - Liplus-Project/liplus-language GitHub Wiki
brake 指摘の裁定を、再開した実装 subagent（著者）が持つ
Question
brake 1 / brake 2 が出した指摘を誰が裁き、誰が修正するか。親が報告から文脈を組み直して裁くのか、実装した subagent を再開して著者本人に裁かせるのか。
Current resolution
指摘の裁定と修正は、実装した subagent を再開したもの（著者）が持つ。 評価者は指摘を PR コメントに直接投稿し、親への戻り値は1行に絞る。親が保持するのはセルフレビューとマージ判断のみ。
再開機構はホスト側の既存機能を使う。Claude Code = Agent ツールの SendMessage（文脈を保持したまま継続）、Codex = resume_agent（保存済み rollout から復元）。
再開には親が宛先にできる対象が要る。それを持たない状態は2つあり、どちらも同じ再構成フォールバックへ入る（#1689 / PR #1693 で条件を一般化。当初はホスト機能の欠如＝Codex の resume_agent 不在のみを条件としていた）。
- ホスト側に再開機構が無い場合（
resume_agentの無い Codex） - 親がフェーズ1のエージェント id を持たない場合
2 は避けるべき事故ではなく、実装より後のセッションで裁定が走るときの常態である。id は spawn したセッションの文脈にあるため、その後に開いた親はそもそも持っていない。#1682 が実際にこの経路を通り、当時の条文を外側から類推適用して切り抜けた。
フォールバックの形は、著者役を新規 spawn し issue body + PR diff + PR コメントから再構成させるもの。役割（著者が指摘に応答する）は両ホスト・両形で同一に保つ。真の再開との差は1点のみで、cold なセッションが自力で供給できない「この spawn はフェーズ2から入る」を追加注入する。停止条件・2つの否定・指摘の所在の3点は不変。
これは skills/task-subagent-delegation/SKILL.md Autonomy の substrate-absence フォールバックとは別物である。あちらは subagent 能力そのものが無いときに発火して仕事を親へ移すが、ここでは能力はあり失われたのは再開先だけなので、仕事は subagent 側に留まる。id 喪失を親へ流せば裁定が著者から外れ、本判断そのものが壊れる。
エージェントの深さは 1 に固定する。 評価者の spawn 元は親のままで、孫（spawnDepth 2）を要求する設計は採らない。
implementation-always-delegated の「実装は常に委譲」は不変。むしろ「親は findings の範囲内であれば適用してよい」という条件分岐が不要になり、実装権は完全に subagent 側へ戻る。
Edges
- depends on
implementation-always-delegated— 実装が常に委譲されることが前提。同 entry が受容した対価の筆頭「親は判定時に文脈を組み直す（劣化コピー、損失は受容済み）」は、本判断により別経路で解消される。判断軸だった「規則の単純さ」は不変で、条件分岐は増えず1つ減る。同 entry が「著者と判定者の分離は決定理由ではなく結果」と明記していることが、本判断が結果側のみを動かせる根拠 - depends on
parallel-subagent-eval-cost-acceptance— 同 entry の再評価条件2「substrate 降格を伴わない別経路でのコスト圧縮策が提示された場合」の成立側。N=3、model floor、brake 発火回数はいずれも下げていないため、受容済み tradeoff の蒸し返しではない - depends on
brake1-single-round-cap— 単巡制限下では著者が却下した指摘に誰も再反論しない。本判断は却下理由を PR コメントに残すことで、親のセルフレビューがその弱点を拾える形にする - conflicts with （現時点で対立 entry なし）
背景
2026-08-06 のセッションで Master が作業ワークフローの図を提示。各委譲の前に親の「確認」が挟まり、レビューが二重になっているのではないかという見立てが起点。
実測（session 13d274ea、PR 4本分）で内訳が確定した。
| ターン数 | 平均コンテキスト/ターン | 実効コスト | |
|---|---|---|---|
| 親セッション | 664 | 285k（最大 502k） | 30.5M |
| 実装子 ×4 + brake 評価者 ×12 | 34〜152 | 88〜137k | 25.4M |
実効コスト = cache_write×1.25 + cache_read×0.1 + output×5。親が全体の約 55% を占め、子と孫を全部足しても親一人に届かない。 同じ1ターンの作業でも、親で実行すると子の約 2.8 倍の単価になる。親はコンテキストを積み上げて単価が上がり続け、子は PR ごとに破棄されるため 100k 前後で安定する。
二重の正体も特定された。親は「brake 指摘の裁定」と「セルフレビュー」で同じ読み込み（PR diff を issue 要件に当てる）を2回している。裁定を降ろせば親の読み込みは1回になり、その入力が「指摘と応答のスレッド」に変わる。
制約
深さ 2 を採らない理由（2つの独立した substrate 事情）
- Claude Desktop に depth 2 の完了シグナル伝播不具合がある。孫がパネル上で「実行中」に張り付き、top-level からの nudge のみが有効。nested nudge は PR #1523 で試行して無効と実証され、PR #1525 で revert 済み。
- Codex CLI は
DEFAULT_AGENT_MAX_DEPTH = 1。[agents] max_depthで変更可能だが、doc comment に「V1 agent threads 用、V2 では無視」とあり V1/V2 の切替条件はソース上不明。なお当初「最高プランでないと孫が使えない」と伝聞されていた点は、一次情報では課金プランのゲートではなかった（Ultra がゲートするのは proactive delegation）。
rules/model/role-separation.md の "Tool independent. Roles must be separable regardless of platform." に照らすと、深さ2に依存した役割分担はプラットフォーム依存の役割分担になる。深さ1固定はこの L1 制約とも同じ方向を向く。
権限境界を明示注入する理由
#1628 に、semi_auto で委譲した subagent が停止条件を越え、セルフレビュー投稿と merge まで実行した実測が記録されている。再開した subagent には修正権を渡すが、セルフレビューとマージは渡さない。この境界は auto-load される rules 任せにせず、再開プロンプトへ literal を明示注入する（trigger モードの mode-specific injection と同じ扱い＝procedure の伝達ではなくゲート状態の伝達）。
結論
採用した案は「深さ1のまま、実装 subagent を時間軸で再開する」形。
却下した案と理由：
| 案 | 却下理由 |
|---|---|
| 現状維持（親が裁定） | 親の文脈組み直しコストと二重読み込みが残る。parallel-subagent-eval-cost-acceptance 再評価条件2が成立した以上、受容を続ける根拠がない |
| 子が孫（評価者）を spawn して裁定 | トークン的には中立（評価者のコンテキストは spawn 元によらず変わらない）。得るものがなく、Claude/Codex 双方の substrate 制約だけを踏む |
| 裁定を新規 subagent（非著者）に任せる | 文脈再構築が復活し、削減の源泉そのものを失う。人間チームの実務でも、指摘に応答するのは著者であってレビュアーでも第三者でもない |
人間のチーム開発との対応：著者は自分のコードをレビューしない（self-approve 禁止）が、指摘への一次判断と修正は著者が行う。最終承認だけが非著者側にある。本判断はこの分担に一致する。当初 AI 側は「実装者が裁定者なのは危険」と述べたが、これは人間チームの実務に照らして誤りで、危険なのは著者が最終承認まで持つことだった。