What an agent cannot guess

An agent driving a browser knows one thing with certainty: whether its own instruction executed. It clicked, the click happened, succes: true.

That statement is true. It is also compatible with the server having received nothing, the form having been rejected, the session having expired, and the page having been the wrong one all along.

Perception is not only about seeing the page. It is about knowing where seeing stops.

The gap between “it ran” and “it worked”

Three real cases, all ending in success:

The browser refused the submission. A required field was empty. HTML5 validation blocked it and drew a small native bubble. The click happened — Diwall is right — and nothing was sent.

The click was synthetic. A JavaScript .click() on a submit button fires the DOM event without guaranteeing the HTTP submission. A theme update in a content management system ended green with no theme updated.

The element was not the one in the picture. Numbers shift with the document; something opened or closed between capture and action. The click landed, on a stranger.

In all three, the agent had no way to know from its own output. That is the point of this page.

Time is invisible

A page can be fully loaded and not yet ready.

After a login form is submitted, the network goes quiet and the navigation completes. The agent concludes the session is established and navigates to a protected page — and lands back on the login screen.

The server had not finished. Many applications regenerate the session identifier right after authentication; the browser is done, the server is not, and there is no visual or structural difference between “quiet because finished” and “quiet because between two states”.

{"type": "cliquer_som", "id": 2},
{"type": "pause", "ms": 2000},
{"type": "naviguer", "url": "https://target.local/protected"}

Two seconds of deliberate waiting, because network silence is not the same as readiness. Nothing in the page says so.

What Diwall does about it

It cannot close the gap — no tool can, from inside the browser. What it can do is stop the agent from reasoning as if the gap did not exist.

Report the count, not just the list. som_hors_viewport says how many interactive elements the capture missed.

Report where you actually are. The compass carries the current URL after redirects, the page title, the last HTTP status. An agent that believed it was elsewhere finds out.

Report drift. session_derive says the session no longer holds. And dernier_code_http disambiguates the two failures that look identical — a real expiry redirects with a 302, an application error hidden behind display_errors=0 gives a 500 and the same login page.

Report escalation. repli_js_utilise appears only when a fallback actually ran, never because the flag was set.

None of these are guarantees. They are signals that turn a silent wrong assumption into a readable one.

The habit to take from this

Read the answer, not the verdict. succes: true is the least informative field in the output — it says the instruction ran.

What tells you whether the work happened is everything around it: where you are, what the server said, what the capture could not see, whether anything had to be forced. An agent that checks only the verdict will be confidently wrong on exactly the cases that matter.

In short

• Mechanical success and real effect are different claims.
• A quiet network does not mean a ready server.
• The signals exist — compass, HTTP status, drift, off-screen count — and they are worth more than the verdict.
• Knowing where perception stops is part of perceiving.