It happens like this: the site is fine, but the check itself broke — a rule or an action stopped finding the element because it was renamed. Before, that meant calling a programmer over one line. Now the agent sees the broken check and repairs it itself. Below is how it works and why it does not get out of control; what this page is about is precisely a broken check script.
Why this is needed
The difference between “the site broke” and “the check broke” is huge, while the error message looks the same. An action did not find the button — maybe the button was removed from the site (a problem), or maybe its name changed and the check just needs a small edit (not a problem). In the second case there is nothing for a person or a business to spend time on: the agent does the work.
Two different repairs
There are two repairs in the product, and they are worth keeping apart. This page is about a broken script — a rule or an action: the agent fixes it itself, and the edit applies at once. A broken test is repaired differently: the agent only proposes a new revision, a human applies it, and only then does a verification run prove the result.
The difference is not in strictness but in the price of an error: a test is what you check the site with, and an unnoticed edit changes what the check means. That is why the proposal, the approval and the verification are kept apart. What that looks like — in the Test Healing section.
When auto-fix fires
- A rule or action ended with an error during a run — it broke, as opposed to merely failing.
- The agent receives the check’s code, the error text and a snapshot of the page at that moment.
- It returns a fix, which is applied immediately and marked “auto-fixed · needs review”.
The mark is not decorative. Verification is reset: someone else’s code edit without your eye is always a risk, and a check that “seems to work” is worse than an honest breakage. Look at the result, run the check — and verify it.
Limits
- One fix per target per hour — when a check breaks again and again, the product stops poking the agent and shows it to you instead. The cause in such cases is almost always the site itself, not the check.
- Five fixes per project per day — the overall ceiling, so that expenses do not run away because of one neglected error.
When a limit is exhausted, nothing is lost: the issue stays in the list and shows up in the summary — so a human still hears about it.
The honest “this is not a breakage” answer
Sometimes the agent answers: the check is fine, the page really did change. That is not a refusal to work but an honest conclusion, and then the product changes nothing. The issue stays and waits for a person: the matter is not in the check but in the site, and it is the site that needs fixing.
Where it is visible
- In the summary — the “auto-fixes to review” number and the project’s badge. While it is not zero, the agent’s work is waiting for your eye.
- On the “Rules” tab — a repaired check carries the mark that the agent fixed it.
- In the chat list — every fix stays as a separate analysis: you can see what the agent received and what it proposed. The whole analysis can be reread when needed.
Next: what the summary shows and how to use it — in the What Needs Attention section.