Examples
These examples show how Cheetah's responsibilities cooperate in believable systems. Some are system journeys that follow one architectural shape through current implementation boundaries. Others are product case studies taken from runnable development and validation products in the repository.
Neither kind is a production template. The useful question is not “Which folder should I copy?” but “Which boundaries does this example prove, and which decisions still belong to my product?”
System journeys
The journeys form a progression, but they are not mandatory deployment stages. A useful application may remain entirely local or use one connected server process indefinitely.
| Journey | Question it answers | Evidence boundary |
|---|---|---|
| Self-contained browser action | What remains of Cheetah when one extension owns both intent and execution? | Tested createLocalApp() construction, dispatch, results, failures, and lifecycle; no server retention or remote coordination |
| Connected console action | What is the smallest real command-and-return path across a process boundary? | Executable smoke with one in-memory Python host and one headless console runtime |
| Several clients in one application | How can browser and machine capabilities cooperate without becoming interchangeable? | Current browser and console consumers plus focused product, policy, state, and isolation tests; not one packaged browser-to-console workflow |
| One system across several server hosts | What becomes shared when connection, return, and application roles separate? | Multi-node integration suites over shared fake Redis plus bounded development adapters; not a production deployment bundle |
Read them in order when evaluating the architecture. Begin with the smallest shape that meets the requirement when designing a product.
Product case studies
The case studies contain application-specific routes, storage, user interfaces, and policy. They are valuable because the framework boundary remains visible beside those choices.
| Case study | Best for | Important limit |
|---|---|---|
| Capture Mini | Seeing a Chrome MV3 extension, server-initiated tab listing, user-initiated screenshot and DOM capture, local artifacts, and a terminal UI in one small product | Its capture upload is a product route; storage and credentials are local-development choices |
| Sitewatch cooperative-site relay | Seeing a bounded local HTTP site exposed to one viewer through a connected console client, session relay, events, and an allowlisted action | Experimental and suitable only for controlled evaluation with a complete product authorization boundary |
| Product01 workbench | Inspecting browser, console, UI, policy, parser, payload, worker, diagnostics, telemetry, and split-role seams together | Broad integration workbench, not a starter architecture or one universal end-to-end proof |
Cheetah's reusable Browser Capture feature is also summarized in the Capture Mini page. That comparison distinguishes a small product-specific upload route from a repeatable capture run that acquires a worker, records ordered states, writes artifacts and a manifest, and releases the worker. The current reusable implementation remains synchronous, sequential, and local-first.
How to assess an example
For every example, separate four layers:
- Framework responsibilities: connection, identity, command dispatch, local execution policy, returned-data ingestion, history, coordination, or an optional reusable service.
- Product behavior: domain actions, routes, workflow state, page layout, local files, and the meaning assigned to the returned evidence.
- Development choices: fixed credentials, plaintext loopback endpoints, permissive CORS, in-memory stores, local paths, and manually started processes.
- Proof: a focused automated test, a connected smoke, retained artifacts, or a clearly labelled architectural composition of separately verified seams.
This prevents a convenient launcher or demo credential from becoming an accidental security recommendation. It also prevents an attractive interface from claiming more than its tests actually establish.
Choose a starting point
Start with the connected console action when you want the smallest repeatable proof across a real process boundary. It has no browser installation step and asserts the full retained result rather than merely observing an open socket.
Use the self-contained browser journey when the product can live inside one extension. Use Capture Mini when you need a concrete browser artifact. Move to Product01 only when its breadth is the subject of the investigation.
An action, HTTP route, policy, or interface present in a case study is not automatically part of Cheetah. Follow each page's links to the reference when you need the exact supported contract.