E2E testing guide where the plan is a Markdown file, not a code file.

A text file with one or more #Case N: headings. Each heading is followed by 1 to 5 imperative English lines describing what to do and what to verify. No imports, no fixtures, no describe/it blocks, no TypeScript. The parser at assrt-mcp/src/core/agent.ts:621 splits the file on the regex /(?:#?\s*(?:Scenario|Test|Case))\s*\d*[:.]\s*/gi, so #Case 1:, Scenario 2., and Test 3: all work interchangeably. Everything between two markers is one scenario. The name of the case is the text between the marker and the first newline; the steps are the rest. The file lives at /tmp/assrt/scenario.md after the first run and can be edited in place; a file watcher debounces at 1 second and syncs the change back to cloud storage.

It does not guess. Before every interaction, the agent calls the snapshot tool, which returns the page's accessibility tree with per-element reference IDs like [ref=e5]. The model reads your English step ('Click Get started'), scans the tree for a matching node (role=button, name contains 'Get started'), and passes both a human description and the ref to the click tool. If the ref goes stale because the page mutated, the system prompt instructs the agent to call snapshot again for fresh refs. That is why the plan never needs a CSS or XPath selector: the accessibility tree is the selector, resolved at runtime by the model from your sentence.

Eighteen, defined in assrt-mcp/src/core/agent.ts starting at line 16: navigate, snapshot, click, type_text, select_option, scroll, press_key, wait, screenshot, evaluate, create_temp_email, wait_for_verification_code, check_email_inbox, assert, complete_scenario, suggest_improvement, http_request, wait_for_stable. The model cannot invent new tool names or reach outside this set. That closed set is a deliberate choice: it caps the blast radius of what a test can do, makes reasoning about failures easy, and keeps the cost low (each run is a conversation, each tool call is one turn).

The create_temp_email tool calls temp-mail.io's internal API (api.internal.temp-mail.io/api/v3/email/new) and returns an address plus a token. You use that address in the signup form. The wait_for_verification_code tool then polls the same inbox every 3 seconds for up to 120 seconds and matches the body against seven verification-code patterns in priority order: 'code: 123456', 'verification: 123456', 'OTP: 123456', 'PIN: 123456', any 6-digit number, any 4-digit number, any 8-digit number. Source: assrt-mcp/src/core/email.ts lines 82 to 129. If the form uses split single-character inputs (common OTP pattern), the agent pastes via a specific evaluate expression that dispatches a ClipboardEvent on the parent element; it does not type digit by digit.

With wait_for_stable, which is step-level instead of step-global. It injects a MutationObserver into the page, counts DOM mutations, and returns as soon as there have been zero mutations for stable_seconds (default 2, max 10) or the outer timeout_seconds (default 30, max 60) is hit. The agent calls it after any action that might start async work: form submission, AI chat response, search results loading. Pages that finish fast return fast; pages that finish slow block longer. You never hard-code a number in milliseconds, and you never maintain a per-test wait budget.

For AI-native teams and for teams who write mostly small journey tests, yes. For legacy suites with thousands of specs, fixtures, and CI budgets tuned over years, probably not as a one-time migration. But the underlying runner is Playwright. Your org does not buy into a proprietary recorder or a yaml-based DSL; it writes Markdown and runs Playwright. When the plan is checked into git alongside the code, it reads like a product requirement. When it is checked into /tmp/assrt/scenario.md, it is editable in place and auto-syncs. A reasonable adoption path is to let engineers write new flows as Markdown #Cases while leaving stable legacy specs alone.

It does not magically retry a failing scenario. Flakiness is usually pushed upstream into the tools themselves: snapshot is called before every interaction so stale-ref flakiness disappears, wait_for_stable replaces wait(ms) so timeout flakiness disappears, ref-based clicks are more stable than CSS selectors against animated pages. When an action does fail, the agent is instructed to snapshot, look at the new accessibility tree, and try a different ref or approach before giving up. Only after three genuine attempts on one step does it mark the scenario failed. You can still build retry into CI around the whole run if you want classical retries.

Three artifacts, all on the local filesystem. scenario.md holds the plan. /tmp/assrt/results/latest.json holds the TestReport (scenarios, passedCount, failedCount, per-assertion evidence, per-step timing). /tmp/assrt/results/<runId>.json is the immutable copy for history. If --video is passed, there is a WebM plus a player.html with keyboard shortcuts for 1x/2x/3x/5x/10x speed. In CI, pass --json to stdout so the pipeline can parse pass/fail without reading files, or just grep results/latest.json. No cloud account is required to run; the optional cloud sync uploads artifacts and returns shareable URLs, but the runner itself is self-hosted and open-source.

Generators emit *.spec.ts once and call it a day; the generated file is then your problem to maintain. Assrt is the other direction: the plan stays in plain English forever, and the agent resolves it into tool calls on every run. That is why selector drift does not require a regeneration step: the agent re-reads the accessibility tree next time and finds the same 'Get started' button even if its class changed. You also get real Playwright at the bottom, not a proprietary YAML; when you want to graduate a #Case into a deterministic Playwright spec, you can. When you want to stay in Markdown, you stay in Markdown.