tiered-audit

段階的監査

使用する場合

• コードベースの品質、パターン、問題を監査するとき
• マージ前にブランチでの変更内容をレビューするとき
• 不安定な領域や変更の多い領域を調査するとき
• PR 前に品質を評価するとき

使用しない場合

• 特定のファイルをレビューするとき（pensive:code-reviewer を使用）
• アーキテクチャのみをレビューするとき（pensive:architecture-review を使用）
• 1 件のコミットをレビューするとき（imbue:diff-analysis を使用）

Tier 1：Git 履歴監査

必ず最初に実行します。 ソースファイルを読み込まずに git log、差分の統計情報、blame を分析し、懸念のある領域を特定します。

Tier 1 での分析内容

対象のコミット範囲（デフォルトでは、現在のブランチと trunk の比較）に対して Tier 1 スクリプトを実行します。

python3 "${CLAUDE_PLUGIN_ROOT}/scripts/tiered_audit.py" --base {base}
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/tiered_audit.py" --base {base} --json

4 つの git クエリ（ファイルの変更頻度、修正を重ねたコミットの件名、コミットごとの差分サイズ、新たに追加されたファイル）を実行し、pensive.skills.tiered_audit のしきい値（モジュール内の 3 ファイル以上が変更され、そのうち 1 ファイルが 2 回を超えて変更された場合、1 つのコミットで 200 行以上が変更された場合、モジュールに 5 ファイル以上が新規追加された場合）を適用します。各フラグは、その根拠となった [E{n}] Command: の横に出力されるため、調査結果ファイルで根拠をそのまま引用できます。--json を指定すると、Tier 2 向けの escalation_targets と escalate 判定が追加されます。

検証： 活発なブランチなのにレポートが空の場合、範囲が正しくありません。結果を信頼する前に、git merge-base {base} HEAD で {base} が解決されることを確認してください。

Tier 1 の出力形式

調査結果を .coordination/agents/tier1-audit.findings.md に記述します。

---
agent: tier1-audit
tier: 1
evidence_count: {N}
---

## Summary

{1-2 sentence overview of what the git history reveals}

## Churn Hotspots

{top 10 most-changed files with change counts}

For each flagged file, include:
- Location: path/to/file.py:line (most-changed function or block)
- Anchor: `verbatim source text at that line`

[E1] Command: git log --format="" --name-only ...
     Output: {relevant output}

## Fix-on-Fix Patterns

{commits that fix previous commits in the same area}

[E2] Command: git log --oneline ... | grep -iE ...
     Output: {relevant output}

## New File Clusters

{modules with 5+ new files}

## Large Diffs

{commits with 200+ line changes}

## Escalation Recommendation

{list of areas flagged for Tier 2, or "no escalation needed"}

エスカレーションの判断

Tier 1 の完了後、調査結果を modules/escalation-criteria.md のエスカレーション基準と照合します。

基準を満たさない場合：監査は完了です。調査結果を報告します。

基準を満たす場合：フラグが付いた領域を列挙し、各領域について順番に Tier 2 に進みます。

Tier 2：対象領域の監査

Tier 1 でフラグが付いた領域に対してのみ実行します。 フラグが付いた領域は並列ではなく、1 つずつ監査します。

Tier 2 での分析内容

フラグが付いた各領域について、次の項目を確認します。

1. その領域のソースファイルを読みます
2. パターン、アンチパターン、バグを確認します
3. テストカバレッジが存在することを検証します
4. ドキュメントが最新であることを確認します
5. アーキテクチャとの適合性を評価します

Tier 2 の出力形式

領域ごとに 1 つの調査結果ファイルを作成します。 .coordination/agents/tier2-{area-name}.findings.md

各ファイルは監査の出力契約に従います （imbue:proof-of-work/modules/output-contracts を参照）。

Tier 3：コードベース全体の監査

ユーザーの明示的な承認が必要です。 ゲートのプロトコルについては、 modules/escalation-criteria.md を参照してください。

Tier 3 では、ファイルベースの調整を用いた専用セッション（領域ごとに 1 つ）を使用し、並列サブエージェントは使用しないでください。

出力契約

すべての Tier で次の契約を使用します。

output_contract:
  required_sections:
    - summary
    - evidence
  min_evidence_count: 3    # Tier 1
  # min_evidence_count: 8  # Tier 2
  expected_artifacts: []
  retry_budget: 1
  strictness: normal

Tier 2 はソースファイルを読み込み、より詳細な分析を行う必要があるため、必要な根拠の最小件数を 8 件に引き上げます。

検証： 各 Tier の完了後、次の Tier に進むか結果を報告する前に、調査結果ファイルが存在し、必要な最小件数の根拠（[E1]、[E2] など）が含まれていることを確認します。

調査結果の根拠を確認する（tiered-audit:findings-verified）

調査結果を .review/findings.json に記述し、引用検証ツールを実行します （Skill(imbue:review-core) の Step 5）。検証ツールが却下した項目は削除するか、UNVERIFIED とラベル付けしてください。

終了基準

• Tier 1 の調査結果ファイルが .coordination/agents/tier1-audit.findings.md に存在し、 根拠が 3 件以上（[E1]–[E3]）含まれている。
• Tier 2 は、Tier 1 のエスカレーション基準で明示的にフラグが付いた領域に対してのみ開始されている。
• 報告するすべての調査結果に、citation_verifier.py で確認済み（終了コード 0）の Location と逐語的な Anchor が含まれている。または、未検証の調査結果が削除されているか、UNVERIFIED とラベル付けされている。