validation

/validation — 完全な検証フェーズオーケストレーター

このワークフローを必ず実行してください。説明するだけではいけません。

ループ内の位置： 運用ループの移動 6（スライスの受け入れ）＋ bead の受け入れの集約です。wave の出力を取り込み、スライス検証の集約を生成します。intent issue のすべての Given／When／Then が、合格したテストに対応している必要があります。アクティビティログでは bead は完了しません。

厳格な委任契約（デフォルト）

検証では、Skill(skill="<name>", ...) 呼び出しを介して、/vibe、/post-mortem、/retro、/forge（およびライフサイクルスキルの /test、/deps、/review、/perf）に委任します。呼び出しは別々のツール呼び出しにしてください。厳格な委任がデフォルトです。

拒否すべきアンチパターン： /vibe の代わりに Agent() で審査役を起動すること、事後分析をインライン化すること、/forge を省略すること。契約の全文と、サポートされている圧縮の例外（--quick、--no-retro、--no-forge、--no-lifecycle、--no-behavioral、--allow-critical-deps）については、../shared/references/strict-delegation-contract.mdを参照してください。

圧縮の実際の兆候については、docs/learnings/orchestrator-compression-anti-pattern.mdを参照してください。 4 レバーのモデルと、scripts/check-skill-isolation.sh がフェーズスキルの SKILL.md 本文で検出する圧縮パターンについては、references/isolation-contract.mdを参照してください。ライフサイクルの原則とアンチパターンの引用表については、references/best-practices.mdを参照してください。

検証は、Intent-to-Loop Hexagonの validate_acceptance ポートを担います。 集約では、受け入れた各シナリオについて、境界づけられたコンテキスト、コンテキストパケット、ガードアダプター、完了状態、新しい証明を維持する必要があります。DONE／クローズ／グリーンの主張を受け入れる前に、Completion-Claim Kernelを適用してください。

実行

references/dag.mdに記載されている DAG を実行してください — STEP 1（vibe）→ 1.5（4 サーフェスのクローズ）→ 1.6（テストピラミッド）→ 1.6b（検証レーンの予算ガード）→ 1.7（ライフサイクル：test／deps／review／perf）→ 1.8（振る舞い）→ 2（事後分析）→ 3（レトロスペクティブ）→ 4（forge）→ 5（フェーズの要約）。ステップ間で停止してはいけません。このファイルでは、実行可能なワークフロー、ゲートの詳細、ブロック条件、フェーズ要約の形式、フェーズ予算、高コストコマンドのポリシーを定めています。

フラグ

フラグ	デフォルト	説明
--complexity=<level>	auto	複雑さのレベルを強制します（fast／standard／full）。/rpi および /discovery と同じ構文です。
--interactive	off	検証レポートのレビュー時（要約の作成前）に人間のゲートを設けます。/vibe の評議会の自律性には影響しません。
--no-lifecycle	off	STEP 1.7 のライフサイクルチェック（test、deps、review、perf）をすべてスキップします
--lifecycle=<tier>	複雑さに準拠	実行するライフサイクルスキルを制御します：minimal（test のみ）、standard（+deps、+review）、full（+perf）
--no-retro	off	レトロスペクティブのステップのみをスキップします
--no-forge	off	forge のステップのみをスキップします
--no-budget	off	フェーズの時間予算を無効にします
--strict-surfaces	off	4 つのサーフェスすべての失敗をブロック対象にします（WARN ではなく FAIL）。/rpi --quality により自動的に渡されます。
--allow-critical-deps	off	CVSS >= 9.0 の脆弱性があってもリリースを許可します（リスクを認識したうえでの受け入れ）。

フラグの相互作用、優先順位、フラグの組み合わせ例については、references/flags.mdを参照してください。

ブラインドサブエージェントによる判定（作成者 ≠ 検証者。同一セッションでも可）

