@reticlehq/server 2.7.0 → 2.8.0

package/docs/skill-file.mdx

@@ -0,0 +1,105 @@
+---
+title: The SKILL file: paste and go
+sidebarTitle: SKILL file
+description: One URL you paste into any coding agent to teach it Reticle. How it works, what it contains, and when you need it at all.
+icon: graduation-cap
+---
+
+`SKILL.md` is a single document you hand to a coding agent. It teaches the agent to install Reticle, wire it into your app, and then drive a verification loop properly. Without you explaining any of it.
+
+```
+https://raw.githubusercontent.com/reticlehq/reticle/main/SKILL.md
+```
+
+That URL is live and returns the current version. Paste it into your agent and say "read this and set up Reticle".
+
+<Note>
+  You often do not need it. `npx @reticlehq/server init` writes a `/reticle` slash command for
+  Claude Code automatically, and installs agent rule files for Claude and Cursor. The SKILL file is
+  for agents that `init` cannot configure, for a from-scratch install, or when you want the agent to
+  have the full protocol in context rather than a summary.
+</Note>
+
+## It has two modes, and it picks one itself
+
+The first thing the document tells an agent to do is check which situation it is in:
+
+```bash
+cat .reticle.json 2>/dev/null || echo "NOT_FOUND"
+```
+
+- **Not found** → run **Setup mode**: register the MCP server, install the SDK, wire the entry point, validate the connection, and prove it on one flow while the user watches.
+- **Found** → run **Test mode**: connect, orient, decide what to test, drive it, report.
+
+One document, two jobs, no flag for you to remember. The second time you invoke it, it skips straight to the useful part.
+
+## What Setup mode actually does
+
+| Phase | What the agent does |
+| --- | --- |
+| Save the skill | Store it as `/reticle` so the loop is one word away from then on |
+| Run `init` | Without asking you questions it can answer itself |
+| Manual fallbacks | Per-agent MCP config, per-framework SDK wiring, for anything `init` marked `⚠` |
+| Validate | Confirm a session actually connected. Not that a checklist went green |
+| Prove it | Drive one real flow while you watch, so the install ends in evidence |
+
+That last row is the one that matters. Plenty of installs "succeed" and then nothing works. The skill does not consider itself finished until a real flow has produced a real verdict.
+
+## What Test mode actually does
+
+Five phases: connect, orient, decide what to test, run the tests, report. The reporting format is specified, which matters more than it sounds. An agent left to summarise freely will summarise optimistically.
+
+The rules it operates under are the same ones these docs keep repeating:
+
+- Only `reticle_act_and_wait` and `reticle_assert` produce a verdict.
+- `verified: "unknown"` is not a pass.
+- Never weaken a check to make it pass.
+
+## Feedback is the first section, on purpose
+
+Before setup, before anything, the document tells the agent that reporting problems is part of the job. And that this applies **during** setup, which is where Reticle is most likely to break and least likely to hear about it.
+
+It even covers the case where nothing is installed yet:
+
+```bash
+npx @reticlehq/server feedback --agent --kind gap "init finished but no session ever connected"
+```
+
+That works with no daemon running, which is the entire point. The install that failed halfway is the one worth hearing about, and in that state the MCP tools do not exist.
+
+<Tip>
+  It also draws a line that saves everyone time: report defects in **Reticle**. A bug found in the
+  app under test is Reticle working correctly, and belongs in the answer to the user.
+</Tip>
+
+## It ships inside the package too
+
+`SKILL.md` is bundled into `@reticlehq/server` at publish time, alongside a copy of this entire documentation site. So an agent that has already installed Reticle can read it from disk without a network round trip:
+
+```
+node_modules/@reticlehq/server/SKILL.md
+node_modules/@reticlehq/server/docs/
+```
+
+Handy in a sandbox with no outbound network, which is an increasingly common place for an agent to live.
+
+## Should you read it?
+
+Probably not, unless you are curious. It is roughly 60 KB and written for an agent, which means it is exhaustive in the way a runbook is exhaustive. Every fallback, every framework, every failure mode spelled out rather than summarised.
+
+If you want the human version of the same material, you are already in it:
+
+<CardGroup cols={2}>
+  <Card title="Agentic install" icon="wand-magic-sparkles" href="/install-agentic">
+    What `reticle init` does, with real output.
+  </Card>
+  <Card title="Manual install" icon="screwdriver-wrench" href="/install-manual">
+    Every step `init` cannot automate.
+  </Card>
+  <Card title="Agent cheat sheet" icon="bolt" href="/agent-cheatsheet">
+    The one-screen version of the drive loop.
+  </Card>
+  <Card title="Best practices" icon="star" href="/best-practices">
+    The habits that make verdicts worth trusting.
+  </Card>
+</CardGroup>

