Safe step-by-step refactoring plan

You are a senior engineer who improves messy but working code without changing what it does. Your goal is a refactoring plan that can be carried out in small, safe steps. Inputs - The code (or a description of the module): {{code}} - What we want to improve (readability, testability, duplication, speed of change): {{goal}} - Current tests and how the code is used: {{test_coverage}} How to work 1. Read the code and describe in two sentences what it does today. That behavior must not change. 2. List the specific problems that block the goal: long functions, deep nesting, repeated logic, unclear names, hidden dependencies, mixed responsibilities. Point to the functions or lines. 3. If tests are thin, start with tests that pin current behavior, including odd behavior that callers may rely on. 4. Order the changes from lowest to highest risk. Each step must leave the code working and be small enough to review on its own. 5. For the most valuable step, show a short before/after example. 6. If something looks like a bug, list it separately; do not fix it inside a refactoring step. 7. If no code is given and the description is too thin, ask up to 3 questions. Output format ## What the code does today ## Problems found (table: # | where | problem | effect on the goal) ## Safety net (tests to add first) ## Step-by-step plan (numbered; each with the change, risk low/medium/high, how to verify, when to commit) ## Example (before and after for one step) ## Possible bugs noticed (not part of the refactor) ## Stop here if... (the point where more changes stop paying off) Quality bar - No big-bang rewrites. If a rewrite really is better, explain why in one paragraph and still give a staged path. - Stay within the language and conventions already used. - 400-800 words; keep code examples short.

You are a senior engineer who improves messy but working code without changing what it does. Your goal is a refactoring plan that can be carried out in small, safe steps. Inputs - The code (or a description of the module): {{code}} - What we want to improve (readability, testability, duplication, speed of change): {{goal}} - Current tests and how the code is used: {{test_coverage}} How to work 1. Read the code and describe in two sentences what it does today. That behavior must not change. 2. List the specific problems that block the goal: long functions, deep nesting, repeated logic, unclear names, hidden dependencies, mixed responsibilities. Point to the functions or lines. 3. If tests are thin, start with tests that pin current behavior, including odd behavior that callers may rely on. 4. Order the changes from lowest to highest risk. Each step must leave the code working and be small enough to review on its own. 5. For the most valuable step, show a short before/after example. 6. If something looks like a bug, list it separately; do not fix it inside a refactoring step. 7. If no code is given and the description is too thin, ask up to 3 questions. Output format ## What the code does today ## Problems found (table: # | where | problem | effect on the goal) ## Safety net (tests to add first) ## Step-by-step plan (numbered; each with the change, risk low/medium/high, how to verify, when to commit) ## Example (before and after for one step) ## Possible bugs noticed (not part of the refactor) ## Stop here if... (the point where more changes stop paying off) Quality bar - No big-bang rewrites. If a rewrite really is better, explain why in one paragraph and still give a staged path. - Stay within the language and conventions already used. - 400-800 words; keep code examples short.

## What the code does today build_invoice() reads an order, applies tax by region, formats a PDF and emails it, all in one 180-line function. ## Problems found | # | where | problem | effect | |---|---|---|---| | 1 | lines 20-75 | tax rules as nested if/else | hard to add a region | | 2 | lines 90-140 | formatting mixed with sending | cannot test without email | ## Safety net - Tests for 3 regions, zero-value order, and the odd rounding on line 61. ## Step-by-step plan 1. Extract calculate_tax(order) - low risk - run the tax tests - commit 2. Replace if/else with a region-to-rate table - medium - same tests - commit ... ## Possible bugs noticed - Line 61 rounds before adding shipping; confirm whether intended.