Understand Cheetah
Cheetah coordinates work whose application decision and execution environment do not share one process or lifetime. Understanding the framework therefore starts with boundaries: who owns the purpose of an action, who owns the live connection, where an action is permitted to run, and what the system can honestly know after a partial failure.
Consider a product that needs to read structured information from a page already open in a user's browser. Product code knows why the information is needed and how it contributes to a workflow. The browser owns the signed-in session, the page, and the local decision to permit access. Between them, Cheetah must address the right client, find its current route, carry a named command into the browser runtime, and accept the result through a trusted return path.
The same framework model also applies when the work belongs in a console process, a cooperative page, or a custom client. The platform capabilities change; the meanings of identity, authority, command, progress, terminal outcome, and retained evidence remain recognizable.
A reading sequence based on dependencies
The pages in this section are ordered so that later details have an established place.
| Page | Question it answers |
|---|---|
| System model and ownership | Which responsibilities belong to product code, the Cheetah server, the shared client runtime, platform-specific code, and the host? |
| Clients and execution environments | What is common across client types, what remains platform-specific, and why does the browser need special lifecycle handling? |
| Identity, trust, and command authority | Which identities survive, which boundary authenticates them, and how central and local authority cooperate? |
| Commands and returned evidence | What happens from application intent through remote execution and back to an observable result? |
| Reliability and recovery | What survives a disconnect or restart, what can be reconstructed, and where must an application accept uncertainty? |
This is an explanatory sequence rather than an API reference. It uses the public names of important components, but it does not enumerate every method, schema, or configuration field. Exact protocol and extension contracts belong in later reference and build sections.
Four distinctions used throughout the documentation
First, product intent is not framework execution. The product decides that reading a page, transforming a file, or observing a device is meaningful. Cheetah gives that operation a structured route and lifecycle. It does not decide what the returned data means to the business.
Second, a logical client is not its current connection. A browser installation or configured console agent can retain a stable client identity while its process and socket change. Cheetah uses a separate runtime instance identity to fence work and returned data to the correct execution lifetime.
Third, delivery is not completion. Dispatcher admission, a socket write, client acknowledgement, handler execution, HTTP ingestion, and application observation are useful but different facts. Treating them as one success state would make retry and recovery unsafe.
Fourth, recovery has several authorities. The platform reports what exists now; the server keeps its own routing and scheduling records; history retains selected accepted messages; the product owns durable business truth. Recovery reconciles those sources. It does not rewind the browser or prove that an unseen external effect did not happen.
What this section deliberately postpones
The foundation pages explain the architecture deeply enough to reason about it, while the other regions keep different reader tasks separate. Get started owns source preparation and a complete connected proof. Build and extend owns construction and customization. Operate owns deployed posture. Reference owns exhaustive lookup contracts.
Optional facilities are introduced only where they clarify the system boundary. Each links to its build, operating, or reference home when the reader needs it. This avoids both extremes: presenting Cheetah as only a command transport, or turning the first technical chapter into a catalogue of every package in the repository.