| Filename | Latest commit message | Latest commit date |
|---|---|---|
d1f82e725e
Fixes #2822. `swarm.js` had two independent per-agent "is this in flight" sources: `transientsState` (operator/worker-initiated ops the backend chose to flag) and `inFlightOpsByAgent()`, a separate derivation straight from `rebuildQueueState` covering everything else. Since #3010/#3016, `running_transients()` is a status-only test — any `Running` job-queue node naming a non-empty agent lights a transient pill, not just a curated subset — so the second source's Running-state handling is now provably redundant: a Running node with an agent always already has a transient by the time `queuedOpsByAgent()` (renamed from `inFlightOpsByAgent`) would be consulted. ## What changed - `transientsState`: `Map<name, {kind, since_unix}>` (one pill per agent) -> `Map<name, Map<kind, since_unix>>` (several pills per agent). `applyTransientSet`/`applyTransientCleared` now add/remove by `(name, kind)` rather than overwrite/delete by name alone, using `TransientCleared`'s `transient_kind` field (landed in #3016) to know which pill cleared. `syncTransientsFromSnapshot` groups the now-flat `TransientView` list by name instead of assuming one row per agent. - `inFlightOpsByAgent()` -> `queuedOpsByAgent()`: trimmed to the `Pending` (queued, not yet started) case only. The `Running` branch and its "running beats queued" priority logic are gone entirely — dead weight now that transients cover every running case unconditionally. - Render loop: an agent's transients win outright whenever any exist (rendered as **one badge per pill**, not collapsed into one label — mara: "show all running nodes that name the agent"); the queued fallback only applies when a agent has zero transients. `opRunning` simplifies to "does this agent have at least one transient". - `docs/web-ui/dashboard.md`'s Container-row section rewritten to match — it described a "transient, then in-flight-queue, in priority order" model that's no longer accurate now that the second source only ever fires for the one case the first can't represent. ## Verification `npm run build` clean for both packages (dashboard + agent). Standalone re-derivation of the transient-map + queued-fallback logic (`/tmp/verify-swarm-transients.mjs`, not part of this diff) run against constructed event sequences: single-pill lifecycle, two simultaneous pills on one agent with independent clear-by-kind, clearing an unknown kind is a safe no-op, a flat snapshot with duplicate agent names groups correctly, the queued fallback only fires when no transient exists and steps aside the instant one arrives, and a Running-state rebuild-queue entry produces no queued badge (confirming the Pending-only trim is correct, not just assumed). All 17 checks passed. Verified directly against the merged backend rather than trusting summaries: `job_queue/mod.rs::running_transients()` filters `State::Running` only (not Pending — an earlier note of mine claiming otherwise was imprecise paraphrasing), and `NodeView.agent` / `running_transients()`'s agent both resolve through the same `payload.agent()`, so a Running node's presence in `rebuild_queue` and its presence as a transient are guaranteed consistent, not just usually so. #2985 (DagView/NodeView deletion) unblocks once this merges — atlas is waiting on a ping. |
||
| .. | ||
| agent.md | ||
| css-vars.md | ||
| dashboard.md | ||
| README.md | ||
| shape.md | ||
Dashboard & Web UI
The operator-facing entry point for running a hive day to day. 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, Builds, Stats,
Settings, Core, Credentials, plus Matrix/Forge when enabled). Every
page links back to H0M3, so you're never more than one click from the
hub.
The dashboard itself (/dashboard.html) is where you'll spend most
of your time. It's a single page with exactly four tabs:
- SW4RM — every agent, live. This is the default tab and the one you'll check most. When the hive has peer hives configured, they show up here too, as a card list under the main container list — not a separate tab.
- Y3R C4LL — anything waiting on you: pending approvals and agent questions. If an agent needs a decision from you, it's here.
- P3RM1SS10NS — what tools and system-level access each agent has.
- SCH3DUL3S — scheduled prompts and agent self-reminders.
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), Logs (/logs.html, per-agent and host
journals), Stats (/stats.html, swarm-wide usage stats), Settings
(/settings.html, your local browser preferences), Builds (/builds.html, the rebuild
queue and build history), Core (/core.html, tombstones and
container resource use), and Credentials (/credentials.html,
provisioning matrix/GitHub/forge accounts per agent).
Each agent also has its own page — a full terminal view of that
agent's session, reachable by clicking 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. SW4RM shows every container as a row: name,
whether it's running, what it's currently doing (a live status pill —
rebuilding…, starting…, and so on — while something's in flight),
and quick links (stats, screen, forge profile). Click the name to open
its terminal and watch it work in real time.
Answer something an agent is waiting on. Y3R C4LL is the one tab worth checking regularly — it's everything that needs you: approvals for config changes, and questions an agent has asked and is blocked on. The tab's count pill tells you at a glance if anything's pending.
Approve or reject a config change. Agent config changes (new packages, env vars, MCP servers) go through an approval queue rather than landing automatically — you'll see them on Y3R C4LL, with a diff of what's changing.
Start, stop, restart, or rebuild an agent. Select one or more
agents on SW4RM (click 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 after approving a change, or whenever an agent
shows as "needs update."
Watch a build. BU1LDS shows the rebuild queue live, plus a streaming log of whatever's currently building. Useful right after approving a 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. The Logs page's AGENT tab pulls a live
journald view for any agent + service; the per-agent ⋮ menu's
journal logs → link jumps straight there, pre-filtered.
Set up a schedule or check on a reminder. SCH3DUL3S covers both — recurring or one-shot prompts you schedule for one or more agents, and reminders agents have set for themselves.
Provision an account for an agent. The Credentials page covers Matrix, GitHub, and external-forge accounts per agent, without editing that agent's config repo.
More depth
- 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, and other plumbing shared across every page.
- CSS theme variables — the colour system, for anyone touching the frontend's CSS.