Dashboard

The Signet dashboard is a React 19 + Vite single-page application served by the local daemon. It is a visual interface for the same local daemon API used by the CLI and integrations.

Start the daemon, then open the dashboard:

signet daemon start
signet dashboard

The default URL is http://localhost:3850. If you set SIGNET_PORT, use that port instead.

Open #setup to walk through onboarding. Navigating to another dashboard page before reaching Ready asks you to confirm leaving setup; cancelling keeps your current step and drafts open. After Welcome, How it works explains capture, recall, and Dreaming before you make configuration choices. Identity lets you name the workspace’s agent, optionally add your name, choose the same Minimal, Hermes, OpenClaw, or Custom identity preset offered by CLI setup, and edit the selected identity files. Existing contents are loaded into the editor; unselected files stay in place. You can also leave identity management to your existing tools. MEMORY.md remains generated by Signet. Saving this profile does not rename an agent’s memory scope or create a separate agent in the registry. The Search step configures embeddings for search by meaning, with built-in local, Ollama, llama.cpp, hosted OpenAI, or keyword-only options. Saving uses the existing daemon configuration path; checking availability is separate from completion of an index rebuild. You can keep your existing search settings instead. The walkthrough ends with a summary of connected tools, background memory, search, sources, and your first saved memory.

Home, Memory, Dreams, and Settings are client-rendered hash routes. Home includes sources and memory search; Settings has its own sections for data and files, connectors, network, inference, secrets, logs, advanced options, and licenses. Select the three dots at the bottom of the sidebar to open Settings.

Dashboard reads share a session-only cache. Returning to a page shows its last successful result immediately. Fresh results avoid another daemon request; stale results refresh in the background. Simultaneous reads of the same query share one request, and slow polls do not start overlapping requests.

The cache retains at most 48 results and 12 MiB of serialized payloads, with a 4 MiB per-result limit. Least recently used results are evicted first, and inactive results expire after five minutes. These are payload bounds, not a measurement of JavaScript heap usage. Parameterized reads, including constellation snapshots, memory searches, and individual Dreaming passes, have separate keys. The cache is scoped to the daemon origin and authentication token, is cleared on authorization failures. Successful dashboard mutations invalidate the affected queries for background refresh. The cache is never persisted to disk. Refreshing the application starts a new cache.

Visible pages poll at their existing intervals; hidden pages and windows stop polling. Failed background reads retain their last successful result and show that updates are unavailable. Read requests have a 20-second deadline. The daemon continues to own database access and every durable transition, including in the desktop application.

The constellation currently refreshes a bounded snapshot. This cache does not introduce graph streaming or a change-feed protocol; external changes are picked up on the next visible-page refresh.

Memory graph

The Memory view uses a 2D force graph. Entity clusters follow the ontology’s entity → aspect → group key → claim key → stored value hierarchy. Evidence references and sources remain distinct from stored values; dashed links show attribution, and arrows show directed cross-entity dependencies.

Drag the background to pan with momentum, drag a node to reposition it, and scroll to zoom. Linked nodes respond to dragging and settle after release. Focus and navigation buttons animate pan and zoom. Connection highlighting waits briefly for the pointer to settle on a node, then fades between highlights. The zoom buttons and Fit graph offer the same navigation without scrolling. Select a node to inspect its content and provenance. With the graph focused, arrow keys browse nodes, Enter selects, and Escape resets the view.

Ask Signet about your memories starts from a compact input at the bottom of the graph. Sending a message opens chat in a right sidebar and moves the input there; the canvas resizes beside it. Closing chat returns the input to the graph and keeps the conversation available for the next message. Selected-node details open in the dashboard’s standard detail dialog, independently of chat. On narrow screens, chat sits below the canvas.

The chat opens a streamed conversation with the daemon’s Pi agent. It uses existing scoped memory and ontology retrieval tools and can highlight retrieved entities and evidence in the graph. Retrieval highlights fade between batches and stay visible until the next question or New chat. The camera automatically follows retrieved nodes on every message. Dragging, scrolling, keyboard navigation, or the navigation buttons pause following for the current response; the next message resumes it. Hover and inspection remain independent. Evidence outside the bounded graph snapshot remains available in the chat sources. The model inherits the backend inference assignment unless an explicit interactive workload overrides it; the selected model must support tools. The composer model picker searches the Pi AI registry for models available through connected Signet accounts. Signet default keeps the backend assignment; choosing a model applies it to subsequent messages in this chat without changing your inference settings. The daemon rechecks credentials on every selected-model request.

