architecture-reviewlisted

## Purpose Most changes don't need a design discussion — they need someone to write the code. A smaller set of changes are expensive to reverse once built (a new data model, a new service boundary, a new public API shape, a change to how auth or permissions are structured) and are worth a deliberate design pass before implementation starts, because the cost of redoing them after the fact is much higher than the cost of a short review up front. ## When a design needs review before building Reach for this before writing code when a change involves any of: - A new persistent data model or a change to an existing one that existing data has to migrate through. - A new service boundary, API contract, or integration point other code will depend on. - A change to how authentication, authorization, or a security boundary works. - Introducing a new dependency or pattern that doesn't exist elsewhere in the codebase yet (the first use sets a precedent others will copy). - Anything where two reasonable engineers would likely propose different approaches — that disagreement is a signal the choice matters. Skip it for: a bug fix within existing structure, an addition that clearly follows an established pattern, or anything where the "design" is genuinely obvious once you read the ticket. ## What to evaluate 1. **Does this need to be general, or does it need to solve the actual problem?** Check against the rule of least power — the simplest structure that handles today's real requireme