REFACTORING OBJECTIVE
Refactor the payment retry logic that ships to production weekly — zero regression tolerance.
Refactoring goal: maintainability — make the next change cheaper without changing current behavior.
Change how the code is built — never what the code does. If a transformation cannot be made safely with the available information, leave that code unchanged and say why.
EXISTING CODE CONTEXT
Code context: production — regression cost is high and rollout matters.
- Optimize for regression avoidance over improvement depth: a smaller, safer refactor beats a better, riskier one.
- Keep changes observable: behavior-relevant logging and metrics stay intact so a regression would be visible.
- Structure the change so it can be rolled out and rolled back safely — reviewable steps, no big-bang switch.
Language: not specified — infer it from the code and stay consistent with it.
Stated constraints:
- Behavior-relevant log lines are consumed by alerting and must stay intact
Code to refactor:
```
[Paste the code to refactor here]
```
REFACTORING GOAL
Primary goal: Maintainability.
Transformation priorities for this goal:
1. Separate concerns: split code that changes for different reasons into units that change for one reason.
2. Reduce duplication by extracting the shared logic — once duplication is gone, a future fix lands in one place.
3. Clarify responsibilities: one job per function, one purpose per module.
4. Localize change impact: a future edit should touch few places, not many.
RISK PROFILE
Risk level: Conservative.
- Treat this as production code with low risk tolerance: make the smallest change set that achieves the goal.
- Prefer many small, independently safe transformations over one large restructuring.
- Skip any transformation whose safety cannot be established from the code in front of you — list it as a suggestion instead.
- Keep every public contract, signature, and observable behavior exactly as it is.
SAFETY RULES
These rules apply to every transformation, at every risk level:
1. Identify behavior assumptions before changing code — list every assumption you rely on.
2. Flag uncertain behavior instead of deciding it: if you cannot tell what a branch does or why it exists, ask — do not guess.
3. Do not remove functionality. Code that looks redundant may be load-bearing.
4. Do not invent requirements. Refactor toward the stated goal, not toward an imagined better product.
5. Do not rewrite unrelated code. Touch only what the goal requires.
6. Explain why each change exists — every transformation traces to the stated goal or to a named problem in the code.
7. Preserve public contracts — signatures, return types, error types, serialized shapes — unless explicitly instructed otherwise.
TRANSFORMATION GUIDANCE
Known failure modes of this goal — watch for:
- Near-duplicate code is not always true duplication — merging two similar blocks that evolve for different reasons creates coupling, not reuse.
- Do not abstract for imagined future requirements — extract what is duplicated now, not what might vary someday.
BEHAVIOR PRESERVATION REQUIREMENTS
- Preserve observable behavior: the same inputs produce the same outputs, including error cases.
- Preserve business rules: every condition, threshold, and special case survives the refactor exactly.
- Preserve outputs: formats, ordering, precision, and encodings stay identical unless the goal explicitly targets them.
- Preserve side effects: writes, emitted events, log lines other systems consume — and their relative order.
- Preserve integrations: API shapes, serialized payloads, database access patterns, and external call sequences.
- These requirements hold unless the instructions explicitly say otherwise — and any knowingly behavior-affecting change must be flagged, never silent.
- If achieving the goal and preserving behavior conflict, behavior wins: stop and explain the conflict instead of compromising it.
VALIDATION STRATEGY
Goal-specific validation: every extraction and merge must preserve each original call path's behavior, including its edge cases.
- Provide a before/after verification plan: the specific inputs to run against both versions and the outputs that must match.
- Provide a behavior comparison: for each changed unit, the observable behaviors it had before and the evidence each is intact after.
- Provide regression validation: the existing tests that must pass, and the missing tests that should exist before this refactor ships.
- Provide integration verification: every external touchpoint — API consumers, database, events, files — and how to confirm each still sees identical behavior.
ASSUMPTIONS
- List every assumption made about the code's behavior, inputs, or environment.
- Mark each assumption VERIFIED (with its evidence) or UNVERIFIED (with the question that would resolve it).
- Any transformation that depends on an UNVERIFIED assumption must be flagged as conditional on it.
NON-GOALS
- Do not invent requirements.
- Do not redesign the entire system.
- Do not remove behavior without justification.
- Do not introduce new features.
- Separate assumptions clearly from facts.
- Flag uncertainty instead of resolving it silently.
- Explain the tradeoffs of any change that has them.
OUTPUT REQUIREMENTS
- Return the refactored code, complete — no elided sections, no "rest unchanged" placeholders inside changed units.
- Follow it with a change list: for each change — what changed, why it serves the goal, and its behavior impact (expected: none).
- Flag any change that could plausibly alter behavior, with the reason it might and the check that would confirm it does not.
- Where a worthwhile transformation was skipped for safety, list it under "Suggested but not applied" with what information would unlock it.