# SDD設計レビュー規約

技術設計ドキュメントの品質レビューのルール。

## 原則

| 原則 | 基準 |
|------|------|
| 品質保証 | 完璧を求めず、許容可能なリスクで判断する |
| 重大問題集中 | 指摘は最大3件。成功に大きく影響するものだけ |
| バランス | 問題点だけでなく強みも認める |
| 実行可能性 | すべての提案は実装可能であること |

## レビュー観点

### 既存アーキテクチャとの整合性（最重要）

- 既存のシステム境界・レイヤーとの統合
- 確立されたアーキテクチャパターンとの一貫性
- 依存方向・結合度の管理
- 現行モジュール構成との整合

### 設計の一貫性と標準

- プロジェクト命名規約・コード標準への準拠
- エラー処理・ログ戦略の統一性
- 設定・依存管理の統一性
- データモデリングパターンとの整合

### 拡張性と保守性

- 将来の要件に対する設計の柔軟性
- 関心の分離・単一責任
- テスト容易性・デバッグ容易性
- 要件に対する複雑さの妥当性

### 型安全性とインターフェース設計

- 適切な型定義・インターフェース契約
- `any`型等の安全でないパターンの回避
- 明確なAPI境界・データ構造
- 入力バリデーション・エラー処理のカバレッジ

## 判定

| 判定 | 条件 |
|------|------|
| GO | アーキテクチャ的な重大な不整合なし、要件が対処済み、実装パスが明確、リスクが許容範囲内 |
| NO-GO | 根本的な矛盾、重大なギャップ、高い失敗リスク、不釣り合いな複雑さ |

## トレーサビリティ

- 各指摘を `requirements.md` の要件IDに紐づける
- 設計ドキュメントのセクション/見出しをエビデンスとして引用する
