# Dashboard layout > Part of [Web UI](../web-ui.md). See also: > [Shape (shared)](shape.md) · [Per-agent page](agent.md) The dashboard is served at `/dashboard.html` (with the home page at `/`). It has a fixed chrome header at the top and a `
` that shows exactly one tab pane at a time. The URL hash (`#swarm`, `#call`, `#system`, `#permissions`, `#schedules`, `#peers`, `#settings`) drives which pane is active; hash changes don't reload the page. FL0W, L0GS, and the optional M4TR1X client are separate pages reachable from the H0M3 hub at `/`, not from the dashboard tab strip. **Chrome header** (fixed, overlays the active tab pane): - **← home back-link**: top-left of the chrome, links to the H0M3 hub at `/`. Every surface links back to the hub rather than to each other. - **Tab strip**: `◆ SW4RM ◆`, `◆ Y3R C4LL ◆`, `◆ P3RM1SS10NS ◆`, `◆ SCH3DUL3S ◆`. In-page tabs only — the SYST3M panels moved to the standalone **C0R3** page (`/core.html`), and FL0W / L0GS / ST4TS / S3TT1NGS / M4TR1X live on their own pages too, all reachable from the H0M3 hub (not the tab strip). Peer hives render as a headline under SW4RM rather than a tab. Count pills on SW4RM (container count), Y3R C4LL (pending approvals + questions + unread operator messages), and SCH3DUL3S (active schedules); P33RS and S3TT1NGS have no count. - **Banner-thin** (`░▒▓█▓▒░ HYPERHIVE / HIVE-C0RE / WE ARE THE WIRED ░▒▓█▓▒░`) — sits below the tab strip. - **Server-warnings banner** — a generic, sticky top-of-page strip shown on **every** page (dashboard + the stand-alone FL0W / L0GS / H0M3 pages), injected at the top of `` by `renderServerWarnings` in `common.js`. Driven by `state.server_warnings` — a list of `{ kind, level, message }` from hive-c0re's `host_stats::server_warnings` — and coloured by `level` (`warn` amber / `crit` red). The backend owns the threshold + message, so adding a new system warning needs no frontend change. The only producer today is the host disk-pressure check (a `statvfs` probe of `/nix`: ≥85% used → `warn`, ≥95% → `crit`, e.g. `⚠ host nix store N% full (G GiB free) — garbage-collect …`). Hidden when there are no warnings. - **Browser tab title** — `hive / c0re` by default; updated to ` / ` once `hive_name` / `swarm_name` arrive in the state snapshot. When there are pending approvals or unanswered questions, a `(N)` prefix is prepended — `(3) pr1ma / hive-c0re` — so the operator can see the call count in an unfocused browser tab without opening the dashboard. The prefix is set on the initial `/api/state` cold-load and updated live by `approval_added` / `approval_resolved` / `question_added` / `question_resolved` SSE events; it's preserved when `hive_name` / `swarm_name` later replace the raw title. The FL0W and L0GS pages use a slim header (a `← home` back-link + the page title) rather than the dashboard tab strip — they're standalone surfaces, not tab panes. ## SW4RM tab **C0NTAINERS** — live containers rendered as a depth-first tree using `ContainerView.parent` (populated by `topology.rs`). Each container's row is prefixed with ASCII tree glyphs (`├─`, `└─`, `│ ` continuation columns) showing the agent parent/child hierarchy. When every container has `parent = null` (flat topology) the tree collapses to a plain list with no glyphs. Children are sorted alphabetically within each parent; roots likewise. Cycles in the parent graph are tolerated — orphaned containers (not reachable from any root) are appended as roots so no agent disappears. Pulsing red banner at the top of this section if any two sub-agents hash to the same port (`port_conflicts` from `/api/state`): the operator must rename one of them and rebuild. `lifecycle::{spawn,rebuild}` also preflight this and refuse with a clear error message naming the conflicting agent. `↻ UPD4TE 4LL` button appears above the containers list when any agent is stale. ## Y3R C4LL tab Things blocked on operator decision — approvals and questions share a tab because they're the same concept ("something is waiting on you"). **P3NDING APPR0VALS** — the queue (see "Approval card" below). The R3QU3ST SP4WN form lives at the top of this section. A `pending · N` / `history · N` tab pair switches between the live queue and the last 30 resolved approvals (see "Approval card" for the history row shape). **M1ND H4S QU3STI0NS** — pending `ask` calls waiting on the operator, with amber pulsing border. Anatomy of each card: - **Filter chips** — `all · N`, `@operator · N`, `@peer · N`, plus one chip per participant name (`@asker · N` / `@target · N`). Every chip shows its own count so the operator can see the distribution at a glance. Clicking a chip narrows the visible list; selection persists in localStorage so a tab switch doesn't lose the filter. - **Question card** — timestamp · asker → target · body text (with file-path links). Operator-targeted questions (`target = null`) show `▸ ANSW3R`; peer-targeted questions (`target = agent`) show `⤿ 0V3RR1D3` so the operator can unblock an agent-to-agent exchange. Questions with a `ttl_seconds` show a `⏳ MM:SS` live countdown chip; the host-side watchdog resolves with `answerer = "ttl-watchdog"` on expiry. - **Answer form** — free-text textarea (Enter = submit, Shift+Enter = newline) + optional option list (radio for single-select, checkboxes for `multi=true`). Submit merges selected options + free text comma-joined into a single `answer` field. `✗ CANC3L` is a separate form so the submit merge handler doesn't interfere. - **◆ answ3red (N)** — collapsible `
` below the pending list; shows the last 20 resolved questions with their answers. **0PER4T0R 1NB0X** — messages agents have sent to `to="operator"` but the operator hasn't read yet. Cold-loaded from `/api/operator-inbox` on tab activation + page load; appended live from the broker `sent` stream (deduped on row id). Each row shows sender · timestamp · body (with file-path linkification). A `✓ mark all read` button on the right acks all rows via `POST /api/agent/operator/mark-all-read` (reuses the existing mark-read endpoint). Unread count folds into the Y3R C4LL tab pill so messages are visible from any tab even while inactive. Backed by `GET /api/operator-inbox` → `{ messages: [...] }` (id, from, body, at, in_reply_to, file_refs). ## C0R3 page (`/core.html`) Passive / rare-interaction state. No longer a dashboard tab — it's a standalone page reached from the **Core** tile on the H0M3 hub (served at `/core.html`), with the same minimal chrome as `/logs.html`: a `← home` back-link + a `createTabStrip` sub-tab nav (**K3PT ST4T3** default, then **C0NT41N3R L04D**). The page is its own esbuild bundle (`core.js`) that cold-loads `/api/state` and subscribes to `/api/dashboard/stream` for `tombstones_changed`, `capabilities_changed`, and `tool_groups_changed` (the latter two re-render the stale-perms sub-section when permission data changes). (Rebuild queue and meta inputs have moved to the BU1LDS page — see below.) **K3PT ST4T3** — two sub-sections on one pane: *Tombstones*: destroyed-but-state-kept agents (size + age + claude-creds badge). Two actions: `⊕ R3V1V3` (queues a Spawn approval; existing state is reused), `PURG3` (wipes state + applied dirs; `POST /api/purge-tombstone/{name}`). *Stale permission entries*: agents with explicit capability or tool-group JSON entries but no live container — typically renamed or deleted agents whose entries persisted in `capabilities.json` / `tool-groups.json`. Lazy-loaded on first K3PT ST4T3 tab activation; auto-refreshes on `capabilities_changed` + `tool_groups_changed` SSE events. Each ghost agent gets a `✕ clear perms` button (`DELETE /api/permissions/{name}`). **C0NT41N3R L04D** — live CPU + memory per agent container, read straight from cgroup v2 on the host (`cpu.stat`, `memory.current`, `memory.peak`, `memory.max` under `/sys/fs/cgroup/machine.slice/machine-h\x2d.scope/`). CPU is a host-normalised percentage (0..100 across all cores) sampled over a short (~200 ms) two-read interval; memory shows current + peak with a bar against the `memory.max` quota. Backed by `GET /api/container-resources` (`container_stats.rs`), which reads the files read-only (world-readable; no `hive-priv`) and skips agents whose scope dir is absent (= not running). Pull-only: `core.js` polls every 5 s **only while the C0NT41N3R L04D sub-tab is active** (CPU needs a fresh sample each refresh), and stops on sub-tab change. Disk size (`disk_bytes`) rides the same row but is fed by a separate ~5 min background `du` sampler (state dir + container writable rootfs, shared nix store excluded via `du -x`), so the 5 s poll stays cheap cgroup-only reads; the row carries the last-sampled value (`null` until the first sample). Network is intentionally omitted — agents share the host netns, so there is no per-container net counter (per-agent network needs the netns-isolation roadmap in `docs/network.md`). ## BU1LDS page (`/builds.html`) The build lifecycle hub — rebuild queue, live build log, meta inputs, and build log history on one page. Standalone page reached from the **Builds** tile on the H0M3 hub, same minimal chrome as `/core.html`. Three sub-tabs: **R3BU1LD QU3U3** (default), **M3T4 1NPUTS**, **BUILD L0GS**. Its own esbuild bundle (`builds.js`); cold-loads `/api/state` and subscribes to `/api/dashboard/stream` for `rebuild_queue_changed`, `meta_inputs_changed`, `meta_update_running`. The dashboard tab keeps the rebuild-queue *state* for the SW4RM card badges without rendering these panels. **R3BU1LD QU3U3** — pending and recently-completed container operations: rebuilds, meta-update cascades, and first-spawns. One operation runs at a time; the worker drains FIFO. Each row shows a state glyph (`⏸` queued / `▶` running / `✔` done / `✖` failed / `⊘` cancelled), kind glyph + verb (`↻ rebuild`, `◆ meta_update`, `✨ spawn`, `🗑 destroy`, `↺ restart`, `⚡ startup_sweep`, `🔑 perm_change`, `⏹ graceful_stop`, `▶ start`, `■ stop`), agent name, source chip (`manual | meta_update | auto_update | startup_sweep | crash_recover | approval` — green for operator-approved config changes), timing, and an optional reason / error. Meta-update cascade rebuilds and deferred-start follow-ups nest under their parent entry (`parent_id` grouping; `rqe-child` CSS class — e.g. a `Rebuild` entry groups its `Start` child, which fires after the profile-swap to free the build lane before the container boot). Dedup: re-enqueueing a still-queued op for the same agent collapses into the existing entry. All timing labels stay live: running entries tick elapsed seconds every second; queued and terminal ("done N ago" / "failed N ago") labels tick every 30s so keyed rows never show stale timestamps as they persist across `rebuild_queue_changed` snapshots. When the worker has annotated the current phase a cyan `↳ ` sub-line appears under the main row showing the in-flight step name (e.g. `↳ meta prepare_deploy` → `↳ nixos-container update` → `↳ finalize deploy`). Terminal transitions clear `step` on the backend so Done / Failed rows don't render stale labels. Queued entries carry a `✗` cancel button on the right edge; running / done / failed / cancelled entries don't show it — the backend refuses cancellation for non-`Queued` rows anyway (`POST /api/rebuild-queue/{id}/cancel`). Successful cancel flips the row to `⊘ cancelled` via the next `rebuild_queue_changed` snapshot. Cold-loaded from `/api/state.rebuild_queue`; live updates via `rebuild_queue_changed` snapshot event. Below the queue, a **live build-log panel** (`#rebuild-live-log`, `renderRebuildLiveLog`) streams the currently-running rebuild's output inline — collapsible, with a live/ok/fail badge and a `↓ raw` download. It's keyed to the running entry's `build_log_id` and opens one `EventSource` to `GET /api/build-logs/id/{id}/stream` (the same stream the BUILD L0GS tab uses; the stream replays accumulated output on connect). It lives in its own container outside `#rebuild-queue-section` so the queue's per-row re-render (rows rebuild as the `step` advances) never tears down the open stream; it hides when nothing is building and each row keeps its `logs →` link out to the full build log history. **M3T4 1NPUTS** — inputs in `meta/flake.lock` the operator can selectively `nix flake update`, rendered as an indented tree: every fetched input at every depth (`hyperhive`, `hyperhive/nixpkgs`, `agent-`, `agent-/mcp-`, …), each shown once at its shallowest path. `read_meta_inputs` walks the lock graph with a `visited` set — `follows` aliases and rev-less nodes are skipped. A `select all / select none` control sits above the tree. Checking inputs + submitting bumps the lock in `/meta/` and rebuilds the selected agents in sequence; each outcome reaches the root agent as a `rebuilt` system event. `POST /meta-update`. While a lock-bump ripple runs, the panel shows a pulsing "⏳ meta-update running" banner and the update button is disabled (snapshot field `meta_update_running`, live event `meta_update_running`). **BUILD L0GS** — all-agents build log history (moved from `/logs.html`). Lazy-loaded on first tab activation; auto-refreshes when `rebuild_queue_changed` fires. Fetches `GET /api/build-logs?limit=30`. Renders a scrollable list of build entries; each row is a collapsible button showing status badge (`live` / `ok` / `fail`), agent name, elapsed duration, build kind, age, and the invocation command line. Expanding a row fetches the full stdout+stderr via `GET /api/build-logs/id/{id}`. A live in-progress build shows a `live` badge with a ticking elapsed-time chip; expanding streams output via `GET /api/build-logs/id/{id}/stream` with sticky-bottom auto-scroll (suspends on manual scroll-up). Deep-link: `?id=N#buildlogs` opens the entry with that id pre-expanded. ## M4TR1X ACC0UNTS page (`/matrix-accounts.html`) Operator surface to provision / log in a per-agent **external** matrix account and store its access token, without editing the agent's config repo. Standalone page reached from the **Matrix accounts** tile on the H0M3 hub, same minimal chrome as `/core.html` (a `← home` back-link + title). Its own esbuild bundle (`matrix-accounts.js`); no SSE — it reads `/api/state` once for the agent picker and otherwise works off two purpose-built endpoints. An agent picker (populated from `state.containers`, the live roster) drives a list of that agent's accounts — name, homeserver, user id, and a status dot — read from `GET /api/matrix-accounts?agent=` → `{ accounts: [ { name, homeserver, token_present, live, user_id } ], as_of_unix }`. `token_present` is whether a token is **stored**; `live`, `homeserver`, and `user_id` are backfilled from the matrix daemon's `matrix-accounts.json` snapshot — a host-visible file the daemon **force-rewrites every ~30s** (a heartbeat), so `as_of_unix` (the snapshot mtime) advances while the daemon is alive and a *stalled* value genuinely means "stopped publishing", not just "old snapshot". An account with a token but absent from the snapshot reports `live: false`. The status dot renders these states: - **green** — `live` and the container is running: online. - **dim green** — `live` but `as_of_unix` hasn't advanced in > ~90s (3 missed heartbeats) while the container is *not* down: the daemon stopped publishing, so the snapshot's `live` is no longer trustworthy (likely dead/wedged). Labelled "online · no heartbeat". - **amber** — `live` but the container is **down** (a stopped container ⟹ a dead daemon, so the snapshot is stale); also the `token_present && !live` "provisioned but offline" case. - **grey** — no token (not provisioned). The container-down cross-reference (`/api/state`) takes precedence over the age check. `as_of_unix` is tooltipped ("live as of N ago") throughout so freshness is always legible. When `live` is absent (an older backend without the snapshot) the dot falls back to a token-present rendering. The provision form (account name, homeserver, login method) posts `POST /api/matrix-account-login` (`x-www-form-urlencoded`, operator-auth): fields `agent, account, homeserver, mode=password|token, user_id?, password?, token?` → `200 { ok, user_id }` on success. Failures come back as RFC 9457 `application/problem+json` (`{ type, title, status, detail }`) with the human-readable message in `detail` and the status code reflecting the cause (400 for a validation error, 500 for a login / `whoami` / internal failure); the page reads `detail` for display. The host coordinator performs the login (password) or validates the token (`whoami`) and writes the bearer to the agent's `matrixAccounts..tokenFile` via the same privileged write path as the hive-internal `matrix-token`; the token is **never** echoed back, and the page clears the secret inputs on submit regardless of outcome. The account list reflects what is *provisioned* (an account with a stored token), so a config-declared-but-unprovisioned account appears only once it has been provisioned through the form. ## P3RM1SS10NS tab Per-agent permission configuration. Two sections, each rendered as a column-driven checkbox matrix: rows are agents, columns are the permission names fetched from the backend. The column list is authoritative — adding a new tool-group or capability to the backend requires no UI change; the new column appears automatically. The snapshot carries `agents` (the full manageable roster — live containers ∪ agents with an explicit entry) and `effective` (per-agent explicit-or-role-default values) alongside the explicit `assignments` map. Rows come from `agents` so **agents on defaults always appear** (not just those with an explicit entry), and checkboxes reflect the `effective` values so a default agent shows the groups it actually runs with rather than blank — which also means saving it won't silently strip those defaults. The `(default)` badge keys off absence from `assignments` (no explicit entry). Fetches fire on tab activation (not page-load) to avoid unnecessary work when the operator never visits this tab. Live mutations from the rebuild-queue worker are also pushed via the `capabilities_changed` / `tool_groups_changed` SSE events (same payload shape as the GET endpoints), so an open P3RM1SS10NS tab reflects worker-applied changes without requiring navigation. Tab-activation re-fetches remain as a safety net for reconnect windows. **C4P4B1L1T13S** — per-agent capability grants. Capabilities unlock gated MCP tools and system-level access beyond the default agent surface. A saving POST queues a rebuild for the affected agent so the new `HIVE_CAPABILITIES` env var takes effect in the next session. The current capabilities are: | Name | Effect | |------|--------| | `manage_root_agent` | allows the `set_status` / lifecycle tools on the root agent | | `read_host_journal` | unlocks `get_host_journal` to read journald from inside a container | | `query_agent_state` | allows `get_loose_ends(agent: "")` calls targeting other agents | | `infra_admin` | allows `restart` on hive infrastructure containers (`hive-ci`, `hive-gateway`, `hive-forge`); each restart is logged to the AUDIT trail | Each row is one agent. Columns are the capability names returned by `GET /api/capabilities` as `caps: Vec`. Checking or unchecking boxes only stages the change in-browser; nothing is written until the page-level **save all** button (described below) is clicked. The checkboxes reflect the *effective* set (explicit grant or role default), so a default-perms agent shows its real grants rather than blank; absent agents in the assignment map have no extra capabilities. **T00L GR0UPS** — per-agent tool-group permissions. Tool groups are named buckets of MCP tools; each agent starts with a role default (sub-agents: `messaging`, `meta`, `inbox`, `execution`; root agent: all groups). Checking / unchecking stages which groups are active for the agent; the page-level **save all** button (below) commits it. Columns come from `GET /api/tool-groups`. A rebuild is queued so `HIVE_TOOL_GROUPS` takes effect. The current tool groups are: `messaging`, `meta`, `inbox`, `lifecycle`, `approvals`, `scheduling`, `diagnostics`, `execution`, `web_tools`. All listed in `ToolGroup::ALL` in `hive-sh4re`. The `web_tools` group is special: it carries no MCP tools; instead it adds Claude's built-in `WebFetch` and `WebSearch` to `--tools` / `--allowedTools` for that agent session. Both tables share the same visual shape: `.cap-table-wrap` / `.tg-table-wrap` outer scroll container, `thead` with a label column (`.cap-agent-col` / `.tg-agent-col`) + one column per permission (`.cap-col` / `.tg-group-col`). Each tbody row is one agent: a name cell and its checkbox cells, where each checkbox carries `data-baseline` (its render-time state) and the row carries `data-agent` for dirty-tracking. **Saving — one button for the whole page.** There are no per-row save buttons. A single page-level `.perm-save-bar` with a **save all (N agents)** button sits at the bottom of the pane, enabled only when some checkbox diverges from its baseline. Clicking it diffs every checkbox across *both* matrices and POSTs one batch to `POST /api/permissions` as `{ changes: [ { agent, tool_groups?, capabilities? } ] }` — only the perm-types that actually changed for each agent are included (an omitted field leaves that file untouched; an included array fully replaces it). The backend coalesces an agent's capabilities + tool-groups into a single rebuild, so changing both for one agent is one rebuild, not two. The batch is atomic: it validates every change first and on any error rejects the whole POST (`{error}`, nothing applied); a clean 200 (`ok`) flips the bar to a queued→rebuilding state and re-fetches both tables. Live `capabilities_changed` / `tool_groups_changed` events re-render the matrices unless the section has unsaved edits, so an in-progress edit set isn't clobbered. ## SCH3DUL3S tab Anything that fires at a future time. Operator-set schedules are created inline in the table (last row); agent self-paced reminders surface at the bottom as a sibling list — they share enough conceptual ground to live together. **N3W SCH3DUL3 / QU3U3D SCH3DUL3S** — operator-managed scheduled prompts. **Single-table layout**: each schedule is one ``; columns are `# | src | next | every | owner | body | …agents… | actions`. Agent columns are dynamic — `operator` + `root` + every live container + any extra name that appears as a target on some schedule but isn't a current container (same `buildTargetChips` membership rule the new/edit forms use, so table and forms agree on what's addressable). Column headers tilt -45° via CSS so each column reads as a narrow ~28px strip; per-agent cells render as: - **active target** → `` that cancels just that one target on click - **cancelled target** → muted `✕` glyph (no button — re-adding goes through the edit form's targets multi-select) - **not a target** → empty cell Per-schedule action column: - **`↯ fire now`** — sends an out-of-band manual pulse to every active target (recurring schedules keep their cadence; one-shots are consumed after the manual fire). Disabled for paused schedules. - **`⏸` / `▶` pause/resume toggle** — only on recurring schedules (one-shots may also be paused to delay a one-time fire, so the button always appears). Paused rows show a `⏸ paused` badge in the `next` column and are sorted to the middle bucket (after active, before cancelled). A paused schedule does not fire regardless of `next_fire_at`; resuming (`▶`) clears the pause without adjusting the next-fire time. POSTs to `/api/schedules/{id}/pause` or `/api/schedules/{id}/resume`. - **`✎ edit`** — expands an inline edit form as a colspan'd row directly under the schedule's row (body / description / interval / next-fire / targets all editable; targets are a multi-select diff'd against the original active set so unchecked-was-active = `targets_remove`, checked-not-originally-active = `targets_add`; submit PATCHes `/api/schedules/{id}`). - **`✕`** — cancels the whole schedule (`POST /api/schedules/{id}/cancel`). The `next` column cell (`.sched-due`) carries a `data-due-at` Unix timestamp attribute; a shared 1s ticker rewrites it in-place showing `fmtDuration` while in the future and `overdue X ago` once the fire time has passed — same zero-re-render pattern as the reminder due-at labels and the question TTL chip. The table's last row is a permanent inline creation row: inputs live directly in table cells (targets as checkboxes, body textarea that expands on focus, datetime-local pre-filled to 5 minutes from now, mini d/h/m/s number inputs (blank or all-zero = one-shot), description). Click `＋` to POST to `/api/schedules` as JSON (or `⌫` to clear the half-filled row); carry-state preserves partially-typed inputs across re-renders. The tab pill shows the count of active schedules (at least one live target not yet cancelled). Refreshed on tab activation and after each submit/cancel. Backed by `GET /api/schedules`. No backend changes for the table layout — it renders entirely from existing `schedulesState` + `containersState`. **QU3U3D R3M1ND3RS** — reminders agents have scheduled for themselves (via the `remind` tool) but not yet delivered. Each row shows the owner, due time, and message; a `CANC3L` button hard-deletes (`POST /api/cancel-reminder/{id}`) and a `R3TRY` button re-arms one whose delivery failed (`POST /api/retry-reminder/{id}`). Backed by `GET /api/reminders`. Lives in the SCH3DUL3S tab alongside operator schedules so the operator has one place for everything time-fired. The due-time label (`.reminder-due`) carries a `data-due-at` Unix timestamp attribute; a shared 1s ticker rewrites it in-place — showing `in Xm Ys` while the reminder is in the future and `overdue X ago` once the deadline passes — without triggering a full re-render of the list. ## ST4TS tab Hive-wide turn statistics, aggregated across every agent's `hyperhive-turn-stats.sqlite` for the selected window. Distinct from each agent's own `/stats` page (which carries the per-agent trend charts): ST4TS is the swarm-level rollup. - **Window selector** (`1h`–`30d`) re-fetches on change. - **Summary chips**: active agents, turns, total/input/output/cache-read tokens, and a labelled **est cost**. - **Busiest agents** table — one row per agent (most turns first): turns, input / output / cache-read tokens, est cost. - **Model mix** — turns per model across the swarm, as CSS bars. - **Favorite tools** — most-run normalised bash-command heads across the swarm (top 10, as CSS bars), aggregated from each agent's `bash_commands` table (written by the hive-bash-mcp capture). The header + list stay hidden until at least one agent has recorded a command, so the section never shows an empty block on a fresh hive. Backed by `GET /api/stats-hive?window=` in `hive-c0re` (`hive_stats.rs`): for every name from `Coordinator::kept_state_names()` it opens `agent_harness_dir(name)/hyperhive-turn-stats.sqlite` read-only (with a 500 ms `busy_timeout`, since `turn_stats` is rollback-journal) and rolls the rows up — missing / unreadable / zero-turn dbs are skipped so one bad db never fails the endpoint. This is a **pull** surface (no SSE): the data is fetched on tab activation and on window change. Rendered with plain tables + CSS bars — the dashboard bundle ships no chart library. The cost figure is a deliberately rough estimate from a per-model price table (`est_cost_usd`); it drifts with list pricing and is labelled accordingly. The table is operator-tunable via the `services.hyperhive.modelPrices` nix option — each key is a model-family short name (matched case-insensitively as a substring of the model id, longest match wins) mapping to `{ input, output, cache_read, cache_write }` USD-per-million-token prices. Models not covered fall back to hive-c0re's built-in estimate. ## P33RS tab Peer hives in this swarm. The tab is hidden when the `state.peer_hives` array from `/api/state` is empty (i.e. no `services.hyperhive.swarm.peers` are configured). When at least one peer is present the `hidden` attribute is removed and the tab becomes active. **P33R H1V3S** — each peer renders as a card row: a hexagon icon (`⬡`), the peer's DNS domain as the primary name, and the peer dashboard HTTPS URL as a clickable secondary link. Clicking the URL opens the peer hive's dashboard in a new tab. ### Backend wiring The host daemon reads `services.hyperhive.swarm.peers` from the nix config (an attrset keyed by peer domain), serialises each entry as `{ name, url }` into `state.peer_hives: Vec`, and includes the field in the `/api/state` snapshot. `tabs.js` reads `state.peer_hives` on every `refreshState` call and calls `swarm.js::renderPeerHives(peers)`, which rebuilds the `#peers-section` div from scratch. The `name` field is the peer's DNS domain (the attrset key); `url` is `https://{domain}/`. Both are derived from the env var `HYPERHIVE_PEERS` (a JSON array of `{ domain, cert_fingerprint }` objects) that the nix module writes into the c0re container environment. `cert_fingerprint` is null for CA-trusted (e.g. Let's Encrypt) peers and non-null to pin a self-signed cert. `parse_peer_hives()` in `dashboard.rs` converts each entry to the `PeerHiveView { name: domain, url: "https://domain/" }` shape the frontend reads. ## S3TT1NGS tab Operator-local preferences. State lives in the browser's `localStorage` — preferences do NOT sync between devices and do NOT survive a profile wipe. Today the tab holds one section (browser notifications); future preferences (theme, density, etc.) land here as sibling `

