brake1 rerun gated on what the round audited - Liplus-Project/liplus-language GitHub Wiki

brake 1 の再実行可否は「そのラウンドが何を監査したか」で決め、停止理由では決めない

Question

skills/evolution-parallel-agent-eval の single-round cap は、verdict が 1 つ出た後の 2 周目を廃する規定である。では verdict がゼロ、あるいは N>=3 の下限に届かないまま止まったラウンドの再実行は、cap が禁じる 2 周目にあたるのか。旧仕様は再実行の例外を rules/* の apply 拒否 1 経路のみに限定列挙し、evaluator crash / malformed prompt / timeout は新しいラウンドを与えないと明記していた。基盤側の停止（予算上限 / レート制限 / ホスト障害）はこの列挙に無く、literal 適用では再実行の道が閉じていた。

Current resolution

原因ではなく、そのラウンドが何を監査したかで決める。 再実行が「同じラウンドの続き」であるのは次の 2 条件が両方成立するときに限る。

  • (a) そのラウンドが返した verdict が N>=3 の下限に達していない
  • (b) 評価対象の baseline（PR の commit SHA）が最初の試行から変化していない

両方が成立するとき、その再実行は誰も監査していない draft を初めて監査しているのであり、round 1 の完了であって round 2 の開始ではない。cap には触れない。

停止理由は判定項ではない。 予算上限・評価者クラッシュ・malformed prompt・timeout は、この基準の下では一つのもの——「下限未満の verdict しか返さなかったラウンド」——であり、これらを分類することは cap が検査できない事後の自己申告になる。旧仕様が原因を列挙していたことが、列挙に無い原因（基盤停止）に対して道を閉じていた原因である。

計器の同一性も条件に入る。 持ち越される verdict は、それを生んだ軸文言と prompt が再実行の spawn 条件と同一であるものに限る。prompt の修復は許される（malformed prompt は書き直さなければ何も返せない）が、修復は旧文言の下で得た verdict を加算せず退役させる。floor が数えているのは 1 つの問いに対する独立標本であり、2 つの文言は 2 つの問いだからである。

cap 本来の対象は一切緩めていない。 条件(a) が「既に得た verdict を、気に入らないので買い直す」経路を拒み、条件(b) が「著者の修正後の draft を再監査する」経路を拒む。後者は SHA が動くため定義上 round 2 であり、cap が元から狙っていたのはここである。

上限: 同一 baseline に対する 3 回目の試行が下限に届かない場合、そこで止めて human へ escalate する。数と task / debug というカテゴリは skills/model-loop-safety 由来であり、この skill は自前の数値を立てない。ただし動作は Loop Safety 由来ではない——Loop Safety の閾値における規定動作は stop-and-switch であり、human は switch が収束しなかった場合にのみ到達する。ここでは switch が閾値より前に尽きている（prompt の修復と上位モデル層の指定が毎試行で利用可能）ため、3 回目に残るのは stop だけである。

Edges

  • depends on brake1-single-round-cap — 本 entry は同 entry が自ら「未解決の境界」として立てた問いに答えるものであり、cap そのもの（N=3 の 1 巡で打ち切る／修正後の再検証ラウンドを行わない）は不変。cap が廃されれば本 entry の前提が消える
  • conflicts with （現時点で対立 entry なし）

背景

2026-08-03、PR #1644 の brake 1 で N=3 の 3 体すべてが利用枠の上限により途中終了し verdict ゼロになった。このときは Master へ提起して再実行の go-sign を得る形で個別に解決し、一般規則は保留された。

2026-08-11、PR #1729 の brake 1 で同じことが起きた。3 体とも PR コメントを投稿する前に落ちており、中断位置はいずれも sweep 開始直前。verdict ゼロのまま cap を literal 通り適用すると、この PR が到達できる仕様適合状態は Or abort のみになる——評価の中身とは無関係な理由で PR を捨てる経路が唯一の出口になっていた。これが issue #1730 の起点である。

2 度目の観測で、個別 override の反復ではなく一般規則を確定させる判断に至った。

制約

  • cap の目的（修正後 draft の再監査を買わせない）を緩める変更にしないこと。論点はラウンドの開始側であり、再監査側ではない。
  • brake 1 が自己進化 PR に必須であること、および N>=3 が下限であることは、いずれも「評価を実施する」ための規定であって「評価が実施できなかったときに PR を捨てる」ための規定ではない。
  • 新しい数値を立てないこと。

結論

採った形 = 基準を述べる。判定を原因ではなく「そのラウンドが何を監査したか」に置き、2 条件の AND で閉じる。

却下した形 1 = step 7 の除外リストに「基盤側の停止」を項目として足す。却下理由 = API エラー全般か上限系のみか、評価者のツール呼び出し失敗はどちらかという線引きを呼び込み、その線は原因の分類に依存する。原因分類は事後の自己申告になりやすく、cap を実質無効化する経路になる。

却下した形 2 = 現状（Or abort のみが出口）を意図されたものとして明示する。却下理由 = brake 1 必須と N>=3 下限の 2 つの literal と整合しない。

派生の形として brake1-firing-closed-by-criterion と同型である。あちらは条件 2 の path 列挙を「検出器が読み手しか無い面か」の基準へ置き換えた。同一 skill の別部位で、列挙が「これまで出てきた事例」に過ぎず条件を閉じないという同じ性質が 2 度目に現れたことになる。

brake 1 の結果（本判断自身への適用）

N=3、単巡、6 軸。所見のあった 5 軸すべてを著者が受理した。

  • 固定軸（impression-literal）で 3 リテラルが閾値到達し削除。
  • 条件(b) が baseline は固定するが計器を固定しないという指摘（3/3）を受け、Current resolution の「計器の同一性」段落が追加された。修理は第三条件の追加ではなく carry-over 節の限定で行っている——第三条件を立てると、malformed prompt の正当な修復経路まで塞ぐため。
  • ceiling 文の applied as written が数については成立するが動作については成立しないという指摘（2/3）を受け、帰属の記述が訂正された。挙動自体は変えていない。
  • rules/* retry path を名指しする節が決定の「個別の但し書きとしては残さない」に反するという指摘（1/3）を、比率ではなくリテラル照合で採用し削除。

割れた 2 軸（ceiling / 掃引）はいずれも same-question check が No を返し、所見は評価者の不一致ではなく軸文言（Axis statement form の Question 部と Scope 部）に着地した。

再評価条件

  • 条件(a)(b) を満たす再実行が、実際には既に監査済みの draft を再監査していた事例が観測された場合。
  • 上限（3 回）に達して human へ escalate する事象が反復し、その反復自体が cap ではなく別の要因（評価基盤の安定性）に起因すると判明した場合。

Related