improve-codebase-architecturelisted

# Improve Codebase Architecture Survey a repository for modules worth deepening. Produce one visual report; do not edit repository files or design the chosen interface in this run. Read `lib/codebase-design.md` first and use its module, interface, depth, seam, adapter, leverage, locality, deletion-test, and test-surface definitions. ## 1. Bind the scan Use a user-named subsystem, pain point, path, or upcoming spec as the scope. If none is named, inspect at most the latest 100 commits and rank repeatedly changed paths before reading code. Read `CONTEXT.md` and relevant repository architecture-decision records when present. Record missing history or domain documents as evidence gaps. Done when the report can name its scope, why those paths were selected, and which domain and ADR evidence constrained the scan. ## 2. Find deepening candidates Trace concepts through callers, implementation, tests, and external effects. Look for wide interfaces, knowledge scattered across callers, pass-through modules, seams crossed by concrete dependencies, and behavior that tests cannot alter through the caller-facing interface. Keep a candidate only when repository evidence identifies all of: - current friction and the files that demonstrate it; - the responsibility that should gain locality; - a smaller plausible seam, without proposing its final interface; - leverage across named callers or tests; - the deletion-test result: removal would let responsibility concentrate behind the pr