sync: update from private repo (2336949a)

docs/bench.md

@@ -14,7 +14,7 @@
 | `config.yaml` の `provider` が動作する LLM を指している（タスク実行 + judge の両方で使う） | ✅ |
 | 初回のみ `npm run bench:fixtures` で `bench/fixtures/sales.xlsx` を生成 | ✅ |
 
-ベンチランナーは外部ネットに依存しない。`fixtures/web/*` はランナー内蔵の **localhost HTTP サーバ** が配信する（起動時にランダムポートを取り、`{WEB_PORT}` トークンで prompt に注入）。
+テスト用の Web 素材はローカルで配信する。タスク実行とモデルによる採点は、設定したサーバーへ通信する。`fixtures/web/*` はランナー内蔵の **localhost HTTP サーバ** が配信する（起動時にランダムポートを取り、`{WEB_PORT}` トークンで prompt に注入）。
 
 ---
 
@@ -30,7 +30,7 @@ npm run bench -- --task=composite-mini-report
 # 別ホスト/ポートのオーケストレータ向け
 npm run bench -- --server=http://127.0.0.1:9876
 
-# LLM judge を skip (axis D を 1.0 固定にして programmatic だけで採点)
+# LLM judge を skip (axis D は「採点していない」扱いで総合点の計算から外れる)
 BENCH_JUDGE=off npm run bench
 
 # judge を別エンドポイント・別モデルにする
@@ -39,6 +39,12 @@ BENCH_JUDGE_MODEL=gpt-oss:20b \
 npm run bench
 ```
 
+### 判定用モデルの設定と認証
+
+既定では `provider.workers` の先頭から接続先・モデル・API キーを取得する。ワーカーが無い場合は旧形式の `provider.baseUrl` / `provider.model` を使う。
+
+`BENCH_JUDGE_ENDPOINT`、`BENCH_JUDGE_MODEL`、`BENCH_JUDGE_API_KEY` は、それぞれワーカー設定より優先される。接続先を別の URL に変更した場合は元のワーカーのキーを引き継がないため、認証が必要なら `BENCH_JUDGE_API_KEY` を設定する。同じ接続先の末尾スラッシュの有無は区別しない。キーを明示的に空文字にすると、認証ヘッダーを送らない。
+
 実行が終わると `bench/results/<run_id>/` に書き出される（`run_id` は ISO タイムスタンプ）。
 
 ---
@@ -60,15 +66,23 @@ bench/results/2026-05-01T03-22-11Z/
 ```
 # Bench run @ 2026-05-01T03:22:11.000Z
 
-**Overall: 73 / 100**
+**Overall: 77 / 100**  (avg of 2 scored tasks of 3, scored weight 75-100 of 100)
 
-| Task                   | Status     | Total |   A |   B |   C |   D |
-| ---------------------- | ---------- | ----: | --: | --: | --: | --: |
-| composite-mini-report  | succeeded  |   73  | 90% | 100%| 70% | 60% |
+**Failed runs: 1** (kept in the table below, excluded from the average)
+
+| Task                   | Outcome | Status    | Total | Scored weight |   A |    B |   C |       D |
+| ---------------------- | ------- | --------- | ----: | ------------: | --- | ---- | --- | ------- |
+| composite-mini-report  | graded  | succeeded |    73 |        100/100| 90% | 100% | 70% |     60% |
+| judge-off-task         | graded  | succeeded |    80 |         75/100| 100%| 100% | 50% | skipped |
+| exploded-task          | failed  | –         | failed|             – |  –  |   –  |  –  |       – |
 ```
 
+総合行の `scored weight 75-100 of 100` は、平均に入れた 2 件が別々の重みで割り直されていることを示す。全件が同じ重みなら `scored weight 100 of 100` と 1 つの数字になる。
+
 各タスクの詳細セクションでは axis ごとに ✓/✗ 内訳とツールコールの全シーケンスが折りたたみで見られる。
 
+**Scored weight 列を必ず一緒に見ること。** 採点した軸の顔ぶれが違う総合点どうしは、同じ 100 点満点でも別の試験の点数になる。
+
 `result.json` は CI から機械可読に扱える形式。
 
 ---
@@ -83,7 +97,22 @@ bench/results/2026-05-01T03-22-11Z/
 | **D. Reasoning** | 25 | 内容の妥当性・統合の質・「次アクション」の具体性など | LLM judge ルーブリック |
 | _補助: Efficiency_ | – | duration / prompt tokens（summary に数値表示のみ） | – |
 
-`Total = A×30 + B×15 + C×30 + D×25` を 0..100 に正規化。
+### 採点した軸だけで割り直す
+
+各軸は `scored` / `skipped` / `failed` の 3 状態を持つ。
+
+| 状態 | 意味 | 総合点への扱い |
+|------|------|----------------|
+| `scored` | 実際に評価した。0..1 の点がつく | 重みぶん加算する |
+| `skipped` | 測っていない（その軸の期待値をタスクが書いていない、judge が OFF など） | 分子からも分母からも外す |
+| `failed` | 採点そのものが壊れた（judge の通信失敗・応答が JSON でない・結果が空） | 分子からも分母からも外す |
+
+総合点は `採点できた軸の (score × 重み) の合計 ÷ 採点できた軸の重みの合計 × 100`。
+`skipped` を満点、`failed` を 0 点として混ぜない。前者は「測っていないもの」を「満点だった」に見せかけ、後者は「採点機が壊れた」を「中身が悪かった」に見せかけるため。
+
+採点できた軸が 1 つも無いときは総合点を出さず `not scored` と書く。`result.json` の `scoring` に `scoredAxes` / `scoredWeight` / `uncountedAxes`（状態と理由つき）が入るので、後から run どうしを比べるときに顔ぶれの違いが分かる。
+
+タスクの実行そのものが落ちた場合は `outcome: "failed"` の結果として一覧に残り、平均からは除いたうえで件数を表示する。落ちた課題を黙って捨てない。**1 件でも落ちたら `npm run bench` の終了コードは 1 になる**（点が低いだけなら 0 のまま。走れなかったことだけを信号にする）。
 
 `completion_status: [succeeded, waiting_human, failed, aborted, cancelled]` で受理する終了状態を指定。デフォルトは `[succeeded]` のみ。**failure でも grader は走り部分スコアが出る**。