interrogate: 独立した審査の panel

入口 bb-writ から始めた仕事で会話が要約された後は、入口を呼び直して全文を読み直す（要約の後は、先に呼んだ入口が落ちていることがある）。

審査役を 2 人立てて変更を敵対的に読ませ、指摘を突き合わせ、自分が主審として判定する。価値は役割の演技でなく、文脈とモデルの系統の違いから来る。審査役の報告は主張であって事実ではない。主審は実物で確かめてから判定する。

1. 範囲を決める

• 利用者が指したファイルや差分があればそれ。作業ブランチなら基点からの差分（git diff <基点>...HEAD）。計画や設計なら、その文書と関係するコード。
• 審査役は自分でリポジトリを読むので、差分を貼り付けるより「どの範囲をどのコマンドで見ればよいか」を渡す。
• 対象のリポジトリに審査の指針（REVIEW.md、指示ファイルの中の審査の節）があれば、依頼文で名指しして審査役に読ませる。その部分で何が大事かは、対象のリポジトリが決める。

2. 意図を書く

依頼・commit・PR の本文・コードから、変更の意図を 1 段落で書く。審査役には「意図そのものは疑わず、実装が意図を満たすかを攻めよ」と渡す。依頼（Issue など）に MUST・受入条件が並んでいれば、1 行ずつ写して意図に添える（審査役が、それぞれを確かめる試験の有無を見られるように）。意図が読み取れなければ、その不明点も審査の対象にする（人間に聞いて止まらない）。

主張が強制の形（「避けられない」「必ず落ちる」「免除できない」「常に」「どう書き換えても」）なら、意図に入力の表を添える。(i) 人のレビューで守る入力と、守る規則の場所（指示ファイル・CODEOWNERS・ブランチ保護など、リポジトリの中か公開先の設定）。(ii) 書き換えられると見なす入力の次元（データファイル・登録の一覧・設定・fixture・環境変数・基準の版など、コードを変えずに結果を変えられるもの）。どちらにも入らない入力は (ii) に入れる。「〜は主張の外」は、(i) の行か、主張の文を狭めた場所としてだけ書き、依頼文のその場の一句にしない。強制の形の主張では、穴はコードでなく入力の書き換えの側に出やすい。

3. 審査役を立てる

同じ依頼文を 2 人に渡す（入口の条件 (6) から通すときの人数は、5 の危険度で決める）。

• 審査役 A（同じ系統・新しい文脈）: Claude Code では launcher の --host claude --interrogate で読み取り専用に立てる。Agent ツールで立てない（書き込みが OS で止まらず、依頼で許された外の ~/.npm に書いた。記録にも残らず、work.py の --reviewed は、その commit を対象に launcher で立てて ok で返った審査役の記録が無ければ通さない）。Codex では launcher の --host codex --interrogate。Codex の workspace-write の sandbox の中では入れ子の codex exec が起動できず、非対話実行ではサブエージェントも起動されなかった（2026-10-17 の実測）。起動できなければ「同系統の審査は無い」と書き、B だけで判定する。

