Capture and payloads
An ordinary Cheetah command carries an object of parameters and eventually returns an object of application evidence. Keep that simple path when it fits. The facilities in this section exist for specific additional needs: observing the page immediately after an action, extracting trusted structure, moving supported large command values outside the WebSocket, protecting plaintext, changing Redis history storage, or coordinating several browser states as one run.
These are separate capabilities. Enabling one does not silently enable the others, and a marker or stored artifact does not inherit guarantees from a neighboring feature.
Choose the capability from the constraint
| Need | Facility | What it changes | What it does not prove |
|---|---|---|---|
| preserve the state immediately after one applied action | post-command capture | adds screenshot, DOM, and named parser evidence to that command's terminal payload | that the page was globally stable or transactional |
| turn page HTML into versioned structured data | parser registry and client parser runner | validates and delivers an exact trusted parser definition | that an arbitrary client supports the engine or may inspect the page |
| fit supported large values within a command transport limit | signed payload reference | stores the value in scoped history and sends a short-lived retrieval capability | confidentiality from the history or spill backend |
| keep selected command parameters unreadable to relay and storage infrastructure | encrypted envelope | encrypts application values before normal client validation and execution | key distribution, rotation, or a complete response-encryption policy |
| keep a large retained payload outside its Redis Stream entry | Redis history spill | changes backend placement while normal history reads rehydrate the message | that a command will fit on the WebSocket |
| capture ordered states from one or more URLs as a named task | browser-capture service | acquires browser workers and writes run records, artifacts, and a manifest | a distributed queue or production retention service |
The attachment point defines ownership
Post-command capture is part of the shared client execution pipeline. The platform-specific capture provider decides how to obtain a screenshot or DOM snapshot. Parser definitions begin in an optional server registry, travel as cache material, and execute in a compatible client.
Signed references connect an App node, history, a token signer, an authenticated HTTP retrieval route, and a client resolver. Encryption is client/application machinery and keeps key material outside the server. History spill is a property of the selected Redis history implementation and its external payload store. Browser-capture runs are a separate service around application commands, worker allocation, run storage, and artifact storage.
This is why there is no global enable_optional_services switch. Each facility has a different owner, lifecycle, failure path, and security boundary.
Read the exact contracts
Post-command capture defines when capture runs, the request and result shapes, parser failure behavior, and the size limits that affect returned evidence.
Parser registry and definitions covers immutable parser identity, Imprint v2 validation, inline and cache-aware delivery, browser preflight, and the current registry limitations.
References, encryption, and spill separates the three different payload problems and documents their processing order, security guarantees, retention behavior, and failure policies.
Browser capture runs documents the authenticated REST surface, worker binding, run and manifest models, status rules, artifact keys, and local-first limits of the optional service.
To build the extension assets required by the browser parser runner, follow Prepare browser parser capture.
Current maturity
Post-command browser capture, the Imprint parser path, payload references, client encryption helpers, and managed Redis-history spill have focused implementation and test coverage. They still require deliberate composition and deployment policy. The supplied parser registry is in-memory, and shared-tenancy composition currently excludes the built-in registry and payload offload until tenant-aware replacements are verified.
The browser-capture run service is a tested, synchronous, single-host first slice. Its run records can expire while local artifacts remain. Treat that limitation as part of the public contract, not as an operational detail to discover after deployment.