### Implementation Plan

**Approach:**
[High-level description of solution approach]

**Why this approach:**
1. [Reason 1: e.g., matches existing patterns]
2. [Reason 2: e.g., minimal invasive change]
3. [Reason 3: e.g., easily testable]

**Alternative approaches considered:**
- **[Approach A]:** [why not chosen]
- **[Approach B]:** [why not chosen]

**Implementation order:**
1. [Task 1] - [rationale for doing first]
2. [Task 2] - [builds on previous]
3. [Task 3] - [completes the feature]

**Checkpoints:**
- After step 1: [what to verify]
- After step 2: [what to verify]
- After step 3: [final verification]

### TDD Cycle

**Red (Failing Test):**
```javascript
// test/feature.test.js
describe('NewFeature', () => {
  it('should do X when Y', () => {
    const result = newFeature(input)
    expect(result).toBe(expected) // ❌ FAILS
  })
})

// src/feature.js
function newFeature(input) {
  // Simplest thing that makes test pass
  return expected
}

// src/feature.js
function newFeature(input) {
  // Proper implementation
  // Handles edge cases
  // Clean and readable
  return properResult
}

### Step 3: Code Implementation

Write production code following project conventions.

**Quality checklist:**

```markdown
### Code Quality

**Correctness:**
- [ ] Solves the stated problem
- [ ] Handles all requirements
- [ ] Covers edge cases
- [ ] No logical errors

**Convention adherence:**
- [ ] Naming matches project style
- [ ] Formatting follows guidelines
- [ ] Imports organized correctly
- [ ] Comments where helpful