• 審査役 B（別系統）: launcher で、自分と別の系統の CLI（Claude Code・Codex・Grok Build のどれか。--host claude|codex|grok）を bb-writ 専用のログインで、読み取り専用で起動する。

  # Claude Code から Codex を（${CLAUDE_PLUGIN_ROOT} はプラグインの置き場）
  python3 "${CLAUDE_PLUGIN_ROOT}/scripts/launch.py" --host codex --interrogate --cwd <対象> --prompt-file <依頼文のファイル>
  # Codex から Claude Code を（このスキルの SKILL.md から 2 つ上の scripts/launch.py）
  python3 <プラグインの置き場>/scripts/launch.py --host claude --interrogate --cwd <対象> --prompt-file <依頼文のファイル>

  --interrogate は、この依頼文で立てた審査役だという宣言で、work.py は危険度が中・高の push・pr でこの記録を求める（入口の条件 (5) の子の記録は代わりにならない。条件 (5) の子には付けない）。--cwd は、届ける commit を checkout して未 commit の変更が無い場所にし、審査役が終わるまで変えない（launcher は、そのときだけ記録に head を書き、--reviewed はそれと照らす。数えるのは status が ok の記録だけで、not-run は数えない。work.py が数える審査の周も、task start の作業場所を --cwd にした記録だけで、別の worktree や写しを --cwd にした審査は数えない）。launcher は 1 行の JSON を返す。報告を使うのは status が ok のときと、下の not-run（読んだだけの審査として）のときだけ。invalid-report（結論・証拠が無い、証拠のファイルが無い、実行の欄の形が違う）・failed・quota・unavailable は、その理由を判定の記録に書く。timeout は、審査役を最初から立て直さず、delegate のとおり --resume で続ける（続きが ok で返り、前の起動が head を書いていて、続きの起動でも同じなら、その記録の head が審査の記録になる。違うか前が null なら続きの head も null なので、届ける commit で審査役を立て直す。resumable が偽の記録は続けられない）。別系統が使えなければ、同じ系統の新しい文脈をもう 1 人立て、「別系統の審査は無い」と書く。利用枠が尽きても、別料金の API へ黙って切り替えない。

  not-run は、報告に実行の欄（execution）が無いか、対象の試験・検査を実行できなかったと書いた報告。捨てずに、読んだだけの審査として使う。status の ok は「起動して、形の整った報告が返り、実行できたか要らないと申告した」までしか意味しない（launcher は申告の真偽を確かめない。主審は execution.commands を読む）。実行が要る審査（試験・検査を足す変更と、その期待値を変える変更）では、実行できなかった審査役（launcher の not-run、execution が not-needed の報告）を審査役に数えない。B がそうなら「別系統の審査は無い」とし、同じ系統の新しい文脈をもう 1 人立てる。読み取り専用の Codex は、起動ごとの一時ディレクトリ（$TMPDIR）にだけ書ける（2026-10-23、0.163.0。-s read-only では mktemp -d も失敗し、2 回の審査が読んだだけの判定になった）。読み取り専用の Claude Code の子も、$TMPDIR に対象を写して試験を動かせた（同日、2.1.309）。

依頼文に入れるもの:

