手引き: eval（目隠しで比べる）

実験の設計はこちらが持つ。計画し、目隠しをし、走らせ、まとめる。

目隠しの取り決め（必須）:

• 候補が見るディレクトリ・ファイル・依頼文に、比較・試験・評価・採点・候補・審査を思わせる語を入れない。bb-writ や変種の名前も入れない。
• 依頼文は、利用者が普通に打つ 1〜2 文。何を測るかを漏らさない。どのスキルや原則を使ったかを報告させない（使ったかは、実際に読んだファイルと成果物の形から判断する）。
• 候補に、他の候補がいることを伝えない。リモートへの push や PR が起きないよう、作業場所はリモートの無い写しにする。

手順

1. 枠を決める。 何の変種を比べるか、何を成功とするか。審査用の基準（3〜6 個の具体的な項目）を書き、候補には見せない。
2. 隠した試験を書く。 成果物を外から確かめるスクリプト（実際の CLI・API・画面の経路）。変更前の状態で欠陥を検出することを先に確かめる。
3. 作業場所を分ける。 候補ごとに同じ状態の写し、変種ごとに別の設定ディレクトリ（Claude Code は CLAUDE_CONFIG_DIR、Codex は設定の上書き -c）。各変種は、その変種の公式の入れ方で用意する。
4. 同じ依頼を同時に走らせる。 モデル・effort をそろえる。時間・費用・使用量を記録する。利用者が普段渡さない設定（GH_CONFIG_DIR・GH_TOKEN など）を候補の起動に足さない。足すと、利用者の環境でだけ起きる失敗が隠れる（2026-10-17、アカウントの取り違えが 1〜7 日目の試験で隠れていた）。
5. 確かめる。 各候補に隠した試験を実行する。審査役は候補と別の系統（launcher）で、候補を記号でだけ見せる（モデル名・変種名を見せない）。1 人の審査役が全候補を 1 つの尺度で、同じ回で採点する。
6. 自分で全部読む。 各候補の成果物と報告を最後まで読み、審査役の判定と比べる。食い違いは、審査役の偏りか基準のあいまいさを示す。実際に読んだファイルは、記録のメタデータ（ツールの呼び出しと対象のパス）から数え、本人の申告を使わない。

返答: 比べた変種、基準、候補ごとの所見（隠した試験の結果・時間・費用）、審査役の判定、まとめ、採否の推奨とその根拠。1 回の実行で決まらないことは、そう書く（揺れを測るには回数が要る）。