Maturity and limits
Cheetah contains a stable coordination center and several optional or developing surfaces. The limits below are part of the public contract because they affect architecture, security, and operating choices.
Strongest implementation surfaces
The Python server core, shared TypeScript runtime, browser client, and console client have the strongest implementation and focused test evidence. The one-process command path and Redis-coordinated multi-role paths are implemented and exercised. Diagnostics, tracing seams, worker contexts, capture/parsing support, reusable UI, derived views, relays, and solution layers exist with feature-specific boundaries.
The web runtime has a smaller validation surface. Mobile/native support is earlier and does not have equivalent TypeScript test and feature coverage.
Reliability limits
- Delivery acceptance, socket write, client ACK, handler execution, and external completion are separate facts.
- A waiter timeout does not cancel every client action or prove that no late result exists.
- Cheetah does not replay an uncertain send automatically.
- Redis command mailboxes retain admitted logical-client work within their configured policy; their node wake-ups are disposable hints recovered by reconnect checks and periodic sweeps. Response notifications are also signals, while history retains accepted application messages. None of these facilities is a durable product job system.
- Application futures do not migrate when their process dies; retained results can still be queried later.
- Browser service-worker recovery is partial and must reconstruct current runtime and page state.
- Worker assignments are live coordination, not durable jobs. Browser auto-provisioning locks, reservations, and selection counters are process-local even when the underlying registries are shared. The current manager also does not enforce negotiated console
max_flows.
Storage and history limits
- History is retained application evidence, not a complete outbound command ledger or compliance log.
- In-memory and Redis timestamp-filter behavior is not identical; cursors are the portable incremental checkpoint.
- Managed Redis-history spill assigns one immutable expiry to the reference and external payload. The built-in file store hides expired values, cleans expired files during continued managed writes, and exposes an explicit cleanup hook. An idle store is not guaranteed to reach zero files without that hook; explicitly unmanaged custom stores remain operator-owned.
- Product business state, idempotency, and reconciliation remain product-owned.
- The current shared-tenancy baseline excludes active tracing, payload offload, central policy, the built-in parser registry, and Derived Views. Each needs a separately verified tenant-aware boundary before use in that mode.
- Derived Views is a frozen, experimental v1 facility for a trusted single-tenant host. The host owns scheduling, bounded state and reducer cost, one cross-process writer, retention and migration, and persisted-state deletion. See the derived-views reference before depending on it.
Production and tenancy limits
- The production preset rejects selected unsafe inputs but does not create a production platform or verify the deployed edge.
- Ordinary node execution does not automatically invoke the supplied rate-limiter and audit- logger interfaces.
- Redis delivery admission has a bounded resource quota; organization and customer quota semantics are not universal.
- Shared tenancy validates known component behavior but does not supply provisioning, billing, support policy, application-database isolation, or compliance deletion.
- Shared tenancy provides logical data-plane isolation, not universal per-tenant CPU, network, Redis memory, history, connection, or downstream-service quotas.
- The repository does not provide a universal supported Docker, Kubernetes, reverse-proxy, or cloud deployment bundle.
Diagnostics and UI limits
Diagnostics require an explicit administrative boundary. The ready browser DevConsole cannot currently add the built-in X-Admin-Key header itself, so non-loopback deployment needs an authenticated gateway or session integration.
Some diagnostic aggregations are intentionally bounded or paginated and can be partial. Redis scan pagination can return an empty page with has_more: true; continue with its opaque cursor. Raw retained payloads and control routes have stronger sensitivity than ordinary health data. Delivery inspection is implemented, but the current DevConsole does not yet expose its complete mailbox, dispatcher-node, reservation, or browser-window surfaces. The reusable UI components are private source consumed by Cheetah's dashboards rather than a supported self-styling package.
Protocol and packaging limits
Protocol compatibility uses exact configured versions. It does not select a nearest version, downgrade, or fallback automatically. Capability advertisement is a startup snapshot. response.mode supports rpc and none, not stream. Progress and result payloads may be a JSON object, explicit null, or absent; arrays and primitives are rejected.
The TypeScript declarations are verified with the workspace's bundler-style module resolution. NodeNext declaration resolution has a known limitation on emitted barrel paths; use public package exports rather than internal paths.
How to make a production claim
Validate the actual product journey through its proxy, identity, Cheetah roles, stores, client platform, authorization, external target, diagnostics, and recovery policy. Include allowed and denied actions, restart or replacement, timeout, late return, tenant isolation where applicable, and cleanup.
State the resulting guarantee at the level proved. A successful local connected action proves the functional path. A mixed-version, failure-injected, monitored deployment exercise is needed for a broader operational claim.