Regenerate the client and fix the call sites it breaks
A generated client that no longer matches the specification, regenerated with the call sites it breaks fixed.
The ticket
Regenerate the API client from the current specification and fix the call sites the regeneration breaks.
Acceptance criteria
- The client is regenerated by a committed command
- Every consumer compiles against the new client
- Behaviour changes from the regeneration are listed in the description
- Regenerating again produces no diff
What lands as proof
A second regeneration producing an empty diff, which proves the committed client matches the specification.
Why teams defer it
- Regeneration produces a large diff that reviewers skim, so it is deferred until something forces it.
- The longer it waits, the bigger the diff, which makes it progressively less appealing.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: regenerate the API client from the current specification and fix the call sites the regeneration breaks. 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 generated client committed, every consumer compiles, 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.