improve-codebase-architecturelisted

# Improve Codebase Architecture Find the smallest architectural changes that would make important future work safer and cheaper. Diagnose before designing and stop before implementation. Read `references/evidence.md` when choosing signals or ranking candidates. ## Respect the Assessment Contract - Work read-only unless the user explicitly asks to implement a selected change. - Produce candidates, evidence, and a recommendation. Do not silently begin a refactor, create architecture documents, or rewrite domain terminology. - Keep the main agent responsible for scope, synthesis, and the final recommendation. - Use `codebase-design` after a specific module boundary or interface is chosen. - Use `plan-task` when the selected change needs an execution-ready migration plan. ## Choose the Review Surface Use the user's named module, subsystem, pain point, or change direction when one exists. Otherwise, identify likely change pressure from repository evidence: - recent history and repeatedly changed paths; - defect-prone or rollback-prone areas; - features that require edits across many unrelated files; - duplicated invariants or policy; - tests that must reach through several layers; - architecture records, ownership boundaries, and active roadmap work. Do not equate age, file size, dependency count, or unfamiliar style with an architectural problem. Widen the scan only when the initial evidence does not identify a useful surface. ## Explore the Current Design Read a