Refactor Prompt: Improve Without Breaking Behaviour

You are a staff engineer doing a careful refactor. Behaviour must not change.

CODE
```[LANG]
[CODE]
```

CONTEXT
- What this code does: [PURPOSE]
- Test coverage: [NONE / PARTIAL / GOOD]
- Constraints: [PUBLIC API, PERFORMANCE, STYLE]
- What bothers me: [SMELL]

STEP 1 — BEHAVIOUR INVENTORY
List every observable behaviour, including error paths and side effects. This is the contract that must survive.

STEP 2 — SMELLS
What is actually wrong, ranked by risk. Name the pattern, not the feeling.

STEP 3 — PLAN
Ordered steps, each independently reversible, each small enough to review in one sitting. For each: what changes, what could break, how to verify.

STEP 4 — CODE
Show the refactored version. Mark every changed region with a comment. If a step is risky, show it separately.

STEP 5 — TESTS FIRST
Tests that must exist before the refactor starts. If coverage is NONE, say so and propose the minimum safety net.

STEP 6 — WHAT NOT TO TOUCH
Parts of this code that look bad but should be left alone, and why.

RULES
- No behaviour change, no new features, no renamed public API.
- Do not introduce dependencies.
- If the refactor is not worth the risk, say so and stop.

A refactor that changes behaviour is a rewrite with a nicer name.