レビュールール（AI相互レビューと人間の裁定）
タイミング
apps/・packages/の振る舞いを変える変更は、push（PR運用ならマージ）前に必ず1回、実装とは別セッションのAIでレビューするdocs/のみの修正は省略してよい（開発サイクルのライトルート）
レビュー観点
実装の経緯は渡さず、差分（git diff）とプランだけを渡して次の観点で読む。
- 仕様整合 —
docs/spec/の正式ページと食い違っていないか。用語の意味がずれていないか。未解決論点を勝手に決めていないか - プラン整合 — プランの受け入れ条件・テストケースに対応する変更があるか。プランにない変更が混入していないか
- テスト — 変更に対応するテストの有無。骨抜きテストの検出（テストルール）
- 設計 — 1ファイル1責務・依存の向き（アーキテクチャルール）。今の開発フェーズに対して重すぎないか
- 異常系 — 境界値の両側、空データ、非同期の失敗経路。MSW の都合だけで起きる経路は P2 にする
Claude Code では観点2・4を design-reviewer、観点5を edge-case-reviewer、観点1を spec-reviewer のサブエージェントが担当する（.claude/agents/）。他のツールでは、観点ごとに別セッションを立てて同じ依頼をする。担当のモデルの段は、設計の判断が要る観点2・4を強い、照合と網羅が中心の観点1・5を標準にする。
指摘の優先度分類
- P0（必須修正） — 仕様との矛盾・データ破壊・機能の誤り。push／マージをブロックする
- P1（推奨修正） — 深刻なバグの芽・テスト網羅の欠落。合理的理由があればスキップ可
- P2（軽微） — スタイル・命名・起きにくい経路。その場では直さず、既知の問題「見送った軽微な指摘（P2）」に1行で記録して終わる
各指摘には file:line と根拠（どのルール・どの仕様ページとずれるか）を添える。
終わりの条件
- P0・P1 がゼロなら合格。P2 だけなら、直さずに記録して push／マージする
- P0・P1 を直した後の再レビューは、P0・P1 を出した観点だけで行う
- 3ラウンドを超えて指摘が循環したら、人間が裁定する（AIどうしで決着させない）
静的レビューの限界
差分を読むAIレビューでは、表示崩れや行き止まりといった実行時のバグは捕まらない。画面を変えたら、人間レビューの前にAIがブラウザで変更した画面を操作して確かめ、スクリーンショットを添える。最後に人間も動かして確かめる。