Reading output
PASS MPP-11 Cumulative Commitment Ordering
Both ordering rules enforced: ...
SKIP MPP-13 Close Settlement [destructive]
Skipped (destructive): closing settles the channel on-chain and
permanently ends it.A FAIL also says what to change, and where the check is documented:
FAIL X402-05 Network Identifier Valid
"eip155:0x14a34" does not carry an EIP-155 chain id in base 10, which the
eip155 namespace requires (Base Sepolia is eip155:84532).
Fix: Write the chain id in base 10: eip155:84532.
Docs: https://usewasit.dev/docs/checks/x402Fix is specific to the cause the check found where Wasit can tell it, and the
check's general fix otherwise. Only a FAIL carries one: a SKIP or an ERROR is not
a defect in the target, so there is nothing for it to change.
PREFLIGHT appears in place of the checks when the target URL or network
identifier is invalid. Both are wrong for every check in the suite, so they are
reported once rather than repeated identically.
See ../design/error-model.md for what each status means.
--json
wasit test --target https://api.example.com/paid-endpoint --read-only --json{
"outcome": "conformant",
"passed": 5,
"failed": 0,
"errored": 0,
"skipped": 0,
"results": [
{ "id": "X402-01", "name": "402 Response Status", "status": "PASS", "detail": "...", "destructive": false }
]
}A result with "status": "FAIL" also carries fix and docs, the same two
lines the text output prints.
Any advisory line that would normally print above the results (missing payer
key, --read-only set, a payment-cost warning) is written to stderr instead of
stdout when --json is set, so stdout stays parseable — safe to pipe into
jq or capture directly in a CI step. outcome mirrors the exit code
(conformant / non-conformant / no-verdict) but is readable without
looking one up, and is the exact same shape the MCP server returns as
structuredContent for the same run — both front ends call the same
toStructuredRun() in @wasit-dev/core, so they can never disagree about how
one is reported.