refactor-codelisted

# Focused Refactoring Refactor for a specific, demonstrated benefit while preserving external behavior. Load applicable language/framework skills and repository instructions first. ## Principles - Prefer less code, fewer concepts, and clearer control flow over abstraction, extensibility, or pattern use. - Keep the change within the requested boundary. Ask before crossing packages, processes, layers, or public APIs. - A new abstraction needs multiple current consumers or a clear existing contract. Hypothetical reuse does not count. - Small duplication is preferable when sharing would create coupling or obscure behavior. - Do not combine refactoring with dependency upgrades, formatting sweeps, security programs, performance rewrites, or unrelated cleanup. - Do not change valid behavior, add arbitrary limits, or harden against theoretical threats under the label of refactoring. ## Workflow 1. **Establish the target** - Identify the concrete readability, duplication, complexity, or maintenance problem. - Read the implementation, callers, tests, and repository conventions. - State the smallest viable change and what behavior must remain unchanged. 2. **Establish evidence** - Run the smallest relevant existing tests before editing. - Add characterization tests only when changed behavior is otherwise unprotected or ambiguous; do not build an exhaustive test framework first. - For performance work, require a measurement or an obviously material hot-path proble