Skip to content

brake evaluator baseline integrity

Jump to bottom
Claude Lin & Lay edited this page Jul 28, 2026 · 3 revisions

brake 評価者のベースライン保全は権限でなく指示と材料で行う

Question

brake 1 / brake 2 の評価者が評価対象を書き換え、他の評価者のベースラインを壊す事故を、何で防ぐか。

Current resolution

subagent のツール権限は変更しない。 brake の委譲プロンプトで評価対象を書き換えないよう明示的に指示し、あわせて評価者へ渡す材料を PR の URL に寄せて共有クローンのパスを名指ししない。

前者が書き込みの意図を断ち、後者が共有ベースラインという的そのものを外す。2つは合成して使う。

評価者区分だけツール権限を絞る設計（agent 定義の tools:）は採らない。

Edges

  • depends on brake1-single-round-cap — 1巡制限下では1ラウンドの verdict がそのまま出荷判断になるため、そのラウンドのベースラインが汚れていることの代償が上がる。ラウンドを重ねる設計であれば次ラウンドで気づけた
  • depends on implementation-always-delegated — 実装が常に委譲され brake が CI green 後に走ることで、評価者へ渡す材料が push 済み SHA と緑の run URL に確定した。材料を PR の URL に寄せる余地はこの位置決定が作った
  • conflicts with （現時点で対立 entry なし）

背景

PR #1581 の brake 1 で、評価者3体へ同一のローカルクローンのパスを渡した。評価者Aが mutation test でソースを差し戻して復元する間に評価者Cが走り、Cは「テストが非決定的に落ちた」と報告した。存在しない flakiness が実欠陥候補として上がる形で現れ、親が単独実行で安定を確認して初めて切り分いた。

同軸の先行例が PR #1560 にある。親が評価プロンプトへ古い main ref の diff コマンドを書き、無関係な2ファイルが混入した diff を渡していた。3体中2体が自力で除外したため実害は出なかったが、評価者が気づかなければ検出不能という性質は同じ。

観測 cluster は brake1-evaluation-baseline-not-isolated（occurrence 2）。

判断の前に確認した反証

AI 側の推奨は当初「ツール権限で縛る」だった。評価者を tools: Read に絞れば物理的に書けなくなり、rules/model/subtractive-structural-beauty.md が求める「実行が保証される構造」に到達する。brake 2 の adapter/claude/agents/l1-gate-eval.md が既にその形で実装されている。

Master はこれを採らなかった。理由 = subagent の書き込み権限そのものを触りたくない。

この経路には副次的な重さもある。skills/evolution-parallel-agent-eval/SKILL.md Constraint が brake 1 評価者への custom-agent ファイル使用を禁じており（理由 = モデル床の固定方法と probe 型 identity の保全）、Claude Code では agent ファイル本文が system prompt を置き換えるため「ツールだけ縛って identity を触らない」ができない。probe 型の実運用実績を調べた上で型ごとに分岐する必要が生じる。ツール権限を採らない判断は、この分岐ごと降りることでもある。

2026-07-28 追記: そもそも brake 1 は tools: で read-only にできない

PR #1596 のマージ前に Master が「read-only にするとして必要なツール権限は何か」を問い、Claude Code の一次資料に当たって確認した。判断の前提が一つ増えた。

  • brake 2 の必要権限はゼロ。 入力（L1 diff + 理由）が委譲プロンプトへ inline で渡り、リポジトリを名指ししない。現行の tools: Read は必要量を上回っている。Codex 版の sandbox_mode = "read-only" も同様。
  • brake 1 の必要権限には Bash が入る。 評価者の取得経路は gh pr diff / gh api contents / 全体掃き用の clone であり、Claude Code に gh 相当の組み込みツールは存在しない。gh も git も Bash 経由でしか動かない。したがって tools: から Write / Edit を外しても Bash が書けるため、allowlist だけでは read-only を表現できない。

tools: を諦めて構造で縛るなら、残る経路は agent 定義の hooks: PreToolUse に Bash バリデータを置き、変異コマンドを exit 2 で弾く形しかない（permissionMode は親のモードに上書きされるため使えない）。ただしこれも agent 定義ファイルを作ることが前提であり、上記の identity 置換の重さは消えない。さらにバリデータはコマンド文字列から「対象リポジトリへの書き込み」と「評価者自身の作業ディレクトリへの clone」を区別できない（cwd が分からない）ため、実装も素直でない。

Master 判断（2026-07-28）= 「今の修正案の方が摩擦は少なそう」。ブレーキ1本を構造化するために評価者が素の subagent であること自体を差し出すのは、釣り合いが取れていない。

受容した対価

指示は親が委譲プロンプトへ毎回書く手続きであり、忘れれば効かない。rules/model/subtractive-structural-beauty.md の procedure-vs-structure 判定では置き換え対象の側に立つ。強制する構造（hook / gate）は置かない。

