---
name: iterative-dev-guide
description: Iterative requirement TDD development work standard. Use when dev_leader determines the requirement is an enhancement or change to an existing product.
---

# Iterative Development TDD Guide

Complete iterative development deliverables step by step. **Each phase MUST be confirmed by the user before proceeding to the next.**

## Working Principles

- Pause after each phase and wait for user confirmation before continuing
- All changes MUST be strictly scoped to the iteration requirement; do not modify unrelated code
- Follow the minimum viable principle: change only what is necessary
- TDD is non-negotiable: tests MUST be written before implementation code
- Existing passing tests MUST remain green throughout the iteration

---

## Phase 0 — Understand the Iteration Scope

Before writing any code, `@dev_leader` MUST:

1. Read the updated PRD documents for this iteration. Focus on:
   - `PRD/2-Scope/Iteration-Roadmap.md` — identify the target version and its scope
   - `PRD/2-Scope/Feature-List.md` — locate the new or changed feature items for this iteration
   - `PRD/3-Structure/*-Requirements.md` — check for new or updated entity requirements
   - `PRD/4-Presentation/` — check for new or updated UI pages (if applicable)
2. Review the existing codebase to understand what already exists and what needs to change.
3. Identify the delta: what is being **added**, **changed**, or **removed** compared to the current version.

After reading, `@dev_leader` summarizes:
- The iteration version and its scope
- The specific delta (add / change / remove) per feature
- Whether frontend work, backend work, or both are required

**Confirm with user before proceeding.**

---

## Phase 1 — Impact Analysis & Task Breakdown

`@dev_leader` produces an impact analysis:

1. **Affected Modules**: List all existing files/modules that will be touched.
2. **Risk Assessment**: Identify changes that could break existing functionality (regressions).
3. **Task Breakdown**: Split the iteration delta into independent development tasks. For each task, specify:
   - Task ID and description
   - Type: `ADD` / `MODIFY` / `REMOVE`
   - Assigned to: `@frontend_dev` or `@backend_dev`
   - PRD references (which Feature-List items it covers)
   - Acceptance criteria (directly derived from the updated Feature-List interaction logic)

**Confirm with user before proceeding.**

---

## Phase 2 — TDD Implementation (per task)

For each task, the assigned agent (`@frontend_dev` or `@backend_dev`) follows the TDD cycle:

### 2.1 Red — Write or Update Failing Tests
- For `ADD` tasks: write new test cases based on the acceptance criteria.
- For `MODIFY` tasks: update existing test cases to reflect the new expected behavior; the updated tests should fail against the current implementation.
- For `REMOVE` tasks: remove the tests for the deleted behavior; confirm no other tests depend on the removed code.
- Run all tests to confirm the targeted tests fail (or the removed ones are gone) while other tests remain green.

### 2.2 Green — Minimal Implementation
- Write or modify the minimum code required to make all tests pass.
- Do not introduce changes beyond what the tests require.

### 2.3 Refactor — Clean Up
- Improve code structure, naming, and clarity.
- Ensure all tests (existing + new) remain green after refactoring.
- Remove any dead code left from REMOVE tasks.

**Report completion to `@dev_leader` after each task.**

---

## Phase 3 — Code Review

After each task (or a logical group of tasks) is complete:

1. `@dev_leader` routes the code to `@code_reviewer`.
2. `@code_reviewer` performs review using the standard checklist and returns a report. Special attention to:
   - Regression risk: does the change break any existing behavior?
   - Scope creep: does the change go beyond the iteration requirement?
3. **If PASS**: `@dev_leader` marks the task as accepted and proceeds to the next task.
4. **If NEEDS REVISION**: The assigned developer addresses each finding and returns to Phase 2.2 for the affected units. Repeat until PASS.

---

## Phase 4 — Regression Verification & Delivery

After all iteration tasks are PASS:

1. Run the **complete test suite** (not just the new tests) to confirm no regressions.
2. `@dev_leader` verifies that the full delta from Phase 1 is covered.
3. `@dev_leader` summarizes the delivery to the user:
   - Features added / changed / removed (mapped to Iteration-Roadmap and Feature-List)
   - Test coverage summary (new tests + existing tests all green)
   - Any deviations from PRD (must be explicitly noted and justified)

**Confirm delivery with user.**
