まとめ

September 21, 2026 · View on GitHub

Jev(TypeSafe AI の System One モデル)は 文字列ではなく型付きの確率判断を返す意思決定専用モデルです。 noul(確率)/ choice(選択 + confidence)/ score(順序つき + confidence)の 3 種だけ。入力 $0.042/MTok・出力無料・レイテンシ 125〜730 ms。

この速度と価格が何を可能にするのかを、61 本のレポートで測りました。番号は 00〜63 で、13〜15 は欠番。61 本のうち 2 本は提案(06 20)で、残り 59 本が実測です。各レポートは生の数値と再現コマンド付き(索引)。

この数字を更新するとき、一度間違えました。前の版の「36 本」は本数として正しかった(当時 36 ファイル)のですが、それをその時点の最大番号 44 に置き換えてしまい、**欠番 3 つを数え込んだ「44 本」**になっていました。 ls [0-9][0-9]-*.md | wc -l で数え直して気づきました (この見出しの数字は毎回そのコマンドで取ること。最大番号から引き算してはいけません)。後半 13 本の主題(§ 計器の規律)が、この文書自身にも当てはまった形です —— 数えられるものを数えずに、近くにある数字で代用した。

後半 27 本(37〜62)は毛色が違います —— 部品を作る話から、本物のエージェントの中で動かして測る話になり、そこで一番多く学んだのは jev についてではなく自分の計器についてでした。 § 本物のエージェントの中でと § 計器の規律がそれです。

やったこと

道具にした

	何	出典
`lib/`	MoonBit の Jev クライアント(3 種の質問、255 選択肢の上限チェック)	—
`jevlang`	条件が Jev の判断である小さな言語。 `if noul("家に牛乳がない") { ... }` が動く。JS と MoonBit の 2 実装で、同じ `.jev` の結果一致をテスト	19
`jevdsl`	MoonBit から `match` できる薄いラッパー。3 種を `(result, confidence)` に揃えて guard に閾値を書く	20
`hooks/jev-permission-gate.mjs`	Claude Code の `PreToolUse` hook。 Bash の実行許可を Jev が判定。依存ゼロの Node 1 枚、判定ロジックは `.jev` に外出し	18
`eslint-plugin-jev`	本物の ESLint プラグイン。関数ごとのレビュー score + 8 つの名前付き指標。ファイル 1 個 = 1 リクエスト	21 22
`jev/rule`	まだ存在しないルールを自然言語で書く。ノードセレクタだけコードで書き、違反かどうかは 1 文で聞く	24 26
`eslint.rules.mjs`	このリポジトリの散文の規約 8 文。`docs/` にしか書いていない規約を lint ルールにして、自分の JS 9,315 行に当てた(6 文出荷・2 文 retire)	26
`shared/thresholds.ts`	閾値を当てはめる部品。最初に返すのは閾値ではなく「当てはめるべきか」(gap の verdict)。置き方は名前で選び、fold を切って採点する	25
`packages/` の 5 つ	pi の拡張として動く jev コンポーネント: model router / skill router / guard rail / 削除だけする compaction / orchestration gate。スタンドアロンの CLI とライブラリも兼ねる(pi を import するファイルは各 1 つ)	36 37
`jev-hermes`	常駐 agent。 5 つを 1 拡張に束ね、同じ turn を読む 3 つは 1 リクエストで聞く。予算台帳を共有し、上限に当たったら全部が host 自身の挙動に落ちる。1,000 turns/day で $1.32/月	37
`task-filter --penalty`	閾値の代わりに損失を最小化する。「閉包の秒数 + penalty × P(見逃し)」で、タスクごとの柵がそのタスクの実測コストから出る	25

ゲームとエージェントに載せた

	何	結果	出典
五目並べ	Jev 同士で対戦、実時間再生の GIF 化(フレーム遅延 = その手の実測 ms)	1 手 ≈ 1 リクエスト	README
3v3 MOBA	2 レーン + ジャングル、視界と戦場の霧。チーム視界 = 1 state に 3 質問	73 ms/キャラ判断、489 判断で反則 0	02
MOBA を独立プロセス化	referee + player ×2。視界の霧を配線で強制	scripted 3/3 引き分け → Jev 同士 6/6 決着	10
シナジーと取り返し	AD/AP・前衛の機構を実装、handicap sweep	弱い編成+Jev が強い編成+scripted に 5-1	11 12
チェス	Jev vs Claude Sonnet 5、同じ合法手リストを渡す	両サイドで Jev の勝ち、0.3 s/手対 13〜24 s/手	03
ブラウザ探索	chaosbringer の次操作選択を Jev に	8 手深いゴール到達 0/3 → 3/3	05

監視に載せた

	何	結果	出典
異常検知のトリアージ	6 サービスを 16 通りに壊した OTLP の窓に対し、検知はコード・トリアージを Jev	severity は規則が 16/16 で完勝、cause はログ本文を伏せると規則 4/10 対 Jev 21/30	27
対訳の同期チェック	このリポジトリの実物の英日 README を整列させ、8 種の変異でラベルを作る	diff 26/30 + 判断 84/90 で誤検出 0。文書全体を足すと omission が 1.84 → 0.57	28
skill カタログからの選択	mizchi/skills の実物 98 行に対し 14 プロジェクト × 74 skill を 7 通りで聞く	74 問 1 リクエストと 1 問 1,036 リクエストで答えが 99.8% 一致、コストは 2.4 分の 1。ティア列をコードに置くと AP 0.41 → 0.70	29
461 skill から選ぶ道具	実在の公開 skill / subagent を 9 リポジトリから集めて、前段 + 判断の 2 段で選ぶ CLI	criteria を state に 1 回置くと 1 リクエストの上限が 260 → 520 問。候補を増やすと P@12 は 0.25 → 0.19 に下がる。終点は 1 リクエスト $0.0003/プロジェクト	30
文書化されたゲート	multi-agent-orchestration の `(1 or 2) and (4)` を、38 シナリオで 5 通りに読む	組み立てても同点(30/38 対 30/38)。効いたのは質問の枠組みで 21 ポイント —— コストを先に述べると 58%・誤り 16 件すべてが「分けない」方向。表 8 行をそのまま choice にすると 22/22	31
修復ループ	バグを植えた JS モジュール 21 件。パッチは 25 個の構文規則がコードで生成し、Jev は並べるだけ	テスト実行が生成順 3.00 回・無作為 7.69 回に対し 1.00 回で 16/16 を一発。`choice` 1 問で全順序が出るのでトークンは半分以下。gap が初めて正(+0.03)だが draw が 0.043 動くので閾値にはならない	32
機械的な指標を渡すレビュー	緑のモジュールへの 1 行 diff 261 件。ラベルは終了コード。指標を見せる arm と見せない arm	ソースとテストは +5 ポイントでトークン +5%、機械的な指標は 0 ポイントでトークン +69%(AUC は 0.941 → 0.921)。数値指標が全部 AUC 0.5 だったことが先にそう言っていた	33
本物の NetHack を tmux で駆動	`nethack-console` 3.6.7 を `tmux send-keys` / `capture-pane` で操作。244 画面 × 12 問、正解は全部盤から計算	ステータス行は 100%(AUC 1.000)、`@` の周り 8 マスは真のとき 53%。同じ `<` について行方向 96% / 列方向 74% —— state の形と一致する軸だけが読める。遊ばせると反則 0 件 / 1,800 リクエストだが地図化はランダム並み —— と書きかけて、探索ボットにだけ記憶を渡していた交絡に気付いた。訪問回数を足すと地図化 48 → 152	34
ゲームの緊張感を confidence で測る	完全に解けるゲーム 5 種で自己対戦。`criticality` を総当たりで計算して照合	`doubt` はゲームを solver と同じ順に並べる(ρ 0.900)が、どの手も無意味なゲームでも `doubt` 0.418 —— 床がある。反転ルールの盤で着手は 81% 正しいのに confidence は反転前の criticality を +0.81 で追う	35

本物のエージェントの中で動かした

ここから「部品を作る」ではなく「部品を本物のホストに挿して測る」になります。

	何	結果	出典
