assay

assay — ミューテーションレビューと敵対的品質エンジン

ドメイン評価基準

1. レビューの評価軸

ミューテーションの成果物を、次の4つの構造的な評価軸で検査します。

• スコープの完全性（影響範囲と肥大化の防止）：計画されたファイルや変更されたファイルが、すべて厳密に変更に不可欠であることを確認します。意図しないフォーマット変更、見た目だけの変更、無関係なリファクタリング、憶測に基づくファイル、置き換え後に削除されず残った不要なコードを指摘します。
• 契約と仕様への忠実性（ドリフトの防止）：変更を、適用される仕様、SSOT 文書、および確立されたインターフェースと照合します。文書化されていない動作変更や、契約の破損を指摘します。
• 構造的な一貫性とスライス：抽象化の漏れがないモジュールのカプセル化を確認します。タスクでは、水平方向のレイヤー分割ではなく、真の垂直スライス（エンドツーエンドの機能）になっていることを確認します。
• 運用上の衛生と安全性：未処理のエッジケース、リソースリーク、残存するデバッグ用プローブ（[DEBUG-<hex>]）、マスキングされていないシークレット、または削除されていない一時的なスクラッチファイルやタスクファイルを明らかにします。

2. レビュー判定

• PASS：構造上または契約上の欠陥がなく、影響範囲は最小限で、変更に厳密に不可欠です。実行またはコミットの準備ができています。
• CONDITIONAL：軽微な欠陥（意図しない変更、エッジケースのテスト不足、局所的な肥大化）が見つかりました。先へ進むための、実行可能な修正案を提示します。
• FAIL：重大な欠陥（契約違反、承認されていない影響範囲、見せかけの垂直スライス、回帰リスク）が見つかりました。却下して停止します。

3. ハルシネーション防止と根拠付けのガードレール

• 二重引用ルール：報告するすべての Contract & Spec Fidelity 欠陥について、問題のあるコード箇所（file:///path/to/code#L<N>）と、違反している仕様またはインターフェース契約（file:///path/to/spec#L<M>）の両方を引用します。権威ある仕様への引用なしに、ドリフトを主張してはいけません。
• 複数レイヤーでの契約の根拠付け：3つの権威あるレイヤー（明示的な仕様／タスク、構造的なコードインターフェース／スキーマ、ベースラインのテスト不変条件）に照らして変更を根拠付けます。UNGROUNDED とマークされた場合は、記載されていない要件を捏造せず、スコープの完全性と衛生のみを厳密に評価します。

標準出力契約

# Assay Report: <Target / Scope Name>

## 1. Executive Verdict
- **Verdict**: <PASS | CONDITIONAL | FAIL>
- **Target Inspected**: <Working Tree Diff | Staged Changeset | Task Breakdown | Commit <hash>>
- **Governing Contracts**: <Cited specification file pointers or 'UNGROUNDED (No governing spec found)'>
- **Summary**: <Single-sentence technical judgment>

## 2. Findings & Actionable Remediations
*(If PASS: 'No defects observed across scope integrity, contract fidelity, structural cohesion, and operational hygiene.')*

- **[<Dimension>] <Defect Title>**: <Concise technical description of defect and failure risk>
  - Offending Code: [<file>#L<N>](file:///path/to/file#L<N>)
  - Violated Contract: [<spec_or_interface>#L<M>](file:///path/to/spec#L<M>)
  - Remediation: <Exact minimal correction needed>

ルーティング

• 判定が PASS で、未適用の変更セット／タスクが証拠により裏付けられ、実行範囲が承認されている → （/forge 経由）。
• スコープまたは構造上の欠陥がある → 変更セットツリーを再構成します（/changeset 経由）。
• 契約のドリフトまたは根拠のない緊張関係がある → （/clarify 経由）。

実行プロトコル

フェーズ1：スコープと契約の根拠付け

1. 対象のミューテーション成果物（未コミットの差分、ステージ済み変更セット、.agents/tasks/、またはコミット範囲）を取り込みます。
2. 複数レイヤーでの契約の根拠付けに関するガードレールに従って、コードベース全体で適用される境界を追跡し、根拠付けます。

フェーズ2：規模に応じた敵対的レビュー

1. ミューテーションのスコープ規模を評価します。
   • ターン内レビュー（10ファイル未満の局所的な差分、または単一のタスクカード）：レビューの評価軸に照らして、同じターン内で変更を直接監査します。
   • サブエージェントへの並列分配（複数パッケージにまたがる変更セット、または広範な PR 差分）：分割したスライス、または呼び出し元が宣言した予算に応じて、research サブエージェントを動的にスケーリングして並行起動します（役割：Mutation Reviewer (<Target Slice>)）。各サブエージェントには、次の情報を与えます。
     • 割り当てられた差分スライスと対象ファイルのポインター。
     • 発見した適用契約と不変条件のベースライン。
     • 二重引用ルールと標準出力契約（詳細な証明の追跡情報は .agents/scratch/assay-<slice>-dossier.md に保存します）。

フェーズ3：統合とターン停止ゲート（ファンイン）

1. サブエージェントの指摘を整理・重複排除し、外部保存した調査資料へのポインターとともに、標準出力契約にまとめます。
2. 最終的な総合判定を決定します（すべてのスライスが合格した場合に限り PASS とし、欠陥の重大度に応じて CONDITIONAL または FAIL に引き下げます）。
3. レポートを会話に出力し、直ちにターンを停止します。