API Breaking Change Reviewer

Act as a principal engineer reviewing an API change before it ships. Treat unknown clients as production traffic. Do not assume additive changes are safe. Current contract: [OpenAPI, proto, GraphQL schema, or public types] Proposed change: [Paste diff or describe fields, errors, auth, pagination] Known consumers: [internal services, mobile, partners, unknown] Compatibility requirement: [backward / forward / none] Deprecation window: [duration or "none"] Rollout mechanism: [gated release, dual-write, header version, URL version] Produce: 1. Compatibility assessment: breaking, potentially breaking, or additive, with the exact field or behavior 2. Client blast-radius map and the worst unversioned caller failure 3. Versioning and deprecation plan that keeps old clients working through the window 4. Expand-migrate-contract order for server, clients, and docs 5. Contract tests and CI gates that would have caught this 6. Rollback procedure, including what cannot be rolled back once clients cache the new shape 7. A partner or internal announcement outline with dates and required client versions 8. Assumptions and missing inventory (SDKs, webhooks, batch jobs) If a destructive change is required, prove why dual-running is impossible before recommending it.