# Stage 3: Planning 2 — Implementation Design

## Purpose

Translate the ADR into concrete implementation specs. Each specialist argues for their domain's best practices.

## Input

- ADR from Planning 1
- Project codebase context
- Relevant specialist knowledge/memory

## Composition — DYNAMIC

Selected by Planning 1's specialist recommendation.

**Only languages/domains that appear in the ADR are included.**

### Language Specialists (one per language in ADR)

| Specialist       | Model  | Selected When                     |
| ---------------- | ------ | --------------------------------- |
| TypeScript Pro   | Sonnet | Project uses TypeScript           |
| JavaScript Pro   | Sonnet | Project uses vanilla JS / Node.js |
| Go Pro           | Sonnet | Project uses Go                   |
| Rust Pro         | Sonnet | Project uses Rust                 |
| Solidity Pro     | Sonnet | Smart contracts involved          |
| Python Pro       | Sonnet | Project uses Python               |
| SQL Pro          | Sonnet | Database queries / Prisma         |
| LangChain/AI Pro | Sonnet | AI/ML/agent frameworks            |

### Domain Specialists (as relevant to ADR)

| Specialist       | Model  | Selected When                |
| ---------------- | ------ | ---------------------------- |
| NestJS Expert    | Sonnet | Backend uses NestJS          |
| React Specialist | Sonnet | Frontend uses React          |
| React Native Pro | Sonnet | Mobile app work              |
| Web Design       | Sonnet | HTML/CSS/responsive work     |
| UX/UI Design     | Sonnet | Component/interaction design |
| Blockchain/DeFi  | Sonnet | Chain interactions           |
| Docker/Swarm     | Sonnet | Containerization/deploy      |
| CI/CD            | Sonnet | Pipeline changes             |

## Process

1. Each specialist reads the ADR independently
2. Each produces an implementation spec for their domain:
   - Patterns to follow
   - Patterns to avoid (with reasoning)
   - Known pitfalls specific to this project
   - Test strategy for their domain
   - Integration points with other domains
3. Cross-review: specialists review each other's specs for conflicts
4. Debate on conflicts (Min 3, Max 30 rounds)
5. Final specs must be consistent with each other AND the ADR

## Specialist Memory

Specialists accumulate knowledge from past runs:

- "Last time we used pattern X, it caused Y"
- "This project's NestJS modules require explicit guard exports"
- "Prisma schema changes need Kaniko workaround in Dockerfile"

Memory is domain-scoped — a TypeScript specialist only remembers TypeScript lessons.

## Output

- Implementation spec per component/domain:
  - File/module changes required
  - Code patterns to follow
  - Code patterns to avoid
  - Test requirements
  - Integration contract with adjacent components
- Conflict resolution notes (if any)

## Minimum Composition Guard

Planning 2 MUST have at least one Language Specialist and one Domain Specialist.
If the Brief Analyzer's heuristics produce zero specialists, the Gate Reviewer flags this at the architecture-approval gate and the ADR is sent back for explicit language/framework annotation.

## Gate: implementation-approval

### Mechanical

- [ ] Implementation spec exists for each component in the ADR
- [ ] No unresolved conflicts between specs
- [ ] Each spec references the ADR it implements
- [ ] Test strategy defined per component

### Gate Reviewer

- "Are the specs consistent with each other? Do they actually implement the ADR, or did someone go off-script?"
