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¶
Three paths, same result:
| Where | How |
|---|---|
| Web UI | Feature page → Run verifier button |
| Claude Code plugin | /dezycro:verify |
| CI / standalone | See the CI example |
All three upload the result to the same workbook, 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 any run |
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
- HTTP request/response for each step (when verifier is configured to capture)
- 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.
Coverage reports are accessed via the feature page's Coverage tab or mcp__dezycro__get_coverage_report. The Claude Code plugin'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.