Auto-E2E

Principles

The requirement is written in stone. The script is a cache.

Three rules that keep the system honest as the product changes.

1 · Scripts are cached, not carved

A failure comes with proof. A model decides: bug or drift.

yes next test no bug drift one-line explanation script updated, requirement not Run cached script no LLM · cheap · fast Green? proof attached Validate proof done Model reads the proof real bug, or drift? Real bug → raise it the requirement still holds Drift → rewrite the script button moved, label changed Owner approves one click, or never asked
Scripts are cached, not carved. A failure comes with proof; a model decides bug or drift; drift gets a rewrite and an owner's click.

2 · Analysis moves to the merge request

The map already exists, so nothing is rediscovered per run

When a task appears in the tracker, the expected scenario changes are drafted. When the merge request lands, dependency breaks surface then — not at the weekly release.

Today task MR merge release weekly E2E found here, days later With the map task MR merge release E2E confirms caught at the MR ↑ scenarios drafted here
Analysis moves to the merge request. The map already exists, so the model never rediscovers the product per run; dependency breaks surface at the MR, not at the weekly release.

3 · Suggestions, not chores

Owners are the authority on how things should work — not the maintainers of a test inventory

The system keeps the inventory and comes to the owner with decisions: "You added a feature — here is the test." "You changed a feature — these six scenarios need a look." One click to approve, reject or correct, and the correction flows back into the tree.

See what the owner sees →

Want this on your product?

We are building the first version with a handful of teams. Tell us what you test with and what breaks.

Get early access See how it works