@reticlehq/server 2.6.0 → 2.8.0

package/docs/tools-act-sequence.mdx

@@ -0,0 +1,120 @@
+---
+title: reticle_act_sequence
+description: Run several actions in order in one round trip. Fill, fill, submit. Instead of paying a full turn for each step.
+icon: layer-group
+---
+
+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
+{
+  "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
+{
+  "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
+{
+  "steps": [
+    { "ref": "e101", "action": "fill", "args": { "value": "admin@reticle.dev" } },
+    { "ref": "e102", "action": "fill", "args": { "value": "reticle" } }
+  ]
+}
+```
+
+then
+
+```json
+{ "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>

package/docs/tools-act.mdx

@@ -0,0 +1,82 @@
+---
+title: reticle_act
+description: Perform an action without checking the result. Useful for setup steps, and dangerous as a final step, because ok means dispatched, not worked.
+icon: hand-pointer
+---
+
+`reticle_act` clicks, fills, types, selects, drags. It does exactly one thing and makes exactly one promise: the event was dispatched.
+
+<Warning>
+  `reticle_act` **proves nothing**. If the action is supposed to cause something, use
+  [`reticle_act_and_wait`](/tools-act-and-wait) and get the verdict in the same call. A drive that
+  ends on `reticle_act` has no result.
+</Warning>
+
+## Example
+
+```json
+{ "ref": "e102", "action": "fill", "args": { "value": "reticle" } }
+```
+
+Real response:
+
+```json
+{
+  "since": 28123,
+  "inputMode": "synthetic",
+  "dispatched": true,
+  "settled": false,
+  "settleReason": "timeout",
+  "result": {
+    "ok": true,
+    "ref": "e102",
+    "action": "fill",
+    "testid": "login-password",
+    "component": "Login",
+    "role": "textbox",
+    "name": "Password",
+    "effect": {
+      "visible": false,
+      "focusMoved": "null->e102",
+      "valueChanged": true,
+      "domMutatedWithin": 15
+    },
+    "source": { "file": "src/components/Login.tsx", "line": 59, "column": 8 }
+  }
+}
+```
+
+## Actions
+
+`click` · `dblclick` · `hover` · `focus` · `blur` · `fill` · `type` · `clear` · `select` · `check` · `uncheck` · `submit` · `press` · `upload` · `scrollIntoView` · `drag` · `webmcp`
+
+| Action           | Arguments                                                       |
+| ---------------- | --------------------------------------------------------------- |
+| `fill`, `select` | `{ value }`                                                     |
+| `type`, `press`  | `{ text }`. For `press`, the key _name_, e.g. `Escape` or `Tab` |
+| `drag`           | `{ toRef }`. The ref to drop onto                               |
+| `upload`         | file arguments                                                  |
+
+## 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`.
+
+## `inputMode` tells you how real the input was
+
+`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.
+
+<Warning>
+  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.
+</Warning>

package/docs/tools-assert.mdx

@@ -0,0 +1,70 @@
+---
+title: reticle_assert
+description: Evaluate a predicate against what the app actually did, and get a verdict. Including a clear explanation when it fails.
+icon: gavel
+---
+
+`reticle_assert` is the second of the two tools that produce a verdict. It takes the same predicate grammar as [`reticle_act_and_wait`](/tools-act-and-wait) and evaluates it against what already happened.
+
+## A real failure
+
+Failures are more instructive than passes, so here is one. I asserted a route change to `/` on a page that was already at `/`:
+
+```json
+{ "predicate": { "kind": "route", "path": "/" } }
+```
+
+```json
+{
+  "verified": "no",
+  "verifiedReason": "assertion_failed",
+  "because": "the declared consequence did not hold",
+  "pass": false,
+  "failureReason": "no route change observed",
+  "observed": "no route change in the window",
+  "expected": "a route change to /",
+  "assertion": "route.changed",
+  "source": "src/components/Login.tsx:81"
+}
+```
+
+<Warning>
+  Read `assertion: "route.changed"` carefully. The `route` predicate asserts that the route
+  **changed**, not that it currently equals a value. Asserting the route you are already on will
+  always fail. This catches people out, and the response says so in `expected` rather than leaving
+  you to work it out.
+</Warning>
+
+Note also `expected` and `observed` side by side. A verdict that says only "failed" makes you go digging; this one tells you what it wanted, what it saw, and where in your source the relevant element lives.
+
+## Arguments
+
+| Argument                 | What it does                                               |
+| ------------------------ | ---------------------------------------------------------- |
+| `predicate` (or `until`) | `{ kind, ...fields }`                                      |
+| `timeout_ms`             | If above zero, wait this long before failing               |
+| `since`                  | Cursor from a prior act. Scope to events after that action |
+
+## Scope it with `since`
+
+Without `since`, an assertion evaluates against the recent buffer, which may contain events from before your action. That can pass for the wrong reason. The request you are asserting fired, but it fired two clicks ago.
+
+```json
+{ "predicate": { "kind": "net", "method": "POST" }, "since": 28123 }
+```
+
+The cursor comes from the preceding `reticle_act` response. Use it whenever you are asserting something an action was supposed to cause.
+
+## When to use assert over act_and_wait
+
+Use [`reticle_act_and_wait`](/tools-act-and-wait) when you are performing the action. Use `reticle_assert` when:
+
+- you are checking a precondition before acting;
+- the state was reached by several actions and you want one verdict over the lot;
+- you want to assert something extra about an action you already ran, using its `since` cursor.
+
+<Note>
+  `verified: "unknown"` means Reticle could not tell. It is not a pass, and it is not a failure, it
+  is a statement that the evidence was insufficient. Report it as unknown rather than rounding it in
+  either direction.
+</Note>

package/docs/tools-console.mdx

@@ -0,0 +1,59 @@
+---
+title: reticle_console
+description: The console log, filtered by level, and an empty result that tells you it is a real reading rather than a missing one.
+icon: terminal
+---
+
+```json
+{ "limit": 3 }
+```
+
+Real response from a page with a clean console:
+
+```json
+{
+  "logs": [],
+  "buffer": {
+    "held": 15,
+    "dropped": 571,
+    "note": "event buffer evicted older events (age/size cap): a negative result here may be a false negative; the evidence may have expired. Grade sooner or widen the buffer."
+  },
+  "observed": true,
+  "note": "no console lines; the observation ran and found none, which is a result, not a missing reading",
+  "cost": { "bytes": 340, "tokens": 85 }
+}
+```
+
+## The empty result is the interesting one
+
+An empty array is ambiguous in almost every tool that returns one. Did nothing happen, or did the observation not run? Reticle answers both:
+
+- **`observed: true`** with that `note`. The observation ran and genuinely found nothing. You may treat a clean console as a fact.
+- **`buffer.dropped: 571`**, older events were evicted. If you are asking about something from a while ago, the honest answer is "not in what I still have", not "it didn't happen".
+
+Read both fields together. `observed: true` with a large `dropped` count means _recently_ clean, which is usually what you wanted but is not the same as _always_ clean.
+
+## Arguments
+
+| Argument          | What it does                                         |
+| ----------------- | ---------------------------------------------------- |
+| `level`           | `log` · `warn` · `error` · `info`                    |
+| `limit`           | Most recent N. Older matches are dropped and counted |
+| `actionId`        | Only lines attributed to one action                  |
+| `since` / `until` | Cursors from a prior act                             |
+
+## The check worth making by default
+
+Plenty of features "work" while quietly throwing. Assert the clean console as part of the action rather than checking afterwards:
+
+```json
+{ "ref": "e103", "action": "click", "until": { "kind": "console", "absent": true } }
+```
+
+That fails if the click succeeds _and_ logs an error, which is exactly the case a human reviewer tends to wave through.
+
+<Tip>
+  `level: "error"` is the fast triage read. If it comes back empty with `observed: true`, stop
+  looking at the console and go look at [`reticle_network`](/tools-network) or
+  [`reticle_state`](/tools-state) instead.
+</Tip>

package/docs/tools-inspect.mdx

@@ -0,0 +1,85 @@
+---
+title: reticle_inspect
+description: Everything about one element. Accessibility properties, geometry, computed styles, design tokens, React component stack, and the exact source file and line.
+icon: crosshairs
+---
+
+`reticle_query` finds elements. `reticle_inspect` tells you everything about one of them. It is the tool that turns a finding into an edit, because it ends with a file and a line number.
+
+## Example
+
+```json
+{ "ref": "e20" }
+```
+
+Real response:
+
+```json
+{
+  "ref": "e20",
+  "role": "button",
+  "name": "Compose",
+  "visible": true,
+  "source": "src/components/Sidebar.tsx:41",
+  "tag": "button",
+  "occluded": false,
+  "states": ["present", "visible", "enabled"],
+  "box": { "x": 14, "y": 211.75, "width": 219, "height": 37.5 },
+  "styles": {
+    "color": "rgb(147, 152, 168)",
+    "backgroundColor": "rgba(0, 0, 0, 0)",
+    "opacity": "1",
+    "cursor": "pointer",
+    "display": "flex",
+    "visibility": "visible"
+  },
+  "theme": {
+    "colorToken": "--muted",
+    "colorTokens": ["--muted"],
+    "backgroundToken": null,
+    "backgroundTokens": [],
+    "offTheme": false,
+    "tokenCount": 17,
+    "themeScope": ":root"
+  },
+  "component": {
+    "componentStack": ["Sidebar", "App", "QueryClientProvider"],
+    "source": { "file": "src/components/Sidebar.tsx", "line": 41, "column": 8 }
+  }
+}
+```
+
+## What each block is for
+
+**`component`** is the payoff. The stack `["Sidebar", "App", "QueryClientProvider"]` tells your agent where this element lives in the tree, and `source` tells it which file to open. This needs `@reticlehq/react`; without it you still get everything else.
+
+**`theme`** catches a bug class most tools cannot see. `colorToken: "--muted"` means this colour came from your design system. `offTheme: false` means nothing here is a hardcoded hex that slipped past review. An agent that pastes `color: #939AA8` instead of using the token produces a change that looks identical and quietly forks your design system. This field is how that gets caught.
+
+Read `colorTokens` rather than `colorToken` when it matters. Design systems routinely give several tokens the same value, and the singular field is `null` whenever more than one matches, because naming an arbitrary winner is worse than admitting the palette cannot tell them apart. `themeScope` says which theme the reading was taken under, so two inspects either side of a theme toggle are comparable instead of quietly contradictory.
+
+**`occluded`** is the difference between "visible" and "actually clickable". An element can be present, visible and enabled while sitting under a modal overlay. `states` will look perfect; `occluded: true` is the honest answer.
+
+**`box`** is geometry in CSS pixels. Useful for layout assertions and for working out whether something is off-screen rather than hidden.
+
+## When to reach for it
+
+<CardGroup cols={2}>
+  <Card title="A click did nothing" icon="hand-pointer">
+    Check `occluded` and `states` before assuming the handler is broken. Very often the handler is
+    fine and something is sitting on top of it.
+  </Card>
+  <Card title="You need to edit the code" icon="file-pen">
+    `component.source` is the file and line. This is the fastest path from symptom to diff.
+  </Card>
+  <Card title="A style looks wrong" icon="palette">
+    `theme.offTheme` tells you whether the value came from your tokens or from somebody's clipboard.
+  </Card>
+  <Card title="Layout is suspicious" icon="ruler">
+    `box` gives you real geometry, no screenshot and no vision model required.
+  </Card>
+</CardGroup>
+
+<Note>
+  `inspect` returns one element in detail. If you find yourself inspecting six things in a row, you
+  probably want [`reticle_query`](/tools-query) with `attrs` instead, one call, six answers.
+</Note>

package/docs/tools-navigate.mdx

@@ -0,0 +1,63 @@
+---
+title: reticle_navigate
+description: Move the connected tab to a URL or reload it, and understand why ok does not mean the page arrived.
+icon: compass
+---
+
+```json
+{ "url": "/deployments" }
+```
+
+Real response:
+
+```json
+{
+  "ok": true,
+  "url": "http://localhost:4312/deployments",
+  "confirmed": false,
+  "note": "ok means the navigation was DISPATCHED, not that the page arrived. The SDK is torn down by the navigation itself, so nothing here can see the new document. Call reticle_sessions to confirm a session reconnected at the new URL before acting; if none appears, the page did not load or is not instrumented."
+}
+```
+
+## `confirmed: false` is the honest part
+
+A full navigation destroys the document the SDK was living in. Reticle cannot report on the new page from inside the old one, because the old one no longer exists. So it tells you what it actually knows: the navigation was dispatched.
+
+Most tools would return `ok: true` and let you assume arrival. When the page then fails to load, or loads without instrumentation, you get a confusing cascade of "element not found" errors several calls later, with nothing pointing at the real cause.
+
+## The pattern after navigating
+
+```json
+{ "url": "/deployments" }
+```
+
+then confirm a session reconnected:
+
+```json
+{}
+```
+
+with [`reticle_sessions`](/tools-sessions), and only then snapshot. If no session appears at the new URL, the page did not load or is not instrumented. And you know that immediately rather than three calls later.
+
+<Warning>
+  **Refs do not survive a navigation.** A new document means new refs. The same "Sign in" button was
+  `e5` before a navigation and `e103` after. Re-snapshot; never carry refs across.
+</Warning>
+
+## Arguments
+
+| Argument | What it does                          |
+| -------- | ------------------------------------- |
+| `url`    | Where to go. Relative paths work      |
+| `reload` | Reload in place instead of navigating |
+| `hard`   | With `reload`, bypass the cache       |
+
+## Client-side routing is different
+
+In a single-page app, clicking a link usually changes the route without destroying the document. That is a route change, not a navigation. Refs survive, and you can assert it directly:
+
+```json
+{ "ref": "e19", "action": "click", "until": { "kind": "route", "path": "/deployments" } }
+```
+
+Use `reticle_navigate` for a genuine document load. A deep link, a hard reload, or the first visit.

package/docs/tools-network.mdx

@@ -0,0 +1,86 @@
+---
+title: reticle_network
+description: A filtered log of every request the app made, with bodies, status, timing, automatic credential redaction, and an honest note when evidence has expired.
+icon: satellite-dish
+---
+
+`reticle_network` is how an agent checks the thing a screenshot fundamentally cannot show: whether the request actually happened, what it sent, and what came back.
+
+## Example
+
+```json
+{ "limit": 3 }
+```
+
+Real response:
+
+```json
+{
+  "calls": [
+    {
+      "method": "POST",
+      "url": "http://localhost:8787/api/login",
+      "status": 200,
+      "statusText": "OK",
+      "contentType": "application/json; charset=utf-8",
+      "responseSize": 67,
+      "requestBody": "{\"email\":\"admin@reticle.dev\",\"password\":\"[REDACTED]\"}",
+      "responseBody": "{\"token\":\"[REDACTED]\",\"user\":{\"email\":\"admin@reticle.dev\"}}",
+      "ms": 67
+    }
+  ],
+  "buffer": {
+    "held": 15,
+    "dropped": 529,
+    "note": "event buffer evicted older events (age/size cap): a negative result here may be a false negative; the evidence may have expired. Grade sooner or widen the buffer."
+  },
+  "cost": { "bytes": 547, "tokens": 137 }
+}
+```
+
+## Redaction is automatic
+
+Look at `requestBody`. The password is `[REDACTED]` and so is the returned token, without anyone configuring anything. Reticle strips credential-shaped values before they leave the page, so your agent's context. And any transcript of it, never holds them.
+
+The email is not redacted, because an email is not a credential. The line is drawn at secrets.
+
+## The buffer note is the important bit
+
+```json
+"buffer": { "held": 15, "dropped": 529, "note": "…the evidence may have expired…" }
+```
+
+Reticle keeps a bounded event buffer. When it overflows, older events are evicted. And if you then ask "did a POST to `/api/orders` happen?", the honest answer is not "no". It is "not in what I still have."
+
+Most tools would return an empty array and let you draw the wrong conclusion. This one tells you the result may be a false negative and suggests grading sooner or widening the buffer. Take that note seriously: a confident "no requests fired" built on evicted evidence is exactly the kind of false green Reticle exists to prevent.
+
+## Filters
+
+| Argument          | What it does                                                           |
+| ----------------- | ---------------------------------------------------------------------- |
+| `urlContains`     | Substring the URL must contain                                         |
+| `method`          | `GET` · `POST` · `PUT` · `DELETE` · `PATCH`                            |
+| `status`          | Exact status code, e.g. `500`                                          |
+| `ok`              | `false` keeps only failures. The fastest way to "did anything break?"  |
+| `limit`           | Most recent N. Older matches are dropped and counted                   |
+| `actionId`        | Only requests attributed to one action: "what did that click request?" |
+| `since` / `until` | Cursors from a prior act, to scope to a window between two actions     |
+
+## Catching a double submit
+
+The bug where one click fires two POSTs is invisible on screen and obvious here:
+
+```json
+{ "urlContains": "/api/orders", "method": "POST" }
+```
+
+If `calls` has two entries with near-identical timestamps, you have found it. Better still, assert it up front so the agent cannot rationalise it afterwards. `reticle_act_and_wait` accepts an exact count predicate, which turns "roughly one request" into a check that fails at two.
+
+## Checking that nothing fired
+
+`ok: false` on an empty result is a genuinely useful answer. Provided the buffer note says nothing was dropped. Read both.
+
+<Card title="Prove it, don't just look at it" icon="circle-check" href="/quickstart">
+  `reticle_network` reads. It does not produce a verdict. Name the expected request in
+  `reticle_act_and_wait` instead.
+</Card>

package/docs/tools-observe.mdx

@@ -0,0 +1,89 @@
+---
+title: reticle_observe
+description: The full timeline of everything the app did in a window. DOM, network, routing, console, animations and signals, with a summary.
+icon: timeline
+---
+
+`reticle_observe` is the wide-angle lens. Where `reticle_network` and `reticle_console` answer one question each, `observe` returns everything that happened in a window, in order.
+
+## Example
+
+```json
+{ "window_ms": 4000, "max_events": 4 }
+```
+
+Real response:
+
+```json
+{
+  "window_ms": 4000,
+  "events": [
+    {
+      "t": 925870,
+      "type": "page.health",
+      "seq": 586,
+      "data": {
+        "hidden": true,
+        "focused": false,
+        "runtime": "web",
+        "engine": "blink",
+        "brand": "chrome",
+        "reason": "heartbeat"
+      }
+    }
+  ],
+  "summary": {
+    "total": 1,
+    "network": 0,
+    "domAdded": 0,
+    "domRemoved": 0,
+    "domChanged": 0,
+    "routeChanges": 0,
+    "consoleErrors": 0,
+    "animations": 0,
+    "signals": 0
+  },
+  "cost": { "events": 1, "bytes": 374 }
+}
+```
+
+A quiet window, honestly reported as quiet.
+
+## Read the summary first
+
+The `summary` 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
+
+| Argument          | What it does                                                       |
+| ----------------- | ------------------------------------------------------------------ |
+| `window_ms`       | How far back to look                                               |
+| `since` / `until` | Cursors from a prior act. The precise way to scope                 |
+| `actionId`        | Only events attributed to one action: "what did that click cause?" |
+| `filters`         | Event-type allowlist. The cheapest way to shrink a big timeline    |
+| `max_events`      | Cap the timeline to the most recent N                              |
+
+## Scope by cursor, not by clock
+
+Every `reticle_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:
+
+```json
+{ "since": 28123 }
+```
+
+This is more precise than `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.
+
+## When to use it
+
+Use `observe` when you do not yet know what went wrong. Use the narrow tools when you do.
+
+<CardGroup cols={2}>
+  <Card title="Good use" icon="circle-check">
+    "Something broke after that click, show me everything that happened."
+  </Card>
+  <Card title="Wasteful use" icon="circle-xmark">
+    "Did a POST fire?" [`reticle_network`](/tools-network) answers that far more cheaply.
+  </Card>
+</CardGroup>
+
+<Note>`observe` reads. It does not produce a verdict. It is for diagnosis, not proof.</Note>