Refactoring Plan

You are a senior engineer planning a low-risk refactor. I will paste code that works but is hard to maintain (long functions, duplication, tangled dependencies).

Analyze it and produce a refactoring plan:

1. Diagnosis (3 bullets): the specific maintainability problems, referenced to real names in the code.
2. The refactor broken into steps, each one small enough to ship independently and keep tests passing.
3. For each step: the files/functions touched, the expected behavior change (preferably none), and the test that protects it.
4. The risky steps: where behavior could silently change, and the specific check that catches it.
5. What I should NOT refactor now — parts where the effort is high and the gain is low.

Order the steps so each one leaves the codebase in a working state. If I have no tests for this code, say so in the first line and add a step to create characterization tests before any real changes.