Swap an SDK at every call site behind an existing interface
One SDK replaced with another behind an interface that already exists, verified by the same interface tests.
The ticket
Replace an SDK with an alternative behind the existing interface.
Acceptance criteria
- The same interface tests pass against the new implementation
- No caller imports the SDK directly
- The old dependency is removed
- Behaviour the new SDK cannot match is raised rather than silently dropped
What lands as proof
An unchanged interface test suite passing against the new implementation.
Why teams defer it
- Without an existing interface this is two projects, and the first one is invisible.
- The new SDK always lacks one thing the old one had, and finding out means reading both.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: replace an SDK with an alternative behind the existing interface. 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 the same interface tests pass against the new implementation, 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.