Sdlc Impl Planning

Read all feature artifacts:

1. docs/artifacts/<feature>/problem_spec.md - Requirements and acceptance criteria
2. docs/artifacts/<feature>/design_spec.md - Component design, API contracts, data models
3. docs/artifacts/<feature>/design_review.md - Review findings and concerns to address
4. docs/ARCHITECTURE.md - System architecture baseline

Step 2: Build Ordered File List

Extract every file that needs to be created or modified from the design spec:

• List each file with its COMP-ID from the design
• Note whether the file is NEW or MODIFIED
• Note the layer (Designer / Hub / Scout / Shared / Tests)
• Note the file type (TypeScript / Python / Config)

Step 3: Compute Dependency Graph

For each file, determine its dependencies:

• Which other files must exist before this file can be implemented?
• Which shared types does it depend on?
• Which services does it call?
• Which models does it use?

Assign each file to a wave based on the TriStar dependency ordering (see references/tristar-dependencies.md):

• Wave 1: Shared types (no dependencies)
• Wave 2: Backend models (depends on shared types)
• Wave 3: Backend services (depends on models)
• Wave 4: Backend API routes (depends on services)
• Wave 5: Frontend services (depends on API contracts)
• Wave 6: Frontend components (depends on frontend services)
• Wave 7: Tests (depends on implementation)

Step 4: Map Acceptance Criteria to Files

For each acceptance criterion from the problem spec:

• Which files are involved in satisfying this AC?
• Which test files verify this AC?
• Mark any AC that spans multiple waves (integration risk)

Step 5: Map Test Strategy

For each implementation file:

• Corresponding unit test file path
• Key test scenarios (from testing.md patterns)
• Mock dependencies needed
• Integration test scenarios (if applicable)

Step 6: Identify Risks

Flag implementation risks:

• Files in multiple waves that share state (race condition risk)
• Complex logic that needs careful testing (fraud detection, scoring)
• External API integrations that need mocking strategy
• Schema changes that affect multiple layers (Zod + Pydantic sync)
• Design review concerns that need special attention during implementation

Step 7: Write Implementation Plan

Save to: docs/artifacts/<feature>/implementation_plan.md

Step 8: Update Artifact Digest

Create or update .claude/checkpoints/<feature>/artifact_digest.md with:

• List of all artifacts produced so far
• Current pipeline stage (impl-planning complete)
• Next expected stage (implementation)

Output Template

# Implementation Plan: <feature-name>

## Overview
- Total files: N (M new, K modified)
- Waves: 7
- Estimated complexity: Low / Medium / High

## Wave Plan

### Wave 1: Shared Types
| # | File | Action | COMP-ID | Description |
|---|------|--------|---------|-------------|
| 1 | src/shared/types/offer-brief.ts | MODIFY | COMP-001 | Add new fields to OfferBrief |

**Wave 1 Verification:**
- [ ] TypeScript compiles without errors
- [ ] Zod schema validates correctly

### Wave 2: Backend Models
| # | File | Action | COMP-ID | Description |
|---|------|--------|---------|-------------|
| 2 | src/backend/models/offer_brief.py | MODIFY | COMP-002 | Mirror OfferBrief changes in Pydantic |

**Wave 2 Verification:**
- [ ] Pydantic model validates correctly
- [ ] Fields match Wave 1 Zod schema

### Wave 3: Backend Services
...

### Wave 4: Backend API Routes
...

### Wave 5: Frontend Services
...

### Wave 6: Frontend Components
...

### Wave 7: Tests
| # | File | Action | Tests For | Scenarios |
|---|------|--------|-----------|-----------|
| N | tests/unit/backend/test_offer_brief.py | NEW | COMP-002 | Validation, edge cases |

**Wave 7 Verification:**
- [ ] All unit tests pass
- [ ] Coverage > 80%
- [ ] Integration tests pass

## Acceptance Criteria Mapping

| AC ID | Description | Files | Test File | Wave |
|-------|-------------|-------|-----------|------|
| AC-001 | Given X, When Y, Then Z | file1, file2 | test_file | 3,4 |

## Risk Register

| Risk | Impact | Mitigation | Wave |
|------|--------|------------|------|
| R-001: Schema sync | High | Implement Wave 1+2 together, verify match | 1-2 |

## Design Review Concerns

| Finding | Severity | How Addressed |
|---------|----------|---------------|
| F-001: Missing error handling | Major | Added try/catch in Wave 4 files |

## Implementation Order Summary

1. Wave 1: Shared types (foundation)
2. Wave 2: Backend models (must match Wave 1)
3. Wave 3: Backend services (business logic)
4. Wave 4: Backend routes (API layer)
5. Wave 5: Frontend services (API clients)
6. Wave 6: Frontend components (UI layer)
7. Wave 7: Tests (verification layer)

Reference Files

• references/tristar-dependencies.md - Layer dependency ordering and wave assignment rules