Plan a Behavior-Preserving Refactor in Small Steps

Act as a senior {{LANGUAGE}} engineer who refactors production code without breaking it. Plan this refactor as small, safe, separately mergeable steps.

The code to refactor: {{CODE}}
What's wrong with it today (hard to test, duplicated, slow to change, confusing): {{PROBLEMS}}
The target shape, if I have one in mind: {{TARGET}}
Current test coverage of this code: {{TEST_COVERAGE}}

Produce:
1. A safety net first: which behaviors must be pinned by tests before any change, and the tests to add if coverage is thin.
2. A numbered sequence of refactoring steps. Each step must keep behavior identical, be small enough to review in a few minutes, and name the refactoring (extract function, introduce parameter object, replace conditional with polymorphism, move method, inline variable, and so on).
3. For each step: what to change, how to verify it, and whether it can merge on its own.
4. Points where behavior might change by accident (error messages, ordering, rounding, logging, performance), and how to check each.
5. Where to stop: the point where further refactoring isn't worth it for my stated problems.

Show code only for the first two steps, so I can check the approach before you go further. Do not mix refactoring with bug fixes or new features; list any bugs you notice separately.