How to zero vendor lock-in on your test outputs

An output is any file a tool writes when it runs. For automated tests, that is typically: the plan, the pass/fail report, per-step screenshots, and a video recording. Vendor lock-in on inputs is easy to spot (a proprietary YAML DSL, a cloud-only editor) but lock-in on outputs is quieter and costlier. If your plan file lives only inside a vendor database, you cannot grep it or commit it. If your screenshots only render inside their dashboard, you cannot paste them into a bug ticket as real PNGs. If the video is trapped behind OAuth, you cannot attach it to a Slack thread. Checking your outputs is a faster lock-in test than reading marketing copy.

The plan goes to /tmp/assrt/scenario.md. Metadata (id, name, url, updatedAt) goes to /tmp/assrt/scenario.json. The latest run report goes to /tmp/assrt/results/latest.json, with a per-run copy at /tmp/assrt/results/<runId>.json. Each run gets its own directory at /tmp/assrt/<runId>/ containing screenshots/ (one PNG per step) and video/recording.webm. The local scenario cache used when the cloud is unreachable lives at ~/.assrt/scenarios/<uuid>.json. You can ls, cat, grep, mv, rm, cp, tar, and git add every one of these paths. There is no proprietary container.

Screenshots are written with a zero-padded index, the step number, and the action name: `${String(screenshotIndex).padStart(2, '0')}_step${currentStep}_${currentAction || 'init'}.png`. In practice you see 00_step1_init.png, 01_step2_click.png, 02_step3_type_text.png. That convention is in src/mcp/server.ts around line 468 of the assrt-mcp package. Zero padding keeps shell ordering correct up to 100 steps per run. If a run has no action (pre-navigation), the name falls back to step1_init. Names are stable inputs to your CI pipeline: a diff tool can line 03_step4_click.png in last night's green run up against 03_step4_click.png in today's red run.

results/latest.json contains the full run: the plan snapshot, the URL tested, the model used, pass/fail status, per-case timing, assertion evidence, and suggested product improvements. It is plain JSON, so jq, Node, Python, DuckDB, and every CI tool can read it. Typical offline workflows: jq '.cases[] | select(.passed == false)' to list failing cases, cat results/latest.json | pbcopy to attach to a Jira ticket, or git diff last-night.json today.json to see what changed between runs. The runId.json copies let you replay any past result without the cloud.

Plans are Markdown with `#Case N: name` blocks. A human reads them in any editor; a grep for '#Case' finds them all. The runtime writes the active plan to /tmp/assrt/scenario.md and starts an fs.watch on that file (scenario-files.ts line 97). Save the file in VS Code and a 1-second debounce timer PATCHes the cloud copy via /api/public/scenarios/<id>. This is the opposite of a vendor DSL: the source of truth is the file you can `git add`, the cloud is a cache. Commercial tools that keep the plan inside a closed database force you to export on their terms. Here the export is the default state.

Every plan ever loaded lives at ~/.assrt/scenarios/<uuid>.json as a full StoredScenario object (id, plan, name, url, passCriteria, variables, tags, timestamps). Every result lives under /tmp/assrt/results/ and /tmp/assrt/<runId>/. Every video is a standalone WebM playable in VLC, Chrome, or ffmpeg. The browser profile (cookies and localStorage used across runs) lives at ~/.assrt/browser-profile/. Move those directories to a new machine, or tar them into a backup, and the history is portable. Nothing is trapped in a cloud-only export format.

The recording has a rendered cursor, click ripples, and keystroke toasts painted into the page. That overlay is injected by CURSOR_INJECT_SCRIPT (browser.ts lines 33-98): a fixed-position red cursor dot, a click-ripple ring, a keystroke toast, and a 6px heartbeat pulse that keeps Chromium's compositor producing frames during quiet moments so the CDP screencast captures motion. Net result: the WebM on your disk is legible as a standalone artifact. No trace viewer required. You can drop it into any video player or attach it to a bug ticket and a non-engineer can follow what happened.

Yes, for replay-as-read. Every run has its own directory at /tmp/assrt/<runId>/ with its plan snapshot, JSON report, screenshots, and WebM. Open video/recording.webm in any player, open screenshots/ with your file manager, or pipe results/<runId>.json into jq. For replay-as-rerun, Assrt also keeps a local scenario cache at ~/.assrt/scenarios/<uuid>.json. The CLI reads that cache when the central API is unreachable, falling back to a 'local-' prefixed ID so you never lose a plan to network trouble. Rerunning locally requires a model key (ANTHROPIC_API_KEY or a Gemini key); the model is where you pay, not where you are locked in.

Abstract version: 'use open standards, validate exports quarterly.' Concrete version, file by file. Plan: /tmp/assrt/scenario.md in Markdown. Metadata: /tmp/assrt/scenario.json. Results: /tmp/assrt/results/latest.json plus one per run. Screenshots: /tmp/assrt/<runId>/screenshots/NN_stepN_action.png. Video: /tmp/assrt/<runId>/video/recording.webm. Local cache: ~/.assrt/scenarios/<uuid>.json. Source code: 1,087 lines of MIT-licensed TypeScript in assrt-mcp/src/core/agent.ts. That is the full artifact surface. Point at any of those with `cat` and you are not locked in.

Typical commercial platforms keep the plan inside a proprietary editor, keep results inside a cloud-only dashboard, and keep videos behind OAuth URLs. Export features exist but return a cleaned-up subset, usually without the original timing or the raw screenshots. Assrt inverts the default: files first, cloud second. The cloud is a capability-URL cache keyed by UUID, not a walled garden. You pay for the model you run the tests on (Anthropic or Gemini), which is a commodity market. You do not pay a seat license for your own test history.