Perform a systematic refactoring of the specified code area.

## Steps

### 1. Identify Code Smells
Read the target code and identify issues:
- **Long functions** (>40 lines): break into smaller functions with descriptive names.
- **Deep nesting** (>3 levels): use early returns, guard clauses, or extract functions.
- **Duplicate logic**: extract shared functions or use parameterization.
- **God objects/modules**: split into focused, single-responsibility units.
- **Primitive obsession**: introduce domain types or value objects.
- **Feature envy**: move logic to the class/module that owns the data.
- **Unclear naming**: rename variables, functions, and files to reveal intent.

### 2. Verify Test Coverage
- Run existing tests to establish the green baseline.
- If coverage is insufficient, write characterization tests that capture current behavior before changing anything.
- Every refactored path must have a test that would catch a regression.

### 3. Plan Changes
- List each refactoring step in order.
- Each step should be a single, atomic change (one rename, one extract, one move).
- Order steps to minimize risk: rename before restructure, restructure before optimize.

### 4. Execute
- Apply one refactoring at a time.
- Run tests after each step to confirm behavior is preserved.
- Commit after each successful step if the changes are significant.

### 5. Verify
- Run the full test suite.
- Check that type checking passes.
- Compare behavior before and after (same inputs produce same outputs).

## Rules

- Refactoring changes structure, not behavior. If behavior changes, that is a feature or a fix.
- Never refactor and add features in the same step.
- If tests are missing, add them before refactoring, not after.
- Keep diffs reviewable: prefer multiple small commits over one massive change.
- If a refactoring reveals a bug, note it and fix it in a separate commit.