Skip to main content

Dashboard Development

note

This page covers extending the dashboard. To use it day-to-day, see the user guide.

Dashboard code lives in internal/dashboard. It is a server-rendered Go UI that uses gateway RPC methods instead of importing product runtime internals.

Server Routes

Routes are registered under /dashboard. Page handlers live in page_*.go, shared routing in routes.go, and static assets under static/.

Keep route handlers thin: decode request, call RPC, assemble view data, render a template or redirect.

RPC Proxy

Dashboard RPC calls go through the dashboard RPC client/proxy and the gateway protocol methods in internal/protocol.

The allowlist should be updated when a new dashboard feature needs a method. Do not proxy arbitrary method names from the browser.

Pages

Templates live in internal/dashboard/templates. Each page should have a small view model, deterministic empty/error states, and tests using the fake RPC client.

Prefer linking to existing user docs for workflow explanation instead of putting long help text in the UI.

Forms

Forms should post to dashboard handlers, validate input, call RPC, and render a small status fragment or redirect. Secret fields must be submitted as secret refs or stored through setup RPCs.

Do not echo submitted token values back into HTML.

Localization

Locale files live under internal/dashboard/locales. Use stable keys rather than embedding English strings in templates.

When adding a visible label, update at least the English and zh-CN locale files or keep the label intentionally non-localized.

Smoke Tests

Use Go handler tests for route behavior and Playwright-style dashboard tests when checking interactive flows or layout-sensitive pages.

Channel, MCP, model, chat, memory, approvals, and roles pages already have test patterns to copy.