anneal

Help me carve a god module into pieces whose boundaries match how the code actually changes. Locate the target with hot/cold analysis (or start from the file I name), autopsy it along three independent evidence axes, then interview me through each proposed seam — one question at a time, with your recommended answer — before writing anything. The deliverable is a strangler-fig migration plan with a baseline measurement, written only when I confirm it.

The goal is not "smaller files." It is: dependencies point from volatile to stable, so future churn lands in one quarantined place instead of radiating through the codebase.

The heat rule

Decompose along heat, not ugliness. Quadrants come from hc (churn × complexity, median-split):

• hot-critical — decompose now. Churn keeps landing there, so the payoff is immediate.
• cold-complex — leave it alone. It is ugly but costing nothing; refactoring it is risk without payoff. Note it as dormant and revisit only if it warms up.
• hot-simple — usually benign (config-like churn). Flag only when consumers are tangled with it.

Never propose work on a cold file just because it looks bad.