このフェーズで認定される受け入れ判定は、コードを作成していないコンテキスト（ag-9jle.5、ag-lmdx.4 の自己採点禁止の不変条件）によって必ず行われなければなりません。検証は作成セッション内で実行してもかまいませんが、判定者はブラインドサブエージェントでなければなりません。つまり、差分／成果物と受け入れシナリオ（ビードの ## Scenarios ブロックまたは .feature ファイル）だけを与えられた、コンテキストが分離された新しいエージェントです。作成時の会話、計画、推論は決して与えてはいけません。

• STEP 1 では /vibe に委任します。評議会の判定者はコンテキストが分離されたサブエージェントであり、Step 4.5 ではブラインド判定者を起動して、作成コンテキストの author_id とは異なるサブエージェントコンテキストの judge_id を記録します。これが受け入れ判定者です。作成を指揮するオーケストレーターによるインラインの自己レビューに置き換えてはいけません。
• コンテキストが分離された判定者が判定を行っていない場合、受け入れ認定（<promise>DONE</promise> の出力）を拒否してください。つまり、judge_id == author_id の場合です。代わりにブラインドサブエージェント判定者を通して判定をやり直してください。唯一の例外は /vibe --allow-self です（サブエージェントの実行環境が利用できない場合のインラインフォールバック）。これは判定を自己採点として記録し、ao turn verify は独立検証済みではなく、免除扱いとして報告します。

高コストコマンドのポリシー

通常の検証は、デフォルトで対象を絞って行います。go test -race、go test -shuffle、N > 1 の go test -count=N、評価ランナー、検索ベンチマーク、ヘッドレスランタイムのスモークテスト、リリースゲートなど、広範な証明コマンドを実行するには、オペレーター、リリース、または受け入れ基準のコンテキストが明示的に必要です。実行する場合は、フェーズサマリーに理由とタイムアウトを記録してください。

リリース対象の作業を検証する場合は、出荷前に通過する必要がある追加ゲートについて、references/release-readiness-gates.md を参照してください。

クイックスタート

/validation ag-5k2                        # validate epic with full close-out
/validation                               # validate recent work (no epic)
/validation --complexity=full ag-5k2      # force full council ceremony
/validation --no-retro ag-5k2             # skip retro only
/validation --no-forge ag-5k2             # skip forge only

出力仕様

形式： 標準出力への Markdown サマリーと、ディスク上の成果物。書き込まれるファイル：.agents/rpi/phase-3-summary-YYYY-MM-DD-validation.md（フェーズサマリー）、.agents/post-mortems/YYYY-MM-DD-<topic>.md、.agents/learnings/<slug>.md、.agents/findings/registry.jsonl（追記）、.agents/ratchet/state.json。終了シグナル： 完了マーカー（以下を参照）。

完了マーカー

<promise>DONE</promise>    # Validation passed, learnings captured
<promise>FAIL</promise>    # Vibe failed, re-implementation needed (findings attached)

トラブルシューティング

references/troubleshooting.md を参照してください。

参考ドキュメント

• references/validation.feature — 実行可能な仕様：基準からテストへの集約、厳格な委任、verdict.json、厳格サーフェスのブロック（soc-qk4b.2）
• references/dag.md — 実行可能なワークフロー、ゲートの詳細、ブロック条件、フェーズサマリーの形式、フェーズ予算、高コストコマンドのポリシー
• references/per-criterion-rubric.md — 基準ごとの判定基準とランナーの契約
• references/step-1.8-behavioral-validation.md — STEP 1.8 のホールドアウトとエージェント仕様評価評議会
• references/four-surface-closure.md — 4 つのサーフェスの完了検証（コード＋ドキュメント＋サンプル＋証明）
• references/forge-scope.md および references/idempotency-and-resume.md — forge のスコープ設定、再実行時の動作、スタンドアロンモード
• references/remote-and-multi-repo-validation.md
• references/phase-data-contracts.md — フェーズ成果物のデータ契約（references/isolation-contract.md から引用）