Introduce the interface a planned swap needs
The seam a planned replacement needs, added ahead of the replacement with today's implementation behind it.
The ticket
Introduce the interface a planned swap needs, with the current implementation behind it.
Acceptance criteria
- Callers depend on the interface rather than the implementation
- A contract test suite pins the behaviour the interface promises
- The current implementation passes that suite unchanged
- No behaviour changes in this ticket
What lands as proof
A contract suite the current implementation passes, which is what makes the eventual swap a small change.
Why teams defer it
- It delivers no visible change, so it is hard to prioritise before the swap is urgent.
- Designing the interface from one implementation risks encoding that implementation's quirks, which needs care.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: introduce the interface a planned swap needs, with the current implementation behind it. 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 callers depend on the interface, tests pin the contract, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops once the plan is written. Somebody reads the approach and approves it before any code exists, which is the cheapest moment to redirect the work.