常駐 agent に束ねる	5 つを 1 つの pi 拡張に。同じ turn を読む 3 つは 1 リクエスト	1,000 turns/day で $1.32/月。ただし束ねるのは無料ではない(下の 28)	37
実物の pi の中で動かす	pi 0.85.1、scripted モデル、18 turn	5/5 が配線で確認。バグ 4 件 —— skill router は一度も skill を見ていなかった、選んだ skill が 1 ターン遅れ、compaction の閾値と目標が別スケール、README が fiction。そして control arm がリポジトリを消した	38
他のモデルと同じコーパスで比べる	guard / orchestration を haiku・sonnet と同じラベル付きコーパスで	精度は互角(guard 96% で sonnet と同点、haiku 88%)、速度はタスクごとに 26〜61 倍	41
残り 3 つも比べる	compactor / model router / skill router も	一貫しているのは速度だけ(5 つすべてで 26〜103 倍)。品質で jev が明確に勝っている列は無い —— model router は誰も無料の `always-haiku` を超えない、skill router は3 者とも分離せず	42
本物のエージェントを完遂まで走らせる	`claude -p` が生成し、jev は `PreToolUse` から挿し込み、判定は `node --test` の終了コードだけ。186 run	18 §1 の 2,500 ms 予算に 40 本ぶん遅れて数字が付いた: 391 コマンドで中央値 371 ms、p99 568、超過 0。修理コーパスでは gate は完遂を 1 件も奪わない(63/63 対 63/63)が、978 コマンド中 12 件しか発言しない	43
残り 4 コンポーネントも配線して測る	model router / skill router / orchestration gate、そして compactor	完遂は 3 つとも天井(Bash が在るのでエージェントはテストが緑になるまで回す)。分離したのは tool call だけ —— 高い段は同じ仕事を中央値 −2 call・32 タスク中 28〜29 で少なく終える(p < 0.001)。skill router は実在 300 件のカタログで測った(私が書いていない最初のコーパス)	44
削除の順序 vs 無料の順序と要約	予算内で何を捨てるか。判断・無料の 3 順序・要約を同じコーパスで	勝つ、が自分の主張 2 つが壊れた —— 差が大きすぎたので疑ったら、判断がしていたのは「作業と周辺探索の分離」で、ゴールとの語の重なりという無料の順序が 67〜100% を取った。残る差は厳しい予算だけ(25% で +18)	39
宿題 4 件を片付ける	記憶の arm 分離 / 却下率 / 緊張感の順位 / union state の並べ方	3 件が「前提が違った」で終わった —— 記憶は訪問回数とゴール文の交互作用(片方ずつは −6 と −12、両方で +60、厳密 p = 0.042)、却下率はプロンプトの矛盾、順位は隣接 4 組のうち両方の尺度で分離しているのが 0 組	40
閾値を動かすべきか / 部品を書く前に設計を測る	`minConfidence` の全値に値段を付ける。要約器の前の判断は上限で測る	正しさのラベルが存在しない(両段 32/32 で `advise()` が `no-signal`)ので値段で語り直した —— 床を外すと 17% 安く・tool call +20・完遂は不変。綺麗な 8/8 を基準率に当てたら約 34% で起きるので選別の証拠にならない。要約器の方は正解の文字列を渡す上限アームが 9/9・捏造 0 で天井に到達 —— 逐語なら従われ、一般的な規則は従われない	45
問いが間違っていた	「このエントリに測定値が入っているか」を jev に当てさせる。まず上限を確認	リクエスト 0 件で問いが否定された —— 9 事実のうち 3 件は数字を 1 文字も含まず、4 件はコマンドが計算した量ではなくソーステキスト。だから完璧な分類器の上限が 6/9 で、何もしないアームが既に 6/9。上限アームが勝っていたのは測定値を見抜いたからではなくゴールが訊いている値を渡したから。そちらで測ると jev 14/40 対無料 15/40、p = 1.000 で分離せず	46
段が 3 つ在って、判断は真ん中に在った	比較型のゴールを 3 段(検出 / 絞り込み / 集約)に分けて測る	§1.7 が疑っていた 2 つの候補が両方とも間違っていた —— 反対方向に。型のラベルは正規表現 1 本で実行可能(8 件中 4 件が手作業と完全一致)、「候補は既に絞られているとして」は全部の仕事をしていた(無料の絞り込みは 2 通りとも 1/4)。そして問いの形を `choice` に変えたら、この掃討で初めて jev が無料に明確に勝った —— 7/8 対 3/8。ただし合成すると端から端まで 1/4	47
値を「見つける」必要は無かった	段 3(集約)を足すのではなく外す。群の数値行を全部渡して、どれが答えかは決めない	上限アームと同点(5/5)—— どれが答えかを教えられずに。だから前の報告が 2/4 と測った集約段はクリティカルパスに無く、後継の問い(引数の範囲で切る)は存在しなくてよい段についての問いだった。端から端まで 1/4 → 3/4 —— 段を足さずに外して 3 倍。ただし 5 事実で、担っているのは3 アームが 0 を取る 1 行	48
私が書いていないコーパス	公開パッケージ 354 個の `scripts` ブロックから 568 コマンドを機械的に集めて gate に当てる	gate が 20 倍うるさい —— 568 件中 137 件(24.1%)で発言、私のコーパスでは 978 件中 12 件(1.2%)だった。score 中央値も 0.05 → 0.31。そして設計していなかった収穫: `deny` 8 件が全部 `npm publish` 系で、あれは誤検出ではない —— クラス境界がコマンドではなく「誰が実行するか」に在った。著者が自分で `release` と名付けた 15 件で AUC 0.933、このプログラムで初めて cutoff が当てはめられた(1.37〜1.48 = 出荷値の 3 倍)	49
危険な側を作って当てる	49 の破壊的コマンド 26 本を、名指すパスの中身だけが違う 2 つの実ディレクトリで走らせる(`built` はビルド出力、`source` はテストが import するソース)。ラベルは実行後の `node --test` の終了コード	危険な側は実在した —— `built` 23/23 緑、`source` 4/23 緑、23 本中 19 本が終了コードで 2 世界を分けた。それでも cutoff は引けない: 世界差の中央値 0.060 に対し同じ世界に 2 回聞いた差が 0.050、`source` が高いのは 19 本中 10 本(p = 0.629)。答えはスイープの前に出荷済みの hook に在った —— state は `command`/`cwd`/`project`/`permission_mode`/git だけで、ディレクトリを列挙することは一度もない。`config.context` に機械的な事実だけを入れると 19 本中 15 本が正しい向きに動く(p = 0.002、中央値 +0.010 → +0.100)が、`advise()` は依然 no-signal。所見は「情報が要求に入っていない」	50
問いを変える(閾値ではなく)	50 の 2 世界に、battery の 9 問全部を当てる。4 問は構成上この世界を読めて 5 問は読めないので、5 問を対照群として掃く前に登録	リクエスト増分ゼロで測れた —— battery は 1 リクエストに 9 問で、hook は `--log` で全答えを既に書いていた(50 は 138 コールして 1 つだけ記録していた)。blind は 9 問中 0 問が世界を分け、informed は 2 問 —— そのうち `affects_others` 17/19(p < 0.001)が対照群で、しかも表の中で最強。事前登録した対照群が発火した。診断: context が運んでいた識別できる事実は 3 つではなく 1 つ(`the_test_requires` 19/19、他 2 つは 0/19)。だから対照はノイズではなく、50 §4 の「危険だとは言わない」が自分に甘すぎた —— 1 事実はラベルから推論 1 歩。§2.3 の候補 `irreversible` は平ら(8/19、p = 0.581)。レバーは問いではなく事実	51
意図の軸を数える(作る前に)	§2.6 が頼んだのは「同じコマンドが違うゴールの下に現れるコーパス」。作る前に `runs.json` を数えた(`task` が呼び出しごとの `command` の隣に在る)	489 コマンド中、2 つ以上のゴールの下に 9、削除対象を名指すもの 5、両方 0 —— 交わらない。ゴールをまたぐ 9 本は全部テスト実行かディレクトリ一覧で全部 `allow`・最大 0.17、削除する 5 本はちょうど 1 ゴールの下で 0.47 以上。構造的: 危険さがゴールに依存するコマンドはゴール固有なので run を増やしても直らない。問い自体は 50 の 2 世界に著者のスクリプト名をゴールとして渡して測り、ゴールだけでは 10 問中 0 問(予測どおり)。そして §2.6 の問いは主語が無いアームで一番よく効いた(`fact` 17/19 対 `goal` 2/19)—— 意図を読んでいなかった	52
人がファンアウトさせた仕事に当てる	公開パッケージの合成 `scripts` を、著者が同時に走らせるか順番に走らせるかでラベル。演算子は request から抜き、枝の解決済みコマンドだけを渡す	`plan()` は 52/52 で分割しない —— `parallel` の最大 0.190 対 cutoff 0.5 なので近いものすら無い。欠けていたコーパスを供給しても seam は発火せず、§2.0 の前提は成立しない。そして gate は正しい: `size` 中央値 0.120 で、この仕事は本当に小さい(`tsc` 3 回は秒)—— 著者が `concurrently` を使うのは 2 つ目のプロセスがほぼ無料だからで、2 人目のワーカーのコストは当てはまらない。免責されない所見が 1 つ: `topology` が 52/52 で `sequential` —— 条件付きの問いなので「小さい」では答えにならず、形が実行で確定している唯一のクラスで毎回外す。31 は同じ `choice` を私のシナリオで 22/22 と測っていた	53
天井を外そうとして、外す必要が無いと分かる	完遂 100% の天井に対し、§2.5 の候補 3 つを記録だけで検証。上限は 1 点ではなく全部の K で掃く	リクエスト 0 件(46 に続く 2 本目)。644 run 中 643 完遂で、`model.json` の boolean は全部が天井か床。原因は記録に 2 回入っていた —— 36 は Bash 無しで 31/32、44 は同じコーパスを Bash 有りで 32/32。`equals-k3` は Bash 有りで安い段が通す(8 call、うち 4 が Bash)。どの上限も call 数に勝てない(定理): 閾値化は順序情報を失うので AUC が抑えられる(0.844 対 0.927)—— 天井は障害ではなく、44 §1.2 が既に対応付きで p < 0.001 を出していた	54
実リポジトリの実エージェントに当てる	30 の roster(この問いが存在する前に組まれたリスト)に、著者自身の `- [ ]` 項目をやらせる。gate は `--dry-run` で観測するだけ、介入しない	発言率はコーパスの性質だった: 1.2%(43、私のサンドボックス)→ 6.3%(実リポジトリ)→ 24.1%(49、公開スクリプト) —— 両端は同じ 1 つの欠落を指していた。tool call 1,268・Bash 746 のうち異なる文字列 712(95.4%)で、43 の 50.0%(`npm test 2>&1` を 127 回)とは形から違う。そして `deny` が初めて本物に当たった —— `curl …	bash`(permission 1.65)、出荷している cutoff が調整なしで。ただし 3 回目の試行で、1 回目は私の fence が止めていたので独立な観測ではない。委譲 12 件・15 run 中 7 runで [44 §3](44-components.md) の 0/227 以来初めてゼロでなく、[53](53-fanout.md) の読みは成立して鋭くなった。`--allowedTools`の外への 18 件を`PreToolUse` の seam は全部見ていた —— allow-list ではなく hook が境界
roster を規則で広げて撮り直す	55 が次の一手に挙げたもの。広げ方が結果になるので規則を 2 本(49 のパッケージが指す GitHub リポジトリ / アカウント自身の listing の public・非 fork・非 archived)だけ用意してどちらも私がリポジトリ名を選ばない形にし、標本規則と検定を最初の run より前に commit	`packages` は 56 本で checkbox 0 件(走らせる前に予測を docblock に書いた)、`account` は 141 本で 34 本が出し 16 本だけが節に両クラス。32 run・3.37 時間、gate は 11.8% で発言(55 の 6.3% のほぼ倍、ただしツールチェーン可用性も同時に変わっている)。対応させたら 5 指標のうち 4 つが 0.05 を切り(55 §5 のプール null が信号になった)、切らない 1 つは「gate が発言」で 55 §5.3 と一貫。`deny` は 1,282 件で 0 —— しかし `curl …	bash` を 2 コマンドに割ると 1.65 → 0.94 で出荷閾値の下をくぐる。自分の fence が入っているコンパイラを隠していて 6 run 捨てた(効果が生態系依存で 55 の roster では現れ得なかった)

