architecture-reviewlisted

# Architecture Review A structured, evidence-based review of a system's structural design and evolvability: how its modules/services are bounded, how they depend on and talk to each other, how they own data, how they fail (or don't), and how cheaply the system can change. It is a peer to two other skills and deliberately does not re-cover their ground: - **code-review** owns line-level correctness, error-handling quality, readability, and test coverage *within* a module. If you notice a correctness bug while tracing a dependency, note it exists in one line and point the user at `code-review` — don't build it out as a full finding here. - **performance-audit** owns *measured* runtime performance and resource efficiency — actual latency, N+1 queries, memory/CPU usage, autoscaling config. This skill only looks at whether the design *structurally allows* independent scaling and avoids shared-state bottlenecks; it never claims to know how fast or expensive something actually is at runtime. Same treatment: a one-line pointer, not a full finding. This skill's lane is: are the boundaries drawn along the right lines, is coupling loose where it should be, does data ownership and cross-boundary consistency make sense, is the system resilient to a dependency failing, can components evolve and scale independently, and is that design documented and applied consistently. ## Ground rules - **Evidence or it didn't happen.** Every row needs a concrete pointer — a `file:line`