# Stage 2: Planning 1 — Architecture

## Purpose

Design the technical architecture. How should this be structured? What can go wrong? How does data flow?

## Input

- Approved brief + Board memo
- Discovery report (`01c-discovery/discovery-report.md`) — codebase patterns, existing implementations, constraints
- Project codebase context (existing architecture, patterns, conventions)

**If Discovery found feature_status = EXISTS_PARTIAL or EXISTS_FULL:**

- The ADR must account for existing implementations
- Architects must avoid redesigning solved problems
- The scope is narrowed to delta work only

## Composition — DYNAMIC

Selected by the Board memo's generalist recommendation list.

| Role                | Model  | Personality                                                      | Selected When                                                              |
| ------------------- | ------ | ---------------------------------------------------------------- | -------------------------------------------------------------------------- |
| Software Architect  | Opus   | Opinionated about boundaries. Insists on clean separation.       | **Always**                                                                 |
| Security Architect  | Opus   | Paranoid by design. "What's the attack surface?"                 | **Always** — security is cross-cutting, implicit requirements are the norm |
| Infrastructure Lead | Sonnet | Pragmatic. "How does this get to prod without breaking?"         | Deploy, infra, scaling concerns                                            |
| Data Architect      | Sonnet | Schema purist. "How does data flow and what are the invariants?" | DB, data models, migrations                                                |
| UX Strategist       | Sonnet | User-first. "How does the human actually use this?"              | UI/frontend work                                                           |

## Process

1. Context Manager produces compact project context packet
2. Each generalist reads brief + context independently
3. Software Architect proposes initial architecture
4. Other generalists challenge from their domain perspective
5. Debate continues (Min 3, Max 30 rounds)
6. Interventions only on circular repetition, not round count
7. Architecture Decision Record (ADR) produced with:
   - Chosen approach + rationale
   - Rejected alternatives + why
   - All dissents recorded
   - Risk register

## Debate Rules

- **No "sounds good to me"** — every participant must state a position with reasoning
- **Challenge required** — if you see a risk others haven't raised, you MUST raise it
- **Dissent is recorded** — disagreements don't disappear, they're documented in the ADR
- **Don't fold under pressure** — hold your position if you believe it's right

## Output

- Architecture Decision Record (ADR):
  - Component diagram / data flow
  - Technology choices with rationale
  - Integration points
  - Security considerations
  - Deployment strategy
  - Risk register
  - Dissents
- Recommended specialists for Planning 2 (which languages, which domains)

## Gate: architecture-approval

### Mechanical

- [ ] ADR exists with all required sections
- [ ] At least 3 debate rounds occurred
- [ ] Risk register is non-empty
- [ ] Specialist selection list is non-empty
- [ ] No unresolved CRITICAL risks

### Gate Reviewer

- "Does this architecture actually solve the problem in the brief? Are the risks real or hand-waved?"
