REFACTORING OBJECTIVE
Clean up this AI-generated service: collapse the repetition and remove the abstraction layers that make no decision.
Refactoring goal: simplification — reduce nesting, branching, and dead weight while keeping every 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: AI-generated — review for the failure modes typical of generated code.
- Hunt repetition: generated code duplicates logic instead of extracting it — consolidate the copies.
- Hunt over-abstraction: unnecessary wrappers, interfaces with a single implementation, layers that make no decision.
- Hunt unneeded complexity: defensive checks for impossible states, dead branches, over-general solutions to specific problems.
- Verify the code does what it appears to do — generated code can look right while being subtly wrong. Do not silently preserve a bug as behavior: flag it.
Language: not specified — infer it from the code and stay consistent with it.
Code to refactor:
```
[Paste the code to refactor here]
```
REFACTORING GOAL
Primary goal: Simplification.
Transformation priorities for this goal:
1. Flatten control flow: guard clauses and early returns instead of deep nesting.
2. Reduce branching: collapse conditions that encode the same decision more than once.
3. Remove dead code — but only code proven unreachable, not code that merely looks unused.
4. Shorten the path from input to output: remove indirection that adds steps without adding meaning.
RISK PROFILE
Risk level: Balanced.
- Apply reasonable improvements: moderate restructuring is allowed where the benefit is clear.
- Group related changes, but keep each group reviewable and separately verifiable.
- When a transformation is borderline-safe, apply the conservative version and note the more aggressive option.
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:
- "Looks unused" is not "is unused" — check for reflection, dependency injection, serialization, dynamic dispatch, and external callers before deleting anything.
- Inverting conditions to flatten nesting is a classic behavior-change risk — verify every branch still routes the same inputs to the same outcomes.
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: confirm every input class still reaches the same outcome — simplification must shrink the code, never the behavior.
- Identify the key workflows this code serves and describe how to verify each still works after the refactor.
- List the major edge cases the original code handles and confirm each is still handled — name them individually.
- Recommend regression checks for the riskiest transformations made, riskiest first.
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.