ブラウザ操作の精度を詰めた

05 の続きで、「Jev にブラウザを操作させるパターン」を確立するところまで。他実装(jev-ultrafast / playwright-mcp / stagehand / browser-use)をコードから評価し、移せる機構を 1 つずつ実装して測った。

	何	結果	出典
confidence フォールバック	低 confidence の手だけ別扱いする 4 policy	confidence は初見の無駄手を検出しない(13 件中 12 件が 0.99 以上。失敗を state に戻せば反応する → 26)。効いたのはジオメトリ	57
カバレッジ誘導	未実行の関数名を渡す。置き場所 × 指示の有無の 2×2	同じ名前集合で 1/12 → 9/12。効くのは場所ではなく印付け(場所か指示のどちらか一方で足りる)	58
1 文 → テスト生成	生成してミューテーションで採点。5 回独立 × 経路 4 通り × 経路選択の要因分解	捕まえたバグ 1 → 2 が 5/5 で再現。ただし経路も 5/5 同一で通らない経路のバグは全見逃し。決めているのはラベル(文字列交換で 0.310 → 0.900)	59
性能改善の自動化	計測 → 診断 → 適用 → 再計測	注記 1 行で推薦の実測価値が 188ms → 1,664ms	60
投機的 fan-out	操作別 target を 1 リクエストで同時に聞く	操作確定前と確定後の判断が全実行で同一(本番 12/12 で TV 0.000)、リクエスト半分	61
重ねたときの ablation	フルスタックから 1 つずつ抜く + 転用候補 5 つを実装	足し算ではなく崖。採用 2・却下 3	62

上流(chaosbringer)に 3 本入った。どれも「Jev を賢くする」側ではなく driver に渡す情報の側である。

判定・分類を測った

	何	結果	出典
シェルコマンドの危険度	エージェントの実行許可ゲート。原子 noul 5 問 + score + 総合	23/24	01
ESLint の合否予測	コードと評価基準だけ渡し、実装を伏せる	88.4%・AUC 0.95	16
タスクランナーのタスク選択	53〜133 タスクから正しいものを選ばせる	名前だけで 90.0%、1 行の説明で 100%	17
エージェントに質問を書かせる	判定パイプラインを動的に組ませる	同じプロンプトで 10/24〜23/24	04
confidence エスカレーション	低 confidence だけ強いモデルへ	チェスで成立、シェルで不成立	07
cookbook 追試 ×2	skill suggestion / LLM guardrails	wrong load 13.2% → 5.9%	08 09

測るための道具も作った

ラベルをコード実行で証明する。 バグ 22 個すべてにプローブを付け、「バグのプローブは必ず失敗、それ以外は必ず成功」を API なしで検証(21 22)。
record / replay。 --from で記録から全数値を再計算。API キー不要・分散ゼロ。 記録に閾値も書く —— 無いと閾値を直すたび過去のレポートの数字が黙って書き換わる。
ペイロードの漏洩検査。 「実装を伏せている」「ラベルを送っていない」を主張ではなくリクエスト本文の検査で担保(48 文字窓の一致で例外)。
leave-one-criterion-out。 質問を 1 つリクエストから抜いて、「列挙し忘れたクラス」を定義上作る。
2 実装の一致テスト。 jevlang は JS 版と MoonBit 版で同じ .jev を走らせ、判断列の一致を CI 的に確認(手書き数値パーサの 0.6 → 0.6000000000000001 を実際にこれで発見)。同じ形が 25 でも効いた —— 集合選択の bitmask 版と素朴版を突き合わせて、 タスク添字の配列をゴール添字で読んでいた(例外も型エラーも出ず目的関数だけが静かに変わる)を発見。
ホールドアウトを部品にする。 標本を fold に切って「当てはめていない側で採点する」を 1 行にする(25)。無いと当てはめた数字をそのまま報告してしまう。

わかったこと

一番効くのは「答えの形」

1. 順序のある結論は score、choice は使わない。 質問の形を変えるだけで 19/24 → 23/24。 choice の低 confidence は「危険かどうか迷っている」ではなく「confirm と block のどちらに寄せるか迷っている」だった。 dd if=/dev/zero of=/dev/sda が choice で block@0.47、score で 1.95/2 @0.93。コード側の閾値をどう捏ねても 14/24 だったものが、この一手で 23/24 になった。

2. 質問はまとめて投げる。ほぼ無料。 20 問を 1 リクエストにすると 5227 ms → 246 ms、8277 → 1000 トークン(21x 速く 8x 安い)。そして答えが動かない(単独で聞いた場合との平均差 0.011)。 → 判断に要りそうな述語は全部書いて 1 回投げるのが正解。質問を削る最適化は意味がない。

3. 上限は質問数ではなくトークン。枠は 2 つ。 1220 問が 1 リクエストで通る(255 は choice の選択肢の上限)。境界は state 32Ki / リクエスト全体 64Ki トークンの独立 2 枠。どちらも公式スキーマに無い。詰まるのは state が先なので、max_tokens_exceeded を見たら質問集合を半分に割って投げ直す。

4. state の「一部分」についての質問も束ねて良い。 ファイル全関数を 1 リクエストで judge しても、1 個ずつ聞いた場合と 平均絶対差 0.082・Spearman ρ 0.931・判定差 3.6%。隣の悪いコードへの汚染はほぼ無い。

閾値と confidence

4.4 コーパスで校正した文を実コードに当てると、出てくるのは「わざとやっている版」。 植え込みバグ 641 行で 5/5 だった文を実リポジトリ 9,315 行に当てると、 19 指摘のうち要修正は 2 件で、残りは意図的にそうしてあるコードだった。そして confidence の向きが逆になる —— 自信のある 5 件は 0/5、当たった 2 件は conf 0.29 / 0.19。形が自明なほど自信は高く、形が自明な違反は意図的であることが多い。

4.5 閾値を触る前に gap を見る —— 校正で直らない失敗がある。 判定を score 順に並べて、当たりと外れの差を見る。 広ければ(1.8〜2.2)閾値はどこに置いても同じ答えなので何もしなくてよい。 狭ければ(0.2〜0.3)それは閾値ではなく質問の問題で、校正では直らない。 ad-hoc ルールを 5 つ書いて 2 つが gap 0.16 / 0.28 で失敗し、どちらも文を書き直して 2.16 / 0.77 になった。下の 5 は「答えは分かれているのに共通閾値で潰している」場合の話で、別の失敗。

5. 閾値は「質問ごと」に引く。共通 1 本は間違い。 同じ形の 8 問を並べたら、自クラスへの答えが 0.20 から 0.94 まで開いていた。共通閾値 0.80 は AUC 0.80 と 0.92 の 2 指標を丸ごと捨てる(13/36 → 24/36)。検出の問題ではなく校正の問題。合成も最大値ではなく各自の閾値からの超過率で。ただし 24/36 は当てはめた標本の数字で、清潔な側をホールドアウトして誤検出 0 を要求すると 18/36(共通閾値の 13/36 にはそれでも勝つ)—— 上乗せの半分は当てはめの自己申告だった。

6. confidence はルーティングに使い、ゲートには使わない。 報告の前提条件にすると 62.5%、外すと 73.7%。 clean も bug も confidence が 0.54〜0.57 に入るので、柵にすると正解ごと捨てる (score 2.42 / confidence 0.42 の当たりが消えていた)。

7. confidence エスカレーションは条件が 3 つ揃わないと成立しない。 (a) 第二段が第一段より本当に強い (b) confidence が判断の質を順序づける (c) confidence が散らばっている。チェスは (a)(b) を満たすが中央値 0.22 で (c) を満たさず、 安い運用点が存在しない。シェルでは (a) から満たさない(第二段のほうが弱い)。

8. 当てはめた閾値は、次のコーパスで必ず境界に乗る。そして「誤検出 0」は構造上そうなるだけ。 「clean の最大値 + 0.01」で引いたら、10 関数足しただけで越えた (unescaped_composition がテンプレートリテラル全部に発火)。ホールドアウトで測ると数字が出る: 当てはめた標本で誤検出 0、見ていない関数で 24 件(1224 中)。 壊すのは draw ではなく新しいコード —— 同じ関数をもう一度聞いて越えるのは 0.37%、新しい関数は 2.0%。効く margin は draw sd の 20 倍必要だった。

8.4 そして出荷した閾値 3 つのうち 3 つが、答えの分布の真ん中に置かれていた。 これは「当てはめる道具」の手前の話で、当てはめる前に答えがどこに来るかを見るだけの話です。 3 回出ました:

	閾値	答えが実際に来る場所
