validate

検証

完了した候補を、元の受け入れ基準に照らして新たに一度だけ判定し、基準ごとの根拠とともに PASS、FAIL、または NOT_PROVEN を返して終了します。 関連項目：助言や二度目の確認は Review、明示された主張が成り立つかどうかは Research を参照してください。このファイルには、判定に必要なルールがすべて記載されています。RPI の境界や 仕組みを含むリンク先ファイルは、理解を深めるためのものにすぎません。読めないファイルがある場合は、このファイルに基づいて判定し、読めなかったファイルを明記してください。

判定を決めるルール

• 作成者は拘束力のある PASS を出せません。また、助言的な所見をこの判定の代わりにすることもできません。作成者の要約、自信、保証は確認すべき主張であり、根拠ではありません。説明だけでは証明になりません。
• 各基準には、対象となる候補そのものに対する個別の根拠が必要です。誰も実証していない基準は not_checked に記載し、PASS の判定には決して含めません。
• テスト、許容範囲、ゴールデンデータ、抑制設定、受け入れ基準の文面を変更しても、元の意図を満たす必要があります。オラクルを弱めて得た成功は、立証するはずだった基準に対する FAIL であり、その成功は根拠になりません。チェックの対象を変更して得た成功も同様です。テストや CI 環境を検知すると異なる動作をする製品コード、空のハンドラーや破棄したエラーによって新たに握りつぶされた失敗経路、ブロックされないように変更されたチェック、スキップされたチェック、迂回されたチェックが該当します。それぞれについて、変更内容から確認でき、かつ元の意図に沿う理由が必要です。
• 実行結果の記録を確認してください。作成者がこの同じ対象に対して実行したチェックや、CI で実行されるチェックを再実行してはいけません。リスク上重要な主張について記録がない場合に限り、再実行してください。
• 必要な指摘を、任意の注意事項や非目標にしてはいけません。

以下の順で判定します。

1. 判定中に対象が変更された、変更されたパスの網羅性が不十分である、または作成者と検証者の身元や鮮度が不明・重複・未証明である場合：NOT_PROVEN。
2. いずれかの基準が満たされないことが立証された場合、または変更がスコープ外であることが立証された場合：他の基準が未検証でも FAIL。
3. スコープ内の基準に根拠が不足している場合：NOT_PROVEN。
4. すべての基準が根拠をもって検証され、確認対象のスコープが空でなく、not_checked も空である場合：PASS。

まず意図を確認する

Validate、受け入れ判定、または元の受け入れ基準が満たされていることの独立した証明を明示的に求められた場合は、「これをレビューして」のような言い方でも、このスキルを選択します。基準が提示されていても、一般的な確認や準備状況の質問では対象になりません。その場合は、助言を求めているのか、受け入れ判定を求めているのかを一度だけ尋ね、回答を待ちます。その間は、判定結果も準備完了の承認も出しません。意図が不明な場合、それは NOT_PROVEN 判定ではありません。共通の振り分けについては、 助言か受け入れ判定かを参照してください。

新たな判定を行う価値がある場合

誤りの代償が大きい箇所に検証を行ってください。通常の変更では、作成者のチェックと CI が関門となり、新たな判定を行う必要はありません。次の場合に Validate を使います。

• 呼び出し元が受け入れ判定または独立した証明を求めている場合。
• 変更が反映された後では、誤りを低コストで元に戻せない場合。たとえば、公開済みリリースやユーザーが従う手順、セキュリティ境界、データやトラッカーの状態の破壊、製品を保護するチェックの削除などです。
• 変更された動作をカバーする決定論的なチェックがない場合。

判定は一度だけ行います。欠落事項とともに NOT_PROVEN を報告し、そこで終了してください。追加のラウンドを求めたり待ったりしてはいけません。作成者が指摘事項を修正した後は、該当するチェックで修正を確認します。二度目の判定を行うのは、呼び出し元がそれを求めた場合だけです。判定にかかるコストは作業コストの一部にとどめてください。作業コストに近づいたら、未確認の項目を示して終了してください。

