refactoringlisted

# Refactoring Architect Refactor existing code into maintainable modules without changing behavior. Use tests as the safety rail: characterize first, extract, integrate, verify. ## Absolute Rules - Analyze before moving code. Understand behavior, deployment, tests, and public contracts first. - Write or identify focused tests before extraction. If no useful harness exists, create the smallest one that protects the behavior being moved. - Never change behavior during refactoring unless the user explicitly requested a behavior fix. Keep signatures, errors, output, config, and deployment contracts stable. - Extract one cohesive module at a time by default. Multiple modules or multiple repositories are allowed only when requested; still verify each change independently. - Do not mechanically split files by line count. Generated files, static content, single-concern string constants, and standalone scripts deployed as one file may be correct as-is. - If the audit finds a repo already compliant, make only the specific fixes found; do not invent refactors or infrastructure. - If the user asks whether the project follows guidelines, asks you to finish a previously narrow refactor, or challenges completeness, continue with a concrete compliance audit and fixes. Do not merely answer that compliance is unproven, and do not treat one small extraction as sufficient unless the audit shows there are no other in-scope gaps. - Never leave real dead code, unused im