architecture-quality

# Architecture quality — readable by construction This skill turns the architecture decision into a small, repeatable delivery contract. It complements `architecture-first`; it does not add layers for their own sake. ## Working contract Before a non-trivial web or service change, record these five facts in `ARCHITECTURE.md` or `docs/architecture/README.md`: 1. **Feature/domain modules** — name them by reason to change, not by a generic `utils`, `helpers` or `services` bucket. 2. **Ownership** — each mutable state, database table boundary and external side effect has one owner. 3. **Dependency direction** — policy/domain code is independent of the web framework, ORM, queue and filesystem; adapters point inward through small ports. 4. **Vertical slice** — prove one user-visible path from entry point to state and test before multiplying layers or pages. 5. **Verification boundary** — list the architecture checks and the test command that must remain green after the change. If the project is a small script or a single-module experiment, state that scope and skip the document. A missing document is a finding only once the project has enough shape to need one, not a reason to create ceremony around a toy. ## Web application shape - Keep routes/controllers thin: parse input, call a use-case or feature API, map the result and return. Do not put business policy, SQL and provider retries in a route. - Keep domain/use-case code framework-free where practical. Inj...