• 意図の段落と、見る範囲（コマンドとパス）。
• 観点: 正しさ（空・境界・異常系・二重実行・中断後の再実行・並行）、症状でなく原因を直しているか（guard や再試行で隠していないか）、構造（検証は境界で 1 回か、データの形が使われ方に合うか、後付けに見えないか）、試験（振る舞いを確かめるか、壊したら落ちるか、同じ意味の書き換えで落ちないか、依頼の MUST・受入条件ごとに確かめる試験があるか）、利用者から見た結果。足したコードは、試験・検査のコード（補助関数を含む）も同じ観点で読ませる: 入力の形の異常（最後の行が改行で終わらない、空、区切りだけの行、空白だけの値）。呼んだコマンド（試験の補助関数の中の cmp・diff・抽出も）自身の失敗が別の結果（「食い違い」「一致」）に化けないか、失敗を診断なしで返さないか。コメント・文書が書く条件が、実装と同じ範囲か（実装より広く書いていないか）。足した試験・検査が出す人が読む文（ケースの名前・失敗のメッセージ）を、実際に流した出力で読む（書式の指定がそのまま残っていないか、どの場合を確かめるかが名前から読めるか）。差分の外も読ませる: 変えた事実を前提にする記述（別の文書の要約文、変えたコードの上の説明・テスト名・assert のメッセージ）が食い違っていないか。リポジトリの取り決めに反していないか（取り決めは指示ファイル・検査と、触る場所のディレクトリの履歴にある合意）。
• 試験・検査を実際に動かして攻めること。対象に書く試験は、書ける一時ディレクトリ（$TMPDIR）に対象を写して動かす。写すときは試験が使わない大きな置き場（target/・node_modules/ など）を除き、注入ごとの写しは流し終えたら消して、差分と出力だけを残す（主審が自分で注入するときも同じ）。動かせなかったら、そう書く（launcher の報告の execution）。ブラウザは子の sandbox では動かないので、親が動かして証拠を残し、審査役の検査に数えない（delegate の launcher の段落）。
• 外部のサービス・道具の挙動（CI がどう報告するか、API の応答など）に頼る主張で、手元で確かめられなかったものは、報告の unknowns に、主張とそれに頼る場所を 1 行ずつ挙げる。前の決定・出典から流用した理由は、今の変更の形にもその前提が当てはまるかを見る。
• 指摘ごとに: 重さ（critical 壊れる / warning 後で痛む / nit 好み）、場所（ファイル:行）、何が悪いか、根拠（呼び出しの経路をたどって示す）、代案があれば。普段の利用で起こる入力か、攻めるために組み立てた入力かも書く。ほめない。何も無ければ「指摘なし」。
• 指摘とは別の節に、試験で落ちない退行の注入を全部挙げる（無ければ「無し」）。変えたコードに手で並べた要素（条件の中で連結した欄、case の分岐、許す値の一覧）や、比べ方（前方一致・完全一致・正規表現）と境界の文字（区切りの /、末尾の改行）があれば、要素を 1 つずつ落とす・緩める注入を要素の数だけ作り、それぞれを落とす試験の名前を表にする。落とす試験が無い要素が、この節の行になる。指摘ごとの形だけを頼むと、審査役は試験が並んでいる判定を「確かめて問題が無い」側に入れ、欠けた要素を挙げなかった。
• 変えたコードを通る既存の試験（差分の外も。変えた関数・分岐を呼ぶ試験を、呼び出しと fixture で探す）も、名前が守ると言う性質ごとに、その性質を壊す注入を変えた後のコードに入れて、表の行にする。判定の作り（比べる対象・比べ方・どの枝で除くか）を替えると、試験の fixture は別の枝を通り、名前と期待は正しいまま、別の理由で通り続ける（境界の / を守る試験の fixture が、替えた後は境界と関係なく除外の外に出て、/ を消しても通った）。
• 表の行ごとに、注入を実際に入れて試験を動かしたか（注入の差分と、落ちた試験の名前と出力）、推論か（動かしていない）を書く。落とすと書く行は、その試験が名前の言う理由で落ちる（出力の文言が守る性質の違反を示す）ことまで見る。準備の失敗や別の検査で落ちたものは、落とすに数えない。
• 主張が強制の形なら、退行の注入と対になる別の節に、コードを変えずに主張を破る入力の書き換えを全部挙げさせる（2 の (ii) の次元ごとに。無ければ「無し」）。表に無い次元があれば、それも挙げさせる。
• 6 の記録があれば（2 周目から）、記録のパスを渡し、未確認 の行を先に確かめて状態を埋めさせ、新しい候補を行として足させる。依頼文に「既知で直さない」「前の審査で確かめた」の除外の一覧や「〜は主張の外」の一句を書かない。外す理由は記録の 範囲外 の行にだけ書く。依頼文で外した経路が、後の周で穴になった。

4. 突き合わせる

• 同じ問題を別の言い方で挙げた指摘をまとめ、誰が挙げたかを残す。2 人が独立に挙げた指摘が最も強い。
• 1 人だけの指摘も読むが、重みを下げる。片方が問題と言い、もう片方が明示的に問題ないと言う箇所は、判定の材料として残す。

5. 主審として判定する

中立の集計係でなく、実用を重んじる主審として、全指摘を 4 つに分ける。経路の候補（6）は、この区分でなく 6 の記録の状態で閉じる。「対応する」に入れる指摘は、主審が実物（コード・実行）で確かめてから入れ、直す前に同じ性質のほかの箇所を探す（principle-fix-root-causes）。試験で落ちない注入の節の行も指摘として扱い、主審が実物に注入して試験が落ちないことを確かめる。表の「落とす試験がある」行のうち、推論の行と、注入の差分か試験の出力が報告に無い行も、主審が同じく注入して、名指しの試験が名前の言う理由で落ちるかを確かめる（落ちなければ、落ちない注入の行に移す）。審査役が推論で「この試験が落とす」と書いた行を確かめずに数えると、表は実際より厚く見え、落ちない注入を見逃した。