You can explicitly ask Signet to remember new context or ask Dreaming to review it. Saving records your exact message as evidence through the normal memory write path. Directed Dreaming records the instruction first and requests an existing scoped Dreaming pass. A requested pass is distinct from a completed pass; Dreaming remains the semantic writer. These actions retain the daemon’s normal write and administration permissions.

The agent cites evidence with Obsidian-style wikilinks such as [[memory:exact-id]] or [[artifact:exact-source-path]]. References must match evidence retrieved in the conversation; unverified references remain text. Verified inline source references appear as compact pills; select one to inspect its retrieved excerpt and full reference. Responses render streaming Markdown, with copy actions and expandable evidence attached to each answer. The conversation follows new responses until you scroll up; use the down arrow to return to the latest message. Enter sends a message, and Shift+Enter adds a new line.

Conversation history stays in browser memory until New chat, leaving the graph, or a reload. Each conversation reuses a native Pi session in a daemon-managed worker, including its tool history, across turns. The worker expires after 15 minutes idle; closing the sidebar or stopping a response does not end the session. New chat starts a separate conversation and the previous idle session expires normally. Model switching preserves the Pi session. Conversations are not automatically stored as transcript evidence; explicit remember requests use the normal evidence path. Stop response cancels inference; evidence already saved and Dreaming already requested remain. Retrieval errors and unavailable models are shown explicitly. The reusable chat component can be mounted elsewhere without graph callbacks.

The graph requests a bounded snapshot of up to 150 entities and displays at most 5,000 nodes, prioritizing hierarchy anchors. Open the graph key for node categories, counts, and gesture hints.

Sources and imports

Use the Sources section on Home to work with source-backed recall:

Connect a source offers the dashboard’s basic Obsidian, GitHub, and Discord forms.
Import files uploads text, Markdown, JSON, HTML, CSV, and supported document formats as durable source artifacts.
Existing source cards show health and index status and provide re-index, snapshot, and remove actions.

The dashboard connect form intentionally exposes only a small set of fields. In particular, Discord uses a guild ID, optional display name, and a secret reference for its bot token. Advanced Discord options such as sync mode, filters, cache paths, and bounded indexing settings belong in the Discord source API reference, not in the dashboard form.

For the source lifecycle and import behavior, see Sources. For HTTP request and response shapes, see Documents and sources API.

The Sources dashboard distinguishes file-import job progress from Dreaming attention and consumption. It shows the job id immediately, per-file states, imported/duplicate/rejected/pending counts, bounded rejection details, and reconciliation. Pause, resume, retry, and cancel call the daemon controls; the browser does not maintain a second client-only queue. The target agent is required, and any embedded transcript agent id is displayed as provenance only.

Serving behavior

The daemon serves the built dashboard as a generic static SPA. Its dashboard handler passes /api/*, /health, and /sse through to their own handlers; remaining extensionless paths fall back to index.html.

A packaged daemon can also serve embedded dashboard assets. If neither a built nor embedded dashboard is available, / shows a small API-only fallback page rather than a dashboard.

Development

The dashboard source lives in surfaces/dashboard/ and uses React, Vite, Tailwind, and shadcn/ui. Run its development server from that package:

cd surfaces/dashboard
bun run dev

The development server serves the frontend separately from the daemon. Start a daemon as well when you need live API data.

Developing onboarding

From the repository root, run:

bun run --cwd surfaces/dashboard dev:onboarding -- --port 5174

Open http://127.0.0.1:5174/#setup for the full-page onboarding flow. In the desktop app, setup sits below the native window-control area. This development-only mode shows all supported harnesses for layout review, regardless of what is installed locally. It uses demo data and simulates harness connections, configuration saves, model sign-in/testing, and remembering/recalling the first memory in browser memory. Reload to reset the walkthrough. No requests reach the daemon; unsupported preview actions report an error. Sources can be skipped; file imports are not simulated. Normal dev and production builds retain real daemon behavior.