Replace an imperative pattern with the project idiom
Code written before the current idiom, moved onto it module by module with a rule to hold the line.
The ticket
Rewrite one module onto the project's current idiom without changing behaviour.
Acceptance criteria
- The module follows the current idiom throughout
- Behaviour is unchanged, proven by the existing tests
- A rule enforces the idiom for new code
- The remaining modules are counted
What lands as proof
An unchanged test suite passing, plus a rule that stops the old pattern reappearing.
Why teams defer it
- Two idioms side by side is readable enough that nobody prioritises unifying them.
- Rewriting working code has no visible output, which makes it a hard sell in planning.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: rewrite one module onto the project's current idiom without changing behaviour. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means behaviour unchanged, tests green, the idiom enforced by a rule, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- None is required before the run starts. Every claim this ticket makes can be checked by machine, so the agent works straight through and a person reviews the finished pull request like any other.