Multi-client integration workbench
Product01 is the repository's broad Cheetah integration workbench. It combines a React interface, browser extension, console client, and Python application. The server roles can run together or as separate Redis-coordinated processes.
Use it to inspect feature interactions and validation surfaces. Do not use its credentials, admin settings, launch scripts, or UI structure as a production starter without a separate design review.
Prepare the workbench
Product01 needs Redis in addition to the repository's Python and Node.js prerequisites. Redis is managed outside the repository and must be reachable at the URL in the selected configuration.
From the repository root on Windows:
bootstrap.cmd --product01 --dashboards
cd products\testCheetahProduct01
start_backend3.batThe default launcher uses config-local.json and starts the single-process backend and frontends. To exercise role isolation and Redis coordination:
start_backend3_multiprocess.batFor explicit testing from another machine, a launcher can receive config-network.json. Review every advertised URL and security setting before doing so; this file is a LAN development configuration, not a public-deployment profile.
Load the browser extension
Build it from:
cd products\testCheetahProduct01\clients\chrome
npm run buildLoad products/testCheetahProduct01/clients/chrome/dist as an unpacked extension in Chrome. Reload it after rebuilding client packages.
The workbench also includes a console client. Browser and console actions share the core runtime lifecycle while preserving different capability and local-policy boundaries.
What to inspect
Product01 exercises browser and console clients, current presence, worker windows, parser definitions, capture and payload handling, central and local permission paths, diagnostics, telemetry integration, reusable UI, and several development operator surfaces.
Single-process mode is useful for following objects directly. Multi-process mode demonstrates that an application host can request work from a client connected to another WebSocket host, and that a REST host can accept the result and notify the original correlator through the shared coordination domain.
The workbench's breadth is evidence that the pieces can coexist. It does not mean every panel or product action is a framework-level feature, and it does not make the workbench one automated proof of every possible browser-to-console workflow.
Authentication differs by launch mode
The current development launch modes use different authentication wiring. Single-process mode uses a Redis authentication provider whose test keys can be populated by the supplied script. Multi-process mode uses matching in-process development key maps in each role.
Both derive a user identity. Neither is a production identity or secret-management design. When moving beyond the workbench, use one deliberately chosen authentication provider across every relevant role and independently protect the administrative surfaces.
Storage and security cautions
Signed payload references require the same non-development signing secret in every process. File-backed spilled history must live on storage accessible to every role that may hydrate the payload; unrelated local disks are not a shared store.
The permissions and worker-window panels are validation tools. No-op administrative authentication and plaintext development endpoints must not be exposed on an untrusted network.
Use bounded journeys to interpret the workbench
Product01 contains several architectural stories at once. Use Several clients in one application to understand why its browser and console runtimes share contracts without sharing authority. Use One system across several server hosts to understand what the multiprocess launchers are demonstrating and why a development launcher is not a deployment package.
When evaluating a specific panel, follow its public reference rather than inferring a framework guarantee from the interface. The workbench is most useful as a collection of bounded probes held in one place.