20 lines
1.2 KiB
Markdown
20 lines
1.2 KiB
Markdown
# 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. |