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 サブエージェントを2～3個起動します（役割：Mutation Reviewer (<Target Slice>)）。各サブエージェントには、以下を与えます。
     • 割り当てられた差分範囲と対象ファイルのポインター。
     • 特定した準拠すべき契約と不変条件のベースライン。
     • 二重引用ルールと正式な出力仕様。

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

1. サブエージェントの指摘を正式な出力仕様に統合し、重複を取り除きます。
2. 最終的なエグゼクティブ判定を決定します（すべてのスライスが合格した場合に限り PASS とし、最も重大な欠陥に応じて CONDITIONAL または FAIL に引き下げます）。
3. レポートを会話ストリームに出力し、直ちにターンを停止します。