vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: add running field to get_agent_meta, document stopped-container display (follow-up to #433)

Browse source
This commit is contained in:
lexis 2026-05-26 00:07:00 +02:00 • committed by Mara
commit 04e67aaa03
2 changed files with 39 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

50
docs/web-ui.md
View file

@ -254,25 +254,37 @@ guess from container state.
the single source of truth. The frontend resolves each
`AgentLink.kind` (`container` → `http://host:<container.port>`,
`forge` → `http://host:3000`, `external` → already absolute).
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…` badge sourced from `rebuildQueueState` (#398) —
so the SW4RM tab shows the same rebuild progress visible on the
SYST3M tab's R3BU1LD QU3U3. Container name + port, and a
`ctx · Nk` chip showing the agent's last-turn context size
(from `ContainerView.ctx_tokens`, read from the turn-stats
sqlite on each `build_all` sweep; absent until the first turn).
The chip colour (green / yellow / red) is keyed off the model's
real context window: `build_all` resolves the last turn's model
against the host's per-model `contextWindowTokens` config and
exposes it as `ContainerView.context_window_tokens`; the badge
goes yellow ≥ 50% and red ≥ 75% of that window (the harness
compaction watermarks). When the window can't be resolved the
badge falls back to fixed 100k / 150k thresholds. (issue #66)
**When the container is stopped** (`ContainerView.running = false`),
the host clears live-only fields before emitting the state, so
the dashboard never renders stale data: the badge chain is
replaced by a single muted `■ not running` badge, the nav-strip
fetch is skipped (the agent web server is down), and the
self-reported status text is 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…` badge sourced from
`rebuildQueueState` (#398) — so the SW4RM tab shows the same
rebuild progress visible on the SYST3M tab's R3BU1LD QU3U3.
Container name + port, and a `ctx · Nk` chip showing the
agent's last-turn context size (from `ContainerView.ctx_tokens`,
read from the turn-stats sqlite on each `build_all` sweep;
absent until the first turn). The chip colour (green / yellow /
red) is keyed off the model's real context window: `build_all`
resolves the last turn's model against the host's per-model
`contextWindowTokens` config and exposes it as
`ContainerView.context_window_tokens`; the badge goes yellow
≥ 50% and red ≥ 75% of that window (the harness compaction
watermarks). When the window can't be resolved the badge falls
back to fixed 100k / 150k thresholds. (issue #66)
- Line 2: action buttons — `↻ R3BU1LD` always, `DESTR0Y` + `PURG3`
on sub-agents, `↺ R3ST4RT` + (sub-agents) `■ ST0P` when running,
`▶ ST4RT` when stopped. Buttons dim + disable while a transient