Architecture Review — Boundaries & Coupling

Perform an architecture review of the codebase described below. Stay at the module level — do not comment on individual functions or style. Your reader is a tech lead deciding where to invest refactoring effort this quarter. Analyze: 1. **Dependency direction** — Draw the actual dependency graph between the major modules (mermaid). Mark every edge that points the wrong way: infrastructure depended on by domain logic, low-level utilities importing business concepts, cycles of any kind. For each wrong-way edge, name the specific import(s) that create it. 2. **Boundary integrity** — For each module boundary: what is the intended contract, and where is it bypassed? Look for: reaching into another module's internals, shared mutable state between modules, database tables written by more than one module, types from one layer leaking through another (ORM entities in API responses, HTTP concepts in domain code). 3. **God modules** — Which module would you have to touch for the majority of plausible feature requests? Measure by fan-in + fan-out, not size. What distinct responsibilities is it hoarding? 4. **Change scenarios** — Take these two upcoming changes: {{upcoming_changes}}. Trace which modules each would touch. If a supposedly local change touches four modules, the boundaries are wrong for this team's actual workload — say where. 5. **The verdict** — Exactly 2–3 refactoring seams, ranked by (pain relieved / effort). For each: what moves where, what gets an interface, the first low-risk PR that starts the migration, and what evidence would show it was worth it. Explicitly list bigger restructurings you considered and rejected as not worth it. Codebase map (directory tree, module descriptions, key imports): {{codebase_map}}