Report Schema

catalog export and publish journeeze read the baselines from this file. The locator-health --json report and a Journey run's result.json use the same rungs.

A Journey run's result.json (0.10.0) also carries resolved[]: for each step, how its target actually resolved at replay — {index, stepId?, rung, testIdAttr?, ordinal?, candidates?}, where testIdAttr is the attribute a test id matched (absent = data-testid) and ordinal/candidates appear when equally named elements had to be told apart — and a compact locatorHealth for the run. Both are advisory and never change the run's outcome.

The review sheet (journey review --json, MCP review_journey) adds anchorWarnings[] (code, severity, path, step?, message, fix?) and locatorHealth (line, stable, brittle and brittleSteps[] with stepId?, index, kind, rung, level, route?, locator, reasons and the fix for the app). With --stale and no id it lists the Journeys whose approval is stale, each with its approved and current hash and stepIdOnly: true when the only change is minted step ids. An approval's provenance.channel can now also be pr-review; a check or catalog status with --require-approvals reports an unverifiable one as unverified.

Exit codes did not change in 0.10.0. job approve refusing a broken job (E_JOB_BROKEN_REF) and journey promote refusing anchor-rule errors (E_JOURNEY_ANCHOR_RULES) are exit 64; publish journeeze exits 0 (imported), 1 (refused) or 2 (the upload could not finish), and 64 for a setup problem.

Scope regions: coverage and scope.region (0.14.0)

With --scope-region (or a Journey anchor's region), the result changes as follows:

• Adversarial: coverage.controls is the region's total and exercised controls and decides sufficient. coverage.pageControls is the route-wide count the region excluded, for a reviewer and never in the decision. coverage.region gives the spec and the step counts.
• Region lost: a step whose page has no matching region counts in outOfScopeSteps. After 2 consecutive such steps the run goes back to its start; scope.region.lostResets counts those resets.
• Coverage and exploratory carry scope.region: spec, outOfRegionControls (distinct controls seen outside the region) and stepsWithoutRegion.
• scope-unreachable: a region that never matches ends inconclusive, stop scope-unreachable, failure.kind: "target-unreachable", never clean.

Store ids (recordings, missions, mission targets, publishes) are letters, digits, ., _ and -, starting with a letter or digit, up to 128 characters. An empty id, .., a slash, NUL, : or a drive prefix is refused with E_INVALID_NAME (exit 64), replacing the old "path traversal risk" error.

Blocked writes are environment faults (0.11.0)

A request jevitate refused to send because its origin is not in --allow is an environment fault, not an app defect. What it provably caused within that action's window (the same step or the next one) is linked to it with causedBy and grouped under it in reports: a console or page error naming the blocked URL, a failed request with its exact method, origin and path, or a busy indicator that appeared with the write and never cleared. Anything less certain (a generic "Failed to fetch", a later step) stays an app defect. A run that had only such findings may now exit clean. jevitate also warns when a blocked loopback origin differs from an allowed one only by localhost / 127.0.0.1 spelling or by port. Fix the allow list, then prove it with verify-fix --allow or --env.

Other 0.11.0 result fields: slowSteps (a late 2xx, with its latency) and slowness.coldStarts (advisory, never an exit code), offAllowlistWrites on a Journey run, preflight: { ok, problems } (and preflight.skipped) in campaign.json, and check.appVersion. Exit codes did not change: a refused campaign preflight, a refused catalog export and a Journeeze product mismatch are exit 64. A busy indicator that clears on a page whose CSP forbids 'unsafe-eval' is no longer reported as a ui-no-progress hang.

Approvals and review sheets (0.8.0)

A promoted Journey records metadata.approval: { contentHash, at, provenance?, acceptedWeak?, waivers?, acceptedFindings? }. waivers is [{ kind: "unvetted", reason, items }] from --accept-unvetted; acceptedFindings records the reason and the acknowledged findings from --accept-findings. provenance is { channel: "tty" | "non-interactive" | "mcp" | "ci" | "pr-review", agentSignals, user?, reason? }: agentSignals names environment markers (never their values) and user is the OS user name. An approved persona or job carries approval in personas.json / jobs.json in the same shape ({ contentHash, at, provenance }, plus acceptedFindings). Provenance is detection, not proof; see what human approval guarantees.

journey review --json (and MCP review_journey, review_persona, review_job) returns the schema-checked sheet: summary, steps, side effects, inputs, proof, the change since last approval, the content hash, the catalog links, the pre-approval findings, and with --readiness the readiness checks (readiness/<code>, GtWR findings readiness/gtwr:<rule>@<field>) and a jev field reporting what ran (status, asked, cached, usage). catalog status --json adds approvals. With --require-approvals, jevitate check adds an approvals item with a hard approval finding per missing, stale or disallowed-channel approval.

The engine field

Every mission result (goal, feature, coverage/exploratory, adversarial, usability) carries an engine object identifying exactly which build produced it:

"engine": { "version": "0.8.0", "commit": "a1b2c3d", "builtAt": "2026-09-23T18:04:11Z" }

commit and builtAt come from a git-rev-parse computation baked in at build time (by esbuild for the published bundle, or a generated module for a tsc dev build). Either falls back to the literal string "unknown" — never a fabricated value — when neither injection path ran (e.g. a source tree with no git history available at build time). jevitate --version prints the same identity: the bare semver once that alone identifies the build, or version (commit …, built …) when it can determine more, so two results produced by different rebuilds in the same session are distinguishable.

Usability report: claims

Since 0.3.0 every usability finding is a claim code verified. A claim comes from a guard probe (opt-in --probe-guards), from your product facts, or from friction the run hit. Jev only picks a claim type from a closed list and the control it is about; code checks it, and a claim that fails is dropped and counted. The finding's text is built from a template over the verified fields, so a model never writes it.