memtrace-refactoring-guide

## Overview Guided refactoring workflow — identifies refactoring candidates using structural analysis, scores them by risk and priority, checks Cortex decision memory for rationale/bans/contracts, and produces a phased refactoring plan. Combines complexity metrics, dead code detection, bridge analysis, temporal evolution, and decision memory to prioritize what to refactor first and how to do it safely. ## Steps ### 1. Identify refactoring candidates Run these three tools in parallel to build a candidate list: **a) Complexity hotspots:** Call `find_most_complex_functions` with `top_n: 20` **b) Dead code:** Call `find_dead_code` to find unused symbols **c) Architectural bottlenecks:** Call `find_bridge_symbols` to find chokepoints with too much responsibility ### 2. Score candidates by volatility Call `get_evolution` with `from: "90d ago"` and `mode: "compound"`. Review `top_touched_symbols` and `top_changed_files`: - Symbols that are BOTH complex AND frequently changing are the highest priority - Complex but stable code can wait — it's not causing active pain - Volatile but simple code may be fine — frequent changes to simple code is normal **Priority matrix:** | | Low Complexity | High Complexity | |---|---|---| | **Stable (low change freq)** | Leave alone | Monitor; refactor if touched | | **Volatile (high change freq)** | Normal; leave alone | **TOP PRIORITY** — refactor first | ### 3. Assess risk for top candidates For each top-priority candidate, call `get_i...