Dashboards and serving

Cheetah maintains two different human-facing applications. DevConsole is the general diagnostic shell. Workbench is a guided, product-oriented interface for selecting and confirming operations. They can share components without having the same authority or intended audience.

The older monitoring, history-explorer, and client-inspector applications remain compatibility and migration surfaces. New general diagnostic integrations should use DevConsole or the diagnostics API rather than treating all dashboard directories as equal products.

Choose DevConsole or Workbench by responsibility

DevConsole organizes inspector evidence into overview, activity, clients, history, pending RPCs, contexts, and command traces. It can remain observation-only or reveal command dispatch when the host supplies a control API base.

Workbench is intentionally write-capable and workflow-specific. It adds operation definitions, parameter handling, target review, confirmations, and product policy. It is not a generic read-only replacement for DevConsole.

DevConsole's diagnostic contracts are reusable across deployments. Workbench behavior belongs with the product and operation definitions that give its controls meaning.

Build the asset before serving it

The maintained dashboards are Vite applications. The Python mount helper serves generated files; it does not compile React when the application starts.

bootstrap.cmd --dashboards

The DevConsole build writes cheetahUI/dashboards/dev-console/dist/index.html and a build-info.json record. The build identifies its source revision and whether that source was dirty. The mount helper validates provenance and warns when a served revision differs from the current checkout, so an outdated UI can be distinguished from outdated runtime evidence.

The generated asset and Python serving helpers live in cheetahUI; they are not installed by the servercheetah package. A deployment must use a prepared source checkout or define its own explicit packaging step.

Place the host beside the evidence it can read

In-memory inspectors hold Python objects inside one process. Mount the diagnostics router and DevConsole in that process; a separate dashboard process cannot inspect another process's memory.

Redis-backed inspectors can run in a separate observation service. The supplied standalone server constructs Redis inspectors for one deployment identity, mounts diagnostics, and serves DevConsole without a control base because it owns no AppNode. It can also use the matching spill path needed to hydrate externalized history payloads.

This placement decision affects what the UI can observe. It does not make the dashboard the owner of server lifecycle, history retention, or business state.

Mount observation and control independently

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 deliberate. The helper's default control base is /api/dev; an omitted argument would inject that location and reveal the Dispatch tab. Supplying a control base still does not create or secure the control router. The host must separately mount create_dev_console_router(app_node, admin_auth=...) and protect it.

Static files, read routes, and write routes are three separate pieces. Check all three when a page loads but evidence is absent or a dispatch control unexpectedly appears.

Put a real browser access boundary in front

The unchanged DevConsole cannot attach X-Admin-Key. Binding it beyond loopback with only the built-in API-key mechanism makes its browser requests receive 403; removing authentication is not the solution. Use a same-origin authenticated gateway or a deliberately designed session integration, and apply equivalent protection to the control path.

The diagnostics API may expose payloads, identities, URLs, topology, traces, and pending work. Control can request any advertised action that central and local policy permit. Treat the first as sensitive administrative data and the second as an operational command surface.

For detailed mounting, capability, and control semantics, continue with DevConsole and operator interfaces.