architecturelisted

# Architecture Choose the smallest design that protects the required behavior. Use this workflow when a change alters responsibility, dependency direction, model meaning, or consistency. Routine changes within an established boundary can follow the repository's implementation workflow directly. ## 1. Establish the current behavior Read the repository instructions, its domain glossary if present, and relevant architecture decisions. Discover their actual locations. Project-specific architecture guidance takes precedence over these defaults. Trace the requested operation through its callers, implementation, persistence, and external effects. Read the tests covering that path. State the business rule, its current owner, and the concrete problem motivating a change. Cite files and symbols. Distinguish observed behavior, documented intent, and assumptions when they disagree. Continue independent investigation while asking about unresolved product rules. **Complete when:** every entry point affected by the rule is accounted for, and the required outcome and failure case are explicit. ## 2. Load the relevant design reference Read each matching reference before proposing a boundary. Several may apply to one change. | Decision | Required reference | | --- | --- | | Change domain meanings, ownership, invariants, or consistency boundaries | [domain-modeling.md](domain-modeling.md) | | Extract a module, change dependency direction, or integrate provider data | [boundaries.md](bou