You are reviewing a PR that renames a response field used by frontend and external clients. What do you check before approving it?

For a coordinated internal client, we may deploy tolerant reading first, add the new field while still returning the old one, switch the client, verify usage, and remove the old field later. For mobile or external consumers, the compatibility window is longer and may require a versioned contract. I check nullability, serialization naming policies, generated client behavior, cached responses, examples, error models, and whether both fields can disagree. One source value should produce both names during transition, and the old field is clearly deprecated in schema and documentation.