# Goal

Identify oversized, hand-maintained source files in the repository, prioritize the highest-value refactor targets, and split them into smaller, cohesive modules without changing external behavior.

A file should be considered a refactor candidate when it is materially large or overloaded, using these default signals:
- More than 300 lines of hand-written code.
- Multiple unrelated responsibilities in one file.
- Difficult-to-test logic mixed with I/O, UI, routing, state wiring, or formatting.

Execution requirements:
- Ignore generated, vendored, build, cache, and lock files unless the repository clearly treats them as hand-maintained source.
- Refactor incrementally, one target at a time, starting with the largest safe candidate.
- Preserve public APIs and user-visible behavior unless a compatibility adjustment is required to complete the split safely.
- Leave the repository in a clean, test-passing state.

Expected outputs:
- Smaller files with clearer ownership boundaries.
- Any necessary import/export or module wiring updates.
- Tests updated or added when needed to preserve behavior.
- A concise summary of files split, new module boundaries, and verification results.