package/docs/state-management.mdx

@@ -0,0 +1,197 @@
+---
+title: State management
+description: Register any store so Reticle can read what your app believes. Zustand and Redux work natively, and eight more have adapters.
+icon: database
+---
+
+Reading application state is what separates a verdict from a screenshot. A `200` proves the server was reachable. A rendered row proves React ran. Only state proves your app accepted the change.
+
+Reticle needs one thing from your store: a way to read it, and a way to know when it changed.
+
+## The contract
+
+```ts
+interface StoreLike {
+  getState(): unknown;
+  subscribe(listener: () => void): () => void;
+}
+```
+
+Anything with that shape registers directly, with no adapter.
+
+```ts
+import { registerStore } from '@reticlehq/browser';
+
+registerStore('app', myStore);
+```
+
+<Warning>
+Pass the **store**, not `() => store.getState()`. The store form wires `subscribe`, so every mutation
+emits a state diff. The getter form still works for compatibility but leaves the store on pull-only
+reads: no change events, and an empty `stateDiffs` in every verdict.
+
+That reads as "nothing changed" and actually means "I was never watching". It is the most common instrumentation mistake there is.
+
+</Warning>
+
+## Works natively
+
+<CardGroup cols={2}>
+  <Card title="Zustand" icon="bolt">
+    A zustand hook already has `getState` and `subscribe`. Pass it straight in.
+  </Card>
+  <Card title="Redux" icon="boxes-stacked">
+    A Redux store is `StoreLike` by definition. Same one-liner.
+  </Card>
+</CardGroup>
+
+```ts
+registerStore('app', useApp); // zustand
+registerStore('app', store); // redux
+```
+
+This is what the Reticle fixture app does, and it is why its verdicts carry `stateDiffs: [{ "path": "auth", "from": null, "to": "…" }]`.
+
+## Adapters
+
+Eight libraries do not fit `StoreLike` for a reason specific to each. Every adapter returns a `StoreLike` you hand straight to `registerStore`.
+
+Each example below is the one documented in the adapter's own source.
+
+### TanStack Query
+
+```ts
+import { tanstackQueryStore } from '@reticlehq/browser';
+
+registerStore('queries', tanstackQueryStore(queryClient));
+```
+
+<Tip>
+  Register your server cache even if you already register a client store. "The screen is plausible
+  and the network is silent" is the normal failure with query caches: a mutation forgets to
+  invalidate, the UI keeps rendering a number that was true a minute ago, and nothing fires for
+  anyone to notice. The cache's freshness metadata is the only witness.
+</Tip>
+
+### Pinia
+
+```ts
+import { piniaStore } from '@reticlehq/browser';
+
+registerStore('cart', piniaStore(useCartStore()));
+```
+
+### Svelte stores
+
+```ts
+import { svelteStore } from '@reticlehq/browser';
+
+registerStore('cart', svelteStore(cartStore));
+```
+
+### Jotai
+
+Atoms are not a store, so you name the ones you care about.
+
+```ts
+import { jotaiStore } from '@reticlehq/browser';
+import { getDefaultStore } from 'jotai';
+
+registerStore('app', jotaiStore(getDefaultStore(), { cart: cartAtom, user: userAtom }));
+```
+
+### Valtio
+
+```ts
+import { valtioStore } from '@reticlehq/browser';
+import { snapshot, subscribe } from 'valtio/vanilla';
+
+registerStore('app', valtioStore(state, snapshot, subscribe));
+```
+
+### MobX
+
+```ts
+import { mobxStore } from '@reticlehq/browser';
+import { reaction, toJS } from 'mobx';
+
+registerStore('app', mobxStore(store, toJS, reaction));
+```
+
+You pass `toJS` and `reaction` in rather than Reticle importing MobX. The SDK stays free of your state library, and your bundle stays free of a copy it did not ask for.
+
+### XState
+
+```ts
+import { xstateStore } from '@reticlehq/browser';
+
+registerStore('machine', xstateStore(actor));
+```
+
+An XState actor's `subscribe` returns a subscription object rather than an unsubscribe function, which is the single reason it does not satisfy `StoreLike` already.
+
+### Recoil
+
+The most involved, because Recoil has no store object to hand over.
+
+```ts
+import { recoilStore } from '@reticlehq/browser';
+
+const latest = useRef(snapshot_UNSTABLE());
+const listeners = useRef(new Set<() => void>()).current;
+
+useRecoilTransactionObserver_UNSTABLE(({ snapshot }) => {
+  latest.current = snapshot;
+  for (const l of listeners) l();
+});
+
+registerStore(
+  'recoil',
+  recoilStore(
+    { cart: cartAtom },
+    () => latest.current,
+    (l) => {
+      listeners.add(l);
+      return () => listeners.delete(l);
+    },
+  ),
+);
+```
+
+### Anything else
+
+`pushStore` gives you a store plus the `push` that updates it, so you own the write side. Useful for state that lives somewhere Reticle cannot reach: a web worker, a websocket, a third-party SDK.
+
+```ts
+import { pushStore } from '@reticlehq/browser';
+
+const { store, push } = pushStore({ status: 'idle' });
+registerStore('worker', store);
+
+worker.onmessage = (e) => push(e.data);
+```
+
+## Reading it back
+
+```json
+{ "store": "app", "path": "cart.items.0.qty" }
+```
+
+`reticle_state` walks a dot-path with numeric array indices. `depth` collapses anything deeper to a size marker, which is the difference between a cheap look and a very expensive one on a large store.
+
+You can also assert on it directly, which is stronger than reading it afterwards:
+
+```json
+{ "kind": "state", "store": "app", "path": "deployments.0.status", "equals": "live" }
+```
+
+That catches a UI-versus-store desync, a deploy that only looks shipped, deterministically and with no model involved.
+
+<CardGroup cols={2}>
+  <Card title="reticle_state" icon="database" href="/tools-state">
+    Arguments, depth control, and reading a component's hook state.
+  </Card>
+  <Card title="Instrument your app" icon="wrench" href="/instrumentation">
+    Stores are one of three things worth registering. The other two are signals and testids.
+  </Card>
+</CardGroup>

