agent-output-audit

エージェントの出力監査

あなたは独立した評価者です。ファイル、公開動作、テスト、CI に基づき、次の問いに答えてください。——「実装エージェントは、task_NN.md に記載された作業を実際に行ったか？」自己申告は証拠ではありません。（実際のユーザーがプロダクトを利用して目的を達成できるかどうかは qa-execution の担当です。Compozy のスラッグに対して両方を実行し、それぞれの出力を分けてください。）

ステップ 1：リポジトリの検証要件を確認する

1. コマンドを実行する前に、ルートの指示、リポジトリのドキュメント、CI／ビルドファイルを読みます。
2. python3 scripts/discover-project-contract.py --root . を実行し、候補となるインストール、検証、ビルド、テスト、リント、起動コマンドと E2E の兆候を確認します。
3. リポジトリで定義された包括的なコマンド（make verify、just verify、CI のエントリーポイントなど）を、言語のデフォルトコマンドより優先します。検出された検証手段が複数ありそうな場合、または複数のエコシステムが混在している場合は、選択する前に references/project-signals.md を読み、選択の決め手を明記します。
4. フローのカバレッジを分類する前に、references/e2e-coverage.md を読みます。
5. 監査成果物のディレクトリを決定します。指定がある場合は audit-output-path 引数を使い、なければリポジトリの慣例に従い、それもなければ /tmp/agent-output-audit-<slug> を使います。その audit/ サブディレクトリを作成し、すべてのバグとレポートを <audit-output-path>/audit/ の下に保存します。
6. Compozy モードを検出します。 .compozy/tasks/<slug>/ が存在する場合は、スラッグを記録し、以下を行います。
   • state.yaml は読み取り専用で読みます。cy-codex-loop の契約により、その変更は scripts/update-state.py が担当します。
   • 存在する場合は _techspec.md（成果物の唯一の情報源）と _tasks.md（タスク一覧）を読みます。
   • すべての task_NN.md を列挙し、フロントマターの status:（pending | in_progress | completed）を記録します。フロントマターと state.yaml が一致しない場合は、フロントマターを正とします。
   • メモリスロット .compozy/tasks/<slug>/memory/qa-execution.md に注意します。ステータスを切り替える前に、ステップ 5 でここに書き込みます。

ステップ 2：ベースラインの検証ゲートを実行する

1. リポジトリで推奨されているコマンドを使って依存関係をインストールします。
2. 監査作業を始める前に、標準ゲートを高速なものから順に一度実行します。リントと型チェック → ビルド → 単体テスト → 統合テスト。
3. E2E コマンドが包括的なゲートとは別にある場合は、今実行するか、実行時の前提条件が整ってから実行するかを判断し、その計画を記録します。
4. ベースラインで失敗があった場合は、最初に失敗した出力を読み、それが既存の問題か、今回の作業で導入された問題かを判断します。クリーンな再現によって無関係であることを確認してから、その失敗を監査の対象外にします。
5. 不安定な失敗への対応手順。 ベースラインの失敗を分類する前に、同じ SHA で失敗したテストを単独で 3～5 回実行します。コードを変更せずに一度でも成功した場合は、合格扱いにせず、テスト名、試行回数、再試行の結果、推定カテゴリを SUITE HEALTH SNAPSHOT に flaky-suspect として記録します。推定カテゴリの割り当てや隔離の提案を行う前に、references/flaky-triage.md を読みます。

ステップ 3：タスクの実装を監査する

タスク、フェーズ、PRD、技術仕様、実装計画の成果物が存在しない場合に限り、このステップを省略します。

1. 判定を下す前に、references/independent-evaluator-protocol.md を最初から最後まで読みます。ここには、何が証拠として認められるか、またトランスクリプトの分類（genuine-failure / grader-bug / ambiguous-task / bypass-exploit）が定められています。Compozy モードでは、実装者の memory/<phase>.md 成果物を読み、タスクを評価する前に、異常の分類を memory/qa-execution.md の「Errors / Corrections」に記録します。
2. 各 task_NN.md とその本文を、Task Implementation Matrix に要約します（列は cy-codex-loop のフロントマターに合わせます）。
   • task_path、declared_status（フロントマターの status: の値をそのまま記載）
   • title、type、complexity、dependencies — フロントマターの値を転記
   • techspec_deliverable — 該当する場合は、リンクされた _techspec.md のセクション
   • 要件、サブタスク、チェックリスト項目、成功基準、依存ファイル
   • implementation_evidence — ファイル、モジュール、ルート、コマンド、マイグレーション、シード、テスト
   • verification_evidence — 実行したコマンド、終了コード、出力の要約
   • qa_verdict — PASS | PARTIAL | FAIL | REOPEN | BLOCKED（declared_status とは別）
   • ai_audit_findings — ステップ 4 で検出されたレッドフラグ ID と判定
   • action — none | fixed | reopened-frontmatter | BUG-NNN.md filed
   • linked_bugs — BUG ID
