refactorlisted

# Refactor Change structure while behavior stays pinned, and leave less code than you found. The enemy is the half-finished move: the old API kept beside the new one, a shim forwarding to it, or a reshape trusted because it type-checks. The overcorrection is a refactor that grows new layers for needs nobody has written yet. ## When to use - A named rename, move, extraction, split, flattening or reshape of an internal API whose results must not change. - The pull to keep the old signature, accept both shapes, or leave a re-export "for compatibility". - Not for choosing what to refactor: `audit-architecture` finds and ranks the candidates. - Not for a change that alters behavior: `build-change` builds it; a mixed request runs the refactor first, then the change. - Not for persisted data, a stored format or a consumer outside this repository: `build-change` keeps those compatible on purpose through its `../build-change/references/data-migration.md`. - Not for a failure whose cause is unproven: `find-cause` owns it. ## The loop 1. **Pin behavior before the first move.** Capture current outputs in a test, snapshot or before/after script over the inputs that matter; type check and lint pin nothing, because both pass on a wrong price. 2. **Name the target shape.** One sentence on the module layout and call graph as if built today; the reshape removes branches, layers or states, never adds indirection. 3. **Subtract first.** Delete dead code, one-caller wrappers and orphaned ref