• 対応する: 正しさ・安全・保守に実害がある。実際の PR なら止める。
• 検討: 正当だが、いま直す費用に見合うか分からない。利用者の判断に値する。
• 記録のみ: 正しいが、いまは行動に移さない（状況次第、早すぎる最適化、影響が小さい）。
• 退ける: 誤り・些末・文脈の欠落。理由を 1 文で。

同じ処理の順序・止め方・再開の指摘が 2 周続くのは、順序の見落としが残っている合図。審査の周は 1 周に 1 つの順序しか見つけないので、create-formal-verification-skill で全部の順序をたどる手がある。同じ解析・変換の入力の形（全角・BOM・非 UTF-8・symlink など）の指摘が 2 周続くなら、create-property-test-skill で揺れの一覧を組み合わせて確かめる手がある。

入口の条件 (6) から通したとき（自分の変更を届ける前）

• 外部の挙動に頼る主張は主審が確かめる。 審査役の unknowns の外部の挙動の行と、変更が書く外部の挙動に頼る主張（流用した前の決定の理由を含む）を、実物（実際の実行結果・公式の文書）で確かめ、コマンドと観測を証拠に残してから届ける。launcher の読み取り専用の Claude Code・Codex の子は試験のコマンドからネットワークを使えず、審査役を何人立てても外部のサービスの実際の挙動は確かめられない（matrix の job を if で省くと、GitHub は展開前の名前のチェックを 1 つだけ skipped と報告し、「job の if なら待ち状態を避けられる」という流用した前提が崩れていた。審査の記録は 6 つ揃っていた）。確かめられなければ、確かめていない範囲として入口の返答の 4 と、変更の文（PR の本文・文書）に書く。
• 「検討」を使わない。 「対応する」「記録のみ」「退ける」の 3 つに決め、どこまで直すかを利用者に選ばせない。記録のみは、直すと誤りになる指摘（状況次第、早すぎる最適化）に限る。影響が小さいこと・起こる確率の見積もり・費用を理由にしない（直すか退ける。確率は測れない）。組み立てた入力でしか起きない指摘は、下の Important の定義で決める。記録のみにした限界は、意図した振る舞いとして試験か文に示し、入口の返答の 2 の「守らないこと」に書く。仕様の矛盾か製品上の選択を含む指摘だけを、入口の返答の形の 4(b) で利用者に返す。
• 深さは危険度で決める。 危険度は書いた人でなく変更の中身で決め、理由とともに返答と work.py の --risk 低|中|高:<理由> に書く（中・高は --reviewed none: と並べられない）。低は、この審査を省く（(5) は条件どおり）。文言だけ・試験だけ・小さな追加と、既存の形に沿ったコードの変更で、振る舞いを実行で確かめたもの。中は、審査役を A の 1 人にする。判定の作り（比べる対象・比べ方・どの枝で除くか）を替える変更、処理の順序・途中の停止・再開・記録をまたぐ状態を変える変更、設計が争点の変更（形が複数考えられ、選んだ形が実物で決まらない）。高（認証・課金・外部操作・データの削除・皆が使う土台）は、A と B の 2 人にする。どの段か迷ったら上の段にする。
• 指摘に重さと由来を付ける。 Important は次の 2 つのどちらか。(a) 安全・認証情報・権限の関門に触れる、またはデータを失う（ファイル・記録・未保存の作業を消す）。起こりやすさも、組み立てた入力かどうかも問わない。(b) 実際の利用・CI・対象の環境で起こる入力と状態で、正しさ・保守に実害が出る。一覧に無くても、実際の入力・状態で再現した欠陥はこれ。試験の穴は、入口の条件 (5) の後退の一覧の行を見逃すときだけ。審査役が攻めるために組み立てた入力・書き換えでしか起きず、(a) に当たらないものは Important にせず、守らない範囲をリポジトリの中の文に書いて閉じる。ほかは Nit（文言・様式・細部）、Pre-existing（変更より前からあったコードへの指摘。この変更の責任にしない）。
• 経路の候補を Nit・Pre-existing・記録のみ・退けるで閉じない。 6 の記録の状態で閉じる。破れた の行は Important として直す。以前からあるコードにある経路も、この変更が届ける主張を破るなら、閉じるまで届けない（直しを別の commit にするのは構わない）。
• 直しの上に直しを重ねない。 指摘の場所が前の周の直しで足したコード・試験・文なら、その上に足さない。前の直しを戻し、元の指摘を閉じ直す。元の指摘が実際の入力で踏める欠陥なら、足す量の少ない別の形（場合分けを 1 つの読み方に畳む、仕組みを足さずに主張を狭める）で直し、踏めないなら守らない範囲の文で閉じる。狭めてよいのは、依頼・出典より広く書いていた主張だけ。依頼の受入条件は狭めず、狭めないと閉じないなら未完了として入口の返答の 4 に書く。戻すより小さい直しがあるなら、その理由を返答の 3 に書いて直す。足した直しの上に次の穴が出続ける形は、周を回しても閉じない。
• 次の周を起こすのは、Important と判定して、実装の振る舞いを変えた直しだけ。 試験だけの直しは、直した commit で新しい子に、後退の一覧の行が落ちることと、直しの差分を 3 の観点で読むことだけを頼み（危険度が中・高なら --interrogate を付けて立てる）、新しい攻めの周にしない。直しで足した試験の名前・メッセージも、ほかのコードと同じく誤りが入る。文だけの直しは周を起こさない。Nit は同じ変更で直しても次の周を起こさない。Pre-existing は、この変更と別の commit にして同じ仕事の中で直す（範囲の外の穴を次の依頼に回さない）。その commit は、この変更と同じ決め方で審査する。書き手がエージェントだと、nit 1 つが commit 1 つと周回 1 つになり、周回が止まらない。主張を変えない直しの後、次の周の範囲は、前に通した commit から直した commit までの差分だけ（判定の作りを替えた直しは下の例外。前の周に通った部分を毎回見ると、指摘が出続ける）。
• 直しの周で主張を足さない・強めない。 直しは、主張どおりに実装を直すか、主張を狭めるだけにする。主張を足したいなら、別の変更として同じ決め方で審査する。主張を強めると、前の周で無害として退けた事実が穴に変わり、範囲が周ごとに広がる。
• 判定の作り（比べる対象・比べ方・どの枝で除くか）を替えた直しは、主張を変えなくても、次の周の範囲に、その判定を通る既存の試験を入れる。 見分けは差分の形で決める（比較の演算・比べる対象・分岐の条件・除く条件を変えた）。次の審査役には、3 の既存の試験の注入をその試験ごとにやり直させ、前の周で落ちることを確かめた行も、替えた後のコードで確かめ直させる。差分だけを範囲にすると、前の commit で書いた試験は攻められず、替えた後に別の理由で通り続けても誰も気づかない。
• 直した部分に次の Important が出たら、または 3 周目でも Important が出たら、次の直しを書く前に principle-attack-the-premise を呼ぶ。 周の数で止めて「十分」と呼ぶのではない（principle-no-budget-cap-on-quality）。直し方と、直している仕組みそのもの（目的に要るか、仕組みの無い別の形より良いか）の前提を疑う合図にする。主張が強制の形なら、前提は「結果を変えられる入力の集合は ___ だけである」と書き、2 の入力の表と 6 の記録から列挙して確かめる。

