What an agent cannot guess
“The click succeeded” is true and says almost nothing. Where a run that worked and a result that happened part ways, and the signals Dinoer returns to tell them apart.
An agent driving the browser core knows one thing for certain: whether its own
instruction ran. It clicked, the click happened, succes: true.
That is compatible with a server that received nothing, a form that was rejected, a session that had expired, or a page that was the wrong one from the start.
Three ways a success is not a result
The browser refused to send the form. A required field was empty, and
HTML5 validation blocked the submission. The click happened; nothing was
sent.
The click was synthetic. A JavaScript .click() on a submit button fires
the click event without guaranteeing that the form is sent.
The page was not the expected one. A redirect led somewhere other than the scenario assumed, and the click landed on a page nobody meant to touch.
In all three cases, the agent’s own output alone cannot tell it. Form that never submits →
Time does not show
A page can be fully loaded and not yet ready.
After a sign-in form is submitted, the network goes quiet and navigation completes. The agent concludes that the session exists, goes to a protected page, and lands back on the sign-in page.
Many applications regenerate the session identifier just after authentication: the browser has finished, the server has not, and nothing in the page distinguishes “quiet because finished” from “quiet between two states”. There is no signal to wait for, which makes this the one case where a fixed pause is the right tool:
{"type": "cliquer", "selecteur": "button[type=\"submit\"]"},
{"type": "pause", "ms": 2000},
{"type": "naviguer", "url": "https://target.local/protected"}
What Dinoer does about it
It cannot close the gap: no tool can, from inside the browser. It returns signals that make a wrong assumption visible.
Where you are. boussole carries the URL after redirects, the page title
and the last HTTP status.
Session drift. After --reprendre-session, boussole.session_derive
appears when the page you ended on differs from the one where the session was
saved. dernier_code_http then separates two failures that look the same: a
real expiry redirects (302), an application error returns 500 and the same
sign-in page.
Fallback used. repli_js_utilise appears only when a JavaScript click
fallback actually ran.
None of these is a guarantee. Each turns a silent wrong assumption into something you can read.
The habit this calls for
Read the answer, not the verdict. succes: true is the least informative
field of the output: it says the instruction ran. Whether the work happened is
in everything around it: where you are, what the server said, whether
anything had to be forced.
The research pipeline follows the same rule: campagne.py reads the status of
each page it fetches (visitee, refusee, insuffisante_legere and others)
and keeps only the pages it could read.
In short
- A run that worked and a result that happened are two different claims.
- A quiet network does not mean a ready server.
- The signals exist (position, HTTP status, session drift, fallback used) and they say more than the verdict.