Verifier runs¶
A verifier run is one execution of the verifier binary against your service, recorded against the feature's workbook. Runs are how Dezycro proves a feature actually works — not just that it has tests, but that the tests pass against a real running service.
For the full mechanics of how the verifier works, see The Verifier. This page covers the workflow once you have a verifier set up.
Running the verifier¶
Two paths, same result:
| Where | How |
|---|---|
| Dezycro CLI | /<prefix>:dz-verify |
| CI / standalone | See the CI example |
Both land in the same workbook — the binary reports its own run — where it appears in the feature's run history.
Run results¶
Each run produces a structured result; the workbook rolls per-run outcomes up into a journey status:
| Journey status | Meaning |
|---|---|
| PASSING | Last run completed end-to-end with all assertions matching |
| FAILING | Last run hit at least one failed assertion or couldn't complete |
| SKIPPED | Intentionally excluded — journey is Inactive |
| PENDING | Journey not yet exercised by its current tests, or its last run was inconclusive |
A run only counts toward a journey if it exercised at least one of that journey's current tests. When the feature's tests are regenerated, for example after a PRD, TRD, or spec change, a journey whose tests changed goes back to PENDING until a run of the new tests reports on it; journeys whose tests didn't change keep their status. A run from a binary built before the regeneration no longer credits any journey: pull the new binary (/<prefix>:dz-verify does this for you) and run again.
A journey turns PASSING only on decisive passes. A test that ends inconclusive (missing auth, missing fixture, a condition never confirmed) leaves its journey PENDING, and a run whose results arrive incomplete credits no passes either. A green-looking run with PENDING journeys is the symptom; the per-test verdicts say why.
Non-passing results come with a verdict indicating the likely cause — decisive failures (FAIL_DECISIVE_*) versus inconclusive runs (INCONCLUSIVE_* — missing auth, missing fixture, input constraint). See the verdict table.
What advances the lifecycle¶
The feature auto-transitions to VERIFIED when:
- All ENFORCED journeys are
PASSING - All journey-linked tasks are
CONFIRMED - No open
HIGH-severity issues remain - No unresolved coverage gaps with
lifecycleBlocking: true
OBSERVED journeys can fail without blocking the lifecycle — useful for in-progress journeys or nice-to-have coverage.
Run history¶
Every run is preserved. From the feature page, expand any run to see:
- Per-journey results, each with its test id: click the TEST ID chip on a row to copy it
- HTTP request/response for each step (when verifier is configured to capture). Authorization, cookie and API-key headers are dropped, and credential values (tokens, secrets, passwords, whether sent by a persona or returned by your API) are masked before anything is stored, streamed, printed to the console or written to the report file
- Diff against the previous run (which journeys regressed, recovered, or stayed the same)
Comparing runs across builds is how you spot regressions before they ship.
Coverage reports¶
Each run also feeds the feature's coverage report — a separate projection that buckets every spec operation by how far it got: bound, executable, observed, inconclusive, decisively failed, or explicitly waived — plus dependency-flow gaps. See The Verifier → Coverage for the full bucket list.
A feature that reports 0 verifiable plans has nothing to run; the causes and fixes are in Making your API verifiable.
Coverage reports are accessed via the feature page's Coverage tab or mcp__dezycro__get_coverage_report. The Dezycro CLI's coverage nudges surface gaps before a push.
Auth setup¶
Most journeys need authentication. Dezycro models test identities as personas loaded from .dezycro/auth.local.json — see Verifier → Personas.