verification-audit

検証監査

担当：検証レコードの作成、検証、および決定論的なクレームの削減です。エビデンス、不変条件、境界差分、ゲート、プロバイダーの機能、マージの承認を解釈し、最終的な判定を下す唯一のスキルです。

規範的な契約一式は次のとおりです。

• 検証レコードのリファレンス
• バージョン管理された JSON 契約
• scripts/verification_contract.py

他のスキルは事実を収集したり、ギャップを指摘したりできます。このポリシーを独自に実装してはなりません。

入力

呼び出し元から提供された正規化済みチケット ID、Ticket Envelope アーティファクト参照、凍結済み CandidateRef に加え、次の情報を必須とします。

• 正規化済みチケットの引き継ぎ情報に含まれる受け入れ条件。
• 実装、簡素化、レビュー、QA の各ステージの結果。
• 実際のクラス／結果と因果関係の参照を含むエビデンスレコード。
• 不変条件レジスターと External Boundary Delta。
• ゲートと正規化済みプロバイダーレコード。
• 要求された操作と要求されたクレーム。
• マージが要求された場合は、正確な SHA に対するマージ承認。

欠落、古い、矛盾している、または未検証の重要な入力は、不明またはブロッキングとして扱います。ライブアクセス、プロバイダーのサポート、承認、マージの成功、本番環境での動作を推測してはなりません。

変動入力の上限

• max_volatile_bytes：呼び出しごとに正規化された UTF-8 で 12017 バイト。コンパクトな TK-01 および TK-02 のチェックポイントイベントにおいて、シリアライズされた verification_inputs ペイロードで観測された最大値です。
• max_single_output_bytes：12017。同じく観測されたペイロードに基づきます。

貼り付けられたステージ結果、エビデンス本文、プロバイダー出力、ツール結果は、CRLF または単独の CR を LF に正規化した後にバイト数を数えます。最初に正規化済み入力マニフェストを読み込みます。コマンド出力はコンテキストに入る前に切り詰めます。貼り付けられたアーティファクトよりも、パスと SHA-256 の参照を優先します。特定の因果関係または契約上の問いに必要な場合に限り、アーティファクト本文を読み込み、そのバイト数を同じ合計に加算します。次に必要な読み込みで上限を超える場合は、正確な残りの参照と budget-exhausted を含むスキーマ 3 の部分チェックポイントを出力し、その事実は不明またはゲート対象のままにします。上限に合わせるために、エビデンスの分類、因果関係の範囲、境界の計上、検証義務、決定論的なクレーム上限を緩めてはなりません。

監査フロー

1. すべてのステージ結果とネストされた成果物を、同一の現在の CandidateRef に紐付けます。
2. 契約バージョン 1 に照らして、ID、参照、必須のマッピング、境界の完全性、ゲートの整合性を検証します。
3. エビデンスが変更された因果メカニズムを通じて得られており、その観察が許容する範囲を超える強度のクラスが付与されていないことを確認します。
4. 外部に影響するすべての変更に、明示的な処置、インバリアント、エビデンス／QA マッピング、クレームマッピングがあり、未解決の場合はゲートが設けられていることを確認します。
5. プロバイダーの能力と変更に関する観察を正規化します。必須の能力が利用できない場合、プロバイダー能力ゲートを明示的にちょうど 1 つ設ける必要があります。
6. 該当する場合、正確な HEAD に対するマージ承認を検証します。
7. schema-3 の各リーフについて、Verification Record のスキーマを変更せずに、その隔離情報を既存のステージ制限に反映します。共有コンテキストまたは不明な隔離状態で独立性を主張する場合は、制限と明示的な unsupported-independence ゲートが必要です。
8. 決定論的リデューサーを実行します。宣言された実装ステータス、最大クレーム、リリースステータス、最終処置は、リデューサーの出力と完全に一致する必要があります。

ticket-autopilot が検証チェックポイントアダプターを提供する場合、セマンティックバンドルの入力を一度だけ生成し、ランナーにシリアライズ、ハッシュ化、検証、リデュース、再開を任せます。このスキルは、引き続きすべてのエビデンス分類、境界の承認、矛盾、不確実性、ゲート、最終文言を担います。ランナーは、このスキルの validate_bundle 関数と reduce_claims 関数を注入する必要があります。チェックポイントのキャッシュヒットによって以前の出力をそのまま再利用できるのは、CandidateRef と正規化された入力ハッシュが変更されていない場合に限ります。スキップ、シミュレーション、ブロック、または利用不能なライブ境界は、明示的な入力として残し、チェックポイントによって格上げしてはなりません。

コマンド

VERIFICATION_AUDIT_ROOT は、利用可能なスキルカタログまたはこの SKILL.md の場所から解決された絶対スキルルートを意味し、リポジトリの cwd を基準にしてはなりません。

python3 -B "$VERIFICATION_AUDIT_ROOT/scripts/verification_contract.py" validate <bundle.json>
python3 -B "$VERIFICATION_AUDIT_ROOT/scripts/verification_contract.py" reduce <bundle.json>
python3 -B "$VERIFICATION_AUDIT_ROOT/scripts/verification_contract.py" \
  validate-pr <bundle.json> <body.md> --pr-head-sha <observed-sha>

Ticket Markdown の解析はスケジューラーではなく、正規の ticket_contract が担います。このスキルが使用するのは、検証済みの ID、Ticket Envelope 成果物参照、CandidateRef のみです。Markdown や文章からチケット ID を再特定することはありません。スキルのみを利用する呼び出し元は、実行台帳なしでこれらをスキルのみの契約を通じて提供できます。同一のバリデーター、現在の候補へのバインド、リデューサー、権限チェックが適用されます。

出力

ランナーへの引き継ぎでは、schema-3 の verify リーフ結果と検証済みバンドルを返します。その schema-1 quality エビデンスを、正確な handoff-ready チェックポイントハッシュと CandidateRef に紐付けます。中断は、合格とはならない部分的な引き継ぎとして扱います。単独で使用する場合は、検証済みバンドルと簡潔な監査サマリーを返します。

• CandidateRef と成果物バージョン
• 実装ステータスと最終処置
• クレームの上限、および許可／禁止される表現
• 阻害要因となる不足項目と未解決のゲート
• プロバイダーの制限とマージ承認の状態
• 残存する不確実性

実行時やリリースに関する重要なクレームが存在しない場合、監査は該当しないと明記します。契約を確立できない場合は、不完全な PASS を出力せず、安全側に倒して失敗させます。