sota-architecturelisted

# SOTA Architecture (2026) ## Purpose Dense, enforceable rules for software and system architecture: choosing styles, drawing boundaries, surviving distributed systems, scaling state, and shipping cloud-natively. One rule set, two modes — apply the rules while **building**, or check code against them while **auditing**. All substance lives in `rules/`; this file routes you to the right one. ## BUILD mode — designing or writing code 1. **Identify the decision surface.** Before writing code, list the architectural decisions in play (style, boundaries, sync/async, datastore, tenancy, caching). Use the index below to read the relevant rules files *before* committing to a design — minimum: 01 for any new system/service, 03 for anything crossing a network, 07 always (know what failure looks like). 2. **Default to boring.** Modular monolith, one database, sync calls within the deadline budget, queues only where semantics are async. Escalate complexity only when a rule's stated forces apply, and record it. 3. **Write the ADR first** for any Type 1 (hard to reverse) decision: context, decision, consequences (must include downsides), rejected alternatives. Put it in `docs/adr/`. 4. **Apply rules as you code, not after.** Timeouts/retries/idempotency at every integration point as you create it; ports before adapters; tenant_id and trace context plumbed from the first commit. Retrofitting these is 10x the cost. 5. **Encode the rules you adopted as fitnes