対象

対象とは、必須チェックと既知の修正を終えた後、そのまま変更されずに保たれている、空でない実装候補です。計画、監査、レビューが対象となるのは、呼び出し元が文書レビューを依頼した場合に限ります。受け入れ失敗を示す証拠が提示されている場合、その対象の判定は FAIL です。修正が進行中のものはレビューしないでください。判定の開始時と終了時に、対象の同一性を確定してください。

• AgentOps がインストールされている場合：ao provenance manifest --root "$REPO_ROOT" --include "$CHANGED_PATH" を実行します。変更されたパスごとに --include を1つ指定してください。
• Git リポジトリ内の場合：コミット SHA（git rev-parse HEAD）と変更されたパス（git diff --name-only <base>...HEAD）を確認します。未コミットの作業については、git status --porcelain の一覧と、変更された各ファイルの shasum -a 256 を確認します。
• 会話内でのみ提示された対象（貼り付けられた差分や、説明された変更など）は、提示された内容そのものが対象です。そこに示されていないものはすべて未検証です。

依頼された振り返りはコードの判定に続いて行うものであり、その判定の証拠にはなりません。意図にコードと振り返りの両方が含まれる場合は、コードの基準を個別に判定し、振り返りが作成されるまで依頼全体を未完了としてください。依頼全体に対する PASS を早期に出してはいけません。振り返りの明示的なレビューが依頼された場合は、その文書をそれ自体の範囲で判定してください。

同一性と鮮度

作成者と検証者の同一性は明示的に示し、互いに異なるものとしてください。また、鮮度はランタイムまたは呼び出し元が、証明者を明示して証明する必要があります。この証明は信頼に関する宣言であり、暗号学的な分離を意味するものではありません。通常の利用では、次のものが該当します。

• 作成者： 候補を作成した人物の同一性として、呼び出し元が指定したもの。人物、セッションまたはエージェント ID、コミット作成者などです。
• 検証者： ランタイムに ID がある場合は、このコンテキストのランタイム ID（サブエージェント ID やセッション ID など）。ない場合は、ディスパッチャーが保持するこのコンテキストの識別子（起動時に返されたエージェント ID など）、または呼び出し元が判定のために開いた「この会話」です。
• 鮮度： このコンテキストが候補を作成しておらず、作成者の作業履歴ではなく、意図、対象、証拠を渡されたことを、誰が証明するのかを明示したうえでランタイム、ディスパッチャー、または呼び出し元が示すこと。呼び出し元が判定のためにこの会話を開き、候補を提示した場合、証明者は呼び出し元です。

役割名、作成者の会話内でのペルソナ切り替え、検証者自身による自己保証は該当しません。同一性を捏造してはいけません。同一性に不備がある場合、結果は NOT_PROVEN となります。レポート内のすべての所見を残してください。

レビュアー

原則として、作成者と同じモデル系列の、鮮度が確認されたレビュアーを1人使用します。Codex/OpenAI には Codex/OpenAI、Claude/Anthropic には Claude/Anthropic を使用し、モデルが固定されていない限り、ランタイムで設定された対応可能なモデルを使います。タスク固有の意図、範囲、対象の正確な内容、関連する証拠を渡し、作成者の完全な履歴、望ましい判定、他のレビュアーの結論は含めないでください。簡潔にしても、必要な証拠を省いてはいけません。基準の判定に必要な場合は、追加のソースを取得してください。

