@reticlehq/server 3.2.0 → 3.4.0

package/docs/use-cases.mdx

@@ -0,0 +1,157 @@
+---
+title: 'Use cases: what people verify with Reticle'
+sidebarTitle: Use cases
+description: 'Verifying agent-built changes, security behaviour, accessibility and UX, performance, SEO basics, and driving the app as different users. What Reticle checks in each, with a call you can run.'
+icon: list-check
+---
+
+Reticle runs inside your app while it is running, so anything the app does (a request, a state change, a console line, a focus move, a route change, a performance entry) is something an agent can check and get a verdict on. People use it for more than "did my change work". This page covers the main uses. Each section lists what Reticle checks and gives one call you can run.
+
+Every predicate below is a `json` value you pass as `until` to `reticle_act_and_wait` (the consequence of an action) or as `predicate` to `reticle_assert` (a check with no action). The URLs, names and store paths are placeholders for your own. The full grammar is in [Predicates](/predicates).
+
+## Verifying agent-built changes
+
+This is what Reticle was built for: an agent says a change works, and Reticle checks it against the running app.
+
+- The request fired, returned the status you expected, and fired **once** (a double-submit is a `count` of 2).
+- Application state moved the way the UI says it did. A total on screen that disagrees with the store is a failure.
+- No console error appeared during the action.
+- A failure names the `file:line` to open (on React, and on any framework whose build plugin stamps source; see [Frameworks](/frameworks)).
+
+Click "Place order", then check all three at once:
+
+```json
+{
+  "kind": "allOf",
+  "predicates": [
+    { "kind": "net", "method": "POST", "urlContains": "/api/orders", "status": 201, "count": 1 },
+    { "kind": "state", "store": "cart", "path": "count", "equals": 0 },
+    { "kind": "console", "level": "error", "absent": true }
+  ]
+}
+```
+
+Once a journey has been driven, it is saved as a flow and replays with no model in the loop. `npx @reticlehq/server gate --since HEAD~1` fails unless a passing run covers every saved flow your edit touched.
+
+## Security checks
+
+This proves how your app behaves around security. It does not search for vulnerabilities, so it complements a vulnerability scanner rather than replacing one.
+
+- **Access control.** Signed in as a role that should be refused, the protected call returns `403` and the app shows the denial, not a success toast.
+- **Forbidden calls.** An endpoint that must not fire (an analytics beacon before consent, an admin API from a viewer's page) fires zero times: `{ "kind": "net", "urlContains": "/collect", "count": 0 }`.
+- **Secrets not rendered.** A value that must never reach the page is absent from its text. Separately, the SDK redacts credential-shaped values (tokens, API keys, passwords, card numbers) from captured request and response bodies, storage and state before they reach the agent, and shows them as `[REDACTED]`.
+- **CSP violations.** A Content Security Policy violation shows up as a console error (as a warning for report-only policies), so a CSP check needs nothing extra.
+
+As a viewer, click "Delete user" and require the refusal:
+
+```json
+{
+  "kind": "allOf",
+  "predicates": [
+    { "kind": "net", "method": "DELETE", "urlContains": "/api/admin/users", "status": 403 },
+    { "kind": "element", "query": { "role": "alert" }, "state": "visible" },
+    { "kind": "text", "contains": "sk_live_", "absent": true },
+    { "kind": "console", "contains": "Content Security Policy", "absent": true }
+  ]
+}
+```
+
+To check reachability for each role, see [Personas and simulation](#personas-and-simulation) below.
+
+## Accessibility and UX
+
+Reticle finds elements the way assistive technology does: by role and accessible name. That makes some accessibility behaviour directly checkable. For contrast, full screen-reader behaviour and complete WCAG coverage, pair it with an audit tool such as axe.
+
+- A control is reachable by its **role and accessible name**. An icon button with no name cannot be found with `{ "role": "button", "name": "Close" }`.
+- **Focus lands where it should.** When a dialog opens, focus moves into it (`state: "focused"`), and Reticle records focus dropping to `<body>` when a dialog closes.
+- **The keyboard works.** `press` with `Enter` or `Escape` fires the control's action, not just a mouse click. The [verify-keyboard-access](https://github.com/reticlehq/reticle/tree/main/skills/verify-keyboard-access) skill walks through it.
+- **Visible, enabled, checked, expanded, pressed and in-viewport** are all element states you can assert.
+
+A synthetic Tab key does not move focus in a browser, so Reticle cannot verify Tab order, and it reports that as unknown rather than as a pass.
+
+Open the "Delete project" dialog with `press` (`args: { "text": "Enter" }`) and require focus to move into it:
+
+```json
+{
+  "kind": "allOf",
+  "predicates": [
+    {
+      "kind": "element",
+      "query": { "role": "dialog", "name": "Delete project" },
+      "state": "visible"
+    },
+    { "kind": "element", "query": { "role": "button", "name": "Cancel" }, "state": "focused" }
+  ]
+}
+```
+
+## Performance and monitoring
+
+- **Request cardinality.** One keystroke in a debounced search sends one request, not one per character. The `duplicate-request` finding flags a write that fired more than once in a single action.
+- **Page performance entries.** The SDK records largest-contentful-paint, a running layout-shift total and long tasks as `perf` events, which you read with `reticle_observe { filters: ["perf"] }`. The layout-shift figure is a running sum without the windowing a Core Web Vitals CLS score uses, so it works for "no layout shift on load" and trends, not as an exact CWV number.
+- **Request timing.** Every captured request carries its duration in `reticle_observe { action: "network" }`.
+- **React render rate.** With the React adapter, the commit count is readable as the `__reticle_renders` store, so a component that re-renders continuously while the screen looks idle shows up.
+- **Recurring re-verification.** `npx @reticlehq/server verify <url>` replays your saved flows against a dev server or a staging/preview deployment and exits non-zero on a failure, so it runs in CI or on a schedule. The SDK refuses to connect in a production build, so this covers environments you control, not live production traffic.
+
+Type "shoes" into a debounced search box and require exactly one request:
+
+```json
+{ "kind": "net", "method": "GET", "urlContains": "/api/search", "count": 1 }
+```
+
+## SEO checks
+
+Reticle sees the rendered page and the routes, so it covers the behavioural half of SEO. It does not read `<head>` meta tags or score a page, so pair it with an SEO crawler for those.
+
+- `reticle_look { action: "page" }` reports the document `title` and the current route.
+- **Headings and links.** The page's heading exists under its accessible name, and `reticle_look { action: "find", by: "role", value: "link", attrs: ["href"] }` lists every link with its `href`.
+- **Redirects and routing.** A legacy URL lands on the right path: `{ "kind": "route", "pathname": "/pricing" }`.
+- **Broken links and dead controls.** `reticle_verify { action: "crawl" }` drives every reachable control and reports failed requests, console errors and controls that do nothing.
+
+After navigating to the old `/plans` URL, require the redirect and the page's main heading:
+
+```json
+{
+  "kind": "allOf",
+  "predicates": [
+    { "kind": "route", "pathname": "/pricing" },
+    { "kind": "element", "query": { "role": "heading", "name": "Pricing" }, "state": "visible" }
+  ]
+}
+```
+
+## Personas and simulation
+
+- **Drive the app as a user.** `explore` takes a persona in plain words, drives that whole journey with a model inside the daemon, and saves what it drove as a flow that later replays with no model.
+- **One context per role.** `reticle_lease { action: "acquire" }` opens an isolated browser context (its own cookies, storage and DOM) and can seed storage or cookies first, so an admin and a viewer drive the same app side by side. Reach it with `reticle_run`, or use `reticle verify <url> --storage-state <file>` from a terminal.
+- **Reachability testing.** Signed in as a role, a control that role must not have is absent, and the call behind it never fires. `reticle_verify { action: "coverage" }` lists the controls you have and have not driven this session.
+- **Multi-agent runs.** Several agents lease contexts from one shared headless Chromium, capped and queued, instead of starting a browser each. See [Multi-agent](/multi-agent-testing).
+
+Have Reticle drive a first-time user's journey and record it:
+
+```bash
+npx @reticlehq/server verify http://localhost:3000 --explore --persona "a new user who signs up and creates a first project"
+```
+
+Then, signed in as a viewer, check what that role can reach:
+
+```json
+{
+  "kind": "allOf",
+  "predicates": [
+    { "kind": "element", "query": { "role": "button", "name": "Invite member" }, "absent": true },
+    { "kind": "net", "urlContains": "/api/billing", "count": 0 }
+  ]
+}
+```
+
+## Pairs well with
+
+Reticle checks what your app does from inside it. Some jobs belong to other tools, and it works alongside them:
+
+- **Pixel-level visual diffs:** a visual testing tool. Reticle can take screenshots, but its verdicts come from behaviour, not pixels.
+- **Driving sites you don't own, or a cross-browser matrix:** Playwright. Reticle needs its dev-only SDK in the app, and its driven browser is Chromium.
+- **Full WCAG audits:** axe or a similar audit tool.
+- **Vulnerability discovery:** a security scanner.
+
+What Reticle cannot see yet: IndexedDB, Web Workers, closed shadow roots and cross-origin iframes. When part of the page was out of reach, the verdict carries a `coverage` note, so a pass reads as "nothing failed in the part I could see". When the evidence cannot decide, the verdict is `unknown`, which is never counted as a pass.

package/docs/vs-screenshots.mdx

@@ -80,11 +80,11 @@ Those are real bugs and structural reads can miss them. Reticle has `reticle_scr
 
 The argument is not "screenshots are bad". It is that a screenshot cannot answer "did the code work", and that is the question an AI coding agent needs answered on every change.
 
-## The honest limits
+## What is measured, and what is not
 
-We have not proven that Reticle makes agents _fix_ more bugs. A controlled test did not show a fix-rate improvement; the benchmark was confounded and we are still working on measuring it properly.
+What is measured is detection: 10 of 10 injected regressions caught with zero false alarms, against 9 and 8 for the alternatives, and one false green against a Playwright script's 29 over an 88-bug registry.
 
-What is measured is detection: 10 of 10 injected regressions caught with zero false alarms, against 9 and 8 for the alternatives.
+What is not established is that Reticle makes agents _fix_ more bugs. A fix-loop test on a small fixture found the same fix rate with and without it; [Why Reticle](/why-reticle#what-the-fix-rate-test-measured) says what that test could and could not show.
 
 ## FAQ
 

package/docs/what-is-recorded.md

@@ -0,0 +1,62 @@
+---
+title: What is recorded
+description: What Reticle keeps on your machine, what is redacted, and what it takes for any of it to leave.
+---
+
+Reticle drives your app and reads what it did. That means it holds real content from real pages, so this page says exactly what it keeps, where it keeps it, and what it takes to make any of it leave.
+
+If you read one line: **a verdict is entirely local and needs no account.** Nothing from your project is sent anywhere until you run `reticle login` and `reticle link`. Without them there is nowhere for it to go. (Anonymous usage counts, which carry nothing from your app, are separate and described in [Telemetry](telemetry.md).)
+
+## On your machine
+
+Everything lands in `.reticle/` in your project, and it is yours. Three kinds of thing:
+
+|  | what it is | what is in it |
+| --- | --- | --- |
+| **runs** | a verdict and its evidence | what was claimed, whether it held, the request or state change that decided it, and the `file:line` of the element driven |
+| **flows** | a journey you drove, saved so it can be replayed | the steps, the anchors they resolve by, and the values that were typed |
+| **memory** | what this project has learned across sessions | intents you declared, envelopes of normal behaviour, notes about anchors that drift |
+
+`.reticle/` splits into a part meant for git and a part meant to stay local. Flows are the part worth committing: a saved flow is a regression test. Evidence is the part that is not.
+
+## What is redacted, and what is not
+
+**Credential-shaped fields are redacted when a flow is saved.** A value typed into a field whose name looks like a secret is replaced with `<redacted: supply at replay>`, and replay reads the real value from `RETICLE_SECRET_<FIELD>` at run time. It keys off the field's name across every anchor kind (a testid, an accessible name, a signal), so an app without test ids is covered too.
+
+**It is name-based, and that is the limit worth knowing.** It redacts a password. It does not redact a customer's name typed into a search box, because nothing about that field says "secret". A flow records the journey you actually drove.
+
+So: **drive staging.** Not because the risk is large, but because it is real and avoiding it is free.
+
+Network bodies are **not** captured by default. Page content that reaches a verdict is the element text and attributes the assertion needed, not a copy of the DOM.
+
+## What leaves, only if you ask
+
+`reticle login` signs this machine in. `reticle link` binds one repo to one cloud project. Until both have happened, or `RETICLE_API_KEY` is set in the environment, `reticle push` has nothing to talk to and the sync path is a no-op. The code calls this the no-phone-home default. A key in the environment is how CI syncs with no login and no link, and it goes to the hosted service unless `RETICLE_CLOUD_URL` names another host.
+
+Once linked, you choose what syncs:
+
+```bash
+npx @reticlehq/server config --runs on|off --flows on|off --memory on|off
+```
+
+## Telemetry, which is separate from all of the above
+
+The CLI sends anonymous usage events: event names and a random installation id. No code, no page content, no URLs from your app. It is how we know which parts of the product are reached at all.
+
+```bash
+RETICLE_TELEMETRY=0          # this shell
+DO_NOT_TRACK=1               # the convention, honoured
+npx @reticlehq/server telemetry disable   # this machine, permanently
+```
+
+Feedback is the only free text that ever leaves, it is never collected passively, and `RETICLE_FEEDBACK=0` disables it.
+
+## What `init` writes to your project
+
+Run it with `--dry-run` and it prints the whole plan without writing anything:
+
+```bash
+npx @reticlehq/server init --dry-run
+```
+
+`--app <dir>` picks which app in a monorepo. `--no-mcp` skips registering the MCP server with your agents and skips the agent rule files with it. `--files-only` writes the files and stops, without booting your dev server.

package/docs/what-is-reticle.mdx

@@ -1,7 +1,7 @@
 ---
 title: What is Reticle?
 sidebarTitle: What is Reticle
-description: Reticle is a verification layer for AI coding agents. It runs a dev-only SDK inside your running web app so an agent can prove a change works, instead of guessing. What it is, what it is not, and what it needs.
+description: Reticle is a verification layer for AI coding agents. It runs a dev-only SDK inside your running web app so an agent can prove a change works, instead of guessing. What it is, where it fits beside other tools, and what it needs.
 icon: circle-question
 ---
 
@@ -12,37 +12,33 @@ It exists because an agent that writes code cannot otherwise tell whether that c
 ## How it works, in three parts
 
 1. **An SDK inside the app.** Dev-only, stripped from production builds, added by a build plugin. It instruments the DOM, network, routing, console, animations, and your state library.
-2. **A local bridge.** The SDK connects over a WebSocket to a daemon on your machine. The daemon never starts or manages your dev server. It attaches to the app that is running. If none is, the agent is the one told to start it, using your project's own dev script, in the background, and saying so.
-3. **An MCP server.** The daemon exposes the app to your agent as tools. `reticle_snapshot` to look, `reticle_act_and_wait` to act and prove in one call, `reticle_state` and `reticle_network` to observe, `reticle_assert` to check.
+2. **A local bridge.** The SDK connects over a WebSocket to a daemon on your machine, bound to `127.0.0.1`. The daemon never manages your dev server; it attaches to the app that is running. On first setup, `npx @reticlehq/server init` starts the dev server with your project's own dev script and opens the app.
+3. **An MCP server.** The daemon exposes the app to your agent as tools. `reticle_look` to look, `reticle_act_and_wait` to act and prove in one call, `reticle_observe` to read what the app did, `reticle_assert` to check.
 
-Everything stays on your machine. No application code, DOM, network traffic, or console output leaves it.
+Your app's data stays on your machine: no application code, DOM, network traffic, state or console output leaves it. Anonymous usage counts are sent by default and can be [turned off](/telemetry).
 
-## What Reticle is not
+## Where it fits
 
-This is the section most people need, because Reticle sits next to several familiar categories without being any of them.
+Reticle sits next to several familiar categories, and it works alongside each of them.
 
-**Not a browser automation framework.** Playwright, Cypress and Selenium drive a browser from the outside and are excellent at it. Reticle runs inside the page you already have open. If you want to script a browser, use Playwright. Reticle is what an agent uses to answer "did the thing I just changed actually work?"
+**Browser automation.** Playwright, Cypress and Selenium drive a browser from the outside. Reticle runs inside the page you already have open and answers "did the thing I just changed actually work?" Playwright remains the tool for sites you don't own and for a cross-browser matrix.
 
-**Not a replacement for your test suite.** Unit and integration tests still do their job. Reticle covers the layer they structurally cannot reach: behaviour that only exists when the whole application runs. Many teams use both, and Reticle is often the thing that catches a suite passing over a broken app.
+**Your test suite.** Unit and integration tests keep doing their job. Reticle covers the layer they cannot reach: behaviour that only exists when the whole application runs, which is often where a suite passes over a broken app.
 
-**Not a screenshot or visual regression tool.** It can take screenshots, but the point is that it does not need to. Verdicts come from predicates over real events, a request with a status, a state path, a signal your code fired, so they do not break when a button moves four pixels. If pixel-perfect visual diffing is your goal, a dedicated visual testing service fits better.
+**Visual testing.** Reticle can take screenshots, but its verdicts come from predicates over real events (a request with a status, a state path, a signal your code fired), so they do not break when a button moves four pixels. For pixel-level diffs, pair it with a visual testing tool.
 
-**Not a monitoring or observability product.** Reticle is a development-time tool aimed at localhost. It is not an APM, not error tracking, and it does not watch production.
+**Security, accessibility, performance and SEO.** Reticle checks how your running app behaves in each: access control by role, calls that must never fire, focus and keyboard behaviour, request counts and long tasks, titles, links and redirects. It pairs with a vulnerability scanner, a full WCAG audit tool such as axe, and an SEO crawler. [Use cases](/use-cases) has what each check covers.
 
-**Not an accessibility auditor.** `reticle_snapshot` addresses elements by role and name, which is not the same as auditing contrast, focus order, or screen reader behaviour. Use a dedicated accessibility tool for that.
+**Monitoring.** Reticle runs against environments you control (a dev server, a staging or preview deployment) and replays saved flows in CI. The SDK refuses to connect in a production build, so it complements an APM or error tracker rather than watching live traffic.
 
-**Not an AI model, and not an agent.** Reticle has no model of its own and makes no decisions. It gives an agent you already use a way to see the running app. Your agent, your model, your keys.
+**Your agent.** Reticle has no model of its own for the verify loop. It gives the agent you already use a way to see the running app. Your agent, your model, your keys. (`explore` can drive a journey for you with a model inside the daemon; see [Autodrive](/autodrive).)
 
-**Not a hosted service that receives your application data.** The daemon runs on your machine and the SDK runs in your browser. Anonymous product analytics are sent unless you opt out, and they never include your code or your application's data. See the [Telemetry Policy](https://www.reticle.sh/legal/telemetry).
-
-**Not a way to make a failing check pass.** A verdict of `unknown` means Reticle drove the app and could not tell. It is deliberately not rounded up to a pass, because a verification tool that flatters you is worse than none.
+**The verdict.** A verdict of `unknown` means Reticle drove the app and could not tell. It is deliberately not rounded up to a pass.
 
 ## What Reticle needs
 
-Honest constraints, so you can tell in a minute whether it fits:
-
-- **A web application you can run locally**, with its dev server. Reticle attaches; it does not start one.
-- **A build step it can hook**, or two lines added by hand. Vite, Next.js, Remix and Astro are proven by gates in the repository. The SDK is framework agnostic and usually connects elsewhere, with reduced source mapping.
+- **A web application you can run**, with a dev build. `init` starts its dev server for you.
+- **A build step it can hook**, or two lines added by hand. [Frameworks](/frameworks) lists what is proven for each.
 - **An agent that speaks MCP.** Claude Code, Cursor, Codex, Copilot, Windsurf, OpenCode and others.
 - **Node 20 or newer.**
 
@@ -59,5 +55,6 @@ Side by side with the tools people ask about most:
 ## Where to go next
 
 - [Quickstart](/quickstart) gets a real verdict out of your own app in about five minutes.
-- [Why Reticle](/why-reticle) is the argument, with the evidence and the cases where it loses.
+- [Why Reticle](/why-reticle) is the argument, with the evidence and what pairs well with it.
+- [Use cases](/use-cases) covers what people verify with it.
 - [For agents](/for-agents) is written for the agent rather than for you.

package/docs/why-reticle.mdx

@@ -63,37 +63,30 @@ Observing one real dashboard once, with no bug involved:
 That last column is the one that matters more than the token counts. The other tools can _describe_ what a page looks like. Only Reticle can check whether the thing the app itself considers success actually happened.
 
 <Card title="How every number was measured" icon="chart-column" href="/benchmarks">
-  The full method, the raw data, and the scenarios where Reticle comes second.
+  The full method, the raw data, and the scenarios where the tools tie.
 </Card>
 
-## Where Reticle loses
+On raw cost per glance, Chrome DevTools MCP is cheaper: 758 tokens against 815. It catches fewer bugs, which is why the efficiency column favours Reticle.
 
-A benchmark that only shows you the wins is an advertisement wearing a lab coat. Ours doesn't.
+## What the fix-rate test measured
 
-- **Sites you don't own.** Reticle needs a dev-only SDK inside the app. If you're driving a third party's website, use Playwright. That is what it's for, and it's excellent at it.
-- **Pixels.** Reticle reads the program, not the screen. If your bug is "the button is three pixels too far left", Reticle is the wrong instrument.
-- **Chrome DevTools MCP is cheaper per look.** 758 tokens against our 815. It catches fewer bugs, so the efficiency works out in our favour, but on raw cost per glance it wins.
+We ran a fix-loop ablation: agents fixed 8 bugs injected into a small fixture app, with Reticle and without it, on a strong model and on a weaker one. **It did not show a fix-rate improvement at either tier.** The strong model fixed 8 of 8 in both conditions and the weaker one 7 of 8 in both, and the Reticle arm made roughly five to six times the tool calls, because driving an app costs more than reading a few short files.
 
-## What we have not proven
+The test cannot settle the question in either direction, and the reasons are specific: the fixture is small enough to read whole, several injected bugs were labelled by a comment on the changed line, and "fixed" was checked by a string disappearing rather than by the app behaving. One case pointed each way. The weaker model without Reticle claimed a fix it never applied, and the live re-check caught that with Reticle; with Reticle, the same model over-edited a stylesheet the string check scored as a pass. The full log is in [`bench/fix-loop/results.md`](https://github.com/reticlehq/reticle/blob/main/bench/fix-loop/results.md).
 
-Being honest here costs us something, and we'd rather pay it than have you find out later.
+A separate, smaller measurement of the source pointer alone found the same fix rate with and without it (6 of 6) and fewer tool calls with it (12 against 22). The pointer removed the search; it did not make the agent more capable.
 
-We ran a controlled test of whether an agent equipped with Reticle _fixes_ more bugs than one without it. **It did not show a fix-rate improvement.** The benchmark was confounded in ways we can point at, and we don't consider the question settled. But we are not going to claim a number we didn't measure.
+That is what Reticle is designed to improve: not the agent, but the verdict it reports. A broken build reads as broken, a failure arrives with the evidence and the `file:line`, and "I couldn't tell" is reported as that. In the 88-bug head-to-head against a Playwright script, Reticle reported one false green where the script reported 29.
 
-What Reticle demonstrably does is catch failures that are invisible to the alternatives, and hand back the file and line to go fix. Whether that translates into a better fix rate is a separate question, and we're still working on measuring it properly.
+## When to use it
 
-## When you should use it
+You own the app, an agent edits it, and you want the agent to prove its work rather than assure you of it. It needs a dev build it can instrument, and React (and any framework whose build plugin stamps source) adds source pointers on top. [Use cases](/use-cases) covers what people check with it beyond change verification, from access control to accessibility.
 
-<CardGroup cols={2}>
-  <Card title="A good fit" icon="circle-check">
-    You own the app. An agent edits it. You want the agent to prove its work rather than assure you
-    of it. React gets you source pointers on top.
-  </Card>
-  <Card title="A bad fit" icon="circle-xmark">
-    You're testing a site you don't control, you need pixel-level visual regression, or your app has
-    no dev build to instrument.
-  </Card>
-</CardGroup>
+## Pairs well with
+
+- **Playwright** for driving sites you don't own and a cross-browser matrix. Reticle needs its dev-only SDK inside the app.
+- **A visual testing tool** for pixel-level regression. Reticle reads the program, not the screen, so "the button is three pixels too far left" is a job for pixels.
+- **axe** for full WCAG audits, and **a security scanner** for vulnerability discovery.
 
 ## The one-sentence version
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@reticlehq/server",
-  "version": "3.2.0",
-  "description": "Reticle bridge + MCP server. Hosts the browser WS endpoint and exposes MCP tools to the coding agent.",
+  "version": "3.4.0",
+  "description": "Reticle CLI, bridge and MCP server: a coding agent drives your running web app from the inside and gets a verdict with evidence, for change verification, access control, accessibility, performance and SEO checks.",
   "type": "module",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",
@@ -19,24 +19,24 @@
     }
   },
   "dependencies": {
-    "@modelcontextprotocol/sdk": "^1.30.0",
+    "@modelcontextprotocol/sdk": "^1.30.1",
     "ws": "^8.21.3",
     "zod": "^3.24.1",
     "zod-to-json-schema": "^3.24.0",
-    "@reticlehq/browser": "3.2.0",
-    "@reticlehq/engine": "3.2.0",
-    "@reticlehq/init": "3.2.0",
-    "@reticlehq/core": "3.2.0",
-    "open-verification": "1.0.0"
+    "@reticlehq/browser": "3.4.0",
+    "@reticlehq/init": "3.4.0",
+    "@reticlehq/engine": "3.4.0",
+    "open-verification": "1.0.0",
+    "@reticlehq/core": "3.4.0"
   },
   "devDependencies": {
     "@types/pngjs": "^6.0.5",
     "@types/ws": "^8.5.13",
-    "yaml": "^2.9.0"
+    "yaml": "^2.9.1"
   },
   "optionalDependencies": {
     "pixelmatch": "^7.2.0",
-    "playwright": "^1.62.1",
+    "playwright": "^1.63.0",
     "pngjs": "^7.0.0"
   },
   "license": "FSL-1.1-ALv2",
@@ -60,6 +60,7 @@
     "mcp",
     "ai-agents",
     "testing",
+    "verification",
     "cli"
   ],
   "reticle": {

package/dist/judgement/capsule/minimize.d.ts

@@ -1,12 +0,0 @@
-/**
- * Bug-capsule minimization — first cut: prefix-trim. A recorded flow that fails is often mostly setup;
- * the capsule should be the SMALLEST flow that still reproduces the failure, so a regression flow stays
- * fast and legible. Prefix-trim drops leading steps while the failure persists — the cheap, deterministic
- * v1 (delta-debugging over arbitrary subsets is a later refinement). The `stillFails` predicate is
- * injected (a real replay), so this stays pure and unit-testable.
- */
-/**
- * Return the shortest trailing sub-flow that still fails, by removing leading steps one at a time while
- * `stillFails` holds. Never trims below one step. Deterministic given a deterministic predicate.
- */
-export declare function prefixTrim<T>(steps: readonly T[], stillFails: (candidate: readonly T[]) => Promise<boolean>): Promise<T[]>;

package/dist/judgement/capsule/minimize.js

@@ -1,22 +0,0 @@
-/**
- * Bug-capsule minimization — first cut: prefix-trim. A recorded flow that fails is often mostly setup;
- * the capsule should be the SMALLEST flow that still reproduces the failure, so a regression flow stays
- * fast and legible. Prefix-trim drops leading steps while the failure persists — the cheap, deterministic
- * v1 (delta-debugging over arbitrary subsets is a later refinement). The `stillFails` predicate is
- * injected (a real replay), so this stays pure and unit-testable.
- */
-/**
- * Return the shortest trailing sub-flow that still fails, by removing leading steps one at a time while
- * `stillFails` holds. Never trims below one step. Deterministic given a deterministic predicate.
- */
-export async function prefixTrim(steps, stillFails) {
-    let kept = [...steps];
-    while (kept.length > 1) {
-        const trimmed = kept.slice(1);
-        if (await stillFails(trimmed))
-            kept = trimmed;
-        else
-            break;
-    }
-    return kept;
-}

package/dist/judgement/outcome/predicate-to-expect.d.ts

@@ -1,44 +0,0 @@
-/**
- * The assertion the agent MADE, in the shape a saved flow can keep.
- *
- * `reticle_act_and_wait { until }` is how agents assert — nearly every asserting call in a day of telemetry
- * carried an `until`. `compileActStep` recorded only the ACTION, so a flow saved after an asserted
- * drive came back graded `assertion-free`: "performs actions but asserts no observable consequence —
- * it will pass even if the feature is broken." The agent had already said what success meant;
- * Reticle discarded it and then warned the agent that the flow asserts nothing.
- *
- * That is the regression-suite story failing at its last step. "Record once, verify forever" is only
- * worth anything if the recorded flow can go RED, and locally 32 of 39 saved flows cannot.
- *
- * The inverse of `successToPredicate`. Only the kinds FlowExpect can express are carried: `settled`
- * is a wait rather than a claim, and `animation`/`anyOf`/`not` have no representation at all (`route` gained one — see its case below).
- * Inventing one would write an assertion into the file that the agent never made, which is worse
- * than recording none — a flow that asserts something nobody chose is a false green with extra steps.
- */
-import type { FlowExpect } from '@reticlehq/core';
-import type { Predicate } from '@reticlehq/engine/question/predicate/predicate.js';
-export declare function predicateToExpect(predicate: Predicate): FlowExpect | undefined;
-/**
- * The subset a REPLAY actually enforces.
- *
- * The rule has never changed: never write an assertion into a flow file that nothing evaluates. A
- * flow reporting `grade: "asserted"` while its assertion is read by no one is a false green, in the
- * feature whose entire purpose is preventing them.
- *
- * What changed is the SET. This kept only `element.testid` and `state`, because for a long time
- * those were the only kinds replay checked — and the note here said lifting it "requires replay to
- * evaluate them per step". Replay now does exactly that: `assertStepExpect` compiles every
- * remaining kind through `successToPredicate` and waits on it. The condition was met and the filter
- * was not updated, so the two drifted.
- *
- * That drift had a cost, and it fell on the agent. `reticle_act_and_wait { until }` IS the agent
- * saying what success means, and `net` is overwhelmingly what it says. Every one of those was
- * discarded at capture, so an agent-recorded flow reached disk assertion-free BY CONSTRUCTION and
- * `reticle_verify` then correctly called it `unverifiable` — the record → save → verify path
- * completing all the way to a run that could never be a pass. Found by driving it.
- *
- * The list below is exactly what `successToPredicate` reads, including an element located by
- * role or name. A testid is also asserted directly against the DOM by the step runner. Anything
- * it cannot compile is still dropped.
- */
-export declare function enforcedOnReplay(expect: FlowExpect | undefined): FlowExpect | undefined;