principle-deep-moduleslisted

# Deep Modules Build a wide system of deep modules. Each module encapsulates substantial functionality behind a small, stable interface. The system holds several independently owned modules that agents can work on in parallel. **Why:** Agents reason best within a bounded context: inputs, contract, outputs, without loading adjacent internals. Deep modules lower context requirements, constrain what a change can accidentally break, let multiple agents modify separate modules without editing shared internals, and make review a check against a contract. A shallow module exposes many functions, types, and implementation decisions relative to the value it provides, and every consumer inherits them. **The topology:** - Wide at the system level. Several independently understandable modules, not one giant deep module hiding the whole application. - Deep at the module level. A small public API over significant internal implementation. Depth is the ratio of functionality hidden to interface exposed. The interface-compression test in the **minimize-reader-load** principle skill is the arbiter, so a pass-through entry point that re-exports three functions is not depth. - Shallow in directory nesting. Deep conceptual modules, shallow paths. `src/ordering/domain/` is fine; `src/modules/business/order/core/domain/entities/internal/` is not. **The rules:** - One obvious public entry point per module. Internal accessibility does not imply architectural permission; callers never reach thro