| Filename | Latest commit message | Latest commit date |
|---|---|---|
An agent's capabilities move from the hive's meta repo
(`meta/capabilities.json`, injected as `HIVE_CAPABILITIES`) into the
`capabilities` field of its key in a new `agent-permissions` KV bucket,
which swarm-controller alone writes.
- swarm-queue-client: `agent_permissions` (bucket, key, `AgentPermissions`,
direct-get read, the import subject and its wire types).
- swarm-controller: creates the bucket at start; `GET|PUT|DELETE
/api/agents/{name}/permissions` (deny_unknown_fields and unknown
capability ⇒ 422, duplicate ⇒ 400, agent must be declared by a hive);
answers each hive's one-shot import, writing a key only where there is
none and only for agents that hive's wanted state declares.
- swarmctl: `agent permissions get|set|clear`.
- swarm-nats-auth: a hive reads every key of the bucket and sends its
import on its own subject; the controller subscribes to the imports and
may answer them (`responses`).
- hive-c0re: reads each of its agents' keys every 30s into
/var/lib/hyperhive/swarm-agent-permissions.json and restarts an agent,
gracefully, when its capabilities change. Unset is the compiled-in
default (ruth: manage_root_agent; everyone else: none). A failed read
keeps the stored value. On first boot it seeds that file from
meta/capabilities.json, sends the grants to the controller, and deletes
the file once the controller answers.
Deleted: the capabilities.json reader/writer, `HIVE_CAPABILITIES` in the
rendered meta flake, ruth's capability seed, the capabilities half of the
permissions rebuild job (`PermPayload::Capabilities`/`Combined`), the
dashboard's capabilities table and `capabilities_changed` event, and the
now-unused `Capability::description`.
Part of #5170.
|
||
| .. | ||
| agent.md | ||
| css-vars.md | ||
| dashboard.md | ||
| design-guide.md | ||
| README.md | ||
| shape.md | ||
| terminal-rendering.md | ||
Dashboard & Web UI
The per-hive dashboard: container state and the rebuild queue for one hive. For swarm-wide day to day, see the swarm UI instead. If you want implementation detail — wire formats, DOM structure, event plumbing — see Dashboard layout, Per-agent page, Shape, and CSS theme variables below; this page only covers what you actually do here.
Where things are
Everything starts at the H0M3 hub, served at / — a grid of tiles
linking to every surface (Dashboard, Flow, Logs, Stats,
Settings, Core). Every page links back to H0M3, so you're
never more than one step from the hub.
The dashboard itself (/dashboard.html) is where you'll spend most
of your time. It's a single page with five tabs:
- 4G3NTS — every agent, live. This is the default tab and the one you'll check most.
- R3BU1LD QU3U3, M3T4 1NPUTS and BUILD L0GS — the build lifecycle: the rebuild queue with a live log of whatever is building, the meta flake inputs you can bump, and the build log history.
- P3RM1SS10NS — what tools and system-level access each agent has.
Everything else lives on its own page instead, all reachable from the
H0M3 hub: Flow (/flow.html, the raw live message stream across
the whole swarm), Stats (/stats.html, swarm-wide usage stats), and
Core (/core.html, tombstones and container resource use).
Each agent also has its own page — a full terminal view of that
agent's session, reachable by selecting its name anywhere in the
dashboard, or directly at /agent/<name>/ (or http://<host>:<port>/
if the gateway isn't in front).
The things you'll actually do
Check on an agent. 4G3NTS shows every container as a row: name,
whether it's running, what it's currently doing (a live status pill —
rebuilding…, starting…, or similar — while something's in flight),
and quick links (stats, screen, forge profile). Select the name to open
its terminal and watch it work in real time.
Review a config change. Agent config changes (new packages, env
vars, MCP servers) are pull requests on the agent's agent-configs
repo. Review and merge them on the forge; the merge deploys the change.
See config-changes.md.
Start, stop, restart, or rebuild an agent. Select one or more
agents on 4G3NTS (select the icon) and use the selection bar, or use the
per-agent ⋮ menu on a single row. Rebuilding re-applies that agent's
current config; use it whenever an agent
shows as "needs update."
Watch a build. The dashboard's R3BU1LD QU3U3 tab shows the rebuild queue live, plus a streaming log of whatever's currently building. Useful right after merging a config change or bumping a flake input.
Grant or revoke a tool/capability. P3RM1SS10NS is a checkbox matrix — rows are agents, columns are tool groups or capabilities. Nothing takes effect until you hit save all at the bottom of the tab; a save queues a rebuild for whichever agents actually changed.
Read an agent's logs. Logs aren't in the hive dashboard. Every
hive ships its agents', daemons' and infra containers' journals to the
swarm's VictoriaLogs; read them in Grafana's Explore — see
swarm/services.md.
Set up a schedule. Scheduled prompts are swarm-level: set them with
swarmctl schedule (swarm/schedules.md) or
on the swarm UI's schedules page (swarm/ui.md).
More depth
Both the dashboard and the per-agent pages are SPAs sharing one
skeleton: GET / returns a static shell, /api/state returns JSON,
JS renders — no full-page reloads.
- Dashboard layout — every tab and standalone page, in full implementation detail: endpoint shapes, event wiring, exact badge-derivation rules.
- Per-agent page — the per-agent terminal, composer, side panel, slash commands, and per-agent endpoints.
- Shape (shared by both) — the SPA skeleton, SSE
multiplexing, terminal pane, listener bind, per-agent relative
paths,
data-asyncform pattern, side panel, atomic repaint. - CSS theme variables — the Catppuccin Mocha custom
properties declared once in
base.cssand the rule that per-page stylesheets reference (never redeclare) them. - swarm-ui design guide — visual language,
motion, theming, error-UX, and component-first principles for the
swarm-level Preact app specifically (not this page's dashboard/agent
UIs).
/componentson a running swarm-ui is the companion living demo of every primitive it references.
Implementation reading paths
Task-oriented jumps straight to the relevant section, for when you're touching the code rather than using the UI:
- "How does the dashboard SPA stay live without polling?" →
shape.md(SSE multiplexing, Worker-death self-heal, atomic repaint). - "What does a container row contain?" →
dashboard.md(Container row, Selection bar). - "What endpoints does the dashboard expose?" →
dashboard.md(Dashboard endpoints, Dashboard event channel). - "How does the per-agent terminal render tool calls?" →
terminal-rendering.md(full row taxonomy and dispatch walkthrough); for a high-level summary seeagent.md(Per-stream rendering). - "What slash commands does the agent accept?" →
agent.md(Terminal-embedded prompt). - "What are the per-agent HTTP endpoints?" →
agent.md(Per-agent endpoints). - "Which CSS variable do I use / where are colours defined?" →
css-vars.md(Palette, single-sourcebase.cssrule).