---
title: "Setup Checklist"
id: "1922"
type: "page"
slug: "checklist"
published_at: "2026-09-30T22:18:24+00:00"
modified_at: "2026-10-01T00:11:02+00:00"
url: "https://xedant.com/agents/test/docs/checklist"
markdown_url: "https://xedant.com/agents/test/docs/checklist.md"
excerpt: "The checklist is not a survey and not a formality: every one of its steps…"
---

# Setup Checklist

[https://xedant.com/agents/test/docs/checklist.md](https://xedant.com/agents/test/docs/checklist.md)

The checklist is not a survey and not a formality: every one of its steps is computed from the project’s real data on every open. That is why it honestly shows what is already ready and what is not yet.

Eight steps lead to the first verdict. Until it is delivered, the top shows how many actions remain before it; afterwards — a short note that the first verdict is in and everything further is only tuning.

## The eight steps

1. **Connect the agent** — ambiguous diff analysis and failed build analysis work through the connected agent. Skipping this step does not stand in the way of anything else.
2. **Scan the routes** — the crawl builds the app map the coverage inventory grows from.
3. **Take the first capture** — one capture from the extension panel is enough to prove the whole path works end to end.
4. **Compose a visual test** — only a test with a declared capture is what builds run.
5. **Run the first build** — the first build creates the baselines for every capture by itself.
6. **Approve the baselines** — approving a difference in build review creates a baseline confirmed by a human.
7. **Run the second build** — a repeat run of the same test proves identical pages compare as unchanged.
8. **Look at the verdict** — the check’s verdict is the end of this path; everything after it is tuning.

Every step has a “why” explanation and an action button, and its state is always one of the understandable ones: not started, in progress, skipped, or done. The “problem” state shows only when a red health check blocks the step.

## Skipping a step

A step can be skipped — when you do not use the agent, for example. But it cannot be skipped without a reason: the reason is saved into the project file, stays visible in the checklist afterwards, and the skip itself can always be canceled.

An honest remark: the first two or three weeks still go into tuning the masks — dynamic areas keep moving, and the masks tell the system what exactly to ignore. That is a normal part of the work, not a sign of an error.

## The CI policy

Separately, you choose how the build pipeline treats the visual results:

- **Report only** — visual results are informational and block nothing.
- **Block critical** — critical visual failures block the merge; cosmetic ones do not.
- **Block gates** — the visual review must approve the changes before the merge proceeds.

The policy itself rides in the check text the pipeline publishes, and the verdict always stays an honestly computed state. Only an administrator can change the policy.

## Where to start

You do not have to walk the eight steps blind. The start can be the application profile: one choice instead of thirty fields sets sensible values you can tune afterwards. Beside it you can see what the chosen profile sets — the engine and sensitivity, the capture type and the window sizes, and the fact that capture stabilization is on.

Next: how to show the result to colleagues and a customer — in [Report & Share Links](/agents/test/docs/report)
.

[← Back to the documentation index](/agents/test/docs)