Refactor with Claude Code without smuggling in a behavior change

You are refactoring, not rewriting. The observable behavior of the code in scope — every input and output pairing, every side effect, every error condition, and every public signature — must be identical before and after this change, unless the preservation constraint below explicitly permits something to change.

SCOPE
OrderProcessor.calculateTotal in services/order-processor.ts

THE ONE GOAL OF THIS REFACTOR
Reduce the nested if and else chain into something readable, no other goal.

MUST PRESERVE
The public method signature and its Decimal return type must not change; internal helper functions may be renamed freely.

EXISTING TEST COVERAGE OVER THIS CODE
14 unit tests in tests/order-processor.spec.ts covering the standard discount tiers, but none covering a cart with a single item.

PROCESS — FOLLOW IN ORDER
1. Before writing any code, list exactly what you intend to change and why, in terms of structure only, for example extracting one specific duplicated check into its own function. Do not begin editing until this list exists.
2. Make the change described in that list, and nothing beyond it.
3. Run the existing test suite exactly as it stands. If any test needs to change to keep passing, that is direct evidence you changed behavior, not merely structure — stop and explain what happened rather than editing the test to match the new code.
4. For each hunk in the resulting diff, write one line: what changed structurally, and an explicit confirmation of what stayed behaviorally identical across that same hunk.

CONSTRAINTS
- Do not change a public function signature, an exported name, or a return shape unless the preservation constraint above explicitly permits it.
- Do not fix an unrelated bug you notice mid-refactor, even a trivial one. Note it separately at the end instead.
- If the stated goal is impossible to achieve without a behavior change somewhere, stop and say exactly where before writing any code — do not make the change silently and disclose it only in a closing summary.
- If the existing test coverage described above does not actually exercise the behavior you are about to touch, say so before refactoring, since a passing suite after the change would not actually prove anything in that gap.
- If the change list from step one would require touching more files than the scope above names, treat that as a signal the scope was drawn too narrowly rather than silently expanding it — stop and ask whether the scope should be widened deliberately, instead of creeping past it one file at a time.

OUTPUT
The structural change list, the diff, the per-hunk structural-versus-behavioral notes, and the test run result with pass and fail counts. If a coverage gap was found, add one line naming the specific behavior that a new test would need to exercise to close it.