breaking-change-reviewlisted

# Breaking Change Review Determine whether a proposed change breaks an existing consumer, contract, data assumption, or operational procedure. Review the actual diff and surrounding evidence; do not call a change safe merely because it compiles or a unit test passes. If the compatibility promise is unknown, state the uncertainty and route it to the contract owner. ## Map the contract surface Identify the changed artifact and every boundary it crosses: HTTP/RPC APIs, SDKs, events and queues, webhooks, files, database schemas, configuration, environment variables, CLI flags and output, feature flags, permissions, generated clients, dashboards, runbooks, and external integrations. Inventory producers, consumers, versions, rollout cohorts, data states, and deprecation policy. Search repository documentation, tests, schemas, and deployment configuration for implicit consumers; mark unverified dependencies. ## Inspect compatibility dimensions Check for: - removed or renamed fields, endpoints, commands, flags, environment variables, events, scopes, or configuration keys; - changed defaults, requiredness, nullability, enum values, formats, ordering, status codes, error shapes, pagination, timeouts, or retry semantics; - narrowed accepted input, broadened or changed output, altered authorization, tenant behavior, idempotency, rate limits, or side effects; - event and webhook shape changes, delivery ordering, replay behavior, schema evolution, consumer lag, and dual-read/dual-wri