The phrase is a tell. The first 'automation' refers to automating test execution, which every tool in the category has done since Selenium in 2004. The second 'automation' refers to automating the work upstream of execution, writing the tests, maintaining them when the UI drifts, and repairing them when they fail. That upstream layer is the one most platforms have not shipped honestly. They generate a first draft with an LLM, lock it behind a cloud editor, and call the result 'automated.' A complete loop needs three tools (write, run, repair) and an artifact you can read. Assrt ships that loop as three MCP tools and a Markdown file at /tmp/assrt/scenario.md. That is specific. That is the shape of the answer.

The tests live at /tmp/assrt/scenario.md on your local filesystem, written by assrt-mcp/src/core/scenario-files.ts line 42. The agent that calls assrt_plan writes the initial draft; you or any other agent (Claude Code, Cursor, the MCP server running in the background) can open that file and edit it like any other Markdown file. When the file changes, the fs.watch() on line 97 fires, a 1000 ms debounce coalesces bursts of edits, and syncToFirestore() pushes the new plan to the optional cloud for sharing. If you disable the cloud sync, the file is still the source of truth and assrt_test still runs it. The Firestore step is optional. The file is not.

You call assrt_diagnose with the failed scenario. It is defined in assrt-mcp/src/mcp/server.ts around line 240 and returns a four-section Markdown response: Root Cause, Analysis, Recommended Fix, and Corrected Test Scenario. The last section is a literal #Case block written in the same grammar as the one in your scenario.md. You paste that block over the failing one in /tmp/assrt/scenario.md, save, and re-run assrt_test. The loop closes in three commands. No vendor rewrites your test silently, no closed AI decides in a dashboard what the fix should be. The diagnosis is a file diff you can review before committing.

One regex: /(?:#?\s*(?:Scenario|Test|Case))\s*\d*[:.]\s*/gi, defined in assrt-mcp/src/core/agent.ts at line 569 inside an 11-line parseScenarios function. The plan is Markdown. A case starts with #Case N:, #Scenario N:, or #Test N:, followed by 2-5 sentences in plain English describing what to click, type, and verify. There is no schema file, no compile step, no AST. If Assrt disappeared tomorrow you could write a replacement runner in a weekend because the format is the regex. Compare that to the reverse-engineering bill for a closed vendor's test record format.

Platforms of that shape run the write/run/repair loop entirely inside their cloud. You log in, click a button, a proprietary LLM drafts a test in a proprietary format, the runner executes it, and if it fails, the platform self-heals the test silently. The artifact never touches your disk. The exit path is a manual export wizard and the audit trail is whatever the vendor chooses to surface. Assrt runs the same three stages as three MCP tools against a file you can cat, grep, and git diff. The runner under the hood is the open-source Playwright MCP subprocess. The LLM is your own Anthropic or Gemini key. The repair is a paste-over. If Assrt's hosted dashboard shuts off, the file on your disk keeps working.

No. Cloud dashboards are useful for sharing runs with teammates, but they are not the loop. The loop is: agent writes a plan, runner executes it, agent reads the results and edits the plan when something failed. That loop runs entirely on a laptop with no network other than the LLM API call. Assrt's optional cloud at app.assrt.ai exists only to share runs; toggling it off does not change the runtime. assrt_test still runs, /tmp/assrt/scenario.md still parses, assrt_diagnose still returns a #Case block. The closed competitors start failing the moment their cloud is down.

A subprocess of the official Playwright MCP server, spawned by McpBrowserManager in assrt-mcp/src/core/browser.ts. When the agent calls the navigate tool in Assrt's agent.ts, that call is forwarded over stdio as a browser_navigate call to the Playwright MCP, which drives a real Playwright-controlled Chromium (or your own Chrome in --extension mode). The tool names in agent.ts (navigate, snapshot, click, type_text, select_option, scroll, press_key, wait) map one-to-one onto Playwright MCP's official tool surface. There is no proprietary browser driver. This is why tests that pass in Assrt will behave the same when reproduced with raw Playwright, and why an Assrt scenario is portable in practice, not only on paper.

It prevents a burst of saves from triggering a pile of Firestore writes. When the agent edits /tmp/assrt/scenario.md the fs.watch() callback fires synchronously, a setTimeout schedules syncToFirestore() 1000 ms later, and any further changes in that window reset the timer. Only the last write hits the cloud. This matters because an agent pasting a multi-line corrected #Case block can produce several fsync events in sub-second intervals, and the naive implementation would spam the API. The skipping logic at line 136 compares the current content against lastWrittenContent so the watcher ignores echoes of its own writes. You can disable the sync entirely by passing a scenarioId that starts with local- (line 94).

Not the authoring and repair parts. assrt_plan and assrt_diagnose both call an LLM (Anthropic Claude Haiku by default, Gemini if you prefer) because those are the tools that write words. assrt_test calls an LLM too, because the agent that drives the browser during execution needs to reason about the accessibility tree. The cheapest model Assrt supports, claude-haiku-4-5-20251001, runs a typical #Case for cents. You supply your own key. There is no Assrt-side billing for the LLM. If you want a fully offline run you can record a scenario to traditional Playwright .spec.ts and run that without any model in the loop, trading the self-repair ability for zero per-run cost.

Three lines. '#Case 1: Homepage loads' followed by 'Navigate to https://example.com and verify the heading is visible.' Save it to /tmp/assrt/scenario.md. Run assrt_test with url http://localhost:3000 and scenarioId derived from the file's metadata (or just pass the plan text inline on the first run). If it fails, run assrt_diagnose with the same plan and the failure, paste the Corrected Test Scenario section over line 1, save, run assrt_test again. That is the minimum reproducer for the full write-run-repair cycle and it fits on a Post-it note.