deep-module-refactor

# Improve Codebase Architecture Explore a codebase like an AI would, surface architectural friction, discover opportunities for improving testability, and propose module-deepening refactors as GitHub issue RFCs. A **deep module** (John Ousterhout, "A Philosophy of Software Design") has a small interface hiding a large implementation. Deep modules are more testable, more AI-navigable, and let you test at the boundary instead of inside. ## Process ### 1. Explore the codebase Use the Agent tool with subagent_type=Explore to navigate the codebase naturally. Do NOT follow rigid heuristics — explore organically and note where you experience friction: - Where does understanding one concept require bouncing between many small files? - Where are modules so shallow that the interface is nearly as complex as the implementation? - Where have pure functions been extracted just for testability, but the real bugs hide in how they're called? - Where do tightly-coupled modules create integration risk in the seams between them? - Which parts of the codebase are untested, or hard to test? The friction you encounter IS the signal. ### 2. Present candidates Present a numbered list of deepening opportunities. For each candidate, show: - **Cluster**: Which modules/concepts are involved - **Why they're coupled**: Shared types, call patterns, co-ownership of a concept - **Dependency category**: See [REFERENCE.md](REFERENCE.md) for the four categories - **Test impact**: What existing tests w...