swarm-designlisted

# swarm-design — system design phase **Gate:** requires a validated SRS (else route back to swarm-spec). Read the SRS and feature specs first; the design must answer them, not your habits. **Lane:** this is the standard, agent-driven lane — you propose, the user validates. If the user wants to *own* the system rather than receive it (deep design, pseudocode, algorithm-level planning, "developer mode"), hand the phase to **swarm-design-deep** instead; the two replace each other and never run together. ## Produce, in order 1. **Tech stack** — options with trade-offs *measured against the NFRs* (not fashion), recommendation first; the user decides. Significant picks become ADRs. 2. **Decomposition** — modules/services with single responsibilities, boundaries, and data flow. Prefer deep modules behind simple interfaces. Mermaid diagrams for the system view and any non-obvious flow. 3. **Data model & contracts** — entities, relationships, API contracts where relevant. 4. **Cross-cutting strategy** — error handling, logging, testing approach fit for the stack. 5. **Milestone boundaries** — group FRs into build milestones; these become swarm-implement's ticket batches. ## Rules - **Traceability table required:** every Must-FR ↦ component; every NFR ↦ one line on how the design satisfies it. Nothing silently dropped. - **Options with recommendation** for anything that meaningfully affects cost, lock-in, or complexity — never decide those silently (mode: in au