4 Code

DDD Phase 4 - Implement and verify code

rysweet 67 updated 1mo ago
Claude CodeGeneric
View source ↗
---
name: ddd:4-code
version: 1.0.0
description: DDD Phase 4 - Implement and verify code
argument-hint: [optional feedback or instructions]
allowed-tools: TodoWrite, Read, Write, Edit, MultiEdit, Grep, Glob, Task, Bash(*)
triggers:
  - "Implement DDD code"
  - "Phase 4 code implementation"
  - "Test as user in DDD"
invokes:
  - type: workflow
    path: .claude/workflow/DDD_WORKFLOW.md
---

# DDD Phase 4: Implementation & Verification

Loading context:

@docs/document_driven_development/phases/04_code_implementation.md
@docs/document_driven_development/phases/05_testing_and_verification.md
@ai_working/ddd/code_plan.md

**CRITICAL**: Read ALL updated documentation - code must match exactly

User feedback/instructions: $ARGUMENTS

---

## Your Task: Implement Code & Test as User

**Goal**: Write code matching docs exactly, test as real user would, iterate until working

**This phase stays active until user confirms "all working" - iterate as long as needed**

---

## Phase 4A: Implementation

### For Each Chunk in Code Plan

#### Step 1: Load Full Context

Before implementing chunk:

- Read the code plan for this chunk
- Read ALL relevant documentation (the specs)
- Read current code in affected files
- Understand dependencies

**Context is critical** - don't rush this step

#### Step 2: Implement Exactly as Documented

**Code MUST match documentation**:

- If docs say "function returns X", code returns X
- If docs show config format, code parses that format
- If docs describe behavior, code implements that behavior
- Examples in docs must actually work

**If conflict arises**:

STOP ✋

Don't guess or make assumptions.

Ask user: "Documentation says X, but implementing Y seems better because Z. Should I: a) Update docs to match Y b) Implement X as documented c) Something else?"


#### Step 3: Verify Chunk Works

After implementing chunk:

- Run relevant tests
- Check for syntax errors
- Basic smoke test
- Ensure no regressions

#### Step 4: Show Changes & Get Commit Authorization

**IMPORTANT**: Each commit requires EXPLICIT user authorization

Show user:

```markdown
## Chunk [N] Complete: [Description]

### Files Changed

[list with brief description of changes]

### What This Does

[plain English explanation]

### Tests

[which tests pass]

### Diff Summary

git diff --stat


### Proposed Commit

feat: [Chunk description]

[Detailed commit message based on code plan]


⚠️ **Request explicit authorization**:
"Ready to commit? (yes/no/show me diff first)"

If yes: commit with message
If no: ask what needs changing
If show diff: run `git diff` then ask again

Step 5: Move to Next Chunk

After successful commit, move to next chunk in plan.

Repeat Steps 1-4 for all chunks.


Phase 4B: Testing as User Would

After all implementation chunks complete:

Step 1: Actual User Testing

Be the QA entity - actually use the feature:

# Run the actual commands a user would run
amplifier run --with-new-feature

# Try the examples from documentation (they should work)
[copy exact examples from docs]

# Test error handling
[try invalid inputs]

# Test integration with existing features
[test it works with rest of system]

Observe and record:

  • Actual output (what did you see?)
  • Actual behavior (what happened?)
  • Logs generated (what was logged?)
  • Error messages (clear and helpful?)
  • Performance (reasonable speed?)

Step 2: Create Test Report

Write ai_working/ddd/test_report.md:

# User Testing Report

Feature: [name]
Tested by: AI (as QA entity)
Date: [timestamp]

## Test Scenarios

### Scenario 1: Basic Usage

**Tested**: [what you tested]
**Command**: `[actual command run]`
**Expected** (per docs): [what docs say should happen]
**Observed**: [what actually happened]
**Status**: ✅ PASS / ❌ FAIL
**Notes**: [any observations]

### Scenario 2: Error Handling

**Tested**: [what you tested]
**Command**: `[actual command with invalid input]`
**Expected**: [error message from docs]
**Observed**: [actual error message]
**Status**: ✅ PASS / ❌ FAIL

[... continue for all scenarios]

## Documentation Examples Verification

### Example from docs/feature.md:123

```bash
[exact example from docs]
```

Status: ✅ Works as documented / ❌ Doesn't work Issue: [if doesn't work, what's wrong]

[... test ALL examples from docs]

Integration Testing

With Feature X

Tested: [integration test] Status: ✅ PASS / ❌ FAIL Notes: [observations]

Issues Found

Issue 1: [Description]

Severity: High/Medium/Low What: [description] Where: [file:line or command] Expected: [what should happen] Actual: [what happens] Suggested fix: [how to fix]

[... list all issues]

Code-Based Test Verification

Unit tests:

make test
# [output]

Status: ✅ All passing / ❌ [N] failures

Integration tests:

make test-integration
# [output]

Status: ✅ All passing / ❌ [N] failures

Linting/Type checking:

make check
# [output]

Status: ✅ Clean / ❌ Issues found

Summary

Overall Status: ✅ Ready / ⚠️ Issues to fix / ❌ Not working

Code matches docs: Yes/No Examples work: Yes/No Tests pass: Yes/No Ready for user verification: Yes/No

Recommended Smoke Tests for Human

User should verify:

  1. Basic functionality:

    [command]
    # Should see: [expected output]
    
  2. Edge case:

    [command]
    # Should see: [expected output]
    
  3. Integration:

    [command]
    # Verify works with [existing feature]
    

[... provide 3-5 key smoke tests]

Next Steps

[Based on status, recommend next action]


### Step 3: Address Issues Found

If testing revealed issues:
1. Note each issue clearly
2. Fix the code
3. Re-test
4. Update test report
5. Request commit authorization for fixes

**Stay in this phase until all issues resolved**

---

## Iteration Loop

**This phase stays active until
```

Maintain 4 Code?

Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.

[4 Code on getagentictools](https://getagentictools.com/loops/rysweet-ddd-phase-4-implementation-verification?ref=badge)