reticle_navigate moves the connected browser tab to a URL, or reloads it in place with { "reload": true }. Reach for it for a genuine document load: a deep link, a hard refresh, or the first visit. Clicking a link inside a single-page app is a route change, not a navigation, and does not need this tool.
Real response, with the throttled-tab session and warning fields trimmed off:
confirmed: true when the page comes back in time
The daemon waits up to timeout_ms (default 5000) for the SDK to re-announce itself. When it does, you are told so and can act immediately without a reticle_sessions round trip. This is a real reload response:
Read the second sentence, which is the one that costs people a turn. confirmed: true restores the session, not the evidence: every event, network call and console line captured before the reload went with the old document.
confirmed: false is the honest part
A full navigation destroys the document the SDK was living in. Reticle cannot report on the new page from inside the old one, because the old one no longer exists. So it tells you what it actually knows: the navigation was dispatched.
Most tools would return ok: true and let you assume arrival. When the page then fails to load, or loads without instrumentation, you get a confusing cascade of “element not found” errors several calls later, with nothing pointing at the real cause.
waitedMs says which of two things you are looking at. Reticle stopped waiting at the budget it had, or the page never came back. The first is fixed by asking for more: a single-page app reattaching under HMR has been measured at 30–60s, which no default should wait for on every call, but which the caller who knows the app can grant.
The pattern after navigating
then confirm a session reconnected:
with reticle_sessions, and only then snapshot. If no session appears at the new URL, the page did not load or is not instrumented. And you know that immediately rather than three calls later.
Refs do not survive a navigation. A new document means new refs. Across one afternoon on the
same fixture, the same “Sign in” button was e105, then e305, then e3. Re-snapshot; never
carry refs across. Reticle refuses a stale ref rather than clicking whatever now occupies the
slot, so the failure is loud, but it still costs you a turn.
Arguments
Client-side routing is different
In a single-page app, clicking a link usually changes the route without destroying the document. That is a route change, not a navigation. Refs survive, and you can assert it directly:
That is a verified call. Its verdict quotes the transition itself:
Use reticle_navigate for a genuine document load. A deep link, a hard reload, or the first visit.
