module-architecturelisted

# Module Architecture — modules and their contracts Turn the blueprint's component view into a concrete module map: self-contained modules with explicit interfaces, dynamically linked, where an upgrade in one module propagates safely to its dependents (#6, modular-by-default). The goal is loose coupling with contracts you can verify. ## Fits in the pipeline - **Stage 4** (`/module-map`). Input: approved stack (Stage 3) + journey + blueprint. Output: a module map + contracts that the foundation-first build plan (Stage 5) is built on. Owned by `solution-architect`. ## What to produce ### 1. Module decomposition List the modules. Each module is **self-contained**: owns its data and logic, exposes a narrow interface, hides its internals. For each: ``` Module: <name> Responsibility: one sentence — what it owns (single responsibility). Owns: data/state it is the source of truth for. Depends on: which other modules' contracts it consumes. Exposes: the contract other modules use (see below). ``` Don't over-decompose — a simple product may be a modular monolith, not 12 services. Match the decomposition to the actual complexity (senior-engineer test). ### 2. Communication & contracts (be explicit) For each link between modules, name the mechanism and pin the contract: - **Synchronous API:** endpoint/method signature, request/response schema, error semantics, versioning policy, auth. - **Events/async:** event name, payload schema, producer, consumers, ordering/delivery guarante