Use the operator workspace

The daemon's client surface exposes a local browser workspace over the same board and fleet facts the CLI reads. It comes up with the daemon; autodev serve still starts it as a separate process for one release and is no longer the supported way. The client is embedded in the binary; the --ui option is a development override, not an install requirement.

Start for one local operator

autodev daemon start --single-user

Open http://127.0.0.1:7777/. The server refuses non-loopback binds because its snapshots can contain repository documents, transcripts, diffs, and runtime history.

--single-user grants permitted mutations to every client on loopback. To start read-only, omit both --single-user and an act token. To grant mutations with an explicit secret, start the daemon with an act token and present it to the client as the token query parameter:

autodev daemon start --act-token '<secret>'

Treat the token as a local credential. The UI still applies its role ladder: possessing a connection does not make every command available, and every accepted or refused action is audited.

Follow the product flow

The current workspace is organized around these views:

View	What it answers
Canvas	Which live panels are useful for the operator's current situation, rendered from a validated declaration
Project	Which repository documents define the project, and what commands can be run against its files
Plan	Which stories exist, what is ready, and which planning or runtime facts explain a story
Build	What the coordinator, workers, workflows, reviews, integrations, gates, and deliveries have actually recorded
Review	Which waves or evidence need attention, with diffs, transcripts, relations, and retrospectives for investigation
Connect	Which compiled connectors and operations exist, and whether the required local credential is wired
Operate	Which requests were recorded, who submitted them, and what durable answer or refusal they received

Build separates an accepted handoff from a landed delivery. A candidate can be implemented and reviewed while still absent from the base branch; the Integrate view keeps that boundary visible. The retained event tail is useful for recent activity, but whole-store delivery projections—not the browser's local history—determine the displayed lifecycle stage.

Talk to a coordinator or agent profile

The Coordinate view and the conversation overlay submit the same durable request envelope as the CLI:

autodev conversation say --profile coordinator "Explain why APP-42 is withheld"
autodev conversation show --profile coordinator

An answering agent names the request it is answering:

autodev conversation answer \
  --request <request-id> \
  --outcome answered \
  "APP-42 is waiting on APP-17."

Requests and answers are records; a chat bubble alone is not evidence that code ran or a story landed. The Operate request queue preserves the exact input, principal, profile, source, time, id, and observed outcome.

The Tasks tab is intentionally incomplete in 0.1.0. Requests can be recorded and answered, but no published classification event yet binds a request to a typed task. The UI says that boundary is missing instead of inventing ownership or status.

Read the canvas safely

Canvas documents use a closed component vocabulary and datasource handles. They cannot embed scripts, arbitrary URLs, or credentials. The server validates and resolves a declaration; the browser renders the resolved tree. An unavailable handle or unsupported component is shown as a named refusal rather than a blank panel.

Canvas authority comes from its resolver, not from the document. A panel can ask for a governed operation, but the current principal still needs the relevant grant before the operation can run.

Preserve the truth boundary

Browser settings, filters, named layouts, and time-travel cursors are view state. They do not modify fleet history. When a count, timestamp, cost, transcript, or stage is absent, the workspace renders it as unknown or unavailable; it does not substitute zero or infer completion from board status.

For exact command syntax and automation, use the CLI reference. For service registration and process topology, see Central daemon and workspaces.