reticle_act clicks, fills, types, selects, drags. It does exactly one thing and makes exactly one promise: the event was dispatched.
reticle_act proves nothing. If the action is supposed to cause something, use
reticle_act_and_wait and get the verdict in the same call. A drive that
ends on reticle_act has no result.
Example
Real response:
Actions
click · dblclick · hover · focus · blur · fill · type · clear · select · check · uncheck · submit · press · upload · scrollIntoView · drag · webmcp
Reading the effect block
This is where act earns its place even though it proves nothing.
valueChanged: true. The field actually took the value. false on a fill usually means the input is controlled and rejected it, or it’s readonly.
focusMoved: "null->e102", focus went where you expected.
domMutatedWithin: 15, something re-rendered within 15ms. A fill that mutates nothing often means no handler is attached.
defaultPrevented. A handler called preventDefault(), which is why your form didn’t submit.
occluded / occludedBy. The click landed on something else. This is the answer to at least half of all “the button doesn’t work” reports.
settled: false is not a failure
settleReason: "timeout" means the page was still busy when Reticle stopped watching. On a fill that’s normal and uninteresting. On a click you expected to complete something, it’s a hint that you wanted act_and_wait with an explicit until.
synthetic means Reticle dispatched events programmatically. real means native CDP input, available under reticle drive. Synthetic input is fine for the overwhelming majority of apps; a few drag-and-drop and pointer-gesture libraries only respond to the real thing.
When the tab is backgrounded, synthetic timers and pointer gestures can silently no-op. Every
response carries a warning when the tab is throttled. Pass refuseWhenThrottled: true to make
Reticle throw instead of pretending it acted.