define-architecturelisted

# Purpose Describe the *shape* of the system: what runs where, how the pieces talk to each other, and what crosses trust boundaries. # Questions to ask (in order) 1. Platforms to support: web, iOS, Android, desktop (macOS/Windows/Linux), CLI, browser extension, server-only, embedded. 2. Service shape: single monolith, modular monolith, a small set of services, or many microservices. 3. Communication between components: HTTP/REST, GraphQL, gRPC, message queue, WebSockets, event bus, file drop. 4. Synchronous vs. asynchronous workloads: long-running jobs, schedulers, background workers? 5. Integrations: external systems to read from or write to. 6. Data flow: a short narrative of how data moves from input → storage → output. 7. Trust boundaries: where does untrusted input enter, where does sensitive data live, and what must never leave the system? 8. Multi-tenancy: not applicable, shared DB with row-level isolation, schema-per-tenant, or deployment-per-tenant. Use `AskUserQuestion` for multi-choice items (platforms, service shape, multi-tenancy, comm style). # Solution space to present - **Platforms**: web only / web + mobile / mobile only / desktop / CLI / mixed. One-line tradeoffs on distribution, update cadence, and platform-specific constraints. - **Service shape**: - *Monolith* — simplest, easiest to evolve early. - *Modular monolith* — clean internal boundaries without distributed-system costs. - *Services* — justified when teams or scaling domains genuinely d