Your AI regression suite should fit in one Markdown file.

What the top ten SERP pages leave out

Search "ai code regression test generation" and you get the same ten pages: Momentic, QA Wolf, Katalon, DeviQA, Parasoft, TestSprite, Virtuoso. Every one of them describes the category in the same four bullets. AI analyzes diffs. AI picks tests to run. AI self-heals broken selectors. AI generates cases from requirements.

Not one of them shows you what the generated test actually is. Is it a .spec.ts file? A YAML document? A record in a cloud database? Can you open it in VS Code? Can you grep it? Can you paste it in a pull request and have a teammate review it without logging into the vendor dashboard? The abstraction hides the artifact, and the artifact is the whole point of regression testing, because regression only works if the same test can run again next week.

This page does the opposite. We are going to show you the exact file Assrt writes, the exact format of each test case, the exact JSON metadata that makes it re-runnable by ID, and the exact file watcher that keeps the file in sync when an agent edits it.

The file: /tmp/assrt/scenario.md

Here is a real regression plan Assrt would write after a singleassrt_plancall against a signup page. Plain Markdown. Every case is self-contained. Every step is an imperative instruction the browser agent can execute verbatim.

The format is pinned by PLAN_SYSTEM_PROMPT inassrt-mcp/src/mcp/server.tsline 219. The prompt enforces: 3 to 5 actions per case, 5 to 8 cases per plan, each case independent, every verification observable (visible text, URL, element presence). Those constraints exist so a single human or a single agent can read the entire regression suite for a feature in under sixty seconds and tell you what it covers.

The sidecar: scenario.json

Alongside the Markdown, a tiny JSON file holds the metadata that makes the plan re-runnable without regeneration. This is the file that turns any test into a regression test.

The id is a UUID issued on first run. From that point on, any call to assrt_test can swap out the plan argument for scenarioId and the same Markdown will be fetched, materialized back to disk, and handed to the Playwright agent. Nothing gets re-generated. The test you wrote in week one is literally the test that runs in week fifty.

How the regression loop actually flows

The reason this works without a compilation step, a self-healing pass, or a selector registry is that the Markdown is the spec and the Playwright MCP agent is the compiler, re-invoked fresh every run. Here is the plumbing.

The 1-second watcher that makes the Markdown alive

This is the mechanic that turns a static plan file into a collaborative regression suite. When writeScenarioFile runs, it calls startWatching, which registers a Node fs.watch handler onscenario.md. The handler debounces for one second after the last keystroke and then syncs to Firestore.

Three things follow from this tiny handler. First, you can edit the Markdown in VS Code while a run is in progress; the running agent does not see the change (it already has the old plan in context), but the next run will. Second, another agent, say a Claude Code session that just shipped a feature, can programmatically append a new #Case to the file using fs.appendFileSync, and the case becomes part of the permanent regression suite one second later. Third, the lastWrittenContent guard on line 44 means the watcher ignores echoes of its own writes, so there is no feedback loop even though both the file and the remote store are being updated.

What it looks like in your terminal

Here is the full generate-then-regress loop you would run locally on a pull request branch. Every line below is a real step you can reproduce.

The numbers, grounded in the code

None of these are invented. Every one comes from a constant inassrt-mcpor from the prompt that defines the plan format. You can grep them yourself.

Assrt vs. the cloud-only regression platform

Most AI regression platforms ship as a SaaS tool where the test artifact lives in their database, selectors are patched by their model, and re-runs go through their scheduler. That stack works until you want to grep your tests, run them offline, check them into your repo, or leave the vendor. The row-by-row picture:

The diff workflow: regression as a pull request artifact

Because the regression suite is a plain file, the pull request review story gets obvious. When an agent ships a new feature, it appends a #Case to scenario.md (or to a committed copy in your repo). The PR diff shows exactly which test case was added, in English. A human reviewer reads it like any other prose change. A teammate in another timezone can comment on the test the same way they comment on a code line.

That diff is both the ticket and the acceptance test. No second artifact in a test management tool. No translation from "acceptance criteria" to "test script." The same sentence is both.