A screen is what the product looks at: the page in the state you saw it in. A comment is what you think about it, in plain words. Together they start all the work: from a comment the agent makes a check that from then on works by itself. Below is how to capture screens, write comments and start the analysis. And one caveat right away: a screen is not the same thing as a visual-check snapshot — that difference has a section of its own below.
What a screen is
A snapshot of the visible area of the page plus its description: the address, the title, the window size and the structure — headings, buttons, fields and their counts. All of this is captured with one button from the panel and saved immediately: there is no interim “review and save” step, because losing an unsaved snapshot is far more annoying than deleting an extra one.
The image is stored in the product’s database, not as a separate file in the project folder. That is why you can take as many snapshots as you like, and they never clutter the edit history of your files.
Do not confuse a screen with a visual-check snapshot — it is described below and in the Visual Testing section.
A screen and a visual-check snapshot are not the same thing
They look alike — both are a picture of the page — but they serve different jobs. A screen exists for comments and rules: it carries your text, a screen type and the agent’s analysis. It lives in the project gallery and serves as material for learning.
A visual-check snapshot is another matter. Its kind (part of the page, the whole page, a component, an element or a text snapshot) is declared in advance by the test step itself; it is tied to that step and compared against the baseline during a build. It never has comments: its job is to show whether the page changed.
Hence a simple rule: there can be as many screens as you like, and they take no part in comparisons; snapshots are exactly as many as the test steps declare. Details — in the Visual Testing section.
The screens gallery
All of a project’s snapshots live on the “Screens” tab. There are search, filtering by screen type and a “Show more” button — the list grows long, and browsing it whole is rarely needed. A screen’s card shows the snapshot itself, where it came from, its type and its comments.
Where a snapshot came from is an important mark: captured manually, “via action” (produced by replaying a recorded scenario) or “from a run” (left by a test step). That way you always know whether you are looking at your training page or at evidence from the latest run.
Comments
A comment is plain text: “the button is invisible on the dark background”, “after submitting the form it is unclear what happened”. You can write it from the panel right after the capture, or later from the screen’s card in the app. Comments live as files in the project folder — which means they land in the edit history together with the rules and tests.
Comments are not analyzed on their own: the product sends nothing to the agent until you ask for it. This is deliberate, so that money is not spent on analyses you do not need right now.
The “Call agent” button
When the analysis is needed, press “Call agent”. A ready report about the screen is placed into the chat field: your comments verbatim, a link to the snapshot, the knowledge accumulated in the project, the list of rules and screen types. Only what you add below is sent — so the press itself spends nothing.
Add your request and send it. In reply the model returns three things: a rule — a check that from then on looks for this problem without the model; a knowledge increment — what it understood about your interface, notes that will help in the next analyses; and the screen type — which group of pages the captured one belongs to.
- Queued — the analysis waits for its turn: only one runs at a time, so the agent’s work never mixes.
- Processing — the agent reads the report and prepares the answer.
- Done — the rule, the knowledge and the screen type are written into the project.
- Error — the analysis failed: the agent is unreachable, or the answer came in the wrong shape. The answer is preserved in full, with a retry button next to it. If the server restarted mid-analysis, the comment returns to the queue by itself.
One analysis — one answer. Messages you type in the chat afterwards are not re-analyzed by the product: to get a new rule, send the report again.
Screen types
A screen type is a name for a group of pages with an address pattern. For example, the type “login” with the pattern /login gathers all the sign-in pages, and a check bound to this type runs only on them. Types are assigned by the agent during the analysis, but you can set them by hand as well — the file screen-types.yml corresponds to them in the project.
Deletion and cleanliness
A screen is deleted together with its snapshot and comments — it makes sense to remove extra training pages so the list stays surveyable. Deletion does not affect the rules already released. Nor does it touch baselines and visual-build snapshots — those are separate storages.
The addon panel never gets into the shot — this was taken care of separately, so that snapshots stay honest. And right away a caveat about links: the screenshot link opens without signing in to the product — that is how the requests to the model are built, it downloads the image over a plain link. That is why the Test Agent server is best kept in a closed network, unreachable from the outside.
Next: what a rule consists of and how to verify one — in the Rules section.