` blocks under the same `
`. **◇ browser notifications** — `🔔 enable notifications` button when permission ungranted; `🔕 mute / 🔔 unmute` toggle once granted (mute silences the dispatch without revoking the OS-level permission). On unsupported origins (non-secure context, or browsers without the `Notification` API) the controls hide and a single status line explains why. See `### Browser notifications` below for the dispatch model + the three signals the dashboard emits OS notifications on. The FL0W page does NOT host this pane — settings live only on the dashboard's S3TT1NGS tab (reach it via the FL0W page's `← home` back-link → Dashboard). Notifications still fire on the FL0W page when they're enabled here, because `NOTIF.show()` in `common.js` depends on `Notification.permission` + the `hyperhive.notify.muted` localStorage key, not on the buttons existing in the page DOM. ## M4TR1X page (`/matrix/`, optional) A static matrix web client (default `pkgs.fluffychat-web` rebuilt with `--base-href /matrix/`, swappable via `services.hyperhive.matrix.gui.package`) served by the hive-gateway nginx container at `/matrix/` when `services.hyperhive.matrix.gui.enable` is on (defaults to `matrix.enable`). c0re signals availability via the `HIVE_MATRIX_GUI_ENABLED` env var → `state.matrix_gui_enabled` in `/api/state`; the gateway does the actual static serving. The operator opens `/matrix/` from the Matrix tile on the H0M3 hub, logs in once with the in-host tuwunel homeserver URL (`http://localhost:8008` or whatever the matrix module exposes). The unified nginx-front re-root to `https://matrix.${hyperhive.domain}` + `.well-known/matrix/client` auto-discovery lives in `docs/gateway.md` (atlas's lane). ## FL0W page (`/flow.html`) A dedicated full-page terminal (not a tab pane — a separate HTML page). Slim chrome: a `← home` back-link to the H0M3 hub, the FL0W title, and the agent-filter select (see below). No dashboard tab strip — FL0W is a standalone surface reached from the hub. The operator inbox is **not** on this page — it lives on the dashboard's Y3R C4LL tab (◆ 1NB0X ◆ section, with per-message and mark-all read). FL0W stays the pure event firehose. **MESS4GE FL0W** — live broker tail wrapped in a `.terminal-wrap`. Cold load backfills the last ~200 messages from `/api/dashboard/history`; live frames arrive on `/api/dashboard/stream`. Each row is one broker event — `sent` or `delivered` — with `from → to: body`. When a `sent` and `delivered` event for the same message arrive within 3 seconds (immediate delivery to a live recipient), the row is upgraded in place (arrow becomes green ✓, title reads "sent + delivered") instead of rendering two near-identical lines — genuine delivery latency (recipient was busy) still appears as a second row. Each row carries `data-from` / `data-to` attributes; an **agent filter select in the FL0W header** narrows the timeline to messages involving the chosen agent (matched on `from` OR `to`), with non-matching rows hidden (`.flow-hidden` class). The selection persists in localStorage across reloads; new rows pick up the active filter at render time. The dropdown populates from the live container list and stays current on add/remove; a saved selection survives even if that agent isn't currently listed. The row is a `flex-wrap: wrap` container holding ts / arrow / from / sep / to chips inline; the **body wraps to its own full-width line below** the chips (`flex: 1 1 100%`) so the body always gets the full row width down to the content edge — long timestamps + agent names used to push the body ~30ch in and force awkward narrow-column wraps. `min-width: 0` keeps `word-break: break-word` effective so the body doesn't force the row wider than its container. Sticky-bottom auto-scroll + "↓ N new" pill. Below the stream sits a terminal-style compose box: `@name` picks the recipient (sticky via localStorage; auto-complete from the live container list, Tab/Enter to confirm; `@*` broadcasts). `POST /api/op-send` drops `{from:"operator", to, body}` into the broker; the resulting SSE frame re-renders the terminal row. The root agent is addressed as `@root`. ## H0M3 page (`/`) The H0M3 hub is the primary landing page (served at `/` by default). A responsive grid of link tiles — Dashboard, Flow, Logs, Matrix (when enabled), Forge (when enabled) — each pointing to their respective surfaces. The page is a pure portal with no tab-bar or SSE subscriptions. Typography + colours inherit from the shared theme (Catppuccin Mocha via `common.css` + `theme.css`). Optional tiles are hidden until `home.js` confirms their availability: Matrix is hidden until `home.js` confirms `matrix_gui_enabled` (same gating as the dashboard's M4TR1X tab); Forge is hidden until `home.js` confirms `state.forge_present` and fills the href from `state.forge_public_url` (the gateway-served public URL when `services.hyperhive.forge.behindGateway=true`) or falls back to the direct `:3000` port. Operators without matrix or forge enabled never see dead links. `home.js` also fills the swarm/hive identity line at the top. Dashboard is now served at `/dashboard.html` (route swap completed in #1464 step 2); the home page at `/` replaces the old dashboard root. All dashboard sub-pages include a `← Home` back-link for navigation. ## L0GS page (`/logs.html`) A dedicated log-viewer page (not a tab pane — a separate HTML page), reachable from the Logs tile on the H0M3 hub. Minimal chrome: a `← home` back link and a three-item sub-tab strip. Tab routing is hash-based (`#agent`, `#system`, `#audit`); default is `#agent`. (Build log history has moved to the BU1LDS page — see above.) **AGENT sub-tab** — per-container journald viewer. Two selects: agent name (populated from `GET /api/state`) and unit filter (`hive-ag3nt.service` / `(full machine journal)`). Fetches `GET /api/journal/{name}?unit=&lines=500` on selection change or `↻ refresh`. Output rendered as a `
` block. A `?agent=`
and/or `?unit=` URL param pre-selects the agent + unit on page
load — the per-agent `⋮` menu's **journal logs →** entry uses this to
deep-link directly to a specific agent's journal. A "fetched N ago"
chip appears after the `↻ refresh` button following each successful
fetch and ticks every 30 s.

**SYSTEM sub-tab** — host-side service logs. Unit selector (currently
only `hive-c0re.service`). Fetches
`GET /api/journal-host?unit=hive-c0re.service&lines=500` on activation
and on `↻ refresh`. Rendered as a `
` block. A "fetched N ago"
chip ticks every 30 s. Available to the operator unconditionally (not
capability-gated — the endpoint lives on the hive-c0re dashboard,
behind the gateway).

**AUDIT sub-tab** — operator-visible trail of agent-initiated
privileged actions (e.g. infra-container restarts via `infra_admin`).
Lazy-fetched on tab show (like SYSTEM) from `GET /api/audit-log`, which
returns `{ entries, total }` — `entries` newest-first, server-clamped to
the latest 500; `total` drives a "latest 500 of N" count so the clamp is
never silent. Rendered as a filterable table (when / agent / action /
target / outcome / detail); the filter box is a client-side substring
match over the cached rows. The outcome badge colours `ok` green and
`err` red, with an `err` whose `detail` starts `denied:` (a capability
refusal) shown amber and labelled `denied` so it reads apart from an
execution failure. `ts_unix` is an RFC 3339 string; a 30 s ticker keeps the
relative "ago" column honest while the tab is in view. The backing
`audit_log` store records every privileged-action attempt (ok / err /
denied). New entries live-append without a refresh: an `audit_entry_added`
event on `/api/dashboard/stream` (the flattened row) is prepended to the table
and the "latest N of M" count bumped, de-duped by id against the cold
fetch.

## Container row

A full-height **square agent icon** (5em, capped) on the left. The
icon is the **selection toggle**: click (or Enter/Space) adds/removes
the agent from the selection set; `aria-pressed` reflects the state;
the tooltip says "select … for bulk actions" or "deselect … (or press
Esc to clear all)". The `` points at `/icon`; load failure
falls back to the dimmed hyperhive mark (`/favicon.svg`). The card
body sits to the right with three stacked lines
(`assets/swarm.js::renderContainers`).

**Icon layout + load strategy:** the `` is absolutely
positioned (`inset: 0`) inside the `.container-icon` wrapper —
the wrapper is the flex child and sizes itself via `width: 5em` +
`aspect-ratio: 1`, the `` is out of flow so its load state
(pending, loaded, broken) can never contribute intrinsic size or
reflow the row. Without that, the row would briefly grow as the
image's natural dimensions arrived, then snap back on
`object-fit: contain`. The load itself is fire-and-forget: the
dashboard doesn't pre-check whether the agent is reachable, it
just lets the `` try and listens for an `error` event. On
failure the handler swaps the `src` to `/favicon.svg` (served by
the dashboard itself, always reachable) and adds the
`icon-unreachable` class for the dimmed look. When the container
is known stopped up front (`ContainerView.running = false`) the
fallback fires immediately, skipping the doomed `/icon`
fetch entirely.

- Line 1: agent name (link → new tab), m1nd/ag3nt chip, an
  **icon-only nav strip** plus live agent-owned state, all populated
  async from a single `GET /api/dashboard-state` call to the
  agent's own backend. The response (`DashboardState`) carries:
  `links` (nav strip entries — `📊 stats`, `🖥 screen` when GUI is
  enabled, `⬡ forge profile`, `↳ agent-configs mirror`, plus any
  agent-declared `dashboardLinks` extras), `status_text` /
  `status_set_at` (agent self-reported status — the `(set N ago)`
  chip is stamped `data-set-at` and ticks every 30s to stay fresh
  across the long-lived keyed row cache), `rate_limited`,
  `ctx_tokens` / `context_window_tokens` (context-window badge
  data). The agent backend is the single source of truth for all
  of these. The dashboard resolves each `AgentLink.kind` against a
  per-agent base URL depending on whether hive-gateway is in front
  (`StateSnapshot.gateway_enabled`, sourced from the
  `HIVE_GATEWAY_ENABLED` env the c0re NixOS module sets when
  `services.hyperhive.gateway.enable = true`). Gateway-on (default):
  base URL is `/agent/` (same origin, gateway proxies to the
  per-agent harness — TCP or unix-domain depending on the agent's
  `HIVE_WEB_SOCKET` opt-in, see
  `docs/gateway.md::Per-agent unix-socket upstream`).
  Gateway-off (legacy / local dev): base URL is
  `http://:` (direct TCP fallback). Forge
  links resolve against `http://:3000`, external links are
  already absolute. The same base URL drives the primary agent-name
  link + favicon fetch, so the whole row routes through the gateway
  as a unit.
  **When the container is stopped** (`ContainerView.running = false`),
  the async `dashboard-state` fetch is skipped entirely (the agent
  web server is down), so the badge chain is replaced by a single
  muted `■ not running` badge, the nav strip is empty, and status
  text / rate-limited / ctx badges are suppressed. The agent icon
  goes straight to the dimmed `/favicon.svg` fallback instead of
  attempting a doomed load from the container's URL. Static fields
  — `needs_update`, `deployed_sha`, `pending_reminders`, `parent`,
  `config` link — remain visible regardless of run state.
  When the container is running, status badges follow — `⊘ rate
  limited` (red, while the harness is parked after a 429), `needs
  login`, `needs update` — in-flight `◐ pending-state…` pill
  (replaces buttons during operator-initiated start / stop /
  restart / rebuild / destroy). Additionally, when a rebuild-queue
  entry for this agent is `queued` or `running` but no
  operator-initiated transient is set, the card surfaces a
  `building…` / `meta-updating…` / `starting…` / `stopping…` badge
  (per queue `kind` — e.g. a `start` entry shows `starting…` /
  `start queued`, `stop` and `graceful_stop` both show `stopping…` /
  `stop queued`) sourced from `rebuildQueueState` — so the SW4RM tab
  shows the same progress visible on the BU1LDS page's R3BU1LD QU3U3.
  The row visual splits queued vs running: a **queued** entry shows
  only the pending-state pill (no row tint, so a long queue doesn't
  paint half the tab amber); a **running** entry keeps the amber
  row tint AND draws a **rotating amber ring** around the agent
  icon, so it's obvious at a glance which container is actually
  moving.
  **Pending-state derivation:** the pill is sourced from two
  separate stores in priority order. (1) The operator-initiated
  **transient** (`transientsState`) is set on the dashboard the
  moment the operator clicks start / stop / restart / rebuild /
  destroy / spawn — covers the create-and-start window where the
  container literally isn't up yet, before any backend state event
  has fired. (2) If no transient is set, the **rebuild-queue
  entry** for this agent is consulted (`rebuildQueueState`); this
  covers worker-driven ops — meta-update cascades, crash-recover
  rebuilds, approval-driven rebuilds — that the operator didn't
  click. `ContainerStateChanged` carries neither signal, so the
  dashboard reads from the two snapshots directly. The
  `opRunning` flag (driving the `pending-running` row class +
  spinner) is true when (1) is set OR (2) is in `running` state;
  queued entries leave `opRunning` false.
  An **active model badge** (`model · `, blue) appears when the
  container is running and the harness has persisted a model name
  (`harness/hyperhive-model`). Read by hive-c0re's `ContainerView`
  (`read_active_model`); absent until the agent has completed at least
  one turn and stale values are suppressed for stopped containers.
  A `ctx · Nk` chip showing the agent's last-turn context size,
  populated from `DashboardState.ctx_tokens` (absent until the
  agent has completed at least one turn). The chip colour (green /
  yellow / red) is keyed off `DashboardState.context_window_tokens`
  (the real context window for the model the agent last ran on,
  authoritative from the agent side); the badge goes yellow ≥ 50%
  and red ≥ 75% of that window, matching the harness compaction
  watermarks. When the window value is absent the badge falls back
  to fixed 100k / 150k thresholds.