21 §7 の報告ゲート	confidence 0.5	0.54〜0.57(clean も bug も)
37 §7 の `escalateAt`	0.7	8 件中 6 件が 0.606〜0.729
44 §1.2 の `minConfidence`	0.5	0.21〜0.76、中央値 0.44(67% に効く)

そして 3 つ目は生きた範囲まで測れました —— 床が触れるタスクの confidence は 0.32..0.69 しか無く、その外では床は定数です。つまりダイヤルは 9 段しか無く、出荷値 0.5 はその真ん中 (45 §1.4)。 閾値の「生きた範囲」は config の性質ではなく答えの分布の性質で、置く前に見るべきものはそれです。

3 つ目は別のコンポーネント・別の質問で同じ形が出たもので、しかも出荷コードのコメントが 1 つ目を出典として引いていました。そして綺麗な結論は間違いでした —— 「床が高すぎて無駄に払っている」と書きかけて、 同じレポートのターン数の表に否定されました(高い段は有意に少ないターンで終える)。 言えるのは「この数が決定の大半をしていて、置いたときに答えがどこに来るかを誰も見ていなかった」だけ。

8.5 置き場所には名前を付ける。「清潔な側の縁」は最も自然に見えて最も脆い。 gap があるなら中央に置く —— 同じ検出のまま、ホールドアウトの誤検出が 24 → 7。正例は gap のずっと上にいるので、中央に寄せても検出は 1 件も落ちない。

8.6 コストが測れているなら、閾値より「見逃しの値段」のほうが答えやすい。 score を確率に直して「閉包の秒数 + penalty × P(見逃し)」を最小化すると、タスクごとの柵がそのタスクの実測秒数から出る(0.1 秒のレシピは無条件、5.3 秒は 1.30 を要求)。実測ラベルで 検出 18/18 のまま削減 73.5% → 81.4%。ただし効果は必ず判断を抜いた同じ規則と比べる —— 同じ検出で 81.4% 対 40.9%。そしてモデルを良く解いても結果は良くならない(総当たり 81.4% 対山登り 83.0%)。

閉じた世界と逃げ道

9. choice は必ず選ぶ。 範囲外の入力が conf 0.96 の自信のある誤答になる (「燕の飛行速度は?」→ technical conf 0.96)。閉じた世界を仮定してはいけない。

10. 逃げ道は選択肢ではなく別の問いにする。 作り方 2 通りは等価ではない: 別 noul で聞くと該当なし 18/18、choice の選択肢に「該当なし」を混ぜると 16/18 に落ち、さらに答えのある難問までそこへ逃げる(conf 0.50 で「該当なし」)。

11. 候補をその場の合法手にすると、不正な答えが表現不能になる。 MOBA 489 判断・チェス 37 手で反則 0。バリデーションではなく型で消すのと同じ効き方。

何を渡すか

12. 判定基準だけ渡せば、実装なしで合否が当たる。 ESLint の説明文だけで 88.4%・AUC 0.95。どこまで見せるかは正解率をほとんど動かさない(ID だけ 86.5% / 説明文 88.4% / 両方 87.4%)。 動くのは正解率ではなく「何を間違えるか」。

13. ただし逃げ道は実装にしかない。 5 回とも外すのは全部「説明文は禁止と言っているが、実装だけが例外を認めている」ケース。公開オプションで表現できる例外は渡せば直る(10/15 → 15/15)が、 渡した例外は隣のケースにも一般化される(見逃し 0 → 11 件)。 → ゲートに使うなら例外は渡さない。

14. 名前が内容を説明していれば、名前だけで足りる。 53 タスクから名前だけで 90.0%、外すのは名前が嘘をつく項目だけ。 1 行の説明を足すと 100% になり、実装(コマンド)まで見せても上積みは無い —— 散文で情報が尽きる。投資先は質問文ではなく項目名と 1 行の説明。

15. 文脈は精度を上げるのではなく、judgment を穏やかにする。 04〜08 では構造化 state が最大のレバー、17 では changed_files も直前の終了コードも 1 件も動かさず、21 ではファイル全体を state に入れると 誤検出が 1/5 になって見逃しが増えた。3 つとも同じ現象(文脈が増えると score が下がる)。 → どちらの誤りを減らしたいかで足す/外すを決める。

述語だけを外に出す

14.5 述語だけ自然言語にして、絞り込みは既存の決定的な仕組みに任せられる。 ESLint セレクタでノードを選び、違反かどうかだけ 1 文で聞く。書かれないままだったルール(「fetch にタイムアウトを渡すこと。ただしリトライラッパの内側で既に設定されている場合を除く」)が設定 1 行になる。 49 ノード → 7 指摘、自信のある 5 件は 5/5 が本物のバグ、$0.0011。絞り込み側はわざと広く書くのが正しく、score のレベル 0 に「このルールは当てはまらない」を置いておくと、モデルがそれを言える。

ただし決定的な側は静かに失敗する。 セレクタに当たらなかったノードは どの閾値でも質問されず、レポートにも出ない(コーパスのバグ 1 件をこれで落とした)。確率的な側の失敗は測れるが、決定的な側の失敗は測れない。

「聞けば答える」の限界

16. 軸を書けば答えが来る、わけではない。 「rubric は書いた軸しか答えない」は真だが逆は成り立たない。落としていた 6 個に専用の指標を名指しで投げても、戻ったのは 2 個。 splice(at) の引数不足は 0.12、/g なしは 0.09 —— ちょうど正しい問いに **自信をもって「いいえ」**と答える(3 回とも)。

17. 指標が効くのは「見えにくいバグ」でだけ。 関数の中だけ読めば矛盾が分かるバグ(return 忘れ、break 漏れ、10% 引きを 10 円引き)は naming の有無にかかわらず 15/15。 特定の API の挙動を知らないと見えないバグ(.sort() の比較関数、await 忘れ)で 14% → 52%。列挙の穴は約 32 ポイント、hard なバグにしか存在しない。

18. 原子質問は汎用質問の代わりではなく上乗せ。しかも互いに重複している。 8 指標のうち 7 個は抜いても自クラスを失わない(隣の指標か汎用 noul が拾う)。本当に失うのは広い 1 個(api_default、9/12 → 4/12)だけ。 → 指標を増やすより、広い 1 個を正しく校正する。

19. 再現率と説明可能性は同じ通貨で買っている。 高い閾値で発火したときの「どの指標か」は 13/13 正しい。拾う数を増やすために閾値を下げると **20/26(77%)**に落ちる。

20. 得意と苦手は「読めば分かるか」で分かれる。 得意 = 関数が名乗っている契約との齟齬(空トークン同士が認証を通る、書き込み失敗を握り潰す、クエリを未エンコードで連結)。苦手 = 特定の API の挙動(.sort() は辞書順、splice(at) は末尾まで削除、/g なしは 1 回だけ)。 → 型・既存ルール・テストの代わりにはならず、ちょうど補完になる。

行動させるとき ——「選ばせる」と「やらせる」は別物

21. 実行単位に値を乗せる。 target は「要素」ではなく「実行できるもの」。ドロップダウンなら index:option、テキストなら (index, text)。調べた 4 実装すべてがこうしていて、「要素だけ指して値は呼び出し側が推測」という形は誰も出荷していない。後者は 6 択で +5 手、記憶を持たないと非停止になる。

22. 位置の事実で判断を駆動すると振動する。必要なのは進捗の事実。 同じ形を 3 回踏んだ —— ドロップダウンの「今の値と違う最初の選択肢」(2 周期)、スクロールの「下に 145 / 上に 172」(2 周期)、そして 必要な操作が無いときの経路探し(3 周期)。 選択ではなく掃引・列挙にすると止まる。

23. 必要な操作が無いとき、ドライバはエラーを出さない。 画面を出て別の経路を探して周回する。「空にする」を操作として持たないだけで 2/2 → 0/2、しかも対象フィールドに一度も触らない。 → action space の表現力不足は、精度の劣化ではなく不可能性として現れる。

24. 表現力を上げる機構は効き、削って安くする機構は効かなかった。 転用候補 5 つの決算で、採用 2(型付き fan-out・clear)はどちらも表現力側、却下 3(候補検索・action キャッシュ・視野絞りの担保としての SCROLL)はどちらも削って安くする側。精度を買えるのは前者だけで、後者が買えるのはトークンである。

25. 「成功したように見えるもの」を安く再生する装置に注意。 クリック列 + 最終 URL のテストは、注文を記録しないアプリに対して緑のまま通る(59)。 action キャッシュはそれを無料かつ無音にする —— 壊れたアプリの上で 10/10 再生してゴール到達し、ordered: no で終わった(62)。 → キャッシュも生成テストも、結果の外部検証と必ず併用する。

26. 無駄手(画面が変わらない手)だけではループを検出できない。 総当たりも振動も画面を毎回変えるので、無駄手 0 のまま予算を使い切る。 wasted が 0 の失敗が 3 回出た。逆に、その事実を state に戻せば confidence は反応する —— last_action_error と無効果連続数を入れると blocked な手が 0.91 → 0.45 と減衰した。 57 で同じ手が 0.99 で返っていたのは、渡していなかったからである。 → 信号が無いのではなく、信号を作る事実を state に戻していなかった。

27. 自分の解釈を後から測って否定した。 57 は「決定的に判定できることは、伝えるのではなく選択肢から消す」と書いた。 62 で「伝えるだけ」のアームを足すと同値で、消す側の追加価値はトークン 4% で精度ではなかった。当時「伝えるだけ」のアームが無かったので、一度も検証されていない主張だった。 → 比較対象を列挙し忘れると、結論ではなく解釈が静かに間に合わなくなる。