緩和として、指示の literal は仕様側に置く。親が毎回文言を作文するのではなく写す形にすることで、「何を書くか」の負荷を消し「書くこと自体」の recall だけを残す。

実測

PR #1583 の brake 1 では、親が手でこの指示を書いた状態で評価者3体を走らせ、3体とも書き込みゼロだった。指示は実際に守られている（n=1）。同 PR は brake の実行位置を CI green 後へ固定した最初の適用でもあり、材料が SHA と run URL に限定されていた効果と分離できていない点に注意。

PR #1596（本判断の実装 PR そのもの）の brake 1 で、仕様側に置いた literal を写す形の運用を初めて回した。評価者3体はいずれも clone を作らず gh pr diff と gh api contents のみで4軸を完走し、3体とも書き込みゼロ。汚染ゼロは n=3 に達した。ただし材料の限定（SHA + run URL）と指示の同時適用という交絡は #1583 から引き継いだままで、依然として分離できていない。

PR URL 経路はリポジトリ外のディレクトリから実測済み。gh pr diff <n> --repo <owner>/<repo> は clone 無しで差分を返し、gh api repos/<owner>/<repo>/contents/<path>?ref=<SHA> は任意 SHA の任意ファイル本文を返す。弱点はリポジトリ全体の grep で、GitHub code search は本リポジトリで総ヒット 0 が返り当てにできない。全体掃きが要る軸では評価者が自分の作業ディレクトリへ clone することになるが、共有面ではないので隔離は保たれる。

再評価条件

本判断は事故の軸（評価者が混乱して評価対象を書き換える）に対する解であり、敵対の軸（評価者が読む材料に仕込まれた指示に乗る）には効かない。プロンプトの言葉で縛る相手が、まさにプロンプトを読んで動く相手であるため、指示は敵対入力に対して構造的に無力である。

現状は敵対の軸が立っていない。Li+ の PR / issue はすべて Master と AI が書いており、評価者が読む材料に外部の書き手が入る経路がない。この前提が崩れたときが再評価点。

具体的な再評価トリガー:

  • Discussions 経由の外部起票（skills/operations-discussions/SKILL.md が定める外部エントリポイント）が、issue 本文や PR 本文として brake 評価者の読む材料に入る運用になったとき
  • 外部コントリビュータが PR を開けるようになったとき
  • 評価者へ渡す材料に、Li+ 外で書かれたテキスト（外部記事、サードパーティのツール出力）を含める軸が立ったとき

いずれかが成立した時点で、rules/model/subtractive-structural-beauty.md の Surfaces of freedom（Action = least authority）および Subtraction safeguards（Security は明示的冗長性が load-bearing な領域）が本来の意味で効いてくる。そのときツール権限による制約は、事故対策ではなく security 対策として要求される。

Related

  • #1584 / PR #1596 — 本判断の実装先。マージ済み
  • #1597 — PR #1596 の brake 1 が出した範囲外所見（Procedure step 2 に docs/* / adapter/* の分岐が無い）
  • #1582 / PR #1583 — brake の実行位置を CI green 後へ固定。材料を SHA + run URL に限定する記述はこの PR で入った
  • #1575 / PR #1581 — 汚染の観測元
  • skills/evolution-parallel-agent-eval/SKILL.md — brake 1 の手続き本体

Li+ Wiki

この Wiki は、Li+ に基づく開発・運用を支えるための情報整理空間です。

ページ構成について

要求仕様書（数字：1–9）

数字で始まるページは、 Li+プログラムの各レイヤーの仕様を定義するページです。

  • 要求（何を満たすか）と仕様（どう振る舞うか）を一体として記述する
  • 実装前に作成または更新する
  • issue群から採用された要件を集約する

これらのページは 安定性と一貫性を重視して管理されます。

参考文書（アルファベット：A–）

アルファベットで始まるページは、 Li+の構想・設定・導入手順などの参照用ページです。

  • 設計思想・背景
  • 設定リファレンス・インストール手順

これらのページは 必要に応じて更新・拡張されます。

rules/, skills/, adapter / update 各ファイル

リポジトリ内の rules/**/*.md（L1–L4 の常時ロード分、subdir 含む）、skills/**/SKILL.md（トリガー起動分）、adapter/claude/CLAUDE.md、adapter/claude/hooks-settings.md、adapter/claude/hooks/*.sh、adapter/codex/AGENTS.md、およびルート直下の Li+config.md、Li+update.md は、 AIやランタイムが直接読む実行用プログラム / 定義ファイルです。

  • docs/ は人間向けの仕様書・要求仕様・手順書
  • rules/, skills/ および adapter / update は実行時に読み込まれる本体

両者は対応しているが、役割は同じではない。

Home | 1. Model | 2. Evolution | 3. Task | 4. Operations | A. Concept

要求仕様書 (1-6)

参考文書 (A-K)

判断構造

Clone this wiki locally