3. 完了済み、または完了と申告されたすべてのタスクについて、実際のファイル、公開動作、自動テスト、受け入れ基準に照らして検証します。現在のリポジトリの状態に対して、最小限の公開証明を再実行します。
4. qa_verdict を割り当てます。
   • PASS：すべての重要な要件と成功基準について、実装と最新の検証証拠が揃っています。
   • PARTIAL：実装は存在しますが、重要でない要件、テスト、または証拠に不足があります。
   • FAIL：申告された動作が機能しない、または重要な要件が欠けています。
   • REOPEN：フロントマターに status: completed とある一方、QA 判定が PARTIAL または FAIL です。
   • BLOCKED：具体的な前提条件が不足しています。不足している依存関係を必要としないローカルの境界はすべて検証し、ブロックされているライブ検証は別途報告します。

ステップ 4：AI テスト衛生スキャン（RF-1..RF-6）

1. declared_status: completed のタスクのテスト差分をスキャンする前に、references/ai-implementation-audit.md を最初から最後まで読みます。ここには、RF-1..RF-6 のスキャナー、Requirement→Test マッピング、判定マトリクスが定められています。
2. タスクのベースライン以降の差分に対してスキャンを実行します（git log --follow <test_file>、git diff <baseline_sha>..HEAD）。
3. マトリクスに定められた判定を出します。RF-1（挿入された skip/only/xit/t.Skip）、P0/P1 基準に対する RF-2（アサーションの弱体化）、TC で Integration/E2E と宣言された依存関係に対する RF-3（モックの使用）、P0/P1 に対する RF-4（正当化されないスナップショットの変更）は、自動的に FAIL とします。
4. 検出結果をマトリクスの ai_audit_findings 列と、audit-report.md のタスク別ブロックに記録します。
5. Requirement→Test マッピングを適用します。task_NN.md のすべての Success Criterion と、リンクされた _techspec.md のすべての箇条書きについて、該当するテストを covers / weak / missing のいずれかに分類します。チェック済みの項目、または status: completed なのに対応する covers 行がない場合は、監査不合格です。

ステップ 5：再オープン、バグの起票、メモリの記録

1. 未完了の完了済みタスクをすべて REOPEN にします。
2. Compozy モードでは、task_NN.md のフロントマターを変更する前に、cy-codex-loop の標準セクション（Objective Snapshot、Important Decisions、Learnings、Files / Surfaces、Errors / Corrections、Ready for Next Run）を含めて memory/qa-execution.md を作成します（メモリをステータスより先に記録する不変条件）。
3. 問題のある task_NN.md のフロントマターにある status: を pending（修正可能な場合は in_progress）に戻します。state.yaml には触れないでください。これは update-state.py が管理し、次のイテレーションでフロントマターの状態に合わせて調整されます。
4. assets/issue-template.md を使って、<audit-output-path>/audit/issues/ に BUG-<num>.md を起票し、以下を含めます。タスクのパス（Reopens task:）、失敗した成功基準（Summary:）、RF-2 が発生したときの元の厳密なアサーション（Root cause:）、レッドフラグ ID と判定（Automation Follow-up:）、およびトランスクリプトの異常分類（Related:）。
5. 問題が監査範囲内の限定的な根本原因の修正である場合は、修正を実装し、リグレッションテストを追加して、タスクの検証を再実行します。それ以外の場合は、タスクを再オープンします。

ステップ 6：品質ゲートの判定

1. 監査中に最後にコードを変更した後、標準の検証ゲートを最初から再実行します。
2. audit-report.md の「Quality Gates」セクションに、各項目の PASS／FAIL／N/A を記録します。
   • 標準スイートでの不安定なテストの割合が 2% 未満であること。
   • P0／P1 タスクの AI テスト衛生スキャンで FAIL がゼロであること。
   • 未解決の Critical／High の問題がゼロであること。
   • カバレッジの差分がベースライン以上であること（リグレッションがないこと）。
   • P0 フローで未解決の flaky-suspect がゼロであること。
3. いずれかのゲートが FAIL の場合、この実行を無条件の PASS 判定にすることはできません。

ステップ 7：監査レポートの作成

1. assets/audit-report-template.md を使って <audit-output-path>/audit/audit-report.md にレポートを作成し、以下の必須セクションをすべて含めます。
   • ステップ 2 と 6 で実行したコマンドごとの Claim / Command / Exit code / Verdict。
   • AUTOMATED COVERAGE — 検出されたサポート対象、ハーネス、標準コマンド、分類付きの必須フロー、追加または更新された仕様。
   • TASK IMPLEMENTATION AUDIT — Compozy スラッグ、計画のソース、マトリクスの合計、タスクごとの判定、再オープン／修正／ブロックされたタスク、バグへのリンク。
   • SUITE HEALTH SNAPSHOT — 不安定なテストの割合、不安定なテストのイベント数、ミューテーションスコア（ハーネスがある場合）、ベースラインに対するカバレッジの差分、ブロックされた件数、手動のみの件数、AI 監査の検出件数。
   • QUALITY GATES — 各ゲートの PASS／FAIL／N/A。
   • ISSUES FILED — 起票総数、重大度別の件数、Reopens task: 注記。
   • ブロックされたシナリオ、欠落している認証情報、環境上の不足について、実行を妨げた正確なコマンドまたは前提条件とともに報告します。
2. Compozy スラッグでは、最終的な PASS によって、Phase E の前提条件である cy-codex-loop の verify.last_status=PASS が満たされます。update-state.py は cy-codex-loop に任せてください。
3. 監査の完了を宣言する前に、references/checklist.md のすべての項目を確認します。これは全ステップにわたる網羅的な完了基準です。