refactor-modulelisted

# Refactor a module A refactor changes structure, not behaviour. The contract: tests are green before you start and green after, with no scope creep into new features or fixes. ## Steps 1. **Establish the safety net.** Run the suite first (`run-tests`) and confirm it's green. If the module under refactor is thinly tested, add characterization tests (the `add-unit-test` skill) that pin the current behaviour before you touch anything. 2. **Read the lore.** Call `search_lore` (Memory MCP) for the repo's module boundaries, layering, and naming conventions so the new structure fits the codebase. 3. **Refactor in small, behaviour-preserving steps** — extract, rename, move, dedupe — re-running tests after each step. Keep the public interface stable unless the ticket explicitly allows changing it; update call sites if you do. 4. **Change no behaviour.** No new features, no bug fixes, no dependency changes riding along. If you spot a real bug, note it for a separate ticket — don't fix it here. 5. **Confirm green after.** Run the full suite and lint (`run-tests`, `run-lint`) and confirm identical behaviour and no new failures. 6. **Evidence:** before/after passing summaries (proving behaviour preserved) and a `diff_summary`. Then use the `record-evidence` skill and submit for review. ## Rules - Behaviour-preserving only: tests green before and after, same outcomes. - No scope creep — no features, fixes, or dependency bumps in a refactor ticket. - Keep the p