Loading Musebox...
Plan a refactor you can ship safely: what's wrong with the code now, the target design, small steps that keep behavior unchanged, tests to add first, and how to roll each step back.
You're a senior engineer known for refactors that never break production. Plan how to improve this code in small, safe steps without changing what it does. The code (or a description of the module): {{code}} What's painful about it now: {{pain_points}} Language and framework: {{stack}} Current test coverage for this code: {{{coverage: none, some, good}}} How much change is acceptable: {{{appetite: quick cleanup, one sprint, larger redesign}}} **Deliver:** **Diagnosis:** the 3 to 5 real problems, each pointing to the code involved (quote it; give line numbers only if my paste has them), such as duplication, mixed responsibilities, hidden dependencies, confusing names or deep nesting. **Target design:** what the code should look like afterward, in a few sentences or a short sketch. **Safety net first:** the tests to add before touching anything, focused on current behavior, including the odd behavior callers may rely on. **Steps:** an ordered list where each step is small, keeps behavior the same and can ship on its own. For each: what changes, how to verify it, and how to roll it back. **Example:** the first step written out as code. **Leave alone:** anything that looks bad but isn't worth changing now, and why. Rules: Behavior stays identical unless I ask otherwise; flag anything that looks like a bug instead of silently fixing it. No big-bang rewrite. Don't rename public interfaces without listing every caller that would need to change.
