codebase-designlisted

# Codebase Design Design **deep modules**: a lot of behaviour behind a small interface, placed at a clean seam, testable through that interface. Use this language and these principles wherever code is being designed or restructured. The aim is **leverage** for callers, **locality** for maintainers, and **testability** for everyone — including the agent navigating the codebase next session. This skill is **reference vocabulary**, not a workflow. It carries no project facts — read `.claude/PROJECT.md` → Architecture for where this project's seams and layers actually live, and `rules/_generic/code-quality.md` for the size/naming/composition floor this builds on. ## Glossary Use these terms exactly — don't substitute "component," "service," "API," or "boundary." Consistent language is the whole point (and feeds the project's own `CONTEXT.md`). - **Module** — anything with an interface and an implementation. Deliberately scale-agnostic: a function, class, package, or tier-spanning slice. _Avoid_: unit, component, service. - **Interface** — *everything* a caller must know to use the module correctly: the type signature, but also invariants, ordering constraints, error modes, required configuration, and performance characteristics. _Avoid_: API, signature (too narrow — type-level surface only). - **Implementation** — what's inside a module, its body of code. - **Depth** — leverage at the interface: how much behaviour a caller (or test) exercises per unit of interface th