Beyond Tests

Jevitate is a testing tool first. The same artifact it produces for tests, a promoted Journey, is also a deterministic browser automation you can run again.

Secondary use. Nothing here replaces the testing workflow. A Journey you automate with is the same one you regress, verify and gate CI with.

Capture once, replay deterministically

Author a Journey from a goal (explore-author-journey) or record a flow by demonstration, then promote it. Promotion is a human approval gate: an unpromoted Journey never runs through the run surfaces. A replay uses no model to choose actions. See Journeys.

Parameters and environments

Values that change per run are declared parameters, supplied with --param name=value. A Journey is environment-free: name where it runs with --env (from the committed .jevitate/environments.json) or an ad-hoc --base-url.

jevitate journey list
jevitate journey run invite-teammate --env staging --param email=a@example.test
jevitate journey run invite-teammate --base-url https://pr-123.preview.example.com --param email=a@example.test

Callable by agents

Agents find and run promoted Journeys over MCP with find_capabilities and run_journey (params, env/baseUrl, selfHeal), the counterparts of journey find and journey run. The tools take no selectors or scripts: the Journey is the only behaviour. See MCP & CLI.

Self-heal when the UI drifts

By default a broken step stops and quarantines the run. With --self-heal hybrid (or full) and a change context (--changes <git range> or --change-note), a step the change explains can be retargeted. A healed run is never a pass: it ends healed-pending-review (exit 5) and writes a proposal; the stored Journey is untouched until a person accepts it. Write and irreversible steps are never auto-healed.

jevitate journey run invite-teammate --self-heal hybrid --change-note "Invite button renamed to Add teammate" --real
jevitate journey review invite-teammate
jevitate journey promote invite-teammate --proposal <pid>   # a person confirms

Chain Journeys

journey chain (MCP chain_journeys) runs a discover Journey once, then an action Journey once per approved request matched to a discovered record. --param name=value supplies the discover Journey's params (validated before anything runs), so the same Journey serves any account or thread. Unmatched requests never run, an empty discovery stops the chain, and the result names ids and outcomes only. Promoted Journeys only.

jevitate journey chain --from discover-conversations --to prepare-reply \
  --requests approved.jsonl --param account=mcpl --env staging --json

Safety boundaries stay on

  • Prepare-only. A Journey can declare a boundary that stops before a person acts. Clicking the stop target, pressing Enter or any click after the last fill is refused at load, self-heal is refused for it, and the run reports prepared only when no write was sent.
  • Human-only approvals. Promotion, review sign-off and accepting a heal proposal are never MCP tools.
  • Credentials and secrets. Secrets are redacted before a model sees a page, typed by code, and a secret parameter is never persisted: supply it again with --param. See Safety & Secrets.
"boundary": {
  "kind": "prepare-only",
  "stopBefore": { "target": { "testId": "reply-send" }, "label": "Send" },
  "nextStep": "Read the prepared reply, then click Send yourself."
}

Example uses

  • Back-office workflows that prepare an approved reply for a person to send.
  • Data entry: one Journey, a different --param set per record.
  • Discover, then act on each record with journey chain.
  • Recurring operational tasks replayed on a named environment.

Only run automation against apps and accounts you are authorized to drive. The site policy, origin allowlist and default refusals (sign-out, delete, revoke, paid) apply to replays too.