- Line 2: status badges only (no per-card action buttons — actions
  moved to the **selection bar** or the **per-agent `⋮` menu**, see
  below).

**Per-agent `⋮` overflow menu** — a `⋮` button appears on the right
edge of each container row. Clicking it opens a small dropdown with
per-agent actions and navigation links. Contents:

- `↺ R3ST4RT` (running agents only) / `■ ST0P` (running only) /
  `▶ ST4RT` (stopped only) — single-agent run-state toggles.
  Identical to the bulk actions on the selection bar but operate
  on one agent without requiring a selection click.
- `↻ R3BU1LD` — always available; queues a rebuild for this agent.
- `journal logs →` — opens `/logs.html#agent?agent=` so the
  operator lands directly in the AGENT log tab pre-filtered to this
  container, without having to pick an agent from the dropdown.
- `DESTR0Y` / `PURG3` — destructive, each prompts for confirmation
  via the themed dialog (see **Themed dialogs** below).
- `deployed: ↗` — present when the agent has a `deployed_sha`
  and the forge is reachable; links the deployed commit on the forge
  agent-configs mirror.

`↻ UPD4TE 4LL` button appears above the containers list when any
agent is stale. Banner pulses on each broker SSE event
(`pulseBanner` with a 4s grace timer).

**Build-queue summary banner** — when the rebuild queue has any
`queued` / `running` entries, a compact amber banner sits above the
container list: `◐ build queue — N running · M queued — view queue →`
(the link goes to the BU1LDS page's R3BU1LD QU3U3). It replaces the
old per-transient spinner list; the actual running step for each
agent is already shown on its card (transient + in-flight-queue
badges), so the top of the tab only needs the at-a-glance summary.

### Themed dialogs

All confirmations, prompts, and transient error notices use an
in-app themed dialog system (`assets/modal.js`) rather than the
browser's native `confirm()` / `prompt()` / `alert()` chrome, so
they match the Catppuccin palette and can't be styled away by the
OS. Three primitives, all built on the `openDialog` core:

- `themedConfirm({ message, danger, confirmLabel, checkboxes })`
  — a modal confirm that resolves to `null` on cancel or an object
  of checkbox states on confirm. Destructive actions pass
  `danger: true` (the confirm button turns red and the cancel
  button takes focus). Backdrop click and `Esc` both cancel.
- `themedPrompt(...)` — a modal with a text input, resolving to the
  entered string or `null`.
- `themedToast({ type, ... })` — a non-blocking toast (top-right,
  `info` / `error` / `ok`) for transient validation + action
  failures, so an error doesn't trap the operator behind a modal.
  Single-action errors auto-dismiss; bulk / partial-failure
  summaries are sticky (click to dismiss) so they aren't missed.

Every destructive run-state action (`ST0P`, `R3ST4RT`, `R3BU1LD`,
`DESTR0Y`, `PURG3`, `M0V3`) routes through `themedConfirm`, on both
the per-agent `⋮` menu and the bulk selection bar.

**Graceful stop** — the `■ ST0P` confirm dialog (per-agent and
bulk) carries a `stop gracefully — let the agent finish its turn
and flush state before the container stops` checkbox. When ticked,
the action POSTs `/api/kill/?graceful=true` (the bulk path
appends the flag per-agent); unticked is the instant hard stop
(`/api/kill/` with no query). The backend enqueues a
`GracefulStop` rebuild-queue transient: the harness runs one
stop-checkpoint turn (so the agent can flush `/state`) and then
exits, with a 3-minute timeout that falls back to a hard stop. The
quiescing progress surfaces through the same rebuild-queue
transient + build log the card already reads for a rebuild. (The
`hivectl --graceful` CLI flag enqueues the same `GracefulStop`, so
the dashboard and CLI paths behave identically.)

### Topology tree

Container rows render as a forest, not a flat list — each agent
sits indented under its declared parent. `swarm.js::buildAgentTree`
walks `ContainerView.parent` for every container in the snapshot
and produces a render order with per-row depth + sibling-position
info:

- Top-level rows are agents with `parent = null` OR a parent that
  doesn't appear in the container map (orphans get hoisted to root
  so they're still visible).
- Within each level children sort alphabetically by name; roots
  likewise.
- Cycle safety: any container not reached during the root-walk is
  appended at the end as a root, so no agent ever silently
  disappears from the list when the topology JSON is malformed.
- The pre-topology rendering shape (every container at depth 0,
  flat list) collapses to the same visual today when no parent
  field is set — bit-identical fallback path.

The per-row prefix column (`.tree-prefix`) is **DOM-painted, not
text-glyph-painted**. Each indent lane is its own positioned
`` so CSS can draw full-height vertical bars that bridge the
gap between sibling rows; using text box-drawing characters
(`├─`, `└─`, `│  `) only paints one text-line tall and leaves
visible breaks between the taller-than-one-line container cards.
The bars come in two flavours: continuation (the ancestor's
subtree extends below this row → vertical line top→bottom) or
blank (ancestor was the last sibling at its level → no line
needed). The joint at the row's own depth column is `├` (more
siblings below) or `└` (last sibling at this depth — vertical
stops at the row's icon midline).

**Indent + lane geometry.** Each depth level shifts the row right
by `1.8em` (the lane width). The per-depth ladders are hardcoded
for six levels — enough for any plausible hive topology, and the
typed `attr()` function from CSS Values 5 that would collapse
this to one rule is still partial-support (Chromium-only as of
2026). The `.tree-prefix` span sits absolutely positioned with
`left: -*1.8em` so its right edge meets the row content
(the icon) and its leftmost lane lines up with top-level rows'
icons at `x = 0`. Each `.tree-lane` is `flex: 0 0 1.8em` so all
lanes have equal width. Continuation bars are drawn at lane
center (`left: 0.6em`, `border-left: 1px solid currentColor`,
`top: 0; bottom: 0`) and extend through `.containers { gap: 0.4em }`
into the next sibling's prefix (`bottom: -0.4em` on the prefix
span itself) so adjacent ancestor lines visually merge into one
unbroken vertical line. The horizontal stub at a row's own joint
lands at the icon midline so the L/T meets the icon edge cleanly.
When every container has `parent = null` (pre-topology state) the
`[data-depth]` attribute is absent on every row and these rules
are no-ops — the layout reads exactly like the legacy flat list.

