m_code_refactorlisted

# m_code_refactor Change structure without breaking behavior — in slices small enough to review in one diff. Two axes decide how you work: - **Behavior mode** - `preserve` (default) — externally visible behavior must not change. For legacy modernization and risk reduction. - `may-change` — an architecture or behavior change is the explicit goal. Enter this mode only when the user asks for it. - **Change strategy** - `report-only` — assessment + migration plan, no edits. Default when the user asks for a review or plan. - `patch-small` — one safe improvement with checks. Default when the user asks to refactor/fix. - `patch-slice` — one vertical slice (extract → seam → adapter → wiring) with tests. Never fold a feature change into a refactor unless asked, and never do a big-bang rewrite unless the user accepts that risk. A rewrite hides the behavior drift that small slices would surface. ## Contract Use `$ARGUMENTS` as the target module / path / feature and the goal. If the user named a behavior change, switch to `may-change`; otherwise stay in `preserve`. Do not apply Clean Architecture, DDD, repositories, services, or interfaces mechanically. Each abstraction has to earn its place (see step 7) — unjustified ceremony makes code *harder* to change, which is the opposite of the point. ## Workflow ### 1. Establish a baseline Before editing, pin down what "still works" means. For a large or unfamiliar area, delegate the wide scan to the `m_code-context-scout` ag