Several clients in one application
A Cheetah application can coordinate browser extensions, console processes, embedded web pages, mobile hosts, and custom clients without pretending that they are interchangeable. They share a command and evidence model. Each client keeps the capabilities, lifetime, and local authority of the environment in which it runs.
The application selects a client for the capability and context it currently exposes. An advertised action describes availability; it does not authorize or schedule the work.
Start from different capabilities
Consider an application that needs to read a signed-in page and then process the extracted data on a machine. A browser extension can see tabs and pages allowed by its manifest and the user's current session. A console runtime can read approved files, invoke a product tool, or run a longer-lived flow. Neither environment should inherit the other's authority merely because both belong to the same application.
The shared runtime gives both clients the same outer lifecycle:
- establish a stable logical client identity and a current runtime instance;
- advertise the actions implemented by that runtime;
- receive a command addressed to that client and, when needed, a specific context;
- validate the command and apply local policy or approval;
- execute a platform or product handler; and
- return progress, a terminal result, or an error through authenticated ingestion.
The platform packages supply different adapters and built-in handlers inside that lifecycle. The browser package understands tabs, windows, content scripts, capture, and browser permissions. The console package understands machine-oriented handlers and flows. Web and mobile packages preserve narrower host boundaries of their own.
Use the live map without treating it as business truth
The application-facing server can query current presence, advertised actions, runtime instances, and reported contexts. That information answers practical routing questions: which browser currently owns a useful tab, which console exposes the required handler, and which runtime instance is eligible to acknowledge this attempt?
The map is operational state, not the product's durable task database. A tab may close after it was reported. A console may reconnect as another runtime instance. A capability can disappear with a new client version. Cheetah provides stable client addressing, current instance fencing, and retained returned evidence; the application decides what a completed job or resumable workflow means.
Follow a two-client workflow honestly
The application can first address a browser client and request a bounded page extraction. The browser checks its local policy, executes the content-script or capture handler, and returns a correlated result. Only after receiving and validating that result does the application construct a second command for a console client—for example, to compare the data with an approved local file or write an artifact.
The console makes a separate trust decision. Permission to inspect a page does not imply permission to access a filesystem. Both outcomes use the same command identifiers, returned message vocabulary, ingestion boundary, and user-scoped history, but the application joins them as two explicit product steps.
This workflow is an architectural composition of implemented seams. The repository does not currently ship one automated browser-to-console scenario that performs this exact chain. Product01 verifies that current browser and console consumers coexist with the application surface, policy routes, parser and payload facilities, worker tooling, diagnostics, and telemetry. Focused package, product, and isolation tests verify the individual boundaries. Those facts support the system shape without turning a hypothetical chain into a claimed test result.
Product01 is evidence, not a starter template
The Product01 workbench is useful when you need to inspect many features together. Its browser and console clients consume the shared packages, while its frontend exposes product-owned commands and operator-oriented test surfaces. It deliberately contains more policy, diagnostics, parser, payload, and worker machinery than a normal first application.
Copy the responsibility boundaries, not the development credentials or every panel. A real product should introduce only the clients it needs, define an explicit selection rule, and test each cross-client transition over public application and client surfaces.
Keep authority layered
Central policy can reject a command before delivery. The addressed client then applies its own local policy and any configured approval step. Returned evidence records what the selected runtime reported; it does not grant the server permanent authority over the page, machine, or user session.
This is how several clients form one application without becoming one imaginary universal computer: Cheetah unifies the coordination machinery while preserving the places where capability and authority actually live.