RULES.md — 開発ルール詳細ファイル
バージョン：v3.0 | このファイルはプロジェクトルートに置く
1. 開発の基本ルール
Rule-001：SRS First（要件定義優先）
実装を始める前に必ずSRSを確認する。 SRSに記載のない機能は実装しない。 SRSを変更したい場合は、コードを変更する前にSRSを更新する。
Rule-002：Test First（テスト優先）
機能を実装する前にテストを書く（TDD: Test-Driven Development）。 テストが通過してから次の機能に進む。 テストを削除・スキップして「完了」と報告することは禁止。
Rule-003：Small Steps（小さなステップ）
1回のコミットで変更するファイルは最大5ファイルまで。 1つの機能を実装したらすぐにコミットする。 大きな変更は小さなステップに分割する。
Rule-004：Document As You Go（随時ドキュメント更新）
実装しながらprogress.mdを更新する。 バグを修正したらbugs_and_fixes.mdに記録する。 セッション終了前に必ずドキュメントを更新する。
Rule-005：No Broken Windows（壊れた窓を放置しない）
テストが1つでも失敗している状態で新機能を実装しない。 警告（Warning）を無視して進まない。 技術的負債を発見したら即座に記録し、計画的に解消する。
2. レビューループのルール
Review-001：実装→テスト→レビューのサイクル
1. 要件確認（SRSを読む）
↓
2. テスト作成（Given-When-Then形式）
↓
3. 実装（テストが通過するまで）
↓
4. セルフレビュー（CONSTRAINTS.mdのチェックリスト）
↓
5. AGENT-REVIEWによるレビュー
↓ 問題あり → 3に戻る
↓ 問題なし
6. コミット
Review-002：レビューチェックリスト
機能レビュー： - [ ] SRSの受け入れ基準（Given-When-Then）を全て満たしているか - [ ] エッジケース（空入力・最大値・最小値）を処理しているか - [ ] エラー処理が適切か
コード品質レビュー： - [ ] 関数が単一責任を守っているか - [ ] 命名が分かりやすいか - [ ] コメントが適切か - [ ] 重複コードがないか
セキュリティレビュー： - [ ] 入力値が検証されているか - [ ] 認証・認可が適切か - [ ] 秘密情報がコードに含まれていないか
テストレビュー： - [ ] テストカバレッジが80%以上か - [ ] テストが意味のある検証をしているか - [ ] テストが独立して実行できるか
3. E2Eテストのルール
E2E-001：E2Eテストシナリオの作成タイミング
- Phase 1開始前にE2Eシナリオを作成する
- シナリオはユーザーの実際の操作フローを表現する
- 「ハッピーパス」と「エラーパス」の両方を作成する
E2E-002：E2Eテストシナリオの形式
## シナリオ名：[機能名] - [正常系/異常系]
**前提条件（Given）：**
- [テスト開始時の状態]
**操作手順（When）：**
1. [操作1]
2. [操作2]
3. [操作3]
**期待結果（Then）：**
- [確認すべき結果1]
- [確認すべき結果2]
**テストデータ：**
- [使用するテストデータ]
E2E-003：E2Eテストの実行タイミング
- Phase完了時に全E2Eシナリオを実行する
- 本番移行前に全E2Eシナリオを実行する
- 大きな変更後に関連するE2Eシナリオを実行する
4. コンテキスト枯渇対策のルール
Context-001：progress.mdの必須項目
progress.mdには以下を必ず記録する：
# progress.md
## プロジェクト状態
- 現在のフェーズ：[Phase 1/2/3]
- 完了した要件：[FR-AUTH-001, FR-AUTH-002, ...]
- 未完了の要件：[FR-ART-001, FR-ART-002, ...]
## 今日の作業
- 実装した内容：[内容]
- 発生した問題：[問題]
- 解決方法：[解決方法]
## 次のアクション（新セッション開始時に確認）
1. [次にやること1]
2. [次にやること2]
3. [次にやること3]
## 学んだこと
- [学んだこと1]
- [学んだこと2]
## 未解決の問題
- [問題1]：[状況]
- [問題2]：[状況]
## 最終更新：[YYYY-MM-DD HH:MM]
Context-002：セッション切り替えのサイン
以下のいずれかが発生したらセッション切り替えを実施する： 1. 会話が50往復を超えた 2. Claudeが「前の会話の内容が分からない」と言い始めた 3. 同じエラーを3回繰り返した 4. レスポンスが著しく遅くなった・長くなった 5. 実装が迷走し始めた（同じ場所を何度も修正している）
Context-003：新セッション開始の手順
新しいセッションを開始します。
以下のファイルを順番に読んでください：
1. CLAUDE.md（プロジェクト設定・ルール）
2. CONSTRAINTS.md（制約事項）
3. docs/SRS_v1.md（要件定義書）
4. docs/progress.md（現在の進捗）
読み終わったら、以下を報告してください：
1. 現在のプロジェクト状態
2. 次に実施すべきアクション
3. 未解決の問題
確認できたら作業を再開してください。
5. メモリ・ログ・DB活用のルール
Memory-001：ファイルベースのメモリ管理
Claudeのコンテキストウィンドウに頼らず、ファイルに記録する：
docs/
├── progress.md # セッション間の状態継承
├── bugs_and_fixes.md # バグと解決方法の蓄積
├── decisions.md # 設計上の意思決定記録
└── glossary.md # プロジェクト固有の用語集
Memory-002：decisions.md（意思決定記録）
# decisions.md — 設計上の意思決定記録
## [YYYY-MM-DD] 決定事項：[タイトル]
**背景：** [なぜこの決定が必要だったか]
**選択肢：**
- 選択肢A：[内容] → [メリット/デメリット]
- 選択肢B：[内容] → [メリット/デメリット]
**決定：** [選択した選択肢]
**理由：** [選んだ理由]
**影響：** [この決定が影響するファイル・機能]
Log-001：ログの活用
エラーが発生した場合：
1. エラーログを確認する（ログファイルの場所：logs/error.log）
2. エラーメッセージをそのままAGENT-DEBUGに渡す
3. 解決後にbugs_and_fixes.mdに記録する
DB-001：データベース操作の安全ルール
本番DBの操作前に必ず実行すること：
1. バックアップを取得する
2. ステージング環境で同じ操作を試す
3. dry-runオプションで影響範囲を確認する
4. ロールバック手順を準備する
5. 実行後に結果を確認する
6. ディレクトリ構造のルール
Dir-001：標準ディレクトリ構造
[プロジェクト名]/
├── CLAUDE.md # プロジェクト設定（必須）
├── CONSTRAINTS.md # 制約事項（必須）
├── AGENTS.md # エージェント設定（必須）
├── RULES.md # 開発ルール（必須）
├── docs/
│ ├── SRS_v1.md # 要件定義書（必須）
│ ├── SDD_v1.md # 設計書（必須）
│ ├── TEST_PLAN_v1.md # テスト計画書（必須）
│ ├── progress.md # 進捗管理（必須）
│ ├── bugs_and_fixes.md # バグ記録（必須）
│ └── decisions.md # 意思決定記録（推奨）
├── src/ # ソースコード
├── tests/
│ ├── unit/ # ユニットテスト
│ ├── integration/ # 統合テスト
│ └── e2e/ # E2Eテスト
├── scripts/ # 自動化スクリプト
│ ├── setup.sh # 環境構築
│ ├── migrate.sh # DB移行
│ └── deploy.sh # デプロイ
└── .env.example # 環境変数のサンプル（.envは.gitignore）
Dir-002：ファイル整理のルール
✅ 関連するファイルは同じディレクトリにまとめる
✅ テストファイルは対象ファイルと同じ構造で配置する
✅ 設定ファイルはルートまたはconfigディレクトリに置く
❌ ルートディレクトリに多くのファイルを散らかさない
❌ 一時ファイル（temp_、test_）をコミットしない
❌ 未使用ファイルを残さない（削除するかアーカイブする）