## Selection bar

Per-card action buttons (`R3ST4RT` / `ST0P` / `ST4RT` / `R3BU1LD` /
`DESTR0Y` / `PURG3`) used to live on each container row; the
operator picked the bulk-bar model instead. Clicking an agent's
icon toggles its selection (an in-memory `Set`); `Esc` or
the bar's `✕ clear` button drops everything. The selection
persists across tab switches in-memory — the bar just hides on
non-SW4RM tabs since other tabs don't show the agent cards needed
to cross-reference.

When one or more agents are selected (via icon click), a sticky
frosted-mauve bar slides up from the bottom of the viewport
(`#selection-bar`, `position: fixed; bottom: 0`). It shows:

- **Count + names** — "N agents selected · name1, name2, …"
- **Bulk action buttons** — only enabled when ALL selected agents
  support the action; disabled with a tooltip naming the blockers
  when the selection is mixed:
  - `↺ R3ST4RT` — running agents only
  - `■ ST0P` — running agents only
  - `▶ ST4RT` — stopped agents only
  - `↻ R3BU1LD` — always available
  - `DESTR0Y` / `PURG3` — always available
  - `⇡ M0V3 → ROOT` — promote selected agents to top-level
    (parent = null); disabled when all selected are already at root.
    Backend `topology::set_parent` refuses moves it can't satisfy
    (e.g. a move that would create a cycle) and the refusal surfaces
    in the failure roll-up.
  - `⇢ M0V3 → [select]` — inline picker available for any
    selection size. The dropdown lists every container that isn't IN
    the selection itself nor a descendant of any selected agent
    (client-side BFS cycle prevention across the whole batch; the
    backend re-checks per-agent). On submit:
    - **single agent** → `POST /api/topology/set-parent`
      (form-encoded `child=&new_parent=`)
    - **multiple agents** → `POST /api/topology/set-parent-bulk`
      (JSON `[{ child, new_parent }]`; all moves land in a single
      `topology.json` commit instead of one per agent)

    Both write `topology.json` and re-emit a container snapshot so
    the tree repaints without a page reload.
