The cheapest AI Playwright test maintenance is no maintenance, because there is no locator to break

Every mainstream approach stores locators. You write page.getByRole('button', { name: 'Sign in' }) or page.locator('[data-testid="submit"]') at authoring time, and the moment a designer renames the button, swaps the test-id, or wraps it in a new parent, the locator stops matching. AI self-healing products detect that failure and try to guess a replacement locator at runtime using historical context, visual hashes, or LLM inference. It works often enough to ship, but you are still maintaining a stale cache of selectors you hope the model can repair. The cheaper move is to not store locators at all. Assrt's agent calls a snapshot of the accessibility tree before every single action, uses ephemeral ref IDs that only live inside that one step, and discards them afterward. There is nothing to go stale. The rule is enforced by the CRITICAL Rules section of SYSTEM_PROMPT at /Users/matthewdi/assrt/src/core/agent.ts lines 206-218: 'ALWAYS call snapshot FIRST' and 'If a ref is stale (action fails), call snapshot again to get fresh refs.'

Those products sit on top of your existing Playwright test code. Your spec file still contains page.locator calls. When a run fails, their service intercepts the failure, consults a model plus historical runs, and patches the locator in-flight. You stay on the locator-first mental model; they add an ML repair step. Assrt replaces the mental model. Your test is a #Case block in plain Markdown that says 'Click the Sign In button', and the agent discovers the Sign In button from the live accessibility tree every time the test runs. There is no step where a locator breaks, because there is no locator. There is also no cloud dashboard, no seat-based pricing, no proprietary YAML to lock you in. The cost side matters: AI-driven closed platforms price around $7.5K/month per seat bundle. Assrt is open-source, self-hosted, $0 beyond the Anthropic tokens your runs consume.

It uses Playwright. The runner spawns @playwright/mcp (the official Playwright MCP server) and drives a real Chromium process. You get the full Playwright surface: real network traffic, real rendering, real video capture written as .webm files to /tmp/assrt/<runId>/. What Assrt changes is the authoring layer above Playwright, not Playwright itself. You write intent in Markdown, the agent translates intent to snapshot+ref+click sequences in real time, and Playwright executes. When someone on your team already knows Playwright, the videos, traces, and failures look exactly like Playwright output because they are Playwright output. You are not buying into a parallel universe; you are changing how tests get authored and maintained.

It is a markdown file at /tmp/assrt/scenario.md with #Case blocks. Example: '#Case 1: Email signup\n1. Navigate to /signup\n2. Type a temp email into the email field\n3. Click the Sign up button\n4. Assert: dashboard heading is visible'. The layout is defined at /Users/matthewdi/assrt-mcp/src/core/scenario-files.ts (scenario.md for plan text, scenario.json for metadata, results/latest.json for the last run). You can check these into your repo next to a Playwright project, version-control them, diff them, review them. Because the format is plain Markdown, grep works, GitHub renders them, and there is no migration pain if you decide to move to a different runner later. The Corrected Test Scenario that assrt_diagnose emits when a test genuinely needs rewriting is the same format, so you paste it straight into scenario.md.

It ships a wait_for_stable tool backed by a real MutationObserver. The implementation is at /Users/matthewdi/assrt/src/core/agent.ts lines 872-925. When the agent calls wait_for_stable, it injects a MutationObserver that counts childList, subtree, and characterData mutations on document.body, then polls every 500ms until either (a) 2 seconds pass with zero new mutations, or (b) a 30-second ceiling is hit. This adapts to the page instead of guessing. A fast SPA settles in 400ms; a chat streaming LLM tokens might churn for 4 seconds. Both are handled by the same primitive. Flaky tests in locator-first Playwright are usually either stale-locator flakes (handled by snapshot-first re-discovery) or timing flakes (handled by wait_for_stable). Between the two, most of the flakiness that drives maintenance overhead in traditional suites never manifests.

Execution runs on Claude Sonnet through the Anthropic SDK. Diagnosis (the assrt_diagnose tool that rewrites a failing #Case after a real failure) runs on Claude Haiku 4.5 with a 4096-token output cap, because diagnosis is bounded and cheap. The full pipeline respects the ANTHROPIC_BASE_URL environment variable, so you can point the runner at a local proxy, a hosted model compatible with the Anthropic API shape, or an air-gapped endpoint. For teams with compliance constraints, this matters: your app under test, your scenarios, and your test videos never leave your network unless you want them to. That is the 'self-hosted, no cloud dependency' property. Contrast with locator-healing SaaS products where your DOM snapshots, screenshots, and selector history all live in their backend.

Yes, and the translation is almost mechanical. await page.goto('/signup') becomes 'Navigate to /signup'. await page.getByRole('button', { name: 'Sign in' }).click() becomes 'Click the Sign in button'. await expect(page.getByRole('heading')).toHaveText('Dashboard') becomes 'Assert heading text is Dashboard'. The locator is gone; the intent remains. If your existing spec is doing something esoteric (say, a hand-written XPath expression or a race-condition workaround), translate the underlying behavior rather than the mechanics. The full conversion usually takes five minutes per test and the resulting #Case is shorter than the TypeScript it replaced. Keep both during a migration if you want a safety net; nothing about Assrt prevents a Playwright project from sitting next to it.

Nothing surprising. The agent already calls snapshot between actions, so it sees the new state on the next iteration and uses a fresh ref. The Error Recovery block of SYSTEM_PROMPT (agent.ts lines 220-226) spells out the sequence: action fails, call snapshot, page may have shifted (modal, navigation), try a different ref or approach, scroll and retry after three failures, mark as failed with evidence if truly stuck. In practice this means an A/B test that swaps a button variant mid-run does not crash your test; the agent finds the new button by role and label and proceeds. A traditional Playwright locator would have hardcoded '[data-testid="cta-v2"]' and required a rerun after someone renamed it to 'cta-v3'.

It degrades gracefully. The accessibility tree that @playwright/mcp snapshots is the computed tree, which includes non-ARIA elements with their text content and roles inferred from HTML semantics. Buttons without aria-labels still show up with their visible text. Divs with click handlers show up as generic interactive nodes. The agent can fall back to evaluate for arbitrary JS if a page is truly opaque, and the SYSTEM_PROMPT explicitly documents an evaluate-based workaround for OTP inputs split into single-character fields (agent.ts line 235). For apps that have zero accessibility story at all, you get the same coverage you would have had with role-based Playwright locators plus an escape hatch. The fix is usually to improve the app, which is also good for users.

Safer than the alternatives. Assrt MCP runs as a local Node process on your laptop (npx assrt-mcp), so the target URL can be localhost, a private preview URL, or anything reachable from your machine. Outbound network goes to the LLM provider and the target URL you chose; no third-party SaaS middleman sees your DOM, your test plan, or your results. Test artifacts land under /tmp/assrt on your own disk. If your security team requires strict LLM routing, set ANTHROPIC_BASE_URL to a proxy you control and every inference call respects it. The scenario format is Markdown you own, the runner is open source, the videos are .webm on your filesystem. There is no vendor who can lose, leak, or gate your test data.