Console

chorus-console is a SvelteKit 2 / Svelte 5 app (adapter-node, port 4319). Every Chorus API call happens server-side — in +page.server.ts loads, form actions, and a few JSON proxy endpoints. The browser only ever talks to the SvelteKit origin; the API key never reaches the client (inv:console §1). All upstream calls go through the @chorus-protocol/sdk client built per-request from the wallet session.

Routes

Route	What it does	Notable
/	Static placeholder card	Stale “scaffold / stubbed surfaces” copy — all eight surfaces below are live (+page.svelte:1-22)
/login-with-wallet	3-step SIWE wallet login	Signs the exact server-issued login challenge and mints a 24h session key
/sign-out	Revokes the current Chorus key, deletes the session cookie, redirects	A failed upstream revocation leaves the cookie so the user can retry
/inbox	Personal summary-first Inbox	Current/Later, ring scope, explicit open, Seen/Done/reply
/tasks + /tasks/[id]	Native execution-task board (7 state columns)	Detail shows runs, deliveries, checkouts, diagnostics
/kanban	Workstream board (5 status columns)	Drag-to-move status + priority edits; no create UI
/rings + /rings/[name]	Ring atlas + charter/policies/protocols/members/activity/library tree	Read-only
/memory + /memory/[id]	Memory browser (namespace + type filters, query/list)	Read-only
/briefing	Compact catch-up over a time window	One focus item, short queue, activity details on demand
/gates	Approval-gate queue (approve/deny/cancel)	Bound gates use “Approve and run” with Ready/Running/Done progress; bearer delegation keeps an advanced copy modal
/circles + /circles/[id]	Auto-approval circle CRUD	The only full create/update/delete surface in the console

The shell (+layout.svelte) renders the sidebar, an identity pill, a health pill, and an SSE heartbeat pill. Every page load issues identity.whoami() and system.healthDetailed() (+layout.server.ts:6-15) — two upstream calls per page.

What the console covers — and what it doesn’t

The console is read + triage + approve + circle CRUD + workstream status/priority. Large parts of the protocol have no console surface: workspace, artifacts, library ask/drilldown/eval, webhooks, dispatchers/runs admin, signal compose (only replies), memory writes (the browser is read-only), and creation of workstreams/tasks/rings/ roles/identities/invites (inv:console §4). Use the CLI or MCP tools for those.

Live updates use canonical durable messages

The server emits event: message on the canonical /events/stream with a versioned, body-free change envelope. Signal, task, receipt, approval, and audience changes carry only invalidation metadata; pages reload their bounded projections. The layout owns exactly one EventSource; inbox, gates, briefing, and the heartbeat subscribe to its typed router instead of opening page-local connections. The last accepted cursor is stored under a non-secret fingerprint of the signed console session. On reconnect or a console-server restart, /api/stream?cursor=… validates that cursor and forwards it to Chorus as Last-Event-ID. The API key remains in the HttpOnly session/server boundary.

The router deduplicates cursors, bounds pending browser work, pauses while the tab is hidden or offline, and reconnects with bounded jitter. Cursor expiry/unknown state forces a fresh page snapshot before streaming resumes; revoked authorization stops retrying. These states are exposed through the accessible shell status pill. Proxy-only failures use event: console-control with chorus.console-stream/1, so they cannot be mistaken for canonical chorus.change-stream/1 messages. Browser disconnect always cancels the upstream reader.

Health pill reads “offline” for non-admins

GET /health/detailed was made admin-only in #348 (src/health/routes.ts:52, requireAdminPolicy). The layout calls it on every request and renders “health offline” when the call fails (+layout.svelte:136-138). The console predates the gating and was never repointed at the public /health, so non-admin sessions show a permanently offline health pill (inv:console §3 Finding 2).

Wallet login signs server authority, not browser-built text

The console sends wallet address and active chain to Chorus through its server-side challenge proxy, then presents the exact returned EIP-4361 bytes to the wallet. It does not reconstruct domain, URI, nonce, timestamps, purpose, or request ID in the browser. Chorus binds the challenge to its configured public origin and chain verifier, consumes it with session-key creation, and the console stores that key only in an HttpOnly SameSite=Strict cookie. The identity must already exist; the console still has no invite-redemption or registration UI.

Admin-dependent degradation

identities/list is admin-only. Non-admin sessions silently lose features that resolve identity names: circle approver pickers, kanban owner labels and filter, memory agent:* namespace options, and ring member names (raw IDs shown instead) (inv:console §4).

Quirks worth knowing

• Kanban stale-NotFound recovery (kanban.server.ts:83-94): on a workstream-update error the page re-lists workstreams to check whether the patch actually landed — a client-side workaround for a read-after-write wart, not a contract.
• Memory detail scans pages instead of calling memory.get (which exists since #263), walking up to 8 pages × 100 across visible namespaces (memory/[id]/+page.server.ts).
• Offline error strings on all pages say CHORUS_API_KEY is not set — misleading in production, where the wallet session is the auth path.