DevConsole and operator interfaces

The maintained DevConsole is Cheetah's general diagnostic dashboard. It turns inspector responses into an operator path through overview, activity, clients, retained history, pending RPCs, execution contexts, and command traces. It remains a presentation layer over explicit HTTP boundaries: mounting static files does not create inspectors, administrative authentication, or a control API.

Choose observation-only or control-enabled operation

mount_dev_console() injects two independent runtime locations into the built page:

api_base identifies the read-only diagnostics API;
dev_api_base identifies the optional write-capable control API.

from cheetahUI.server.mount import mount_dev_console

mount_dev_console(
    app,
    prefix="/monitor",
    api_base="/api/diag",
    dev_api_base=None,
)

Passing None is important: the helper's default control base is /api/dev. With no control base, the client explorer hides its Dispatch tab. Supplying a control base reveals that tab but does not mount or secure the route. The host must separately create create_dev_console_router(app_node, admin_auth=...).

The control route always sends an RPC through the normal AppNode path. Central authorization, client-local policy, argument validation, approval, targeting, leases, handler execution, returned message authentication, and history still apply. Intentional central permission_denied decisions return a sanitized 403; an authorization evaluator failure remains a sanitized 500. A waiter timeout returns 408 and does not prove client cancellation.

Control can navigate a page, modify a file, run a console action, or invoke any other advertised handler the policies allow. Treat enabling it as a separate product and security decision rather than as an extra diagnostic panel.

Build and identify the dashboard asset

The supplied mount and standalone helpers serve a generated Vite application. They do not compile React at application startup. From a prepared Cheetah checkout, build the maintained dashboards:

bootstrap.cmd --dashboards

The DevConsole build produces cheetahUI/dashboards/dev-console/dist/index.html and build-info.json. The mount helper refuses an existing asset without valid build provenance and warns when the asset revision differs from the current checkout. The UI can show the build identity, making a stale dashboard distinguishable from a stale server response.

These serving helpers and generated assets live in cheetahUI; they are not installed by the servercheetah Python package. A deployment using them today needs the Cheetah source tree or its own deliberate packaging step.

Choose the host from the state family

An in-memory deployment must mount inspectors and the DevConsole in the same process as the live components. A separate process cannot inspect another process's Python objects.

Redis deployments can use cheetahUI/server/standalone/server.py. It creates Redis inspectors for one required deployment_id, mounts the diagnostics router, and serves the DevConsole with no control base because it owns no AppNode. It defaults to loopback and can use a matching spill path to hydrate externalized history.

The ready browser client currently issues ordinary fetch requests without an option to add Cheetah's X-Admin-Key header. Protecting the API with ApiKeyAdminAuth therefore makes the unmodified page receive 403. A non-loopback deployment needs a surrounding same-origin authenticated gateway or session integration. Do not embed a long-lived administrator key in browser JavaScript or weaken the diagnostics router to make the page load.

Understand what the current console does not expose

The server diagnostics surface is ahead of the UI in several areas. The DevConsole summarizes worker pressure from sampled contexts and provides a context view, but its typed client has no browser-window or delivery-inspector methods. It therefore does not yet provide complete mailbox, delivery-node, reservation, or window panels.

Command traces can expose trace, command, user, client, instance, node, stream, RPC, and parent-span identities. A host may supply window.CHEETAH_OBSERVABILITY_LINKS templates that turn available identities into links to an external trace, log, or metrics system. Links whose required fields are absent stay hidden. The DevConsole does not embed an APM backend or make a trace authoritative.

Keep the other UI boundaries explicit

@cheetah/ui contains the domain components and composites used by Cheetah's own dashboards, but it is a private, source-consumed package. The dashboards supply the Tailwind build environment that its utility classes require. It is not currently a supported installable, self-styling package for arbitrary applications.

The Workbench is a separate guided, write-capable application. Its operations, Product01 policy controls, target review, and confirmations make it unsuitable as a generic read-only diagnostic shell. The older monitoring, history-explorer, client-inspector, and inline server dashboards are deprecated compatibility surfaces and migration targets; new general integrations should use the DevConsole or the diagnostics API.

For the server-side read contract, return to Diagnostics API and security. For the optional technical timing path, continue with Server tracing.

For reusable components, composites, themes, payload renderers, and source-level styling limits, continue with UI integration.