The question the comparison posts never ask: can you still read your own tests after you stop paying the vendor.

Three things, and only three. (1) The source of truth for a test is a file on your disk, readable without the vendor's software. (2) The result is a structured artifact (JSON, plain text, or standard video formats), not a cloud-only dashboard. (3) The runner is invokable from a shell, so a CI machine that has nothing but curl, jq, and node can execute a scenario. Assrt puts the scenario at /tmp/assrt/scenario.md, the result at /tmp/assrt/results/latest.json, and the runner at npx assrt run. That's the whole portability surface.

Because the buyers writing those lists haven't had to leave a vendor yet. Portability only matters when you're mid-migration, mid-acquisition, or mid-renegotiation. Until then, it reads like an abstract concern. But when it matters, it matters catastrophically: an org can spend 18 months and six figures porting TestComplete Keyword Tests into something open, only to discover that the recorded object identifiers don't map cleanly. Listicles comparing on 'mobile support' or 'integrations' miss the one axis that decides whether your six-year-old regression suite survives the next CFO.

Run assrt_test once. It writes the plan to /tmp/assrt/scenario.md and starts fs.watch on that path. Open the file in any editor, make a change, save. Within one second, the debounce fires (scenario-files.ts lines 99 to 102), the watcher reads the file, checks it against the last content it wrote, and calls updateScenario with the new plan. Your next assrt_test run sees the edited version. If you skip the cloud sync (--no-save), the file is still the source of truth locally, there's just no cloud copy.

No DSL. The format is a Markdown-style list of #Case N: <name> headers, followed by 3 to 5 imperative steps per case. 'Navigate to /signup. Click Sign in. Type test@example.com into the Email field. Assert the dashboard heading is visible.' That is a full scenario. The test agent reads each case, pulls a fresh accessibility tree from Playwright MCP before interacting, and reports pass or fail with evidence. There are no selectors, no waits, no page-object classes, no language bindings to install.

Fully optional. Pass ASSRT_NO_SAVE=1 (server.ts:404) and the local files are the only copy. Or pass --no-save to the CLI. The scenario file, the results, the video, and the log all live under /tmp/assrt with no network call. Cloud sync is a convenience for sharing runs and scenarios across a team; it is not a dependency for running a test. Same for the MCP path: the MCP server exists on your machine, it talks to Playwright MCP over stdio, it doesn't need to phone home to function.

On portability and on the source-of-truth question, Assrt wins trivially because the scenario is already on your disk. On features like large-scale test orchestration, distributed runners, and enterprise reporting dashboards, commercial platforms still have more polish. The real question is what you actually need. If the need is 'run 30 test cases against every PR in CI, fail the build on a red result, and keep my scenarios version-controlled,' Assrt covers it at $0 of tooling cost (only the LLM API calls for the agent, which are a few cents per scenario at Haiku prices). If the need is a procurement-friendly SaaS with an enterprise sales motion, that's a different market.

That is the recommended workflow. Copy /tmp/assrt/scenario.md into your repo (conventionally at tests/scenarios/<name>.md) and point assrt_test at it with plan-file. PR reviews become plain-text diffs. Code review comments work out of the box. git blame tells you who last touched a case. You can store scenarios per project, per feature, or per user flow; the runner doesn't care about the path, only the #Case format. There's no import step, no sync step, no conversion.

Yes. Assrt is additive. It runs an agent on top of Playwright MCP, which is itself a thin wrapper over Playwright core. Your existing Playwright tests still work, your existing CI config still runs them, your existing reporters still report. Teams typically use Assrt for the scenarios that keep breaking because selectors change (signups, checkouts, onboarding flows, long forms) and keep hand-written Playwright for the hot paths where deterministic behavior matters more than robustness to redesigns. Both suites can share a single local Chromium profile via Playwright MCP, so you don't double your CI wall time.

It's deterministic enough that the failure mode is 'the agent noticed a real bug you didn't plan for,' not 'the agent hallucinated a click.' The reason: every step reads a fresh accessibility tree, every assertion requires explicit evidence from the DOM, and wait_for_stable (agent.ts:956-1009) blocks on a MutationObserver quiet period before the agent is allowed to assert. For extra paranoia, pass passCriteria to assrt_test (server.ts:343) and the agent will verify every listed condition explicitly before marking a scenario passed. A scenario with good passCriteria fails the same way twice when the app is broken the same way twice.

You lose the recorder UI. If your QA process relies on a non-technical teammate clicking through the app in a special mode to generate a test, the closest analog in Assrt is assrt_plan: navigate to a URL, it analyzes three scrolled screenshots, and emits 5 to 8 #Case scenarios you can edit. That replaces the recorder for most cases. What you don't get back is the recorder's illusion that the resulting test doesn't need human judgment. Record-and-replay suites break on the first redesign because the recorded selectors are tied to the old DOM. A #Case file written in intent-first English survives redesigns for the same reason a bug report does.