Refactoring Plan for an Existing Module

Plan a refactor. Binding constraint: every step deploys separately, reviews separately, and reverts separately. No big rewrite.

Current code: <code> [Paste the module or describe its structure] </code>

The actual problem: [what is hard to do today, not "the code is ugly"] Existing test coverage: [describe]

Produce:

1. Whether to refactor at all — if the code works and does not touch upcoming work, say so and stop. A refactor without a need is risk without return.
2. Safety net — which tests must exist before touching anything. With no coverage, step one is characterisation tests documenting current behaviour, including behaviour that looks wrong.
3. Step sequence — each step with: what changes, estimated diff size, what proves nothing broke, and how to revert. Aim for steps under 200 lines.
4. Order — start with the step having the best value-to-risk ratio. Never change behaviour and structure in the same commit.
5. Compatibility — how existing callers keep working through the transition. A shim if needed, and when it gets deleted.
6. Stop condition — what signals the refactor has become too expensive and should stop with what has been achieved.

Explicitly state what not to touch in this pass, and why.