improve-architecture

# improve-architecture ## Purpose Surface architectural friction in a codebase and propose **deepening opportunities** — refactors that turn shallow modules into deep ones. Output is structured (numeric scores + JSON proposal payloads) so `surgeon`, `review`, and `audit` can consume it programmatically without re-reading the codebase. The goal is **testability and AI-navigability**: a deep module presents a small interface that hides large machinery, so tests target one surface and future agents can reason about the system without traversing N small wrappers. ## Vocabulary (controlled — use exactly) These eight terms have precise meanings. Banned aliases: "boundary" (overloaded with DDD), "component" (UI-specific), "service" (microservice-specific), "layer" (too generic). See [references/language.md](references/language.md) for full definitions. - **Module** — anything with an interface and an implementation (function, class, package, slice). - **Interface** — everything a caller must know to use the module: types, invariants, ordering, error modes, config. - **Implementation** — the code inside. - **Depth** — leverage at the interface; large behavior behind a small interface. - **Seam** — where an interface lives; place behavior can be altered without editing in place. - **Adapter** — concrete thing satisfying an interface at a seam. - **Leverage** — what callers get from depth. - **Locality** — what maintainers get from depth. ## Triggers - Called by `cook` Phase 5 ...