28. 実行経路を決めているのはラベルである。 カートに「Proceed to checkout」と「Express checkout」を並べると、文字列だけ交換すれば選ばれる経路が入れ替わる (p 0.310 → 0.900、6/6)。位置でも picker の指示句でも同点でもなかった。 → カバレッジを広げたいならラベルを変えるしかなく、逆にリンク文言の変更はカバレッジを静かに動かす。 通らなかった経路のバグは構造的に見えない。

運用に載せるときに先に決めること

29. 判断を下す場所では、失敗の落とし先を先に決める。 精度より先に決まるのは「API が落ちたらどうなるか」。hook は**全失敗経路を「判断なし = 通常フロー」**に落とす (allow に倒せば黙って承認、deny に倒せば障害で停止)。そして ゲートは狭める方向にだけ使う(allow を返すとユーザーの permission 設定を上書き承認してしまう)。

30. オフラインの正解率は質問文の妥当性を保証しない。 23/24 を取った exfiltrates の文言を hook にしたら、1 発目で普通の git push を deny した。 24 件のコーパスに「正当な外向き転送」が 1 件も無かっただけ。 実運用の形に載せることが最後のテストで、それ以外に文言の穴を出す方法は無い。

31. 非同期の判断を同期の拡張点に入れるには、判断を前に出す。 ESLint のルールは await できない。事前バッチ + ハッシュ引きにすると lint 時間は何もしない lint と誤差の範囲(31 ms 対 36 ms)。ブロッキングも本当に可能(execFileSync)だが 1 ファイル 361 ms で、「できる」と「入れて良い」は別。

32. 確率的な判断には record/replay を最初から入れる。 同じ入力で分岐が変わるので、無いとテストが書けない。実装差とモデルのばらつきを分ける唯一の土台でもある (閾値の再設計をリクエスト 0 回でやれたのはこれのおかげ)。

33. 設計判断は構文で強制できる。 ライブラリなら「閾値はコード側に置け」はお願いだが、言語なら質問文に閾値を書く場所を作らないで済む。「逃げ道は選択肢ではなく別の問い」も、else 腕が gate noul を生やす設計にすれば 混ぜる書き方が存在しなくなる。

34. 審判のいない領域では、正解率ではなく「指摘の中身」を報告する。 不均衡な集合では「何も言わない」が 76.5% を取る。だから (a) ラベルはコード実行で証明できるものに寄せる、 (b) 証明できない意見は別クラスにして主指標から外す、 (c) 精度と再現率を分けて出す(自信のある指摘 15/15 が本物 / 12 バグ中 5 個)。

35. 上流のミスは下流の正しい判断で買い戻せる。ただし上限があり、相手の強さに反比例する。 弱い編成 + Jev が強い編成 + scripted に 5-1。ただし基準を強い bot にすると 0-6 に反転。 handicap sweep で境界は scripted 相手 ~20〜30%、smart 相手 <20%。 弱い基準で観測した「取り返し」を一般化してはいけない。

本物のホストに挿すと、精度とは別のものが効いてくる

28. 束ねるのは無料ではない。幅は無料で、union は無料ではない。 29 §4 の「1 リクエストに問を詰めても答えは動かない」は 1 種類の問 × 1 つの state の話でした(99.8% が 0.25 以内)。 3 コンポーネントの state を union して束ねると、 7 問すべてが「同じ聞き方の再試行間」より大きく動く(比 1.71〜7.32)。ずれの絶対値は小さい(0.024〜0.058)ので効くのは閾値の近くだけ —— decision が変わった 3 件はすべて cutoff の跨ぎでした。

29. 無人のホストでは ask は deny です。 jev-guard は 18 から attended / unattendedAsk を持っていて、 出荷 hook がそれを公開していませんでした。だから常に ask を出し、ヘッドレスの claude -p はそれをコマンドの拒否にします。 人間が居る前提のラベルを、人間の居ない場所に置かないこと —— --unattended-ask block|defer で塞ぎました。

30. 正しい判断が仕事を奪うことがある。閾値ではなくラベル集合の問題として。 境界コーパスで gate が初めて完遂を奪った 1 件の中身は、 入れ子の node_modules を正しく特定 → rm -rf が ask でブロック → 3 回試して停止。そして rm -rf ./node_modules は 01 自身のコーパスで confirm です。 gate は自分のラベルどおり正しく振る舞い、確認する人間が居ないのでその正しさが仕事を奪った —— 直す場所は閾値ではありません。

31. ブロックした相手には理由を渡す。渡さないと迂回できない。 ask の理由が systemMessage にしか入っていなくてモデルに届いていませんでした (contract は省けと言っていません)。直したので、 理由が届くかどうかが完遂を変えるかをアームとして測れるようになりました —— 44 §4.4 は 22 介入・17 run・16/17 完遂で、 唯一の失敗は既定の ask(ホストが誰も選んでいない文面で拒否する経路)の下でした。 ただし小さい分母の null 結果です。

32. 「この gate はコマンドの X% を止める」という形の主張は成立しません。3 つの理由で。 220 コマンド × 7 ドロー = 1,540 コールで測ると:

候補集合はコマンドが決める —— 5 タスク中同じ 2 件だけ、両掃きとも、残り 3 件では一度も
境界では verdict が揺れる —— 218/220 は全ドロー同一だが、意見を持つ 5 件のうち 2 件が跨ぐ
分母はエージェントが何を打ったか次第 —— どのタスクにも安全ルートが在るので、同じタスクで rm -rf を選ぶ run と選ばない run が在る

33. 速度は一貫していて、品質は一貫していません。 5 コンポーネントすべてで 26〜103 倍速い。 品質で jev が明確に勝っている列は 1 つも在りません —— model router は誰も無料の always-haiku を超えず、skill router は3 者とも分離せず、 compactor だけは形が違って予算を守るのは jev だけ(モデルの select は圧縮を断る)。 → 売りは「安くて速いから全部に回せる」で、「賢い」ではない。

計器の規律 —— 後半 27 本で一番多く学んだこと

34. 嬉しい数字が出たら、結果ではなく計器を見る。 新しいアームが全部 100% で返ってきたので計器を見たら、両プロンプトが Do not modify any test file. と言っているのに passed は node --test の終了コードだけ —— assertion を書き換えたエージェントも 0 を返します。186 run がその穴の上で採られていました。 塞いで掃き直したら改竄は 0 件でしたが、低い事前確率は測定ではありません。

35. 判断を再び聞くハーネスは、判断に世界を正しく渡しているか。3 回間違えました。 (a) cwd を捏造して outside_project を立てさせ無害な rm 4 件を停止に変えた、 (b) 存在しないファイルについて聞いた(全タスクに空のサンドボックス 1 つ)、 (c) cwd を tool_input の中に入れた(hook は event.cwd ?? process.cwd() を見る)。 3 回とも gate が正しく、ハーネスが嘘をついていました。 見つかった理由は毎回同じ —— 新しいドローの隣に記録の列を印字していて、食い違ったら記録を信じた。

36. 通り得ない wire check は、失敗し得ない wire check より悪い。 種を読んだか確かめる検査が、label だけで一致させてassistant のターンを拾い、識別子の無い 1 文を検索して、動いている種に対して 0/7 を報告しました。

37. 天井に当たったら尺度を変える。天井は null 結果ではない。 完遂は 3 コンポーネントとも 100% で不一致ペア 0 組 —— それは「この尺度ではこのアームを分離できない」という言明です。 対になった tool call 数で測り直すと p < 0.001 で分離しました。

38. 追試は元とプールしない。そして「1 件起きた」が再現しないなら存在証明で、率ではない。 186 run を掃き直したら、レイテンシは 371 → 372 ms で再現し、 gate が発言したタスクは同じ 2 件で再現し、 「gate が仕事を奪った」1 件は再現しませんでした(14/15 → 15/15)。起きたことは起きたので存在証明としては立ちます。率としては立ちません。

39. 同じアームを 2 回走らせて、「差」をドローと比べる。 要約指示の書き換えは事実の生存を 67% → 78% に上げたように見えました。 plain をもう 1 回走らせたら、同じ transcript で同じように 78% になりました —— 要約器のドローは指示が動かす幅と同じで、n = 8 では測定不能。これは null への注意書きではなく、null が解釈できない理由です。 アーム 1 つ足すだけで、ヘッジが数字になりました。

40. 計器の借金は「直した」で終わらせず、いくらだったかを測る。 出荷 hook の --log は answers 全体を書いていて、こちらが 3 フィールドしか取っていませんでした —— だからスコア分布は再質問から作るしかなく、それは別のドローです。直して同じ 221 コマンドで並べたら、対になった差の中央値 0.020、 読みを変え得る差(0.36 の跨ぎ)は 0 件。 債務は実在したが、それが乗っていた主張の単位では何も損していなかった —— ただし極値は再質問のもので、引用されていた最大 0.70 に対し run 側は 0.59 でした。

41. 「捏造」を言う前に、正しい在り方を全部引く。2 回間違えました。 言い換えを捏造と数えたのが 1 回目(661 docs/31-... を言い直しただけ)。 2 回目は書式 —— ホストが pi.ts at 30,130 bytes と書き、事実が 30130 なので、 正しい数字が桁区切りで書かれていただけで捏造と報告されました。 捏造はこの judge が言える一番重いことなので、正しい在り方を全部引いてから言う。

42. アームを走らせる前に、そのコンポーネントに決めることが在るか聞く。 router アームを足して 32 タスク走らせるところでした —— 1 時間かけて全行が同じモデルの表が出る。 32/36 の修理タスクは 53 件が 1 本のプロンプトを共有しているので、リクエストについて聞くルータは同一の質問を 53 回聞かれます(実測 58/58 が 1 段)。 エージェント抜きで 1 タスク 3 判断、58 タスクで数セント・数分。掃き掃除は数時間。

