architecturelisted

# Architecture Design system-level architecture: pick patterns, size components, choose datastores, and record decisions as ADRs. Pragmatic trade-offs over theoretical purity — document what you chose, what you rejected, and why. ## When to use - Designing new system architecture or reviewing an existing one - Choosing between architectural patterns (monolith vs microservices, event-driven, serverless) - Making technology choices that carry lock-in (database, message bus, auth provider) - Planning for scalability or evaluating NFR trade-offs (performance, availability, cost) - Writing Architecture Decision Records (ADRs) - Triggers on "system design", "architecture review", "scalability", "ADR", "架构设计" **Not for:** Code-level design patterns (use `simplify` or `codebase-design`), database-only design without system context, or feature-level API contracts (use `api-design`). Requirements/product-spec writing without system design (use `spec` — architecture takes the spec as input). ## Steps ### 1. Gather requirements (functional + non-functional) Collect functional requirements, constraints (budget, timeline, team), and NFRs. Use the NFR checklist to make scalability, performance, availability, security, reliability, and cost targets explicit — never assume "it should be fast." _Verify: every NFR category has a concrete target or an explicit "not applicable" decision recorded._ - Load `references/nfr-checklist.md` when gathering NFRs - Load `references/system-design.md