6. 経路を閉じる

入口の条件 (5)・(6) から通したとき（自分の変更を届ける前）に従う。

経路の候補は、「届ける commit のコードと試験はそのままで、誰が何の入力（データファイル・設定・fixture・環境など。強制の形の主張では 2 の (ii)）を書き換えると主張が破れる、または破れそう」と読める文のすべて。審査役の指摘・3 の入力の書き換えの節・入口の条件 (5) の子が通した書き換えに限らず、自分の判定の「記録のみ」「退ける」の理由、依頼文に書いた疑い、PR の本文が書いた歯止めや設計の理由も含む。ただし候補にするのは、書き換える入力と、変わる結果を具体的に書ける文だけ（書けない漠然とした疑いは候補にしない）。コードや試験そのものを書き換える後退（退行の注入、条件 (5) の (b)）は、これまでどおり 5 と入口の条件 (5) で決める。

候補は、見つけた周で記録の 1 行にする。置き場は、担当を取った仕事では claim の出力の note.evidence_dir の paths.md、取らない仕事では ~/.local/state/bb-writ/notes/<owner>__<repo>/ の同じ名前のファイル。行は「主張／経路（誰が何を書き換えると）／状態／出所（誰が、どの周に、どこで書いたか）」。状態は次の 4 つだけ。

