Single-round cap leaves no path when brake 1 is stopped by infrastructure rather than by an evaluator defect

[liplus-lin-lay]

目的

skills/evolution-parallel-agent-eval/SKILL.md Procedure step 6 の単巡キャップが、基盤側の停止（使用量上限 / レート制限 / ホスト障害）と評価者側の欠陥（クラッシュ / 不正プロンプト / タイムアウト）を区別していない。前者で verdict ゼロになった PR は、literal どおりなら brake 1 を通せず、self-evolution PR として merge 不能のまま残る。

欠陥の芯: 基盤側の停止は 5 時間のローリング窓で自然に回復する。にもかかわらず仕様は、回復した基盤を使い直す権利を与えていない。基盤が詰まっているのではなく、仕様が詰まっている。

確認済みの事実

3 日連続で同型が発生した。いずれも N=3 の 3 体すべてが途中終了し、verdict がゼロ。

日付	PR	issue
2026-08-03	#1644	#1641（L1）
2026-08-04	#1650	#1636
2026-08-04	#1652	#1651

停止の実体は 5 時間ローリングの使用量上限（Master 確認）。ホストが返すエラー文字列は You've hit your monthly spend limit だが、これは表示が実態と食い違っている。本 issue の初版および #1644 / #1650 時点のコメントは、この文字列をそのまま事実として記録していた（Source check の失敗）。実態が月次の課金上限でないことは、以下 2 点に効く:

• 復帰は待てば起きる。恒久的な詰まりではない。
• 再実行が Master の追加支出を伴わない。サブスクリプションのレート制限であり、支出ゲートの軸に乗せる問題ではない。

step 6 の literal:

Single round: steps 2-4 produce one verdict per draft, and the revised draft ships without re-verification (see Non-scope: what the single-round cap gives up). The cap does not block step 2's rules/* retry path, and that path only: there, a refused apply leaves the round with no verdict, so re-running from a session that can apply IS the round, not a re-verification of it. Do not generalize this to any round that failed to produce a verdict — an evaluator crash, a malformed prompt, or a timeout does not earn a fresh round.

