brake 1 は N=3 の1巡で打ち切り、修正後の再検証ラウンドを行わない

Question

brake 1（skills/evolution-parallel-agent-eval）は、verdict が partial / negative の場合に親が draft を修正して eval を再実行する設計だった。ラウンド数に上限は無く、実測で 3〜4 ラウンドを要する PR が連続した。ラウンドを何周まで回すべきか。

Current resolution

N=3 の1巡で打ち切る。修正後の再検証ラウンドは行わない。 出た指摘は親がソースに照らして採否を裁き、修正した draft をそのまま self-review へ通す。N=3 の下限（sample count 軸）は据え置き。

期間を区切った試行として入れた決定であり、恒久確定ではない。再評価条件は下記。

Edges

• supersedes parallel-subagent-eval-cost-acceptance の再評価条件2（「substrate 降格を伴わない別経路でのコスト圧縮策が提示された場合」）— 本決定がその経路。コスト受容の判断原理（予防コスト < 修復コスト、時間軸波及込みで評価）自体は不変で、圧縮の具体軸が1本追加された形。全廃ではないため cost-acceptance の結論は生きている
• depends on parallel-subagent-eval-three-axis-decomposition — N / M / P の三軸は「1ラウンド内の幅」を規定する。ラウンド数はそれと独立した第四の変数であり、本決定はそこだけを固定する
• depends on liplus-evaluation-criterion — 受容の判断軸そのもの
• conflicts with （現時点で対立 entry なし）

背景

観測 cluster brake1-round-termination-is-parent-feel-dependent（occurrence 4）が起点。cluster が名指しした欠陥は「ラウンドが多い」ではなく 打ち切り判断が親の感覚に依存している ことだった。#1543 / #1550 では親が R1・R2・R3 の各時点で収束を予測し、3 回とも外している。

PR #1560 の実測: 378 行の変更に対し brake 1 評価者 3 ラウンドが 1,640,972 トークン、実装・修正 subagent が 571,074 トークン。検証が実装の約 2.9 倍。1 巡制限適用時の推定は約 61% 減。

同 PR の収穫分布ではコード欠陥 4 件がすべて R1 で出ており、R2 の 2 件のうち 1 件は R1 の修正が新設した欠陥だった。#1555 の観察エントリも「ラウンドを伸ばした主因が実装でなく親の修正だった」と記録している。

判断の前に確認した反証

「コード欠陥はすべて R1 で出る」は #1560 単独の観測であり、記録には後半ラウンドが実欠陥を出した例が 3 件ある。

PR	ラウンド数	後半ラウンドの収穫
#1543	4	R3 = chunk 境界のマルチバイト破損。初回実装に元から在った挙動欠陥で、修正が新設したものではない
#1550	4	R4 = 書き換えで落ちた、まだ生きていた記述
#1533	3	R2 = dialogue-evaluator が 4 区分目として漏れていた仕様欠落

とくに #1543 R3 は、1 巡制限下では #1562 のテスト被覆でも受け止められない（被覆範囲は on-session-start であって post-tool-use ではない）。

AI 側の推奨は「一律のラウンド数ではなく、指摘の性質変化で打ち切る基準の構造化」だった（PR #1551 / #1560 で実地適用済み、cluster が名指しした設計軸「親の修正が生んだ周回と実装由来の周回を区別できるか」にも対応する）。

Master の判断

反証を提示した上で、Master が 一律1巡 を選択。literal:

精度をとるならそうなるよなぁ〜。。。でもコストが馬鹿にならないから一旦aの案でしばらく使ってみることにしよう。 確かにバグは見逃しやすくはなるが、表面化しないバグはバグではないからね。

判断軸は Li+ の評価基準そのもの（rules/model/foundational-invariant.md: 正しさは現実の挙動で定義される）。上記 3 件はいずれも本番で表面化しないまま検出された欠陥であり、検証コストは確実に発生する一方で回避された実害は仮定にとどまる。精度の側が正しいことは認めた上で、コストとの秤で降りる、という構造の判断。

降りたもの（明示）

