Dashboard

The Dashboard is the agent home in the TUI (Activity) and the GUI (Dashboard). It is a first-level overview of the software factory — SDLC, Docs, Observability, Security, Optimizations. In the GUI the area panels are the navigation: clicking one opens its subpage, and a back button returns to the overview.

The TUI Activity screen and the API read one aggregated payload, GET /api/dashboard. The GUI Dashboard also fans out per area: workflow runs and the newest run’s step log (GET /api/workflows/{kind}), the Analytics rollup (GET /api/analytics), audit (GET /api/audit), and token usage (GET /api/token-usage).

Factory areas

Area	Overview shows	Subpage adds
SDLC	Tasks in progress, workers, queue, delivered/failed in range, latest task, dispatch state	Active work, dispatch capacity, admission deferrals, the work board (deliveries, reviews, harness runs), and the per-kind workflow list
Docs	Sessions recorded, retrieve packs ready, embed failures, retrieves in range	`docs_converge` runs, session memory, and the retrieve corpus
Observability	Checks green, failing checks, groups ok	Environment health, agent liveness, and `production_monitor` runs
Security	Pentests in the last 30 days and whether the harness pack is applied (drift vs in sync)	Harness pack drift detail (missing requirements and the harness PR), `pentest` runs, and recent audit entries
Optimizations	Tokens (input, output, cache hit rate) in range and `optimize_performance` runs	Top token-consuming agents and `optimize_performance` runs

Agent liveness — version, coordinator heartbeat, and auto-update — lives in the Observability subpage’s Agent liveness card.

The harness pack card reads GET /api/workflows/harness_converge plus the newest run’s step log. Drift reasons (missing files, bind suggestions, overlay errors) come from the converge state; agents that do not persist them are still classified by whether the converge routed through open_or_update_pr.

Environment health

The agent reads the latest safety-check result per check name for every environment in monitor_environments (falling back to monitor_environment, default production) and rolls them up:

overall is healthy when every required check passes, degraded if any required check fails, and unknown when no checks have run.
Groups summarize by kind: HTTP apps and Grafana / metrics per monitored environment (labelled staging · HTTP apps), plus agent-level Tooling and Agent. Individual checks carry an environment tag when more than one environment is monitored.
The Agent group is busy while workers or tasks are in flight, otherwise healthy.
Tooling readiness comes from GET /api/tooling (GitHub, coding runtime, gcx, and so on).

System failures — a missing gcx binary, an unconfigured Grafana credential — are shown but do not degrade the environment. They are agent-side problems, not environment health.

Dispatch capacity

The capacity block explains why the agent is or is not starting workers:

Field	Meaning
`workers_used` / `workers_max` / `workers_free`	Occupied, configured, and free worker slots
`coordinator_inflight`	Coordinator coding-runtime decisions holding a slot
`spawns_pending`	Spawns between the capacity check and the agent row
`compile_slots`	Configured `max_compile_slots` (0 = unlimited)
`dispatch_min_available_mb`	Configured `dispatch_min_available_mb` floor (0 = off)
`mem_available_mb`	Current host `MemAvailable` in MiB, when readable
`dispatch_allowed`	Whether the memory floor currently permits a spawn
`queued_tasks` / `running_tasks`	`task_lifecycle` runs waiting for a slot / running
`queued_stalled`	Runs waiting for capacity longer than `queue_stall_minutes`
`stall_reason`	Why capacity is closed, when a stall is present (memory floor, pool full, …)

Capacity is fail-closed: when occupancy cannot be read, the pool is treated as full, not empty.

A capacity wait is deliberately exempt from step timeouts, so the queue-stall watchdog is what makes a stuck queue visible: the first deferral of a step stamps a wait anchor in the run’s step state, and the coordinator’s watchdog audits and alarms (queue_stall_minutes, default 120, 0 disables) when the wait outlives it. Waiting runs keep their queue position — the alarm names what to free, it does not kill the work. active_work rows carry the same facts per run: waiting_secs and stalled.

Active work and delivered tasks

active_work lists every running workflow (delivery, monitors, sync, and so on) with its kind, current step, status, issue/PR, branch, timestamps, and error.
recent_tasks lists running task_lifecycle runs first, then the latest finished ones.
delivered_tasks is the work board: issue deliveries, external PR reviews, and harness converge runs. Each row carries an outcome (running, delivered, failed) and a short outcome_label such as merged & healthy on staging, opened harness PR, or failed @backlog.

Workflow titles are recovered from older runs and from the GitHub preview when later steps drop title from step state.

Auto-update and coordinator health

coordinator.running and coordinator.last_heartbeat_at come from the watchdog heartbeat.
auto_update.enabled, pending, and draining show whether a newer release is waiting and whether the agent is waiting for in-flight workers before it applies the binary.

Drill in

Select a delivered or active row to open the workflow run detail:

TUI: open the run from Dashboard.
GUI: drill in from the row.
API: GET /api/workflows/{kind}/runs/{id} returns the run plus its step log.

From run detail you can terminate a stuck run: POST /api/workflows/{kind}/runs/{id}/terminate. Termination is recorded in the audit log as workflow.terminate.

Gotchas

The dashboard reads the latest result per check name; a stale green can outlive a current outage until the next monitor cycle runs.
overall reflects required checks only. Optional failures stay visible in the group summary but do not mark the environment degraded.
delivered_tasks is capped (20 rows) and merges delivery, review, and harness runs; reviews are deduped per PR.