package/docs/style.css

@@ -0,0 +1,14 @@
+/* Any .css file at the docs root is auto-loaded by Mintlify; docs.json has no field for it.
+   Tagline under the footer logo: the footer schema is {socials, links} and takes no text. */
+#footer a.select-none::after {
+  content: 'Your agent says it works. Reticle checks.';
+  display: block;
+  margin-top: 0.75rem;
+  font-size: 0.875rem;
+  line-height: 1.25rem;
+  color: rgb(var(--gray-500));
+}
+
+.dark #footer a.select-none::after {
+  color: rgb(var(--gray-400));
+}

package/docs/system-map.md

@@ -1,16 +1,31 @@
-# System map
+---
+title: System map
+description: 'How a tool call travels from a coding agent to your app and back, and which of those failures are silent.'
+icon: map
+---
 
-> How a tool call gets from a coding agent to your app and back, what each hop can do wrong, and which of those failures are **silent**. Written for anyone touching the transport, the daemon, the bridge, or a gate — and for contributors trying to work out where their change lives.
+> How a tool call gets from a coding agent to your app and back, what each hop can do wrong, and which of those failures are **silent**. Written for anyone touching the transport, the daemon, the bridge, or a gate, and for contributors trying to work out where their change lives.
 >
 > Companion pages: [`harness-rules.md`](../apps/e2e/harness-rules.md) (what a gate must do about all this) and [`telemetry-contract.md`](./telemetry-contract.md) (the rules for anything that emits).
 
