Build and extend
A Cheetah application is assembled at explicit seams. Product code chooses a coherent server component family, creates the server roles it needs, registers client-side actions, and adds optional facilities only where they solve a product problem.
That explicit composition is important. Authentication, routing, history, tracing, browser capture, diagnostics, and worker coordination have different security and lifecycle requirements. Hiding them behind one global enable switch would make a small example shorter while making a real system harder to reason about.
The four layers of an application
Product code defines the workflows, domain authorization, target selection, business state, and interpretation of results. It calls the application-facing server role but does not need to locate the process that owns a client's socket.
Server roles and components authenticate clients, maintain current presence, deliver commands, accept returned data, correlate outcomes, retain messages, and expose application operations. Presets provide known-compatible in-memory and Redis-backed component families.
The shared client runtime implements identity, protocol negotiation, action registration, argument validation, local authority, optional approval, leases, cancellation, progress, terminal outcomes, state reporting, and telemetry hooks.
Platform and product client layers connect that runtime to browser tabs and windows, console files and processes, cooperative web pages, native bridges, or other environments. Handlers at this layer perform the actual useful work.
Work through the section in dependency order
Compose the server starts with an implementation family, wires the three roles, and leaves mounting and lifecycle with the host application.
Issue commands and use results shows the application API, the difference between a command ID and a terminal waiter, and how retained history completes the result-reading path.
Add client actions covers handler registration, capability advertisement, the execution pipeline, and the boundary between shared runtime behavior and platform-specific work.
Prepare browser parser capture packages the content-script and offscreen-document pieces needed when a browser action must return structured parser evidence.
Add optional facilities maps recurring product needs to Cheetah's capture, parsing, worker, derived-view, relay, observability, diagnostics, and UI features.
Replace core components explains what an interface permits, what a behavioral contract still requires, and why distributed and shared-tenant components must be evaluated as a family.
Verify a custom integration selects focused, cross-language, System Test Lab, and product proof according to the claim an extension changes.
Preserve one end-to-end proof while extending
Add one dimension at a time. Keep a known action that proves connection, delivery, execution, return, correlation, history, and cleanup. When adding Redis, a browser, central policy, or a custom history store, rerun that proof and add assertions for the new boundary.
This makes failures local. A green WebSocket connection cannot hide a broken result path, and a returned payload cannot hide a listener that never shuts down.