Playwright visual testing without baseline PNGs. A vision model watches every screen change, and the recording carries its own overlay.

It is visual testing in the working sense: a non-deterministic UI change (color, layout, copy, modal pop, missing element) is caught by something other than a DOM assertion. The mechanism is different from pixelmatch baselines. Assrt's agent loop at /Users/matthewdi/assrt-mcp/src/core/agent.ts:1024 captures a fresh JPEG quality 50 screenshot after every visual action (navigate, click, type, select, scroll, press_key) and pushes it back to the LLM as a tool-result image block at agent.ts:1036-1037. The model sees the screen exactly as a user would, and writes its assertion in plain English ("the upgrade modal is open and the annual price reads $39/mo"). Pixelmatch is one way to detect a regression; a vision model reading the screenshot is another. Both are visual.

It is. The line is browser.ts:601: `await this.callTool("browser_take_screenshot", { type: "jpeg", quality: 50 })`. Two reasons. First, every screenshot becomes an image block in a Claude or Gemini API request, and image blocks are billed by pixel count and base64 size. Quality 50 cuts the payload roughly in half compared to PNG, which adds up over a 30-step scenario. Second, Anthropic's vision models top out at usable image resolution well below what a lossless 1600x900 PNG carries; the lossy compression artifacts at q50 are below the model's perceptual threshold for layout, color, and text legibility. If a regression is visible to a human at q50, the model will see it.

Because there is no baseline file. `toHaveScreenshot()` writes a `*-chromium-darwin.png` to disk on the first run, then on every subsequent run runs pixelmatch and fails if the diff exceeds the threshold. Assrt's screenshot path never persists. The screenshot exists in memory for one model turn, the model reads it, and it is discarded (or, if you ran with `--video`, captured into a 1600x900 WebM at browser.ts:628 instead). There is no `tests/__snapshots__/` directory in your repo. There is no "update baselines" flag. The assertion is whatever the English `#Case` paragraph said it was.

The traditional fix list (disable animations, hide elements, mask regions, set a deterministic timezone, preload fonts) exists because pixelmatch is binary: a single-pixel difference fails the test. A vision model reasoning about a screenshot does not care that two adjacent frames of a CSS spinner differ by 12 pixels of subpixel anti-aliasing; it cares whether the spinner is present. Assrt does not ship masking config or animation-disabling CSS, because the failure mode it is built for is different. There is one wait helper (`wait_for_stable` at agent.ts:186-195, polls until the DOM stops mutating for N seconds, default 2s) and that is it.

If you pass `--video` to the CLI (cli.ts:89-91), Playwright MCP starts a WebM recording at viewport size 1600x900 (browser.ts:628), and the file ends up under your test output directory as `recording.webm` (cli.ts:540-542). The recording is not just raw page video. It contains the injected DOM overlay defined at browser.ts:33-97: a 20px red cursor (`rgba(239,68,68,0.85)` with white border), a click ripple that scales 0.5 to 2.0 over 50ms, a green monospace keystroke toast at the bottom that fades after 2500ms, and a 6px green heartbeat dot at bottom-right pulsing every 800ms. The heartbeat is there for a single technical reason: it forces the compositor to push frames continuously, so the WebM does not skip during idle waits.

No, and this is the subtle part. The injected overlay only matters for video frames that the CDP screencast captures. The screenshots passed to the LLM are taken via `browser_take_screenshot` (browser.ts:601), which Playwright takes from the page snapshot, not from the screencast layer. The model sees the real page; the human watching the WebM sees the page with the overlay on top. So the overlay never confuses the model into clicking on a fake red dot, and a human reviewing a failed scenario sees exactly which element the agent moved to and what it typed.

The screenshot rides as an `image` content block in the next user-role message of the conversation. For Anthropic, it is `{ type: "image", source: { type: "base64", media_type: "image/jpeg", data: screenshot } }` (agent.ts:1037). For Gemini, it is `{ inlineData: { mimeType: "image/jpeg", data: screenshot } }` (agent.ts:684). Alongside it, the same message carries the latest accessibility-tree YAML (truncated to 3000 chars at agent.ts:1054). So every model turn after a visual action is reading both the rendered pixels and the AX tree at the same time. The DOM tells it what to click; the screenshot tells it whether the click did what was expected.

Yes. Assrt is built on real Playwright under the hood, exposed through the official @playwright/mcp server (browser.ts:296 launches it as `npx @playwright/mcp/cli.js` with `--viewport-size 1600x900`). Anything Playwright supports is available via `browser_evaluate` or by writing a normal `*.spec.ts` next to your `#Case` markdown. The two patterns coexist. Most teams that adopt Assrt for the LLM-watching pattern keep their existing pixel-diff tests for components where they actually want pixel-perfect lock-in (icons, marketing screenshots, design-token regressions). The LLM-watching pattern handles the long tail of "is the right thing on the screen" assertions where pixelmatch is brittle.

Two paths. In normal mode, the JPEG bytes live in the model conversation only (sent inline as base64), and the agent emits a `screenshot` event over the EventEmitter at agent.ts:653 and 1025 that includes the base64 payload, so the web UI can render a thumbnail strip. In file output mode (`--output-dir`), Playwright MCP writes the JPEGs to disk and Assrt reads them back with `readFileSync` and base64-encodes them for the model (browser.ts:606-620). If you want a permanent visual record, use `--video` and you get the WebM that contains every frame plus the cursor/keystroke overlay.

Write a `#Case` paragraph that focuses the agent. Example: `#Case 1: the pricing card upgrade modal looks right. Navigate to /pricing. Click "Upgrade" inside the Pro card. Verify a modal appears centered on the page, the title reads "Upgrade to Pro", the price reads $39/mo, the "Pay" button is enabled, and the modal can be closed with Escape.` That paragraph becomes the prompt. The agent will snapshot, click, snapshot again, screenshot, and the model judges every visible part of that scene against the English checklist. No selectors, no baseline image. If a designer changes the modal background tomorrow and breaks visual hierarchy, the model can see that and report it.