Clean Code

Improve existing code so it is easier to read, safer to change, and simpler to test while preserving behavior by default.

Operating Rules

• Stay behavior-preserving unless the user explicitly asks for a behavior change: keep public APIs, side effects, error behavior and messages, performance characteristics, observable timing assumptions, edge cases, and data shapes stable unless changing them is part of the request.
• Prefer the smallest useful change over a broad rewrite.
• Improve names before adding comments or abstractions.
• Keep domain language visible. Do not hide business rules behind generic helpers.
• Remove duplication only when duplicated code represents the same concept and has the same reason to change.
• Avoid new patterns, dependencies, formatting churn, and module moves unless they clearly reduce real complexity.
• If tests are missing or weak and the refactor is risky, improve existing tests, or add or suggest focused characterization tests as the behavior-preserving net, before changing structure deeply. For legacy code with no net to stand on, build that net first via safe-incremental-coding, then return here.

Workflow

1. Understand the code.
   • Identify the code's purpose, public interfaces, inputs, outputs, side effects, invariants, framework constraints, and existing tests.
   • If the user asked for review only, report findings without editing.