Bump a vendor API version and adapt to the payload changes
A vendor API version bump, adapted with recorded fixtures replayed against the new version.
The ticket
Move to a newer vendor API version and adapt to its payload changes.
Acceptance criteria
- Recorded fixtures are replayed against the new version
- Removed and renamed fields are handled explicitly
- The version is pinned in one place
- Behaviour differences are listed in the description
What lands as proof
Fixtures replayed against the new version, which surfaces the field changes the changelog forgot to mention.
Why teams defer it
- The deadline belongs to the vendor, so it arrives without regard to your roadmap.
- Their changelog covers the documented changes and not the ones you actually depend on.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: move to a newer vendor API version and adapt to its payload changes. 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 recorded fixtures replayed against the new version, 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.