plan-audit

計画の監査

概要

完了した作業を計画（WI、受け入れ基準、テスト）と照合して監査し、ファイル名と行番号を示しながら、ギャップ、ロジックエラー、カバレッジ不足を報告します。

ワークフロー（監査）

1. 計画を特定する

   • dev-docs/plans/<plan>.md を優先します。
   • 不明な場合は、計画のパスまたは WI の一覧を尋ねます。

2. 監査チェックリストを作成する

   • 各 WI について、以下を列挙します。
     • 目標
     • 受け入れ基準
     • 必要なテスト
     • 変更対象の領域（ファイル／シンボル）

3. 実装を WI に対応付ける

   • git log、git show --stat、rg、ファイルの調査を使用します。
   • 各 WI を満たすファイル／コミットを記録します。

4. ギャップと正確性を分析する

   • 各受け入れ項目を実際の動作と照合します。
   • ロジックエラー、エッジケースでの失敗、不完全なフローを特定します。
   • 「テスト（先行）」セクションに照らして、テストカバレッジを検証します。
   • 計画で仕様が参照されている場合は、実装がその仕様と一致することを確認します。
   • 計画に受け入れ基準やテストが不足している場合は、計画の品質に関するギャップとして記録します。

5. 指摘事項を報告する

   • 重大度の高い順に並べます：Critical → High → Medium → Low。
   • 各指摘事項には、以下を含める必要があります。
     • WI 参照
     • ファイルパスと行番号
     • 計画に違反している理由
     • 計画で定められた期待される動作

出力形式（必須）

• 指摘事項（重大度順）
  • File:line と WI 参照
  • 影響と推奨する修正
• 計画のギャップの概要
  • WI‑### → 受け入れ項目の不足／一部不足
• テストカバレッジのギャップ
  • 不足しているテスト、失敗しているテスト、または「テスト未作成」
• 注記／リスク
  • 前提や未検証の領域
• 根拠
  • 各指摘事項について、具体的な根拠（ファイル／行番号／コミット ID）を示します。

監査ルール

• ユーザーから明示的に依頼されない限り、ここではテストを実行しないでください。これは調査のみの段階です。
• 仕様とのずれには厳密に対処し、動作が計画の記述と異なる場合は指摘してください。
• 計画を特定できない場合は、作業を中止して計画を尋ねてください。