実装
Phase 4–6 コア・アプリ・共通作業。
Phase 4〜6 — コア → アプリ → 共通作業 の順で実装する。
やること
- Phase 4 でコア
- 必要なら Phase 5 アプリ層
- Phase 6 でテスト・運用を揃える
完了: 関連テストが green、完了条件を満たした
Plan + docs を冒頭で AI に渡す。完了 → Phase 5
Phase 4 はコアロジック（ビジネスルールが集中する部分）を実装する段階です。命名やディレクトリは 02_design.md と rules に合わせます。DDD なら domain 層、Vertical Slice なら feature 単位、などプロジェクト次第です。
Phase 1 のルールは毎回 AI に渡し、既存パターンから外れないようにします。厳格な TDD を標準にしているチームだけ、下の 10.2 テンプレを使います。それ以外は「テストを足しながら実装」＋レビュー・CI で足りることが多いです。
TDD サイクル（概要）
エージェント TDD 5 ステップ（公式）
出典: Cursor BP。チームが TDD を採用するときの Agent 依頼順。
- 期待入出力付きテストだけを書かせる（実装はまだ書かない）
- テスト実行 → 失敗を確認（RED）
- テストをコミット
- テストを変えずに通る実装を書かせ、green まで反復（GREEN）
- 満足したら実装をコミット · Refactor は時間があれば
Done when を Plan / tasks/todo.md に書く。検証は 18-4-verify。
1 モジュールあたりの典型的なループは次のとおりです。
各フェーズで AI に何を頼み、いつ完了とするかは次の表にまとめています。
| フェーズ | AI への依頼 | 完了条件 |
|---|---|---|
| RED | 失敗テストのみ書く | 対象テストが fail |
| GREEN | 最小実装 | 対象テストが pass |
| REFACTOR | 振る舞いを変えず改善 | 全テスト pass |
対象洗い出し
設計 docs が揃ったあと、まだコードを書かない段階で次のプロンプトを送ります。Inside-out（内側から外へ）で進める前提です。
コアロジックを Inside-out で実装します（TDD 採用時）。実装はまだしません。
お題と設計 (docs/<feature-name>/02_design.md) から、Phase 4 で実装すべき
モジュール/コンポーネントを、依存関係順に列挙してください。
【出力】
1. 実装順序リスト
2. 各対象について
- 責務 (1行)
- 主要不変条件 / ビジネスルール
- 想定テストケース 3〜5個 (正常/境界/異常)
3. TDDサイクル合計数の見積もり（TDD 採用時）
4. 既存モジュールとの関係 (再利用 / 拡張 / 新規)
実装/テストコードはまだ書かないでください。
TDDテンプレ（任意）
チームが Inside-out TDD を標準にしているときの、1 サイクル分のテンプレです。ルールと 02_design.md をコンテキストに含めてください。
サイクルごとにチャットを分けると履歴が追いやすいです — サイクルごとにチャットを分けると履歴が追いやすいです。「Cycle 2: OrderTotal」のように対象名をプロンプト先頭に書き、RED のあとローカルで fail を確認してから GREEN に進む。
RED
まず失敗するテストだけを追加します。実装ファイルは触りません。
=== TDD Cycle N: <対象> ===
【RED】
以下のテストを tests/unit/<module>/test_<対象>.py に書いてください。
実装ファイルは触らないでください。
（パスはプロジェクトのテスト配置規約に合わせて読み替える）
対象: <対象>
責務: <責務>
テストケース (今サイクル):
1. test_<条件1>_<期待結果1>
2. test_<条件2>_<期待結果2>
3. test_<条件3>_<期待結果3>
要件:
- Arrange-Act-Assert を明確に分ける
- 既存テストヘルパ/フィクスチャがあれば再利用
- 1ケースだけ実行可能な命名
出力後、テスト実行で全件failする想定であることを宣言してください。
GREEN
テストを通す最小の実装だけを書きます。
【GREEN】
上記テストを通す最小実装を src/<module>/<対象>.py に書いてください。
（パスは 02_design.md のモジュール構成に合わせる）
ルール:
- 過度な抽象化禁止
- 未使用フィールド/メソッド禁止
- 将来用パラメータ禁止
- プロジェクト rules（.cursor/rules/ / CLAUDE.md 等）を遵守
- 既存コードの設計パターンに揃える
出力後、全件pass想定であることを宣言してください。
REFACTOR
テストはそのまま、設計だけを整えます。新規テストの追加はしません。
【REFACTOR】
テストは全て保ったまま設計改善してください。
観点:
- 不変条件を型・小さな関数に閉じ込められるか
- 計算ロジックが再利用可能な private メソッドに切り出せるか
- 例外メッセージに業務情報を含められるか
- 既存の共通ユーティリティに置き換えられるか
【制約】
- 新規テスト追加禁止
- 振る舞いを変えない
- 採用する改善は3つ以内
- 改善後のdiffと理由を最後にまとめる
REFACTOR で private メソッドを 2 つ増やしたら、diff 末尾に「… — REFACTOR で private メソッドを 2 つ増やしたら、diff 末尾に「① 境界チェック共通化 ② 丸め処理分離」と理由を 3 行で書かせる。テスト追加は禁止のまま全件 pass を再確認する。
各サイクル後のコミット
NOTE: git add / git commit はユーザー明示許可後に実行（強制確認ルール）。以下はコミットメッセージ例です。
テストの pass/fail を確認したあと、リポジトリのルールに従いコミットします（操作確認が必要な環境では、許可を得てから実行）。
git add . && git commit -m "[RED] add failing tests for <対象>"
git add . && git commit -m "[GREEN] implement <対象>"
git add . && git commit -m "[REFACTOR] <改善点>"
Phase 4 の設計 docs に沿う。完了 → Phase 6