> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reticle.sh/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Reticle is a dev-only, localhost-only verification layer for AI coding agents. It reads program truth (network, state, console, routing, animations, framework state) from inside a running web app and returns a deterministic verdict with evidence. It is not a screenshot tool and not a browser automation library.
> Only `reticle_act_and_wait` and `reticle_assert` produce a verdict. Every other tool moves or reads the app and proves nothing. A drive that ends without one of those two has no result, however many tools it used.
> A verdict of `verified: "unknown"` is not a pass. It means Reticle drove the app and could not tell what happened. Report it as unknown; never weaken a check to make it pass.
> Package names are scoped `@reticlehq/*` and the CLI is `reticle`. Install with `npx reticle init`. The complete tool surface is on the `/usage` page; `/agent-cheatsheet` is the one-screen version.

# reticle_act_sequence

> Run several actions in order in one round trip. Fill, fill, submit. Instead of paying a full turn for each step.

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

```json theme={"dark"}
{
  "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:

```json theme={"dark"}
{
  "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.

<Warning>
  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`](/tools-act-and-wait) on the final step, or with an
  [`reticle_assert`](/tools-assert), or you have proved nothing.
</Warning>

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

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

then

```json theme={"dark"}
{ "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`](/tools-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.

<Note>
  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.
</Note>