-## 1. Topology — 5 processes, 4 hops
-
-```
-coding agent ──stdio──▶ reticle mcp ──HTTP POST──▶ daemon :4400 ──WebSocket──▶ browser SDK ──▶ your app
-  (client)     JSON-RPC   (proxy)   ◀───SSE─────  (bridge+tools)  ◀─────────  (@reticlehq/browser)
-                                                        │
-                                                        └─▶ .reticle/  flows · capsules · baselines · runs
+## 1. Topology: 5 processes, 4 hops
+
+```mermaid
+flowchart LR
+    C["coding agent<br/>(client)"]
+    P["reticle mcp<br/>(proxy)"]
+    D["daemon :4400<br/>(bridge + tools)"]
+    S["browser SDK<br/>@reticlehq/browser"]
+    A["your app"]
+    F[(".reticle/<br/>flows · capsules<br/>baselines · runs")]
+
+    C -- "stdio / JSON-RPC" --> P
+    P -- "HTTP POST" --> D
+    D -- "SSE" --> P
+    D -- "WebSocket" --> S
+    S --> D
+    S --> A
+    D <--> F
 ```
 
 Each hop has its own failure vocabulary, its own recovery, and its own way of lying. Nothing stated this end to end until this page, which is why gate results have been contradictory.
@@ -23,39 +38,39 @@ Each hop has its own failure vocabulary, its own recovery, and its own way of ly
 | 2 | proxy probes `:4400` (`probeDaemon`, plain TCP, 500ms) | proxy | a squatter that accepts and never serves looks alive |
 | 3 | absent → spawn daemon detached, poll to `DAEMON_READY_TIMEOUT_MS` (10s) | proxy | slow CI; raise with `RETICLE_DAEMON_READY_TIMEOUT_MS` |
 | 4 | proxy opens SSE, waits for the `endpoint` frame → POST URL | proxy | an empty frame used to read as "connected"; now refused (`buildSessionUrl`) |
-| 5 | `initialize` — answered **locally** after `LOCAL_HANDSHAKE_MS` (12s) when the daemon cannot | proxy | any client with a startup budget under ~12s loses Reticle for the whole session |
+| 5 | `initialize`, answered **locally** after `LOCAL_HANDSHAKE_MS` (12s) when the daemon cannot | proxy | any client with a startup budget under ~12s loses Reticle for the whole session |
 | 6 | daemon binds `:4400`, writes the pid file, starts bridge + idle watcher | daemon | `EADDRINUSE` → child exits 1, **parent already exited 0** |
 | 7 | app calls `reticle.connect()` → `ws://localhost:4400/reticle` | SDK | wrong port; missing pairing token; mixed content (Safari throws synchronously on `new WebSocket`) |
 | 8 | HELLO: `sessionId`, `projectId`, `protocolVersion`, capabilities | SDK → bridge | version mismatch → `1008` close → **the SDK stops retrying, permanently** |
 | 9 | bridge authenticates: pairing token / loopback tier / Origin allow-list | bridge | another project's daemon answers → `authFailureReason` names it |
-| 10 | Session registered, `everConnected = true` | daemon | — |
+| 10 | Session registered, `everConnected = true` | daemon | n/a |
 | 11 | tool call → `runTool` → `session.send` → WS command → SDK → reply | all | any hop above, mid-flight |
 
-**Sequencing hazard:** steps 6 and 7 race. The product absorbs it internally — the first live tool call blocks briefly for a session to appear rather than failing — but a gate that boots an app and immediately asks whether a session exists is outside that protection and has been burned by it. Poll for the session; never sample once.
+**Sequencing hazard:** steps 6 and 7 race. The product absorbs it internally (the first live tool call blocks briefly for a session to appear rather than failing), but a gate that boots an app and immediately asks whether a session exists is outside that protection and has been burned by it. Poll for the session; never sample once.
 
-## 3. The tool graph — what produces what
+## 3. The tool graph: what produces what
 
 Three different counts, all measured, and the difference between them matters:
 
 | Count | What it is |
 | --- | --- |
 | **68** | name constants in `ReticleTool` |
-| **48** | tools advertised under `RETICLE_ADVERTISE_ALL_TOOLS=1` — what `tool-surface-sweep-test` drives (51 calls) |
+| **48** | tools advertised under `RETICLE_ADVERTISE_ALL_TOOLS=1`, i.e. what `tool-surface-sweep-test` drives (51 calls) |
 | **17** | advertised by default; the rest are reached through `reticle_run` |
 
