architectural-design-principleslisted

# architectural-design-principles Canon for decisions above the function and class. `software-design-principles` governs how a unit of code is written (SOLID, DRY, clean code); this skill governs how the system is shaped: layers, boundaries, its relationship to the platform, and how those properties stay true over time. Read it alongside that skill, not instead of it. Markdown only, no scripts: consulted, not invoked. Its job is to point each architectural rule at the **fitness function** that enforces it. A rule no test defends is advisory; a rule a fitness function defends is part of the build. ## When to use - A workflow skill's agent contract tells you to import it (e.g. the `consort` Architect Reviewer reviews every design against layering + twelve-factor; the Test Strategist authors the fitness functions named here). - You're deciding a system boundary: what is a layer, a backing service, where config lives, what is stateless. - You're about to declare an architectural constraint ("we use an ORM", "raw SQL appears only in the repository layer") and need it enforced, not just written down. ## Architectural fitness checklist (mandatory before promote/merge) Confirm each row before declaring the design done. A blank row is fine when scope justifies it; an unconsidered row is a smell. | Property | The rule | Enforced by (fitness function) | |---|---|---| | Layer direction | Dependencies point inward; infrastructure never imports service, service never imports HTTP |