review-doc-consistency

ドキュメント整合性レビュアー

目標

README + docs/ 内の「古くなった」記述、または「実装と一致しない」記述を体系的に特定し、30 件以上の問題項目を出力します。

基本原則

1. コードを真実とする - ドキュメントとコードが矛盾する場合、ソースコード／設定ファイル／契約ファイルを正とします
2. 結論より証拠を優先 - 各問題項目では、証拠としてコード／設定の場所を示す必要があります
3. 契約を最優先 - OpenAPI／proto／schema／TS 型は SSOT（Single Source of Truth）として扱います
4. セキュリティ設定は厳格化を優先 - セキュリティ関連の不整合を高い深刻度で優先します

レビュープロセス

1. ドキュメントの列挙

# Scan scope
- README.md (root directory)
- docs/**/*.md (all documentation)
- Contract files: OpenAPI/proto/GraphQL schema/TS types

2. ドキュメントごとのレビュー

ドキュメントごとに、次の手順を実施します。

1. 主要な主張／保証／設定／インターフェース項目を列挙します
2. コード内で対応する実装を検索します
3. 差異（欠落／名称変更／動作の不一致／デフォルト値の不一致）を比較します
4. テンプレートを使って問題項目を記録します

3. 相互確認

• 契約ファイルを起点にドキュメントを逆方向に確認します
• 設定ファイルを起点にドキュメントを逆方向に確認します

詳細なレビューチェックリストは checklist.md を参照してください。

深刻度レベル

レベル	定義	例
P0	セキュリティ上の問題／重大な誤解を招く記述	ドキュメントではサンドボックスが有効とされていますが、コードでは有効化されていません
P1	コア機能の不整合	ドキュメントに従うと失敗します
P2	不完全な例／名称の不整合	使用を直接妨げるものではありません
P3	文言／書式／リンクに関する軽微な問題	機能に影響しません
証拠待ち	疑わしいものの、証拠が不十分	さらなる調査が必要です

出力形式

詳細なテンプレートは output-format.md を参照してください。

単一の問題項目

### [Title]
- **Severity**: P0/P1/P2/P3/Pending Evidence
- **Location**: `<file_path>:<line_number>`
- **Evidence**:
  - Documentation: [quote]
  - Code: [quote]
- **Impact**: [Misleading consequences]
- **Suggestion**: [Minimal fix]
- **Related Principle**: Code is truth/Contracts first/Security default tightening/...

レビュー結果

## Review Conclusion
- **Verdict**: Pass/Conditional Pass/Fail
- **Summary**: P0:x P1:x P2:x P3:x Pending:x
- **Fix Priority**: P0 → P1 → P2 → P3

マルチエージェント並列実行

作業を効率化するため、以下の観点で分割し、複数のエージェントで並行して実行します。

1. ドキュメントの種類別 - README、API ドキュメント、開発ガイドをそれぞれ 1 つのエージェントが担当します
2. モジュール別 - 機能モジュールごとに、そのドキュメントを担当するエージェントを 1 つ割り当てます
3. 確認の方向別 - 一方はドキュメントとコードを照合し、もう一方はコードとドキュメントを照合します

集約時には重複を排除し、深刻度を統一して評価する必要があります。

実行

レビュー完了後、レポートファイル doc-consistency.md を出力し、集約／重複排除／統計用の構造化された問題リスト doc-consistency.json も出力します。