ContractKit1. Name the change and its consequence
Write one sentence that someone outside the implementation can review: “Existing support callers now need a reply address.” Add an ordinary request, a missing-field request, a wrong-type request and the exact boundary you changed. Give each case a purpose rather than numbering it test1, test2 and test3.
Keep the before contract from the released version. Use the after contract from the proposed version. Preserve expectations until you decide that a change is intentional. Save the result report and the fixture pack separately: the pack contains inputs and should be reviewed before sharing.
2. Verify the handler boundary
On your own staging app, arrange a request that the schema should reject and observe whether the action starts. Record the handler outcome and the final application state. If the browser delivers an invalid object, your application must still reject it before a side effect. ContractKit’s native receipt check helps demonstrate the distinction, but it cannot inspect your staging backend.
Also test a valid request without the required application permission. Input validity, authentication, authorization and user confirmation answer different questions. An annotation is useful metadata; it does not replace an application access check.
3. Repeat the human path in a fresh session
Open the deployed staging URL without existing cookies or extensions. Complete the same request through the visible form using the keyboard. Check focus order, field labels, error messages, duplicate submits and the state after navigation. The ordinary path should remain understandable when WebMCP is unavailable.
Fresh-browser checkpoint
Open WebTraceCheck ↗ for a temporary Linux browser session when you need to compare a public staging form with a fresh profile. Save your observations before ending the session. It is a separate product and may require sign-in or paid time beyond its free allowance.
Use it for the human browser path. This guide does not promise that its browsers expose a particular experimental WebMCP flag or trial. Use your configured development browser for the native API check.
4. Follow your own confirmation email
If the tool’s job includes a support acknowledgement or signup confirmation, use a staging recipient and a synthetic message. Submit once, note a test label and time, then confirm that exactly the expected message arrives with a working link. A schema check cannot establish that the message was generated, delivered or linked to the right request.
Disposable-recipient checkpoint
Open CleanTempMail ↗ for a temporary inbox when testing a non-sensitive email from a system you control. Copy the address into your staging flow manually. ContractKit neither provisions an inbox nor sends a message.
Use invented content and a disposable test account. Keep customer messages, production recovery links and sensitive credentials out of a temporary mailbox. A disposable address tests that one delivery path; it is not a representative inbox-placement study.
5. Record enough evidence to reproduce the failure
Keep the contract revision, case name, expected result, observed result, browser build and staging release identifier together. Describe whether the failure occurred before registration, at input validation, in the callback or after the server action. Redact addresses and private identifiers before sharing evidence.
Stop when the intended change has an observed end-to-end result and unrelated old cases still behave as expected. If a requirement changed deliberately, update the expectation with its rationale. Do not keep widening the suite just to collect a larger green count.
The two linked products share this project’s operator. Links carry source-site and placement parameters for referral attribution. They are optional steps for the browser and email portions of the workflow, not dependencies of the free local workbench. See privacy and link behavior.
Bring the question back to a concrete case.
Open ContractKit ↗