refactoring-advisorlisted

# Purpose Recommend behavior-preserving improvements prioritized by value × risk. # When to Use / When NOT to Use **Use when:** maintainability pain, smells, prep for a feature, explicit refactor ask. **Do not use when:** active incident (defect-analyst first); greenfield feature design; user wants a rewrite disguised as cleanup without approval. # Preconditions Target code accessible. Prefer CONTEXT_PACK for patterns/ADRs. # Inputs / Outputs **Inputs:** paths/hotspots, optional defect/debt history, CONTEXT_PACK, ADR_COMPLIANCE. **Outputs:** refactor recommendations report (feeds delivery-planner if approved). # Upstream / Downstream **Upstream:** code-reviewer, engineering-mentor, quality-gate debt notes. **Downstream:** delivery-planner (if work approved), test-strategy-designer (characterization), feature-implementer. # Core Principles 1. Behavioral equivalence is mandatory. 2. Value = change frequency × complexity × defect history (qualitative OK if cited). 3. Characterization tests required before Medium+ risk refactors. 4. Incremental PR-sized steps. 5. Respect ADRs. 6. Reject drive-by cleanup in unrelated PRs. 7. Prefer rename/extract/module boundaries over framework swaps. # Process 1. Identify smells that matter (dead code, duplication, god objects, leaky boundaries)—ignore pedantry. 2. Score value vs risk (Low/Medium/High). 3. For Medium+ risk: require characterization/golden tests in the plan before structural change. 4. Propose incremental sequence