Version negotiation: inspect payload compatibility

Edit the request data

Exact current operation

A version label cannot transform a payload

This experiment defines fictional revisions to make compatibility visible. Revision 1.0 uses id and text; revision 1.1 uses requestId and a nonempty array of text parts. A server normalizes either supported representation into one requestId and text value, counts whitespace-separated words, then encodes a response. These revision numbers and schemas are invented for teaching. They are not A2A release numbers, protocol compatibility guarantees or a claim that matching major versions automatically interoperate.

Use each contract control

Request fixture loads a complete editable JSON document for revision 1.0, 1.1 or unsupported 2.0. Choosing a fixture or Load example replaces your edits. Server policy either allows both supported revisions or requires exactly 1.1 before decoding begins. Enable explicit 1.0 request adapter controls whether the legacy id/text fields can be normalized. An accepted version negotiation can still fail without that adapter. Response encoding either matches the negotiated client revision or always emits the newer 1.1 representation. The latter can break a legacy client even when the handler completed correctly.

Test both directions

Choose revision 1.0, allow both revisions, enable the adapter and match response encoding. The baseline text contains three words; the decoded reply is Words: 3 with the original request identifier. Disable the adapter to fail request decoding. Restore it and force a 1.1 response: the server still counts the words, but client decoding rejects the response revision. Next choose exact 1.1 policy to reject the legacy request earlier. In a 1.1 document change the text part value or add another text part; inspect the normalized text and computed word count rather than treating the outcome as a preset badge.

Inspect failure boundaries honestly

Malformed JSON stops before negotiation. Unsupported 2.0 stops before the handler. Missing identifiers, empty text and incorrectly typed parts fail normalization. A numeric request identifier is retained as a number through the response, not coerced to a string. The inspector shows the exact value or error for the current gate; later gates are marked not run after a failure. Play reveals six gates over sixty inspection seconds; Pause, Next operation, Restart, Speed and the timeline control the view. Inputs reset the experiment. There is no HTTP negotiation, authentication, feature discovery, backward-compatibility proof, generated client SDK or remote agent. This bounded lab demonstrates why a version policy needs tested adapters and response contracts.