reticle_act_sequence

A login is three actions. Driving it one call at a time costs three round trips and three turns of context. reticle_act_sequence does it in one. This tool exists because of a measured problem: agents were driving forms one call at a time, over and over. Those repeats were not retries. The calls succeeded and got repeated, because the batching tool was not advertised and so nobody knew it was there.

Example

{
  "steps": [
    { "ref": "e101", "action": "fill", "args": { "value": "admin@reticle.dev" } },
    { "ref": "e102", "action": "fill", "args": { "value": "correct-horse-battery-staple" } },
    { "ref": "e103", "action": "click" }
  ]
}

Real response, trimmed:

{
  "since": 13776,
  "dispatched": true,
  "result": {
    "ok": true,
    "count": 3,
    "effects": [
      {
        "dispatched": true,
        "focusMoved": "null->e101",
        "valueChanged": false,
        "domMutatedWithin": 6
      },
      {
        "dispatched": true,
        "focusMoved": "e101->e102",
        "valueChanged": true,
        "domMutatedWithin": 10
      },
      {
        "dispatched": true,
        "focusMoved": "e102->null",
        "domMutatedWithin": 15,
        "appeared": "Signing in… | Invalid email or password | Sign in"
      }
    ],
    "steps": [
      {
        "ref": "e101",
        "action": "fill",
        "testid": "login-email",
        "source": { "file": "src/components/Login.tsx", "line": 48 }
      },
      {
        "ref": "e102",
        "action": "fill",
        "testid": "login-password",
        "source": { "file": "src/components/Login.tsx", "line": 59 }
      },
      {
        "ref": "e103",
        "action": "click",
        "testid": "login-submit",
        "source": { "file": "src/components/Login.tsx", "line": 81 }
      }
    ]
  }
}

Read that response again

ok: true. count: 3. Every step dispatched. And the login failed, look at appeared:

"appeared": "Signing in… | Invalid email or password | Sign in"

That password was wrong. The app rejected it. And this tool still reported ok: true, correctly, because ok means the three actions were dispatched, which they were.

This is the whole reason act and act_sequence do not produce verdicts. ok: true is a statement about the input, not about the outcome. Follow a sequence with reticle_act_and_wait on the final step, or with an reticle_assert, or you have proved nothing.

The honest pattern is: batch the setup, prove the outcome.

{
  "steps": [
    { "ref": "e101", "action": "fill", "args": { "value": "admin@reticle.dev" } },
    { "ref": "e102", "action": "fill", "args": { "value": "reticle" } }
  ]
}

then

{ "ref": "e103", "action": "click", "until": { "kind": "signal", "name": "auth:granted" } }

Two calls instead of four, and the last one returns a verdict.

What each step reports

Every step comes back with the same effect fields as reticle_act: valueChanged, focusMoved, domMutatedWithin, occluded. Plus its testid, component and source. When a sequence goes wrong, that per-step detail tells you which step, and which line of which file.

Steps run in order and do not stop on a soft failure, because “the field rejected the value” is not an exception. It’s a result you need to see. Read effects[] rather than assuming ok: true means all three did what you wanted.

Tools

Beyond the loop

CLI

Libraries

Grammar

Long form

reticle_act_sequence

Example

Read that response again

What each step reports

​Example

​Read that response again

​What each step reports

Example

Read that response again

What each step reports