QA automation is a program that drives your application the way a user would and writes down, to disk, what happened. That definition is deliberately boring: it excludes dashboards, pyramids, and vendor pitches, and it puts the emphasis on the only thing that matters at 2am when a release breaks — can you read what the test did. A QA automation setup that does not produce a scenario file, a video, a sequence of screenshots, a structured events log, and a pass/fail result JSON is not automation. It is a screensaver that occasionally returns green.

Because the pyramid is a prioritization model, not a guide. Every top-ranked 'QA automation guide' on Google reuses the same three levels (unit, integration, end-to-end), lists benefits, lists frameworks, and ends. None of them answers 'what should be on my disk after a run.' Artifacts are concrete, portable, reviewable in a PR, replayable by a teammate. The pyramid is advice. The artifact tree is evidence.

Minimum five. One, the plan: the English or pseudo-English description of what was tested (in Assrt this is /tmp/assrt/scenario.md, a plaintext file with `#Case N: name` sections). Two, the video: a WebM recording of the whole run (assrt writes it to /tmp/assrt/<runId>/video/recording.webm). Three, the screenshots: one PNG per visual step, deterministically named (assrt uses `${index.padStart(2,'0')}_step${stepN}_${action}.png`). Four, the events log: a JSON timeline of every action, assertion, and reasoning trace. Five, the result file: the structured pass/fail summary that your CI job can grep. If any of those five is missing, debugging a red build will require re-running the test.

Yes. After running `npx assrt-mcp` and executing one test, look at /tmp/assrt/<runId>/ on your disk. You will find: screenshots/ populated with files like 00_step1_navigate.png, 01_step2_click.png, 02_step3_type_text.png; video/recording.webm plus video/player.html; plus a results payload. The filename format is hardcoded at assrt-mcp/src/mcp/server.ts line 468: `${String(screenshotIndex).padStart(2, '0')}_step${currentStep}_${currentAction || 'init'}.png`. The run directory creation is at lines 427-432 of the same file. The plan sync is at src/core/scenario-files.ts line 16 where ASSRT_DIR is pinned to `/tmp/assrt`.

A Playwright spec is JavaScript or TypeScript: `await page.goto(url); await page.getByRole('button').click();`. A Cypress spec is similar. Both are code: executable, versioned, but not human-first. An Assrt plan is a plain .md file shaped like this: `#Case 1: Sign in with the demo account\n1. Open /login\n2. Type demo@example.com into the email field\n3. Click Continue\n4. Verify the dashboard greeting appears`. The agent reads that, calls real browser tools, and writes artifacts. The PM reviews the plan. The engineer reviews the results JSON. The plan is the contract; neither side is forced into the other's domain.

Space toggles play/pause. ArrowLeft seeks back 5 seconds, ArrowRight seeks forward 5. The digit keys rebind speed: 1 is 1x, 2 is 2x, 3 is 3x, 5 is 5x, 0 is 10x. Default playback speed is 5x because nobody wants to watch a real-time browser video. The logic is inline in the generated HTML, defined in assrt-mcp/src/mcp/server.ts around lines 96-107. You can open /tmp/assrt/<runId>/video/player.html directly in any browser even after Assrt has quit; the file is self-contained.

The expensive SaaS tools author tests in a proprietary YAML or graphical DSL, execute them in a vendor cloud, and keep the artifacts in that cloud. You rent access to your own test results. If you cancel, the specs are unexportable and the history is inaccessible. Assrt is the opposite: open-source (`npx assrt-mcp`), self-hosted, and every artifact is a file on your disk. The scenario.md will still run next week under any Playwright MCP agent, because there is no proprietary format between you and the browser. The trade is that you run and pay for your own LLM calls; at Claude Haiku 4.5 pricing (the pinned default at agent.ts line 9) that is tiny.

The browser is driven by `@playwright/mcp` version 0.0.70 (pinned in assrt-mcp/package.json), spawned over stdio. The tool names the agent calls (navigate, snapshot, click, type_text, scroll, press_key, select_option, wait, evaluate) are the literal Playwright MCP tool names. The difference from writing a Playwright spec by hand is not what runs the browser, it is what decides which calls to make: in Assrt the decider is an LLM reading your plan file, not a hand-coded scenario script. That means the same browser automation engine, a different planning layer.

Open the run directory. First glance is the player.html video at 5x — in thirty seconds you see which click produced the wrong state. Then look at the numbered screenshots folder for the exact step (the name encodes the step number and action, e.g. 04_step5_click.png). Then open events.json for the structured timeline: each assertion has {description, passed, evidence} fields, where evidence is the English sentence the model wrote about what it saw (type defined in src/core/types.ts lines 13-17). This is meaningfully different from reading a Playwright CI log, which gives you a stack trace but no narrative.

Yes. The plan references URLs and text, not implementation. `#Case 3: Checkout with a test card\n1. Navigate to {{baseUrl}}/cart` works against any base URL passed at run time. Assrt's assrt_test tool accepts both `url` (the target) and `variables` (a key/value map for parameterized tests). One plan file runs unchanged against localhost:3000, staging.yourapp.com, and yourapp.com, and writes per-run artifact directories you can diff between environments.

Manual exploratory testing does not die. A human finds a class of bug that a plan-based agent never thinks to check: visual subtlety, emotional friction, unexpected user paths. The right frame is that artifact-first automation handles the regressive cases (the flows you have already decided matter) and frees the humans to chase the unknown. A QA team running artifact-first automation on its top 40 flows can redirect 60% of the hours they used to spend re-running the same checkout test to actually breaking the product in creative ways.

Writing the plan: one to three minutes, because it is English. Running it the first time: a few minutes while the agent finds the right selectors and stabilizes. From there, every future run is headless, in CI, in the background, and produces the same artifact tree. Contrast with writing a Playwright spec: you open the inspector, find stable selectors, write the code, debug the flake, add waits, add masks, parameterize env vars. The plan skips every step that is not about deciding what to test.