Scenario
An API response will rename displayName to name, add a defaulted locale, and keep the old field for one release. The examples show a possible shape, but they do not prove a safe rollout.
Broken input
{ "user": { "id": "usr_182", "displayName": "Ada", "locale": "en" } }
Goal
Create a local Current-to-Proposed plan that keeps structural evidence, declared intent, rollout assumptions, and generated review artifacts separate.
Tool sequence
- Open Toolzy JSON Plan and create Current and Proposed from a known sample.
- Edit Proposed deliberately: add
name, retaindisplayName, and add the defaultedlocalefield. - Record declarations for the rename, deprecation, and addition; include a rationale and rollout assumption where the samples cannot decide.
- Review producer, consumer, and rollout impact separately. Keep uncertain cases as needs review.
- Review the local Markdown, schema, TypeScript, fixture, and bundle artifacts before exporting any of them.
Checkpoint output
Current: $.user.displayName
Proposed: $.user.name + $.user.displayName (deprecated) + $.user.locale
Review: producer and consumer impact recorded separately
The plan explains what will change and what still needs a decision; it does not pretend that one example proves compatibility.
Common mistakes
- Deleting the old field while calling the action a deprecation.
- Treating a sample-added field as automatically required.
- Exporting artifacts before resolving missing rationale or rollout assumptions.
- Using a comparison baseline as if it were a declared contract plan.
Related tools and lessons
- Toolzy JSON Compare - Collect ad hoc evidence before planning.
- Toolzy JSON Schema - Generate an observed starter schema locally.
- JSON Formatter - Make a sample readable before review.
- Related lesson: Compare JSON Payloads Across Environments
- Related lesson: Review Breaking JSON Contract Impact
- Related lesson: Verify an Implemented JSON Contract