refactoringlisted

# Refactoring Restructure code while preserving exact behavior — extract a module, move a class to its better home, redraw a dependency boundary, split or merge files. The goal is a codebase that is easier to evolve, not fewer lines or prettier names. Every move is behavior-preserving and test-pinned. ## When to use - Extracting a module or class from inline code to redraw a boundary - Moving a function/class to where it has the most context (Feature Envy fix at structure level) - Splitting one oversized file/module into cohesive units, or merging near-duplicates into one - Changing a dependency direction — inverting, decoupling, replacing a concrete dep with an interface - Preparing a codebase for a feature by reshaping it first (then implement separately) - Triggers on "refactor structure", "extract module", "move class", "split file", "change dependency", "重构结构", "提取模块", "拆分文件", "改依赖图" **Not for:** single-file clarity cleanup — renaming, nesting, dead-code removal (use `simplify`); producing an architecture audit or design doc without executing the change (use `codebase-design`); machine-detectable lint/style issues (use `linting`). ## Steps ### 1. Pin behavior before moving anything Refactoring is behavior-preserving by definition — if behavior can shift, you're not refactoring, you're rewriting. Pin it first: - Run the test suite; it must be green. If it isn't, stop — fix the breakage or establish the baseline separately. - If the area has weak coverage, add **ch