API Contract Compatibility Review
Use current primary guidance as a review baseline, then report only what the available evidence supports. Primary authority: official reference.
Workflow
- Inventory producers, consumers, versions, transports, schemas, ownership, and independent deployment paths.
- Compare request, response, event, error, authentication, pagination, ordering, idempotency, and timing semantics.
- Identify additive, breaking, ambiguous, or behaviorally breaking changes, including optionality and default shifts.
- Review tolerant-reader assumptions, unknown fields, enum expansion, precision, units, locale, and time handling.
- Define contract tests and compatibility fixtures across old and new producer-consumer combinations.
- Specify negotiation, versioning, deprecation, rollout, telemetry, and rollback behavior.
- Separate documented contracts from accidental implementation behavior and unratified proposals.
Boundaries
- Do not call a change backward compatible from schema shape alone.
- Do not remove or reinterpret a field without consumer evidence and deprecation authority.
- Passing one consumer test does not prove compatibility for unknown consumers.
Output
Return Contract inventory, Compatibility findings, Consumer risk, Test matrix, Rollout, Deprecation, and Unresolved authority.
1---2name: api-contract-compatibility-review3description: Review API, event, schema, and client changes for backward, forward, and rollout compatibility. Use when producers and consumers may upgrade independently or when a change can alter behavior, shape, timing, errors, or semantics.4license: MIT5---67# API Contract Compatibility Review89Use current primary guidance as a review baseline, then report only what the available evidence supports. Primary authority: [official reference](https://www.rfc-editor.org/rfc/rfc9110.txt).1011## Workflow12131. Inventory producers, consumers, versions, transports, schemas, ownership, and independent deployment paths.142. Compare request, response, event, error, authentication, pagination, ordering, idempotency, and timing semantics.153. Identify additive, breaking, ambiguous, or behaviorally breaking changes, including optionality and default shifts.164. Review tolerant-reader assumptions, unknown fields, enum expansion, precision, units, locale, and time handling.175. Define contract tests and compatibility fixtures across old and new producer-consumer combinations.186. Specify negotiation, versioning, deprecation, rollout, telemetry, and rollback behavior.197. Separate documented contracts from accidental implementation behavior and unratified proposals.2021## Boundaries2223- Do not call a change backward compatible from schema shape alone.24- Do not remove or reinterpret a field without consumer evidence and deprecation authority.25- Passing one consumer test does not prove compatibility for unknown consumers.2627## Output2829Return Contract inventory, Compatibility findings, Consumer risk, Test matrix, Rollout, Deprecation, and Unresolved authority.
JovaniPink