異なるモデル系列によるレビューはオプトインです。--cross-model [model] は AO フラグではなく、スキルのプロンプト選択であり、model-dispatch を通じて、別のモデル系列から鮮度が確認されたレビュアーを追加します。必須のレビュー担当が実行できない場合、もう一方の担当が PASS していても、依頼全体の結果は diversity_unsatisfied かつ NOT_PROVEN となります。任意の多様性を確保できない場合は、その事実を開示しますが、所見を無効にしてはいけません。提出された FAIL と異論はそのまま有効です。投票やモデルの優先度によって意見の分かれた結果を PASS にしてはならず、意見の一致も真実の証明にはなりません。固定の10分制限はありません。実際の呼び出し元やランタイム固有の制限に従い、期限を延長してはいけません。タイムアウトは判定の欠落であり、FAIL ではありません。

判定

1. 対象を確定します。呼び出し元が所有する正確な意図、引用された証拠、変更パス全体の網羅性との連続性を検証します。完全性が欠けている場合は NOT_PROVEN です。
2. 会話または bead に含まれるものも含め、当初受け入れられた動作例を再確認し、正確な候補上で各観測可能な結果とそのドメイン上の意味を確認します。新しいテストや名前を変更した概念で、未達成のシナリオを置き換えることはできません。すべての基準に照らして実際の差分を調べます。ドキュメント内の公開や来歴に関する主張にも、検証可能な証拠が必要です。リスクに応じて調査の深さを決めます。受け入れ、権限、テストとゲート、停止、開示、フック、実行可能な制御については、文章によるポリシーも含め、より深く読み込みます。不明なリスクには調査で対応し、レビュー担当者を増やして対応してはいけません。
3. コマンドは実行前に分類します。再生成、同期、フォーマット、--force は、そうでないと証明されるまで対象を変更する操作です。使い捨てのコピー上、または対象をコミットした後にのみ実行し、判定対象のツリーでは決して実行しません。
4. 対象を再度確定します。不一致がある場合は NOT_PROVEN です。
5. 以下の形式で結果を 1 つだけ、速やかに返し、その後は終了します。

レポート

Verdict: PASS | FAIL | NOT_PROVEN
Subject: <manifest digest, or commit SHA and changed paths>; unchanged start to end: yes | no
Criteria:
  1. <criterion> - verified | failed | not verified - <evidence: file:line, receipt, observed output>
Findings: <class> - <what and where> - <consequence>   (or "none")
Notes (optional, do not change the verdict): <...>
Checked: <what was inspected, and how>
Not checked: <in-scope acceptance not verified>   (empty only for PASS)
Identity: author <id>; validator <id>; freshness attested by <runtime | caller>: <attester>

所見とは、受け入れ基準を満たさないもの、またはユーザーに誤解を与えるもの、インストールや CLI を壊すもの、製品の保護を取り除くものです。それ以外は、作成者が無視してもよい任意の注記です。新しい所見ごとに短く安定した class を付け、再発時も同じものを使い、変更前後の証拠から、既存、導入済み、または変更前の状態が不明のいずれかを明示します。件数やタイムスタンプだけでは原因を特定できません。以前の所見は表示したままにします。not_checked には、対象範囲内のうち検証していない受け入れ項目を記載します。それ以外の制約は、PASS を得るために隠すのではなく、基準に関する理由、明示された非目標、または残存リスクの説明に記載します。受け入れ範囲内のデリバリーは、証拠が揃うまで未検証のままです。PASS に到達するために、その基準を決して削除してはいけません。仕組み では、レポートの適切な分量と、各範囲上の制約を記載する場所について説明しています。

verdict.v2 の意味上の作成者は Validate だけです。 呼び出し元が機械可読な証拠を要求した場合、または宣言済みのコンシューマーがそれを必要とする場合に限り、ao provenance store-verdict (仕組み) を通じて保存します。Go が検証するのは構造と保存であり、真偽ではありません。それ以外の場合は、隠れた機械生成アーティファクトを作成せず、呼び出し元が既に使用しているチャネルを通じて結果を返します。Validate は修復、再試行、デリバリー、トラッカーの遷移を担当しません。既知の所見は直接修正するため作成者に返し、因果関係のある停滞には RPI の単一ヘルパールールを適用します。