- **`✕ clear`** button + `Esc` key clear the entire selection.

Stale selections (agents destroyed while selected) are pruned on
every render before the bar appears.

## Approval card

Each pending approval renders as a card (`assets/call.js::
renderApprovals`) with three stacked sections:

- **identity header** — glyph, `#id`, agent, kind chip, and a
  right-aligned `requested  ago` relative time from
  `ApprovalView.requested_at`. Glyph and chip vary by kind:

  | kind | glyph | chip | sha shown |
  |---|---|---|---|
  | `apply_commit` | `→` | `apply` | proposal sha (`sha_short`) |
  | `merge_config_pr` | `⇒` | `merge-pr` | PR-head sha (`sha_short`) |
  | `update_meta_inputs` | `↻` | `meta-update` | — |
  | `schedule_prompt` | `⏱` | `schedule` | — |
  | `init_config` | `⊕` | `init` | — |
  | `spawn` | `⊕` | `spawn` | — |

  The chip ticks live every second via a `data-requested-at`
  attribute + client-side interval (no re-render). Turns amber once
  the request has been pending ≥ 1h so a stale approval stands out;
  the `.stale` class flips precisely at the 3600s boundary rather
  than at the next `renderApprovals` call.
- **what-changed body** — the submitting agent's description, then
  kind-specific drill-in triggers:
  - `apply_commit`: `↳ view diff` opens the inline diff side-panel;
    `↳ commit on forge ↗` deep-links the proposal commit into
    `agent-configs/` (shown only when `forge_present`).
  - `merge_config_pr`: `↳ review PR on forge ↗` deep-links the
    config PR into `agent-configs//pulls/` (shown
    only when `forge_present` and `pr_number` is set). No inline diff
    side-panel (apply_commit-only for now).
  - `init_config` / `spawn`: a one-line "container will be created"
    note instead.
