Refactor without touching architecture

Improve a targeted area via dependency mapping, atomic refactors, and regression checks — no changes to architecture or public contracts.

Use this when

Use this for a focused readability, typing, maintainability, or performance refactor whose intended behavior and public contracts should remain unchanged.

How it runs

1. Define the target, measurable goal, current behavior, public contracts, and applicable baseline checks.
2. Map internal call sites, upstream dependencies, and downstream consumers using the repository evidence available.
3. Select or add representative tests for boundaries, type constraints, and failure modes without forcing arbitrary coverage work.
4. Apply one atomic refactor and rerun the baseline, static checks, and affected-consumer checks.
5. Keep only verified improvements and repeat for no more than five rounds before entering a terminal state.

Done when

✓ The target improves without changing contracts or downstream behavior. The stated measurable goal is met, baseline behavior and public interfaces remain intact, and the relevant tests, type checks, lint checks, and affected-consumer checks pass under recorded conditions.

Why it works

A blast-radius map prevents a locally attractive change from breaking consumers elsewhere. Atomic iterations and fixed checks make it possible to reject a failed attempt without compounding uncertainty across later changes.

Implementation note

Do not discard unrelated work, modify public signatures or contracts without authorization, or manufacture a clean result by weakening tests or checks. An AST or generated dependency graph is optional when direct repository evidence provides a clearer impact map.

Source: Forward Future ↗graded C · 65/100 — how grades work →

More testing loops