Add one more provider to an existing integration point
Another provider behind an interface that already exists, verified by the shared conformance suite.
The ticket
Add a provider implementation behind an existing integration interface.
Acceptance criteria
- The provider passes the shared conformance suite with no changes to the suite
- Credentials are resolved the same way as the existing providers
- Provider-specific behaviour is handled inside the implementation, not leaked to callers
- Selection is configuration rather than code
What lands as proof
An unchanged conformance suite passing against the new provider, which is what proves the interface held.
Why teams defer it
- The new provider always differs in one awkward way, and deciding whether to bend the interface is a design call.
- Testing it properly needs credentials for a service the team may not have an account with yet.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: add a provider implementation behind an existing integration 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 provider passes the shared conformance suite unchanged, 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.