• 破れた→<直した commit>: 破れることを実物で確かめ、直した。直した後に、同じ経路で落ちる試験がある。
• 破れない→<確かめ方>: 実物で試して破れなかった（実行したコマンドと観測）。または、破れたら落ちる試験の名前。
• 範囲外→<場所>: 2 の (i) の入力で、守る規則の場所がある。または、主張の文を狭めて経路を外した（狭めた文の場所）。
• 未確認: 上のどれでもない。

経路の候補は、ほかの根拠では閉じない。「以前からある」「既知」「本文に記載済み」「作為的」「今回の退行ではない」は閉じた理由にならない。入力の書き換えを作為的として退けてよいのは、2 の (i) の入力のときだけ（範囲外）。「どう書き換えても」の形の主張は、届ける前に 2 の (ii) に並べた次元に狭めて書き、並べていない次元は主張の文に範囲外として書く。(ii) に並べた次元の書き換えは、作為的として退けない。

未確認 の行は、次の審査役を立てる前に、まず自分で埋める。経路を 1 文で書けるなら、実物で試して（入力を書き換えて検査を走らせる）結果を状態に書き、子には結果を記録として渡す。自分で書ける疑いを子に確かめさせると、子 1 人と直しと全体の検査で 1 周を使う。試すのに別の環境や権限が要る行だけを子に頼む。

未確認 の行が残る間は、届けない（work.py op run の --reviewed に審査を通した commit を書かない）。収束は、未確認 が 0 行になったことで判定する。最後の審査役が Important を出さなかったことは、収束の証拠にならない（審査役はそれぞれ別の所を見ているだけ）。

返す形

1. 意図（2 の段落）。
2. 審査役: A と B のホスト・モデル（launcher の model_effective。分からなければ「不明」）・指摘の数・launcher の status・実行できたか（B は launcher の execution、A は報告から）。実行が要る審査で、実行できなかった審査役を数えなかったなら、そう書く（3 の not-run）。
3. 対応する / 検討 / 記録のみ / 退ける（各指摘に、挙げた審査役と 1 行の理由。対応するには確かめた方法）。条件 (6) から通したときは検討を除き、各指摘に重さ（Important・Nit・Pre-existing）と、次の周を起こすかを付け、最初に危険度とその理由を書く。
4. 一致と相違: どこで一致し、どこで割れ、それが何を示すか。
5. 経路の記録（6）のパスと、状態ごとの行の数。未確認 が 0 でなければ、届けられないと書く。

利用者に頼まれた審査では、変更を自動で入れない。利用者が「直して」と言えば、入口 bb-writ から直す。入口の条件 (6) で、自分の変更を届ける前に通したときは、「対応する」を同じ変更で直す。次の周を通すかと範囲は、5 の「入口の条件 (6) から通したとき」に、経路の候補は 6 に従う。