- **decision actions** — `◆ APPR0VE` and `DENY`. Deny pops a
  `prompt()` for an optional reason carried to the submitting agent as
  `HelperEvent::ApprovalResolved.note`.

The diff panel has a 3-way base toggle — **vs applied** (the
running tree, served instantly from the diff already on the
approval), **vs last-approved**, **vs previous proposal** — the
latter two fetched on click from `GET /api/approval-diff/{id}
?base=approved|previous`. Each line is classified client-side
(`+` / `-` / `@@` / `--- ` / `+++ ` → add / del / hunk / file).

A `pending · N` / `history · N` tab pair switches the section
between the live queue and the last 30 resolved approvals.

## Browser notifications

Pure frontend (`Notification` API). Three signals trigger them:

- new pending approval (per id, delta on `/api/state`)
- new pending operator question (per id)
- new broker message sent `to: "operator"` (live via SSE)

The toggle controls live in the `S3TT1NGS` tab (`#settings`); see
that section above for the user-facing shape. Dispatch logic lives
in `common.js::NOTIF`.

First `/api/state` after page load seeds "seen" sets without
firing — only items that arrive while the page is open count.
Per-event tags (`hyperhive:approval:`, `hyperhive:question:`,
`hyperhive:msg::`) so distinct events stack in the OS
notification center instead of overwriting each other.
`console.debug` logs at every block point (unsupported,
permission ungranted, muted) for in-browser debugging. Click
focuses the dashboard tab. The localStorage key
`hyperhive.notify.muted` (`"1"` = muted, absent = unmuted) backs
the toggle and silences dispatch without revoking the OS
permission. Requires a secure context (HTTPS or localhost); on
other origins the controls hide themselves. Browsers typically
suppress notifications while the originating tab is focused —
that's a browser-level decision, not ours.

## Dashboard endpoints

- `POST /api/approve/{id}` — approve a pending approval. Fires
  `ApprovalResolved` on the dashboard event channel; client
  updates derived approvals state from the event.
- `POST /api/deny/{id}` (`note=`, optional) — deny a pending
  approval with an optional operator-supplied reason. The reason
  travels to the submitting agent as `HelperEvent::ApprovalResolved.note`
  and also rides on the dashboard's `ApprovalResolved` event.
  Dashboard prompts via the themed `themedPrompt()` dialog on
  click — a resizable `