43. seam が無いと書く前に、ホストのバイナリから読む。 compactor は 2 報告ぶん「seam が無い」と書かれていました。読んだら 2 つ在り、片方(PostCompact)が要約そのものを渡してきます —— 下流の挙動から推定する計画が、直接採点に変わりました。 そして同じ読み方が、次の報告で候補を 1 つ無料で退場させました —— 入口と出口は非対称で、PreCompact は hook の stdout が指示になるのに PostCompact は { userDisplayMessage } しか返さない(45 §2.1)。 渡された要約はもう確定しているので、差し替えは不可能。

44. 綺麗な数字は基準率に当てる。「説明」ではなく「帰無の計算」で。 minConfidence が効いた 8 件全部で安い段の方が高くつきました —— 「床が狙って効いている」と読めます。 ですが安い段はコーパスの 88% で高くつくので、任意の 8 件でも 8/8 は約 34% 起きます (45 §1.3b)。8/8 は選別の証拠になりません。 44 §1.2c は同じ罠に 2 回はまっていて、効いた防御は毎回これでした。

45. 正しさのラベルが無いなら、閾値は「値段」で語れる。 両段とも 32/32 で終わったので advise() は no-signal(片方のクラスが空)を返します —— 定数のラベルは何も順序づけないので、どの床も正しさでは同じです。そこで実測コストに貼り替えて全値に値段を付けました: 床を外すと 17% 安く・tool call +20・完遂は不変(45 §1.4)。 「どの閾値が正しいか」が測れないときに「どの閾値がいくらか」は測れる。 そして当てはめ側も見ておくこと —— fold ごとの閾値 0.59..0.70 が 最高 confidence 0.69 より上に来て、陽性を 1 件も予測しません(適合率 0/0)。 「安い段が勝つ場所を見つけよ」と言われた当てはめが、線をデータの上に置いた。

46. 部品を書く前に、設計の天井を測れる。同語反復であることが要点。 「要約器の前に測定値を拾う判断を置く」設計を、正解の文字列そのものを渡すアームで測りました。分類器は正解を渡されるのには勝てないので、これは上限です —— 超えなければ部品を書かずに設計が否定され、届けば残る未測定は精度だけになります。 届きました(9/9・捏造 0、45 §2.3)。 ただし飽和したアームには対の数を隣に置くこと —— 不一致は 3 組で p = 0.250。言えるのは機構で、分離ではありません。