**Code quality:**
- [ ] DRY (Don't Repeat Yourself)
- [ ] Single Responsibility Principle
- [ ] Appropriate abstractions
- [ ] Clear variable/function names

**Error handling:**
- [ ] Validates inputs
- [ ] Handles errors gracefully
- [ ] Provides clear error messages
- [ ] Fails safely

**Performance:**
- [ ] No obvious inefficiencies
- [ ] Appropriate data structures
- [ ] Avoids unnecessary work
- [ ] Acceptable time/space complexity

**Security:**
- [ ] Input validation
- [ ] No injection vulnerabilities
- [ ] Proper authorization checks
- [ ] Sensitive data protection

### Bug Fix Implementation

**1. Add test that reproduces bug:**
```javascript
it('should handle edge case correctly', () => {
  // This test currently fails
  const result = buggyFunction(edgeCase)
  expect(result).toBe(correctValue)
})

// Before:
function buggyFunction(input) {
  return input.value // Fails when input.value is undefined
}

// After:
function buggyFunction(input) {
  return input?.value ?? defaultValue // Handles undefined
}

**For Features:**
```markdown
### Feature Implementation

**1. Define interface:**
```typescript
// Define types/interfaces first
interface NewFeature {
  doSomething(param: Type): ReturnType
}

function coreFunction() {
  // Happy path first
  // Clear, readable code
  // One level of abstraction
}

function coreFunction(input) {
  // Validate inputs
  if (!isValid(input)) {
    throw new Error('Invalid input: ...')
  }

  // Handle empty/null
  if (isEmpty(input)) {
    return defaultValue
  }

  // Core logic
  const result = process(input)

  // Post-conditions
  validateResult(result)

  return result
}

**For Refactoring:**
```markdown
### Refactoring Implementation

**1. Ensure test coverage:**
- [ ] Tests exist for current behavior
- [ ] Tests are comprehensive
- [ ] Tests pass before refactoring

**2. Refactor incrementally:**

**Step 1:** Extract function
```javascript
// Before:
function complexFunction() {
  // Long complex code
  // Mixing concerns
  // Hard to understand
}

// After Step 1:
function complexFunction() {
  const data = fetchData()
  const processed = processData(data)
  return formatOutput(processed)
}

function fetchData() { /* extracted */ }
function processData(data) { /* extracted */ }
function formatOutput(processed) { /* extracted */ }

### Step 4: Test Implementation

Write comprehensive tests.

**Test coverage goals:**

```markdown
### Test Strategy

**Unit tests:** (test individual functions)
- Location: [where tests go]
- Coverage target: [percentage or specific cases]

**Test cases:**

**Happy path:**
```javascript
it('should work with valid input', () => {
  expect(feature(validInput)).toBe(expected)
})

it('should handle empty input', () => {
  expect(feature([])).toBe(defaultValue)
})

it('should handle null input', () => {
  expect(feature(null)).toThrow('Invalid input')
})

it('should handle large input', () => {
  const largeInput = generateLargeData()
  expect(feature(largeInput)).toBeDefined()
})

it('should throw on invalid input', () => {
  expect(() => feature(invalid)).toThrow()
})

it('should provide clear error message', () => {
  expect(() => feature(invalid))
    .toThrow('Expected X but got Y')
})

it('should integrate with existing feature', () => {
  // Test feature working with other parts
})

it('should render correctly', () => {
  const tree = renderer.create(<Component />).toJSON()
  expect(tree).toMatchSnapshot()
})

**Test best practices:**

```markdown
### Test Quality

**Clear and focused:**
- [ ] One assertion per test (generally)
- [ ] Clear test names describe behavior
- [ ] Tests are independent
- [ ] No test interdependencies

**Readable:**
- [ ] Arrange-Act-Assert structure
- [ ] Descriptive variable names
- [ ] Comments for complex setups
- [ ] DRY (use helpers/fixtures)

**Maintainable:**
- [ ] Tests don't test implementation details
- [ ] Tests are resilient to refactoring
- [ ] Test data is realistic
- [ ] Mocks/stubs are minimal

**Fast:**
- [ ] Unit tests run quickly
- [ ] Minimal external dependencies
- [ ] No unnecessary setup/teardown

### Local Testing

**Build:**
```bash
# Clean build
[build command]

# Check for warnings
[any warnings to address?]

# Run all tests
[test command]
# ✅ All pass

# Run with coverage
[coverage command]
# ✅ Coverage meets threshold

# Run specific affected tests
[command for affected tests]
# ✅ Pass

# Check code style
[lint command]
# ✅ No errors

# Auto-fix if available
[format command]

[type check command]
# ✅ No type errors

### Step 6: Code Review Self-Check

Review your own code before submitting.

**Self-review checklist:**

```markdown
### Self Code Review

**Completeness:**
- [ ] All requirements implemented
- [ ] All edge cases handled
- [ ] All acceptance criteria met
- [ ] No TODO/FIXME left unaddressed

**Code quality:**
- [ ] Code is self-explanatory
- [ ] Complex parts have comments
- [ ] No dead code or commented-out code
- [ ] No debugging code (console.log, etc)

**Changes are minimal:**
- [ ] Only changed what's necessary
- [ ] No unrelated refactoring
- [ ] No formatting-only changes mixed in
- [ ] Git diff is clean and focused

**Testing:**
- [ ] Tests are comprehensive
- [ ] Tests are meaningful (not just for coverage)
- [ ] Tests pass consistently
- [ ] Edge cases have tests

**Documentation:**
- [ ] Public APIs documented
- [ ] Complex logic explained
- [ ] README updated if needed
- [ ] Migration guide if breaking

**Security:**
- [ ] No secrets/credentials committed
- [ ] User input validated
- [ ] No obvious vulnerabilities
- [ ] Dependencies are safe

**Performance:**
- [ ] No performance regressions
- [ ] Algorithms are efficient
- [ ] Resource usage reasonable
- [ ] No memory leaks

**Commits:**
- [ ] Commits are logical
- [ ] Commit messages are clear
- [ ] No merge commits from main (rebase if needed)
- [ ] History is clean

### Documentation Updates

**Code comments:**
```javascript
/**
 * Converts user data to CSV format
 *
 * @param {User[]} users - Array of user objects
 * @param {ExportOptions} options - Export configuration
 * @returns {string} CSV formatted string
 * @throws {ValidationError} If users array is invalid
 *
 * @example
 * const csv = exportToCSV(users, { includeHeaders: true })
 */
function exportToCSV(users, options) {
  // Implementation
}

## [Unreleased]
### Added
- Export to CSV functionality (#123)
  - New `exportToCSV` function
  - Customizable column selection
  - Header row optional

## Migrating to v2.0

### Breaking Changes

**Function signature changed:**
```javascript
// Old:
doSomething(param)

// New:
doSomething(param, options)

# ✅ Implementation Complete: [Issue Title]

**Issue:** #[number]
**Branch:** [branch-name]

---

## Changes Made

### Core Implementation

**1. [Primary change]**
- File: `[path]`
- Changes: [description]
- Lines modified: ~[count]

**2. [Secondary change]**
- File: `[path]`
- Changes: [description]

### Tests Added

**Unit tests:**
- `[test-file]` - [N] test cases
  - Happy path
  - Edge cases: [list]
  - Error cases: [list]

**Coverage:** [percentage] (previous: [X]%, delta: +[Y]%)

### Documentation

- [ ] Code comments added
- [ ] README updated
- [ ] CHANGELOG entry added
- [ ] API docs updated

---

## Verification

**Local testing:**
- ✅ All tests pass
- ✅ Linting passes
- ✅ Build succeeds
- ✅ Manual testing complete

**Checklist:**
- ✅ Requirements met
- ✅ Edge cases handled
- ✅ Follows conventions
- ✅ Self-review complete

---

## Commits

```bash
# Commit history
git log --oneline origin/main..HEAD

## Integration with Main Framework

When invoked from main framework:

1. **Receive context:** Issue analysis from Phase 2, requirements, code locations
2. **Guide implementation:** Step-by-step with quality checks
3. **Verify completion:** All requirements met, tests pass
4. **Return summary:** What was implemented and how
5. **Update tracker:** Mark Phase 3 complete
6. **Transition:** Ready for documentation and PR creation

Implementation phase may iterate with Phase 2 if code structure different than expected.

## Incremental Development

**For large implementations:**

1. **Milestone 1:** Core functionality
   - Implement minimal working version
   - Add basic tests
   - Commit: "feat: add core X functionality"

2. **Milestone 2:** Edge cases
   - Handle edge cases
   - Add edge case tests
   - Commit: "feat: handle X edge cases"

3. **Milestone 3:** Polish
   - Error messages
   - Documentation
   - Commit: "docs: add X documentation"

**Benefits:**
- Can get early feedback
- Easier to review
- Simpler to debug
- Clear progress tracking