skills/evolution-parallel-agent-eval/SKILL.md の Non-scope「What the single-round cap gives up」に、観測された PR 番号つきで 3 クラスを列挙してある。「見落とした」ではなく「降りた」と後から読めるようにするための記述であり、削除すると将来の読み手がこれを見落としバグと誤読して勝手にラウンドを復活させうる。

1. 親の修正が新設した欠陥（#1560 G2 / #1555 R2・R3）— #1562 のテストが挙動欠陥サブセットの受け皿
2. 後半ラウンドでしか出ない散文層（#1550 R4）— テストでは落ちない
3. 初回実装に在り R1 が届かなかった挙動欠陥（#1543 R3 / #1533 R2）

決着した境界: 基盤停止で verdict ゼロになった場合

2026-08-17、brake1-rerun-gated-on-what-the-round-audited が一般解として確定した。 本節はその経緯の記録として残す。

本 entry の打ち切り規定は verdict が 1 つ出た後の 2 周目を廃するものであり、verdict がゼロのラウンドの扱いは別軸である。この別軸が長く未確定のまま置かれていた。

旧仕様 (skills/evolution-parallel-agent-eval/SKILL.md Procedure step 7。当時の記述と本節の以前の版はいずれも step 6 と誤記していた) は再実行の例外を rules/* の apply 拒否 1 経路のみに限定列挙し、evaluator crash / malformed prompt / timeout は新しいラウンドを与えないと明記していた。基盤側の停止（予算上限 / レート制限 / ホスト障害）はこの列挙に無く、literal 適用では再実行の道が閉じていた。

2026-08-03、PR #1644 の brake 1 で N=3 の 3 体すべてが利用枠の上限により途中終了し verdict ゼロになった。AI 側で「基盤停止は評価者クラッシュではない」と読み替えることは可能だが、L1 に触る PR で仕様の限定列挙を自分の都合で広げる形になるため自己認可せず、Master へ提起して再実行の go-sign を得た。この時点ではその一件に対する上書きであり、一般規則の確定ではないという位置づけだった。無人 run では同じ状況で PR が詰まったまま復帰できない点が主要な論点として残されていた。

2026-08-11 の PR #1729 で同じ停止が再発し、2 度目の観測をもって issue #1730 が起票され、PR #1774 で一般規則が確定した。判定は原因ではなく「そのラウンドが何を監査したか」に置かれ、条件は「verdict が下限未満」かつ「baseline の SHA 不変」の AND となった。本 entry の打ち切り規定そのものは不変である。

（当時この節が一般解の追跡先として挙げていた issue 番号は、現在 GitHub 上で解決しない。当該番号帯の未診断の retrieval 欠落については本 entry の範囲外）

再評価条件

• 1 巡制限下で merge した変更が、本番挙動として実害を出した場合。 Master の受容根拠「表面化しないバグはバグではない」の前提が、表面化した時点で崩れる
• 同種の取り逃がしが複数回観測され、削減したコストを修復コストが上回った場合

再評価時の第一候補は保留した「性質変化での打ち切り」。一律のラウンド数でなく、指摘が「仕様と実装の食い違い」から「記述が実態より盛っている」へ変わった時点で打ち切る。

実装 PR 自身の記録

PR #1573 は変更前の規定（複数ラウンド可）で回し、2 ラウンドを要した。R2 で 3/3 が「R1 の修正が carve-out を過度に一般化した」ことを検出しており、本 issue が受容した当のクラス（修正が新設する欠陥）を実地で再現している。R2 の修正自体は N=3 未検証のまま出荷した。

検出サイン（この判断が後で疑問視される場合）

• 「1 巡では足りないので再検証ラウンドを戻すべき」と提案された時 → 再評価条件に触れているか（本番実害が観測されたか）を先に確認する。観測されていないなら skills/model-accepted-tradeoff を適用し、同じ証拠での蒸し返しを抑止
• Non-scope の 3 クラス列挙を「未修正のバグ一覧」と読んで塞ぎに行こうとした時 → 意図的に降りた範囲であり、塞ぐなら再評価条件の側から入る
• 「N を減らせばもっと安い」と提案された時 → sample count とラウンド数は別軸。N=3 の床は #1296 由来で本決定は触れていない