• 再実行が許される例外は rules/* の operational copy apply 拒否 1 経路のみと明示的に限定列挙されている。
• 「verdict を出せなかったラウンドに一般化するな」の例示は evaluator crash / malformed prompt / timeout の 3 つ。使用量上限による中断は文言上この集合に最も近い（「API エラーで途中終了」）。
• したがって literal 適用の帰結は「当該 PR は brake 1 を通せず、再実行の権利も無い」。brake 1 は全 self-evolution PR で必須（Trigger の Self-evolution PR brake (mandatory)）であるため、merge 不能が確定する。

3 回とも AI 側で読み替えを自己認可せず Master へ提起し、再実行の go-sign を得て解決した。人間が居る session ではこの経路が使えるが、無人 run では窓が回復した後も復帰できない。

制約

• キャップの目的を壊さないこと。 Cap brake 1 at a single round and drop post-fix re-verification #1563 で確定した単巡キャップは「修正後の再検証ラウンドを廃止する」ためのもので、判断軸は Master literal「表面化しないバグはバグではない」。verdict が 1 つ出た後の 2 周目を防ぐ設計であり、verdict がゼロの状態を救済することとは別軸。救済経路を足すことでキャップが骨抜きになる形は採らない。
• rules/* retry path の書き方が既に答えの形を持っている。 同経路は「apply が拒否されればラウンドに verdict が無い、よって apply できる session からの再実行は再検証ではなくそのラウンド本体である」と論じている。基盤停止も同じ構造（ラウンドが成立していない）で説明できるかを先に検討する。
• 区別の根拠を「何が落ちたか」でなく「verdict が産出されたか」に置けるか。 「評価者が途中で落ちた」は基盤停止と表層が同じ（API エラー）ため、落ちた主体で切ると毎回判定がぶれる。産出の有無で切れば、現行が名指しで除外している 3 語（crash / malformed prompt / timeout）も同じ規則に入る。ただしその 3 語の限定列挙と正面から衝突するため、列挙を産出条件へ置き換える判断が要る。
• N 未達の扱いが同じ軸に乗る。 N=3 のうち 1 体だけ落ちて 2 体が verdict を返した場合（spec(delegation): add subagent model policy and parallel-width cap #1533 R2 に実例）。産出条件で切るなら「N=3 の floor を満たしたか」が別途要る。
• 再実行の待機設計。 停止が 5 時間窓であることが分かった以上、救済は「窓が回るまで待って再走」で足りる可能性が高い。無限リトライを防ぐのは回数上限より待機と上限回数の組が素直。人間ゲートは支出の軸ではなく、待機が長引いた場合の escalate として置く。

完了条件

• 基盤停止で verdict ゼロになった brake 1 ラウンドについて、再実行が許されるか / 人間ゲートへ escalate するか / PR を保留するかが仕様上一意に決まる
• その判断が evaluator crash と区別できる根拠を持ち、単巡キャップの目的（修正後の再検証ラウンド廃止）を損なわない
• N=3 のうち一部のみ落ちた場合（N 未達）の扱いが同じ軸で決まっている
• 無人 run で窓の回復後に自力復帰できる（待機と上限回数が仕様上決まっている）

関連

• Cap brake 1 at a single round and drop post-fix re-verification #1563 / PR spec(brake1): cap parallel-agent-eval at a single round [rules, skills, docs] #1573 = 単巡キャップの導入。判断軸と受容した反証 3 件の出典
• spec(delegation): add subagent model policy and parallel-width cap #1533 = brake 1 の R2 で評価者 1 体がセッション上限で途中終了し N=2 未達のまま進んだ先行事例。当時は複数ラウンド運用だったため詰まらなかった
• Single-round cap makes a host-process death unrecoverable for brake 1 #1612 = ホストプロセス停止で同型。resource 消費の軸を持たない点が異なる
• L1 skill descriptions cannot route to firing moments their bodies declare #1641 / PR fix(model): align L1 skill descriptions with body firing moments #1644 = 本 issue の検出元

[liplus-lin-lay]

実地データ点: 本 gap が初めて実運用で発火した (2026-08-04)

PR #1650 (issue #1636 / Codex hooks への promotion detector 移植) の brake 1 で、本 issue が記述している状態がそのまま起きた。

観測:

• 評価者 3 体を並列 spawn (sonnet 床、N=3、単巡)。3 体とも You've hit your monthly spend limit の API エラーで途中終了。
• 1 体は軸 3 の途中まで進んでいたが、部分出力のみで verdict 無し。残り 2 体は verdict 無し。
• 結果として brake 1 は verdict をひとつも産んでいない。評価者の欠陥でも、対象 PR の欠陥でもなく、インフラ側 (課金上限) での停止。
• brake 2 は inline 入力で完結する設計のため独立に完走し PASS。ブレーキ 2 本のうち片方だけが成立している状態になった。

適用した規則リテラルと詰み方:

skills/evolution-parallel-agent-eval/SKILL.md Procedure step 6 は、step 2 の rules/* retry path について「verdict の出なかったラウンドは round として数えない」と書きつつ、直後に 「これを verdict の出なかった任意のラウンドへ一般化するな — 評価者のクラッシュ、不正なプロンプト、タイムアウトは新しいラウンドを得ない」 と明示している。今回の停止はこの禁止側に文字通り該当する。

したがって:

• 再 spawn は単巡 cap のリテラルに反する
• brake 1 は自己進化 PR に必須なので、verdict 無しではマージゲートを通せない
• 親の N=1 自己チェックは Constraint で明示的に禁止 (最低 N=3)

PR #1650 はこの 3 条件の交差で、規則上どこへも進めない状態で停止している。 本 issue が「path が無い」と述べているのは、こういう形。

補足: 停止理由が課金上限だったため、再実行の可否そのものが Li+ 外の判断 (human) に依存する。仕様側で retry path を開く場合も、「インフラ停止での再走は round に数えない」だけでは足りず、再走が外部資源を消費する場合の human gate を同時に決める必要がある。#1612 (host-process death) は同型だが、こちらは資源消費の軸を追加で持つ。

[liplus-lin-lay]

@

3 例目（2026-08-04, PR #1652 / issue #1651）

同型が 3 日連続 で発生した。

日付	PR	事象
2026-08-03	#1644 (#1641)	評価者 3 体が monthly spend limit で途中終了、verdict ゼロ
2026-08-04	#1650 (#1636)	同上
2026-08-04	#1652 (#1651)	同上（本コメント）

本件の固有情報:

• 3 体すべてが spawn 直後に落ちており、部分的な verdict すら残っていない。fix(model): align L1 skill descriptions with body firing moments #1644 / Port live-memory promotion detectors to both Codex hooks and align flat memory filename references #1650 と同じく「N が減った」ではなく「N=0」。
• 再走の可否は 3 回とも人間の go-sign に依存した。無人 run ではこの経路が存在しないため、PR は brake 1 を通せないまま停止する。

再走時に親が採った読みを記録しておく（本 issue の仕様化の材料として）:

単巡 cap が「新しいラウンドを与えない」と限定列挙しているのは評価者クラッシュ / 不正プロンプト / タイムアウトであり、いずれも評価そのものの欠陥を指している。基盤が実行を拒んで verdict がゼロの場合、再検証すべきラウンドがまだ成立していないため、再走は 2 周目ではなく 1 周目と読める。これは skills/evolution-parallel-agent-eval/SKILL.md Procedure step 6 が rules/* の apply 拒否経路にだけ認めている例外（「refused apply leaves the round with no verdict, so re-running IS the round」）と同じ構造であり、その literal を基盤停止側へ広げる形が仕様案の第一候補になる。

つまり必要な区別は「クラッシュか否か」ではなく verdict が 1 つでも産出されたか否か。産出ゼロなら周回として成立していない、と書けば evaluator crash / timeout も自然に同じ扱いへ入る（現行の限定列挙はこの 3 語を名指しで除外しているため、そこと衝突する点は仕様化時に裁定が要る）。
@

[liplus-lin-lay]

訂正: 停止の実体は月次課金上限ではなく 5 時間ローリング使用量上限

本 issue 初版・および #1644 / #1650 / #1652 各回のコメントは、ホストが返す You've hit your monthly spend limit という文字列をそのまま事実として記録していた。この表示は実態と食い違う。実体は 5 時間ローリングの使用量上限（2026-08-04 Master 確認）。

上の 2 コメントは経緯の記録としてそのまま残す（誤読が起きた事実自体が観測材料のため）。本文は訂正済み。

何が変わるか

	誤: 月次課金上限	正: 5 時間ローリング窓
復帰	支払うか月が変わるまで詰み	待てば自力で戻る
再走のコスト	人間の追加支出を伴う	サブスクリプション内、追加支出なし
必要な仕様	支出ゲート付きの救済経路	窓の回復後に再走する権利（＋待機と上限回数）

欠陥の性質が反転する。基盤が恒久的に詰まっているのではなく、基盤は回復するのに仕様がそれを使わせない。無人 run で PR が止まり続ける結論は変わらないが、原因は資源の枯渇ではなく単巡 cap の限定列挙のほうにある。

「再実行が無限に走る危険」を人間ゲート（支出の軸）で抑える方針も、この訂正で不要になる。窓が回るまでの待機と回数上限で閉じる。

手続き上の所見

エラー文字列というツール出力を、発話前に検証せず判断材料へ載せた。rules/model/trigger-check-gate.md Source check（話者の権威で検証を免除しない／ツール出力も対象）が禁じている形そのもの。3 回とも同じ文字列を見ていながら、3 回目に人間から指摘されるまで疑っていない。ホストの表示は Li+ 外の実装であり、こちらから実態を確かめる手段が無い面では人間にしか見えない事実だったが、それなら「表示によれば」と限定して書くべきだった。