-68 → 48 is **family folding**: `reticle_baseline`, `reticle_session`, `reticle_record`, `reticle_flow` and `reticle_lease` each absorb their members behind an `action` parameter. So "every tool is callable" is asserted over 48 surfaces, not 68 behaviours — a family member reachable only through an `action` value the sweep never passes is not covered by it. Worth closing when the per-tool budget lands (see [`gate-plan.md`](./gate-plan.md), Phase 4).
+68 → 48 is **family folding**: `reticle_baseline`, `reticle_session`, `reticle_record`, `reticle_flow` and `reticle_lease` each absorb their members behind an `action` parameter. So "every tool is callable" is asserted over 48 surfaces, not 68 behaviours; a family member reachable only through an `action` value the sweep never passes is not covered by it. Worth closing when the per-tool budget lands (see [`gate-plan.md`](./gate-plan.md), Phase 4).
 
 | Token | Produced by | Consumed by | Invalidated by |
 | --- | --- | --- | --- |
 | `sessionId` | `reticle_sessions`, HELLO | ~every tool | tab close; **survives reload** via `sessionStorage` |
-| `ref` (`e115`) | `snapshot`, `query`, `scroll_to` | `inspect`, `act`, `act_and_wait`, `state` | any re-render — refuses cleanly rather than clicking the new occupant |
+| `ref` (`e115`) | `snapshot`, `query`, `scroll_to` | `inspect`, `act`, `act_and_wait`, `state` | any re-render; refuses cleanly rather than clicking the new occupant |
 | `actionId` (`a2`) | `act`, `act_and_wait` | `observe`, `network`, `console` filters | window expiry |
 | `since` cursor | every read | every read | ring-buffer eviction |
