reticle_observe returns the full timeline of everything the app did in a window: DOM, network, routing, console, animations and signals, in order, with a summary on top. Reach for it when you do not yet know what went wrong. It reads and diagnoses; it does not produce a verdict.
It is the wide-angle lens. Where reticle_network and reticle_console answer one question each, observe returns everything.
Example
headers block on that net.detail event is trimmed out for length.
Read the summary first
Thesummary block is the cheap answer. consoleErrors: 0 and network: 0 tells you most of what you need without reading a single event. Pull the timeline only when the summary says something interesting happened.
Arguments
Scope by cursor, not by clock
Everyreticle_act response includes a since cursor. Passing it to observe scopes the timeline to exactly what followed that action, with no guessing about how many milliseconds to look back:
window_ms and it does not drift when the machine is slow. Which matters, because a timing-based window that works on your laptop and fails in CI is a flaky test waiting to happen.
Every event scoped this way carries its actionId and attribution, so you can tell what the action caused from what merely happened alongside it:
contradictions is the field to read first
When two channels disagree, observe says so without being asked:
When to use it
Useobserve when you do not yet know what went wrong. Use the narrow tools when you do.
Good use
“Something broke after that click, show me everything that happened.”
Wasteful use
“Did a POST fire?”
reticle_network answers that far more cheaply.observe reads. It does not produce a verdict. It is for diagnosis, not proof.