Regression & CI

A discovered anomaly never becomes a test on its own. Jevitate reproduces it, minimizes it, and keeps a deterministic, replayable repro — evidence first, always.

Evidence, not interpretation

After every action, Jevitate collects what actually happened and monitors for:

• Browser errors — uncaught exceptions, page errors, console errors, crashes, navigation failures
• Network errors — failed requests, unexpected 4xx/5xx, timeouts, aborted or malformed responses
• UI failures — blank screens, error boundaries, infinite spinners, unresponsive controls, stale overlays
• Behavioral anomalies — no state change, endless repeats, success UI despite a failed request, backend success with no UI transition

A failure is based on observable evidence or an explicit invariant you define; a suspicious state may be recorded without being classified as a confirmed failure. Failure classes include browser_exception, console_error, network_failure, assertion_failure, dead_end, infinite_loop, unexpected_state, and custom_invariant_failure.

The trace

Every execution produces a serializable, replayable trace. Each step captures its evidence:

step:
  number: 7
  state_before: "sha256:..."
  action: CLICK
  target:
    role: button
    name: Apply
    test_id: apply-promo
  decision_probability: 0.91
  state_after: "sha256:..."
  console_errors: []
  network_failures: []
  screenshots: []

Traces carry enough semantic selector information to reconstruct locators — never only ephemeral DOM indices.

Reproduce, then minimize

Explore → Discover failure → Capture trace → Reproduce
  → Minimize trace → Generate regression test → Fix → Verify

Jevitate retries a failure a configurable number of times and computes a reproduction rate. Flaky failures are labeled, never silently promoted to deterministic regressions. Reproducible ones are minimized by replay-and-elimination — often from dozens of actions down to a handful — while preserving reproduction at each step.

Generated tests

Generated Playwright tests (TypeScript by default) prefer semantic selectors, in order:

1. data-testid
2. role + accessible name
3. label, then placeholder
4. stable application identifier, then text
5. CSS selector (last resort)

They never depend on Jev or temporary indices, are human-readable, and include comments linking the test back to its discovery trace and the observed failure evidence.

Proof-of-failure / proof-of-fix

Run the generated test against the buggy build (it fails), fix the code, and run it again (it passes). This is behavioral evidence, not a proof of total correctness: a passing regression proves only that the captured failure no longer reproduces under the encoded conditions. Failing to find more bugs never proves none exist.

Artifacts

.jevitate/
├── runs/
│   └── <run-id>/
│       ├── run.json
│       ├── trace.json
│       ├── states.json
│       ├── transitions.json
│       ├── failures.json
│       └── screenshots/
├── regressions/
└── coverage/