ContractKitThe proposed change
A support tool accepts a topic, a message and an optional reply address. The product team wants replies to every request, so a developer makes replyTo required. At the same time, they add a technical category to the allowed topics. Neither change is inherently wrong. They have different consequences for callers.
The released contract requires topic and message. Messages need at least eight characters. The revised contract adds the reply requirement. Both versions reject undeclared fields. These rules are the fixture’s product assumptions, not requirements of WebMCP itself.
{
"topic": "account",
"message": "Where is my export?"
}Before: accept. After: reject. The candidate fails this case’s retained expectation of acceptance.
Read the seven-case result
| Case | Before | After | Meaning |
|---|---|---|---|
| Existing account question | Accept | Reject | Tightened; review the missing reply address |
| Billing with reply address | Accept | Accept | The known complete request survives |
| New technical category | Reject | Accept | Intended widening |
| Short message | Reject | Reject | Length rule remains active |
| Unexpected admin property | Reject | Reject | Unknown-field rule remains active |
| Unknown category | Reject | Reject | The enum is still bounded |
| Wrong message type | Reject | Reject | A number is not a message string |
The default run shows six of seven candidate expectations matched. That fraction describes these seven fixtures, not a quality score or production failure rate. A more realistic suite could include empty addresses, whitespace-only messages, Unicode text and a caller that already supplies every field.
Decide what the expectation should mean
If the existing caller is still supported, remove replyTo from the candidate’s required array and rerun. All seven default expectations should then match. This is a useful repair when the signed-in application can retrieve an account address elsewhere. It is not appropriate when a reply address is truly necessary and unavailable.
If the requirement is deliberate, leave the schema unchanged, change that fixture’s expectation to reject, and document the rollout. Update the caller to collect the field, test the human-facing error, and decide when the old behavior can retire. Editing an expectation is a product decision; a green row alone does not justify it.
What the fixture deliberately does not test
The address is a string with a minimum length. This profile does not assert email syntax, ownership, deliverability or mailbox access. person@example.test is synthetic test data; no email is sent. A real system still needs its own validation, access checks and delivery tests.
Download the complete support fixture pack and import it in the workbench. Use the staging playbook to follow the contract result into a real form and, only on your own test system, a non-sensitive confirmation message.
Bring the question back to a concrete case.
Open ContractKit ↗