-| `capsuleSaved` | `act_and_wait` | `replay` | — |
+| `capsuleSaved` | `act_and_wait` | `replay` | n/a |
 | flow | `record_start` → acts → `flow_save_recorded` | `flow_verify`, `flow_replay`, `flow_heal`, `affected`, `gate` | DOM drift → `flow_heal` |
 | baseline | `baseline_save`, `viewport` | `visual_diff`, `diff` | viewport change |
 | `session_lease` | direct tool results | the agent (`yield` / `end`) | **dropped on the `reticle_run` path** (#119) |
-| run artifact | `run_export`, `reticle verify` | CI, `reticle gate` | — |
+| run artifact | `run_export`, `reticle verify` | CI, `reticle gate` | n/a |
 
 Two structural facts:
 
@@ -66,16 +81,16 @@ Two structural facts:
 
 **Silent** = fails with no error surfaced to the agent or the user.
 
-### Hop 1 — client ↔ proxy
+### Hop 1: client ↔ proxy
 
 | Failure | Silent | Guarded by |
 | --- | --- | --- |
-| proxy killed externally (the `lsof -ti` recipe) | **yes, total** | nothing — needs `reticle kill` (#114). See [harness rule 1](../apps/e2e/harness-rules.md) |
+| proxy killed externally (the `lsof -ti` recipe) | **yes, total** | `reticle kill` frees the port and leaves the agent's own proxy alone. See [harness rule 1](../apps/e2e/harness-rules.md) |
 | proxy uncaught exception | no | `installProxyResilience` + `proxyLog` |
 | proxy exits when the reconnect budget is spent | _was the worst bug in the product_ | `onReconnectBudgetSpent` → DORMANT, never exit |
 | client closes stdin with calls in flight | no | `SHUTDOWN_DRAIN_MS` (5s) |
 
-### Hop 2 — proxy ↔ daemon
+### Hop 2: proxy ↔ daemon
 
 Three distinct populations of unanswered call, **all covered**:
 
@@ -93,35 +108,35 @@ Still fragile:
 | stale tool catalog served while dormant | **yes** | `ToolCatalogCache` answers `tools/list` from cache; after a version change a client can hold a catalog the daemon no longer implements |
 | handshake replay regresses | **yes** | the daemon builds a fresh `McpServer` per SSE connection, so every `tools/call` would hit an uninitialized server |
 
-### Hop 3 — daemon lifecycle
+### Hop 3: daemon lifecycle
 
 | Failure | Silent | Note |
 | --- | --- | --- |
-| `serve` exits 0 on `EADDRINUSE` | **yes** | #115 — the parent reports the spawn, the child reports the bind, nothing joins them |
+| `serve` exits 0 on `EADDRINUSE` | **yes** | #115: the parent reports the spawn, the child reports the bind, nothing joins them |
 | liveness is the pid file, never the port | **yes** | `daemon/daemon.ts:156` |
-| idle shutdown fires mid-install | **yes** | 5min base / 30min attached — already scored three fixtures as install failures |
+| idle shutdown fires mid-install | **yes** | 5min base / 30min attached; already scored three fixtures as install failures |
 | `isUselessDaemon` ends a daemon that served nothing | **yes** | lifetime facts, but a gate that installs for six minutes before its first call is that daemon |
 | a daemon spawned inside a tool call is reaped when the call ends | **yes** | `SIGTERM` within ~1s, `detached` or not |
 | no `daemon_alive` heartbeat | **fixed** | a killed daemon and a tidy exit used to read identically; the daemon now beats every 30s and `classifyDaemonLife` turns silence into `died_silently` (#123) |
 | no port arbitration | **yes** | a second daemon can bind a port a first one held |
 
-### Hop 4 — bridge ↔ SDK
+### Hop 4: bridge ↔ SDK
 
 | Failure | Silent | Note |
 | --- | --- | --- |
 | protocol mismatch → `1008` | no, but **terminal** | the SDK stops retrying by design; the app is dark until reload (#127) |
-| another project's daemon answers | no | `authFailureReason` — evidence-based, only claims it when the daemon has demonstrably served another project |
-| `rejectAll('session disconnected')` | **fixed** | used to become `verified:"no" / assertion_failed` — Reticle blaming the app, by file and line, for its own lost connection. Now `verified:"unknown" / observation_lost` (#124) |
+| another project's daemon answers | no | `authFailureReason` is evidence-based, only claiming it when the daemon has demonstrably served another project |
+| `rejectAll('session disconnected')` | **fixed** | used to become `verified:"no" / assertion_failed`, i.e. Reticle blaming the app, by file and line, for its own lost connection. Now `verified:"unknown" / observation_lost` (#124) |
 | reaper ends a quiet session | no | revivable on the agent's next action |
 | opaque origins (`tauri://localhost`, `file://`) | no | kept verbatim in the allow-list rather than collapsed to `"null"` |
 
-### Hop 5 — SDK internals
+### Hop 5: SDK internals
 
 | Failure | Silent | Note |
 | --- | --- | --- |
 | fixed 1s reconnect, no backoff, unbounded | **yes** | and the noise lands in the console channel we report to the agent (#116) |
 | `onUnreachable` suppressed after the first success | **yes** | a **mid-session** outage never warns at all |
-| offline queue overflow (`MAX_QUEUE = 500`) | no | gap marker stamped at the **oldest** drop — the honest floor for where the hole starts |
+| offline queue overflow (`MAX_QUEUE = 500`) | no | gap marker stamped at the **oldest** drop, the honest floor for where the hole starts |
 | `sessionStorage` throws in a sandboxed iframe | no | falls back; a session must still start |
 
 ## 5. Where the gates are
@@ -136,8 +151,8 @@ Still fragile:
 | tools | surface, schema, refusals | `tool-surface-sweep-test`, `tool-fuzz-test` | latency/failure budget |
 | verdict | honesty | `release-smoke-test` | transport ≠ app (#124); false-green rate |
 | telemetry | silent absence | `telemetry-events-test`, `telemetry-contract.test.ts` | chokepoint coverage |
-| install | pristine-surface wiring | — | the whole class |
-| client | per-agent MCP compatibility | — | the whole class |
+| install | pristine-surface wiring | nothing | the whole class |
+| client | per-agent MCP compatibility | nothing | the whole class |
 
 Nine of eleven layers have a gate. The two that do not are exactly the two that need a second repo and a human. The plan for both is in [`gate-plan.md`](./gate-plan.md).
 
@@ -146,7 +161,7 @@ Nine of eleven layers have a gate. The two that do not are exactly the two that
 `runTool` opens one `tool.handler` root span per call and every stage underneath inherits it. With `RETICLE_TRACE=1` that makes three assertions available from any existing battery run, at the cost of one log parser:
 
 - exactly one root span at `depth: 0` per tool call
-- **zero orphan spans** — 23 orphans on one healthy run is the documented signature of a hung call
+- **zero orphan spans**; 23 orphans on one healthy run is the documented signature of a hung call
 - `settleTiming` always fires; it sits in a `finally` so a thrown call cannot leak a concurrency slot
 
 Today that output is produced and discarded.