A rule is the heart of the product. It is a small check that looks for one specific problem on a page and runs right in the browser, without calling the model. Because of that, checks are fast and cost nothing, no matter how many times you run them. Below is where rules come from, what they can do and what “verifying” a rule means.
What a rule is
A small set of conditions in JavaScript — the language browsers run programs in. A rule opens the page, looks at its elements and decides: everything is fine, or there is a problem. When there are several problems, each gets its own message, a pointer to the guilty element and a severity: a hint, a warning or an error.
A check can look at the text of elements, their sizes, placement, counts and contrast — that is, at what a person sees with their own eyes. For example: “the sign-in button must be visible and at least 40 pixels tall”, or “the payment page must have exactly one heading with the amount”.
Where rules come from
- From a comment — the main route. You describe the problem in words, the agent writes the rule and decides on its own which pages it applies to.
- By hand — any rule can be opened and edited: it is a plain file in the project folder. Useful when a threshold needs changing, “at least 48 pixels” instead of 40, for example.
- With the agent’s help — if a rule does not work the way you wanted, you can ask it to fix the rule in words, without touching the code.
Where a rule runs
- Everywhere in the project — a universal rule. Fits the things every page must have: the logo, the menu, the readability of the main text.
- Only on its own pages — the rule is bound to screen types and fires where the address matched the pattern. That way a payment check does not nag the news pages.
The browser panel shows, on the open page, only the rules that apply to it — so the list is always short and to the point.
A rule as one of the build’s check layers
Rules are not the only check in a build. A visual build has several layers, and a rule works alongside them: visual comparison, text, the page structure (DOM), the network, the console, accessibility, design tokens, performance and the URL. That way one build can stand up for several truths at once — the picture, the text and the behavior.
Every layer has the same choice of three modes: enforce — a mismatch fails the build, log — the result is recorded but does not sink the build, disable — the layer is skipped entirely. This is configured in the Visual Testing Settings section, and how the builds themselves are arranged — in the Visual Testing section.
Checking and verifying
The “Check this page” button in the panel runs all the applicable rules and shows the result for each: passed, or a problem was found. The results are stored — this is the first evidence that the rule works on a real site, not only in the agent’s head.
A new rule needs to be verified. Here it is important not to fool yourself: verification means “the rule runs and works without errors”, not “the page is fine”. A rule can honestly find a problem — and still be verified. The point is different: until a check has run at least once, it cannot be trusted, and it is not used in tests.
Rule states
- Verified — the check works, it can be trusted and included in tests.
- Unverified — the rule has never run yet. It does not take part in tests.
- Auto-fixed · needs review — the rule broke and the agent repaired it itself. The mark stays until you look at the result: someone else’s edit without your eye is always a risk.
- Disabled — the rule exists but does not run. A convenient way to retire outdated checks without losing their text.
The knowledge box
Next to the rules lives the project’s knowledge box — a file where the agent appends what it has already understood about your interface: where the login is, what the sections are called, which buttons matter. This is what makes every following analysis cheaper and more precise: the agent does not have to figure out again what it already knows. The knowledge box, like the rules, lives in the project folder and lands in the edit history.
Limitations
- A couple of seconds per check — a rule has to fit into that. A long check slows down the whole run, so heavy tasks are better split into several simple ones.
- A cap on the whole rule set — about 100 kilobytes of code per project. Whatever does not fit is skipped with a mark, visible in the results. People usually hit the cap when copying huge checks wholesale — the fix is to factor the common part into one rule.
Next: how to record a scenario of working with the interface — in the Actions section.