実装エージェント→リーダー→レビュアー（複数段）の体制では、テスト・ビルド等の検証実行が各段で暗黙に重複しやすい。実装者が通し、リーダーが「念のため」再実行し、レビュー観点の「テストの空通し確認」が実行を誘発し、差し戻しラウンドごとに全量再検証が走る。生成ではなく検証・レビューがボトルネックになる構造で、この多重実行が直列時間の主要因になる。

運用ルール

• 検証実行は実装エージェントの1回を正とする。完了報告に証跡（実行コマンド・exit code・pass/fail 件数）を必須で含めさせ、証跡の無い完了報告は差し戻す。
• リーダーは証跡と diff の整合確認のみ行い、原則再実行しない。再実行は証跡が欠落している・証跡と diff が矛盾する場合の抜き取り1回に限定する（「疑わしければ再実行」という裁量規定は実運用で毎回実行に膨らむため、原則禁止＋例外列挙の形で書く）。
• レビュアーはテストを実行しない静的専任にする。「テスト不足・空通し」の観点は、証跡とテストコードの静的照合で判定させる。例外は実行可能な検知器（テスト基盤・検証スクリプト・品質ゲート）自体の変更のみ: 検知器の false green は静的レビューで見抜きにくいため、独立した実行検証を維持する。
• 差し戻し修正後の再検証も実装エージェントが行う。これが自然に「最終状態での検証」を兼ねる。

却下した代替案

「検証はレビュー収束後の最後に1回だけ」方式: レビューループ中に diff が動くため、最後の1回を誰がいつ実行するかの調整が発生し、削ったはずの直列時間が戻ってくる。実装者が修正のたびに通す方式は調整コストがゼロで、最終実行を構造的に含む。

検証

導入前後のセッションで、同一検証コマンドの実行回数（実装者以外による実行が0になっているか）と、完了報告〜コミットまでの直列時間を比較する。品質側の劣化は、リリース後に発覚したバグ件数を記録して監視する。