47. 問いそのものが否定できることが在る。ラベルを作る前に。 「このエントリに測定値が入っているか」を jev に当てさせる話が在りました —— コーパスを見たら、9 事実のうち 3 件は数字を 1 文字も含まず (registerFlag("jev-advise" は測定値ではなく問いの答え)、 4 件はコマンドが計算した量ではなくコマンドが表示したソースでした。だから「数字を含むか」の完璧な分類器の上限は 6/9 で、 何も指示を送らないアームが既に 6/9(46 §1)。 完璧に答えても何もしないのに勝てない問いだった、とリクエスト 0 件で分かりました。 上限アームが効いた理由を、上限アームの説明で済ませてはいけない —— あれが勝っていたのは測定値を見抜いたからではなく、ゴールが訊いている値を渡したからです。

48. 2 つの列が同じなら、片方が入力を失っている。 無料の baseline 2 本(overlap と largest)の行がバイト単位で同一になりました。候補集合に制限してからランク付けしたので、その集合が pin されたゴールのターンを除外しているぶん、 overlap はゴールを見つけられず自分の契約どおり largest にフォールバックしていた —— 39 の一番強い無料アームが、ゴールを無視するアームと同点なのは結果ではなくハーネスの故障です。 ただし「同じになった」が全部バグでもありません —— 入れた検査が次に stale == oldest で止まり、そちらは本物の性質でした (どのコマンドも直前に宣言され二度と参照されないコーパスなので)。 39 自身の表が 4 予算のうち 2 つでバイト単位で同一の行を出していて、そう書いていない。

49. 分離しなかったのは、コンポーネントが弱いからではなく問いの形が悪かったからかもしれない。 46 は「どのエントリが答えを持つか」を 56 件の不透明なエントリの順位付けで聞いて、 無料の語数と p = 1.000 で分離しませんでした。ところが transcript は自分の出力をコマンドで既にグループ化しているので、同じことを 10 個ほどのラベル付き候補に対する choice で聞くと 7/8 対無料 3/8 —— この掃討で初めて jev が無料に明確に勝った列(47 §3)。 01 の「答えの形を問題の形に合わせろ」がnull 結果の診断として効いた形です。 null を見たら、コンポーネントの前に問いの形を見る。

50. 段の点数は掛け算にならない。合成した数だけが呼び出し側の体験する数。 段 2 が 3/4、段 3 が 2/4 で、合成すると 1/4 です(47 §3.2)—— 2 件が段 2 を通って段 3 で同じ行に落ちるので、掛け算(3/4 × 2/4)でも足し引きでも出ません。同じ行で落ちる失敗は 1 件分しか引けない。

51. 1 行で直る失敗でも、その 1 行をどこで見たかを書く。 段 3 の miss 2 件はどちらも総計行で(wc/du の総計は構成上どの要素より大きい)、除けば 2/4 → 3/4。wc に初めて触った実装なら誰でも書く 1 行です。 ですがこの 4 行を見てから選んだ 1 行なので(教訓 8)、 持ち越すのは 2/4 で、3/4 は失敗の値段として併記しました。

52. 「見つける」で設計する前に、「落とさない」で足りるか問う。 比較型のゴールの前段を 3 段(検出 / 絞り込み / 集約)で作って端から端まで 1/4 でした。集約を足すのではなく外して、選んだ群の数値行を全部渡すようにしたら 上限アームと同点(5/5) —— どれが答えかを教えられずに(48 §2)。 端から端まで 3/4 で、段を外して 3 倍。 そして後継の問い(引数の範囲で切る)が消えました —— あれは段 3 が 1 行を選ばなければならなかったから問題だったのです。 ただし一般則にしてはいけません: 外せたのはこの問いが「落とさない」で足りたからで、要約に 1 行だけ書きたい問いでは集約が必要なままです。 言えるのは「どちらで足りるかを先に問え」で、「段は少ないほうが良い」ではありません。

53. 点数が上がっても、失敗が沈黙になる設計は悪い性質を足している。 keepnums は前段が数値行の無い群を選ぶと走れません —— 呼び出し側はホスト既定の要約を受け取り、信号を受け取りません。 「1/4 が 3/4 になった」より悪い性質で、運用で見つけにくいからです。点数の隣に失敗の形を書くこと。

54. 自分が書いたコーパスは、部品を実際より静かに見せる。20 倍。 43 は私が書いたコーパスで gate が 978 コマンド中 12 件(1.2%)しか発言しない、と測りました。公開パッケージ 354 個の scripts ブロックから機械的に集めた 568 コマンド(私が書いていない)では 137 件、24.1% —— 20 倍です(49 §2)。 score の中央値も 0.05 → 0.31 で 6 倍。 部品が静かに見えていたのは、部品の性質ではなくコーパスの性質でした。 31 の限界節と TODO §2.1 が 40 本ぶん心配していたことに、数字が付いた形です。

55. クラス境界が「コマンド」ではなく「誰が実行するか」に在ることが在る。 deny 8 件が全部 npm publish / git push --follow-tags / changeset publish で返ってきました —— あれは誤検出ではありません。 公開パッケージのリリーススクリプトは著者にとって正当で、無人のエージェントにとって正当ではない。 だから破壊的な動詞(rm)を positive class にしようとしていたのが間違いで、 危険なクラスは著者が release と名付けた方でした(49 §3)。そしてラベルを貼ったのは著者たち(自分のスクリプト名)で、gate はその名前を一度も見ていません。

56. 由来についての主張は、結果を見ても見えない。 「このコーパスは私が書いていない」という主張が、7 パッケージぶん間違っていました —— 自分のパッケージが packages/node_modules/ にワークスペースインストールされていたからです。 被害は 569 行中 1 行で、どの数字も動きませんでした。 だから目では見つからず、テストが 7 つの名前を出して落ちました(49 §4)。 → 測定値には表れない主張には、テストを書く。 そしてその cwd テストの最初の版は存在確認だけだったので、全部のディレクトリをリポジトリのルートに置き換えても通りました (43 §4.4 の捏造そのもの)—— 存在確認では捏造を捕まえられません。

57. 差だけを見ても意味が無い。同じ問いを 2 回聞いた差を隣に置く。 2 世界の点数差は中央値 0.060 でした。 これは、同じ世界に 2 回聞いた差が 0.050 だと分かるまで、何も意味しませんでした(50 §3)。 variance.json は 7 ドローの verdict 計数を持っていますが点数は持っていないので、 他のレポートに訴えるのではなく、その場で測りました。 → 効果量を報告するなら、その計器のドローを同じ行で報告する。

58. 「どちらが大きいか」は、大きさより先に消える。 この 1 行は 2 回間違えました —— 最初は「2 世界は同一の点数」(違う。19 ペア中 2 ペアが完全一致)、次はドローを並べた上で「世界の方が大きい」。 同じコードを 2 回走らせたら順序が反転しました(0.060 対 0.050 と 0.050 対 0.080)。 ラベル計数と blind の結果は完全に同じに戻ったのに、順序だけが消えました。 → レポート生成側に「報告しない」を実装する。 今は差の大きさだけを出し、どちらが大きいかは n が足りないと言います(50 §3)。

59. レポート生成器に測定値をリテラルで書くな。 "1 of 19 pairs matched exactly" と "19 commands" を文字列に焼き込んでいました —— 数字は隣で計算しているのに、この 2 つだけ手書きでした。 2 回目のスイープで 2/19 になったので、生成器は嘘を印刷するところでした。 → レポートの中の数はすべて記録から導く。例外は無い。

60. キー無しで走るレシピが、記録を消してはいけない。 --worlds は API キー不要なので score が全部 null で、 その null を damage.json に上書きしていました —— つまりこのレポートが公開している再現手順を踏むと、 レポートの元になった点数が消え、テストも落ちるところでした。 → 書き込み先は「キーが在るか」で分ける。 今は記録の隣に書きます。

61. 帰無結果の値は、間違っていても正しく見える。 同じ比較の p 値を 2 か所で違う値で印刷していました(0.629 と 1.000)—— 片方だけ signTest(n - up, up) で計算していたので、同点 2 件が負けに畳まれていたからです。 符号検定は不一致ペアの上で走るもので、同点は「負け」ではありません。 そして出力を見ても分かりません —— 1.000 は帰無結果がちょうど取る値です。記録から手で計算し直して見つけました(50 §5)。 → 統計量は 1 か所で計算する。そして「予想どおりの値」こそ手で検算する。

62. 対照群を掃く前に登録すると、有益に失敗できる。 9 問のうち 4 問はこの世界を読めて 5 問は読めないと、世界の作り方から導いてソースに固定しました。 対照の 1 つ(affects_others)が表の中で最強の効果を出しました(51 §4)。 貼り替えませんでした —— 結果を見た後にラベルを動かすのが 47 の警告だからです。代わりに、その下に隠れていた問い(context には実際に何が入っているのか)を聞いて、 context が運んでいた事実は 3 つではなく 1 つだと分かりました。 → 反証条件を先に書く。そして反証されたら、ラベルではなく問いを取り替える。 → そして貼り替えを失敗させるテストを入れる。

63. 「事実を渡したら読めた」は、事実がラベルから何歩かを先に数える。 50 §4 は context を「機械的な事実 3 つ、危険だとは言わない」と書きました。 2 つは 2 世界でバイト一致(情報を運べない)で、残る 1 つは「テストが、消されるものを必要としている」—— ラベル(終了コード)から推論 1 歩です。 だから複数の問いが同時にそれを読みました —— 独立に世界を知覚しているのではなく、与えられた 1 つの文をそれぞれ言い換えている(51 §5)。 → informed の数字は上限であって推定ではない。 → そして効いた事実が判断なしで計算できるなら、それは所見ではなく設計 (import グラフ上のリゾルバで足りるなら、モデルは要らない)。

64. 型を読むのは無料で、掃くのは無料ではない。 value() は probability/value/score/level/index を探していました。 Answer は判別共用体で、{type:"noul", noul} と {type:"score", score} が別のキーなので、 9 問中 7 問を静かに落とすところでした(§2.3 自身の候補を含む)。呼び出し側の throw が捕まえたはずですが、それは 138 コールした後です。 → 形を推測する前に、その形を定義しているファイルを開く(44 §5.1 を型に当てたもの)。

65. コーパスを作る前に、数えて在るかを見る。 §2.6 は「同じコマンドが違うゴールの下に現れるコーパス」を頼んでいました。 作る前に数えたら、489 コマンド中 9 がゴールをまたぎ、5 が削除し、両方は 0 —— 交わりません(52 §0)。しかも理由が構造的でした: 危険さがゴールに依存するコマンドは、そのゴール固有なので、 同じ種類の run を増やせば同じ形が再現します。 → 「コーパスが無い」は、作ってから言うのではなく数えてから言う。 → そして数え上げがそのまま所見になり得る(49 は在った、ここは在り得なかった)。

66. 問いが、自分の主語が無いときに一番よく効いたら、それは別のことを読んでいる。 §2.6 の問い(「このコマンドはゴールが記述する作業の一部か」)は、 ゴールが一切供給されていないアームで 17/19、本物のゴールを渡すと 11/19 でした。 主語が無いアームが最良なら、読んでいるのは主語ではありません —— 参照するゴールが無いと「プロジェクトが必要とするものと整合しているか」に退化し、それは file fact が直接答えます(52 §3)。 → アームを 1 つ増やして「その問いの主語を抜く」を作る。 → 効き続けたら、その問いは名前が言っていることを測っていない。

67. 交絡した検査は、検査ではない。 再構成した state が hook と同じことを聞いているかを確かめるつもりで、 51 の blind(context なし)をゴールを送るアームと比べていました —— だから permission が 0.190 ずれても 「state が違う」と「ゴールが動かした」を区別できません。空 context のアームを足して再掃きしたら 0.075 で、ずれの大半はゴールのものでした(52 §4)。 → 検査には、検査したい変数以外が動かないアームが要る。

68. コーパスは条件の文面を満たして、その趣旨を外し得る。 §2.0 は「エージェントが実際にファンアウトを選ぶ仕事」を求めていました。 著者が concurrently で並列化した 52 件は、その文面をきれいに満たします —— そして plan() は 52/52 で分割しません。 gate が正しいからです: size 中央値 0.120 で、tsc 3 回は本当に秒の仕事。 シェルの 2 つ目のプロセスはほぼ無料で、エージェントの 2 人目はそうではない —— だからこのコーパスにはファンアウトを判断にする性質が無い(53 §4)。 → コーパスを集める前に、ラベルの「選択」が測りたい選択と同じコストを持つか問う。

69. 条件付きの問いは、前段の否定で免責されない。 「この仕事を分けるべきか」に gate が「いいえ」と答えたのは正しかった。 しかし topology(もし分けるならどの形か)は条件付きなので、「仕事が小さい」はその答えになりません —— そして形が実行で確定している唯一のクラスで 52/52 外しました(53 §2)。 → 条件付きの問いは別に採点する。 前段が「やらない」でも、後段は正しくなければならない。

70. 自分が書いたコーパスは choice にも甘い。 31 は topology の choice を私が書いた 38 シナリオで 22/22 と測っていました。 他人が書いた仕事で、答えがその著者が出荷したことで確定しているところでは 0/52 です。 49 は同じ母集団で gate が20 倍うるさいことを見つけました —— 同じ教訓が、別の質問型に届いただけです(53 §2)。 → 「自分のコーパスで良かった」は、部品についての主張ではなく、コーパスについての主張。

71. 導出したラベルの「率」は、対象の性質ではなく自分の上限の性質。 完遂が天井なので「K call 以内で終わったか」に替えたら、K = 6 で 0% 対 63%、K = 10 で 100% 対 100%。 「haiku は X% 完遂する」は haiku についての事実ではありません(54 §2)。 25 の「cutoff はコーパスに属する」が、導出したラベルに当たった形です。 → 上限を 1 つ選ぶのではなく、全部の上限で掃いて縦の動きを見せる。

72. 連続量を二値にするのは、情報を増やさない。 「K call 以内」は call 数の閾値化で、単調な多対一写像は 順序情報を失うことしかできない —— だから AUC は上から抑えられます(0.844 対 0.927)。 これは定理で、コーパスの性質ではありません(54 §2)。 44 §1.2 は既に対応付きで 32 件中 28 件・p < 0.001 を報告していました。 → 「ラベルの形が欲しい」と「測れていない」を混同しない。 → そして定理はテストで固定する(全 K について、印字する 1 点ではなく)。

73. 天井の原因は、コーパスではなくハーネスに在ることがある。 同じ hard コーパスが記録に 2 回: Bash 無しで 31/32、有りで 32/32。 equals-k3 は安い段が落として、テストを走らせられるようになったら通しました —— 記録の Bash 呼び出しが npm test 2>&1 → 失敗を読む → 再編集(54 §1)。 Bash 有りの passed はモデルの答えではなく、ハーネスが自分の仕事を確かめる手段を与えたかを測っています。 → 天井を見たら、コーパスを難しくする前に --allowedTools を見る。

74. 発言率は判断の性質ではなく、コーパスの性質。 同じ gate・同じ cutoff で 1.2%(43、私が構成したサンドボックス)→ 6.3%(55、実リポジトリの実エージェント・9 リポジトリ)→ 11.8%(63、同じ手で roster を 16 リポジトリに広げた)→ 24.1%(49、公開された npm run スクリプト)。 43 と 49 の両端は同じ 1 つの欠落を指していました —— 一方は私が書いたコーパス、他方はエージェントのトラフィックでないもの。 そして 6.3% → 11.8% は roster を広げただけの効果ではありません —— 63 §3.6 で分かったように 55 の run は ツールチェーンに到達できていませんでした。2 つが同時に変わっているので寄与は分離できない、と書くところまでが測定です。 → 「この guard はうるさい/静かだ」は、測った母集団を書かないと意味を持たない。 → そして母集団を 1 つ変えたつもりのとき、本当に 1 つだけ変わったか確かめる。

75. 自分が書いた限界も測る。 55 は「clone は shallow だからタスク文は著者の現在の版」と限界に書きましたが、 clone 木の HEAD を読んだら 9 本中 7 本が pin された rev と一致しており、 タスクを産んだ 2 本は両方一致でした。 → 限界の節は正直さの表明であって、推測の置き場ではない。

76. 自分の測定が、自分の安全装置の下流に在ることが在る。 55 の deny 1 件(curl … | bash)はこのプログラムで初めて「本物のエージェントが自分で選んだコマンド」に当たったものですが、 3 回目の試行で、1 回目(インストーラをファイルに落とす形)は私の fence が拒否していました。 止めた判断は正しく、経路の一部は私が作っています。 → 実トラフィックでも、ハーネスが形づくった部分は数えるときに分ける。

77. 合計ではなく行を読む —— レポート自身の表も含めて。 harvest ラベルが構成上 negative なクラスを含んでいたのが 4 度 (49 の pre*、53 の single が 2 回、 55 のテンプレート 66 件)。そして 5 度目は自分のレポートの表でした —— 55 §3 の fence 5 件を要約から手で書いて、1 件を別のクラスに数えていました。 → 記録から導出して、どの行もどのクラスにも入らなければ落ちるテストを置く。

78. プールした null は、符号が逆の 2 群が打ち消した結果かもしれない。 55 §5 の - [x] 対照アームは、プールすると全指標が null (tool call p=0.802・編集 p=0.384)でした。 節で割ると 5 指標のうち 4 つが符号反転していて —— Tier 2(lint 規則)では done が小さく、P6(機能)では done が大きい。 → 「差が無い」と書く前に、設計が対応させた単位で割ってみる。

79. 小標本では、検定の床を結果より先に書く。 5 対 8 の厳密順列検定は C(13,5)=1,287 通りなので、p は 1/1287 ≈ 0.0008 より下に行けません。節で割ると n=2 対 3 で床は 0.100 —— どんな分離でも 0.05 を切れない。 → 床を印字させる。 そうしないと「p > 0.05」を「差が無い」と読んでしまう。

80. 対照群は「同じラベルの別クラス」ではなく「同じ文脈の隣の行」から作る。 - [x] を file 順に採ると ## Goals のチェック済みの方針文が来ます (「GitHub Docs を仕様の真実とする」)。それを open 項目と比べたら、測れるのは文の種類です。 55 §5.1 は著者の見出しを対応の単位にして、 timeout-minutes 対 concurrency、S006 対 S007 の隣接行にしました。 → 対応は「ラベルが違う」ではなく「他が全部同じ」で作る。 81. 誤差の床を測る前に、小さな差を解釈してはいけない。 同一条件を 2 回回したら 0.04 動いた。1 回目に「2 つの条件が 0.853 でぴったり一致」と出て、機構として書きかけた —— 2 回目で偶然だと分かった。 → 再実行が唯一の検出器。 これを当てると、0.03 や 0.02 の「効果」は効果ではなく「この n では区別できない」に変わる。

82. 機構が同じでも、領域が違えば数字は移らない。 候補 2 択では並び順が +0.21 動かすが、数十候補では誤差に埋まる。「絞ると confidence が下がる」(2 択で 0.845 → 0.783)を 214 → 58-64 の盤面で測り直したら 0.76 対 0.77 で床の内側だった。 → 転移させる前に、その盤面で測る。

83. clone の失敗は、間違った名前の検出器ではない。 リポジトリ名を切り出す正規表現が最初のドットで止まって 4 本間違え、 3 本は存在せず clone に失敗したので気づきました。 4 本目 dcodeIO/protobuf は実在します —— clone でき、harvest も通り、 普通に見える 1 行として記録に座っていました。56 本を選ぶ規則に対して 57 行、という形でだけ残っていました(63 §1.1)。 → 記録を規則から再導出して差分を取る。失敗したものを数えるのでは足りない。

84. 安全装置の効果が生態系依存だと、レポート 1 本ぶん隠れる。 /root/.moon/bin/moon は入っていて実行可能なのに PATH に無く、呼ぶには /root/ を名指すしかなく、私の fence がそれを deny していました。 6 run 中 4 run でエージェントは原因を正確に突き止めて export PATH=… を打ち、全部拒否された —— それでも 55 では現れませんでした。/root/.cargo/bin は既に PATH に在るので、あちらの Rust リポジトリは cargo を裸で呼び、fence は一度も発火していません(63 §3.6)。 → 1 つの規則が言語ごとに違う効果を持つとき、1 つの roster では見えない。

85. 規則が 2 つある計器を、片方だけ写した分類器がテストを通る。 fence は絶対パスと ../ 遡りの 2 つで deny します。 55 の拒否 5 件は全部パス側だったので、パスしか知らない分類器が通っていました。広げた sweep が遡り側を 1 件出して、§3 の表(合計は別に印字される)から落ちました。同時に fence は file_path にもかかることも出ました(63 §3.7)。 → 計器の分類器は、計器の分岐を全部写したか数える。

86. 自分の穴の測り方を間違えた。 記録は cwd をサンドボックス相対で保存し、ルートは "" です。 startsWith("") が常に真なので、自分のサンドボックスを絶対パスで書いた call が全部「外部」に見え、 55 の記録に「109 件」と報告しました。正しくは 0 件(63 §3.7)。 → 空文字列を prefix 比較に渡すと、全件一致する。

87. 事前登録した指標は退化しうる。そして断定しなかったことだけが正しかった。 最初の 4 run が全部 600 秒の上限に当たったので、「秒は退化している可能性が高い」と §3.0 に書きました。外れです —— 上限に当たったのは open 11/16・done 2/16 で、「秒」は 5 指標で最も強い信号になりました (p = 0.0049)(63 §3.4)。 → 4 run から母集団を推定しない。そして予告は「可能性が高い」で書く。

88. 何も言えない表は、言わない表より悪い。 1 対 1 の節に対照なしの置換検定を当てると C(2,1) = 2 なので 全指標で p = 1.000・床 0.500 が構成上確定します。広げた記録ではそれが 80 行出て、16 件の発見のように見えていました(63 §3.4)。 → その数字が他の値を取り得るかを確かめる。取り得ないなら表ではなく理由を出す。

89. 自分の修正も、器具の途中変更なら交絡。 gate.mjs は tool call ごとに再実行されるので、sweep 中に fence を直すと 前半と後半で器具が変わります。穴は実測して報告し(32 run で 1 call・write 0)、 塞ぐのは sweep の後にしました。捨てた 6 run も結果にプールしていません —— 1 つの記録に 2 つの計器が混ざるのは、それが自分の修正であっても同じ交絡です(63 §3.5)。 → 「直した」は「今すぐ有効にする」とは別の決定。

結局、この速度と価格は何を変えたか

全部に回せる。 関数 1 個 $0.000017(2 問)/ $0.000055(10 問)。 1000 関数のリポジトリを丸ごと 1 回判定して $0.017〜$0.055、リクエストは 20 本弱。普通の LLM judge との違いはここ。
人の操作に間に合う。 hook が median 329 ms(node 起動込み)、1 コマンド $0.000032。エージェントの Bash 1 回ごとに判定を挟んでも体感に乗らない。 そしてこれは本物のエージェントの中で 2 回測り直されました —— 18 §1 が 40 本前に主張した 2,500 ms の予算に対して、出荷配線(コマンドごとに node 起動込み)で 391 コマンド中央値 371 ms・p99 568・超過 0、掃き直しで 394 コマンド中央値 372 ms・超過 0。予算は持ちます。
迷ったら聞いておける。 質問を足すコストが質問文のトークンだけなので、「使うか分からない述語も込みで 1 回投げて、必要なものだけコードで拾う」が成立する。
確率が返るので、閾値がこちら側に残る。 判定の変更に API 呼び出しが要らない。代わりに校正が自分の責任になり、そこが一番手間だった(→ 5, 8)。
そして「全部に回せる」は、本物のエージェントの中では品質の主張になりませんでした。 5 コンポーネントすべてで 26〜103 倍速いのは一貫していますが、 品質で jev が明確に勝っている列は 1 つも在りません(42)。端から端まで走らせると gate は完遂を 1 件も奪わない代わりに 978 コマンド中 12 件しか発言せず(43)、残り 3 コンポーネントは完遂では分離しません(44)。 → 正しい売り方は「安くて速いから、迷ったら聞いておける」で、「賢い」ではない。
行動させる側では、値段より手数が高い。 1 手あたりは数セント未満だが、 1 手は実アプリに対する変更で、失敗すれば取り消しが要る。だから 62 の結論は「安くする」ではなく「手数を減らす」に寄った —— トークンを 67% 落とす機構は担保付きの借金で、手数を 5 手減らす機構は素の利益だった。

正直な限界は各レポートの「正直な限界」節に全部書いてあります。一番大きいのは コーパスが小さい(10〜130 件)ことと、 「コード品質」のような審判のいない領域ではラベルがこちらの意見であること。後者は 22 バグ全部にプローブを付けて実行で証明する、で潰しました。

後半 9 本で足された限界は別種です:

自分が書いたコーパスは自分のコーパス作文を測る。 境界コーパスの 5 件は私が書きました。緩和は「偏っていない」ことではなく「安全ルートが検証済みで、どちらを取るかはエージェントの判断」。 44 §2 の skill router だけは実在 300 件で測れました —— このプログラムで私が書いていない最初のコーパスです。
コンポーネントに仕事が無いコーパスでは、コストしか測れない。 gate は 978 コマンド中 12 件、orchestration gate は Task 呼び出し 0 件。 全員が一致した測定に情報は入っていません。
完遂が天井なので、モデルの段を完遂では分離できない。 Bash が在るのでエージェントは緑まで回します。
そして「私が書いていないコーパス」は 3 つになりました —— 44 §2 の skill router(実在 300 件)、49 の npm script(354 パッケージ)、そして 55 の実リポジトリの実エージェントのトラフィック(15 run・Bash 746)。 3 つ目だけが「他人のコーパス」と「エージェントのトラフィック」を同時に満たします —— 43 の 1.2% と 49 の 24.1% はその欠落の両端でした。 ただし実質 2 リポジトリで、30 の roster は skill 選択のために組まれたので ビルドするものが無いリポジトリが多い —— より広い roster が明らかな次の一歩です。
そして残っている宿題は「走らせれば済む」ものではなくなりました —— TODO.md の §2 は全部「測り方が分からない」で、 閉じ方が分からないものはそう書いてあります。