01 — Initial Product & UX Recommendation: Fleet Monitor

2026-07-18. Written BEFORE the research pass, per process; the research must challenge it, and 00-SYNTHESIS.md records where it survived or fell. Inherits the plans/001-factory-apps-validation verdict (row 3: ADOPT + thin layer, local-first) as the frame under test, not as settled truth.

Context: internal tool, two operators total (Robert; Tomas as consumer), fleets ≤64 concurrent Claude Code sessions executing the Groupon rebuild on Zaruba’s groupon2 substrate. Tomas explicitly asked (2026-07-18, 16:52 GChat) that Robert’s tooling also watch his deployments and workflows — a scope input the 001 plan did not yet contain.

What the product fundamentally is

An attention router, not an analytics suite. The name “control-room dashboard” is the wrong metaphor and the first thing to remove: NOC-style metric walls are for visitors, operators work a queue. The product is ONE prioritized list of fleet units — needs-input floats to top, inline answer without context-switch — with aggregate health/cost (Grafana) underneath and a small set of factory metrics (joined with the work-ledger) that nothing off-the-shelf computes.

One sentence: “Which of my N agents needs a human right now, and what is the fleet costing per merged unit — answerable in one glance, actionable in under a minute.”

The ten judgments

Question	Recommendation
Serve first	Robert, solo operator. Tomas second, as read-only daily-digest consumer — not a dashboard user.
Most important problem	At N>10 concurrent sessions the operator cannot tell which agents are blocked/awaiting-input/failed without tab-cycling; blocked agents idle silently (wasted wall-clock + tokens); the program has no cost/quality accounting per merged unit.
Simplest useful version	(a) Adopt: `claude agents` Agent View for the needs-input list + inline reply; docker-compose OTel→Prometheus→Grafana with dashboard 25255 for aggregates. (b) Build: hook-event ingest → SQLite → one local web page joining work-ledger rows: unit status board + four metrics (rework rate, cost/merged-unit, queue depth, stall detection).
Primary journey	Glance → triage → unblock → return to decision work. Target: <60 s per interrupt, zero terminal tab-cycling.
Interaction model	Two surfaces. Board (persistent, glanceable, read-only, big type, no interaction) and queue (keyboard-first, inline answer). No third surface.
UX/UI direction	One screen, no navigation. Status IS the interface. Color carries state only (red = needs human, amber = stalled, everything else recedes). Empty state is the goal state: “0 blocked” rendered large is success. Dark, calm, dense type; zero decoration (Rams), affordance-first (Norman), remove until it breaks (Ive).
Remove from concept	The metric wall as primary UI; a kanban board (the ledger already owns state — a board duplicates it); historical analytics suite; alert zoo; the phrase “control room”.
Not in MVP	Auth/multi-tenant (localhost only), mobile, Tomas write-access, auto-remediation (auto-kill/restart agents), triage dedup (separate factory app), cloud deploy (billing gate anyway), notifications beyond one daily digest.
Biggest usability risk	Trust. A needs-input list that is stale or wrong ONCE sends the operator permanently back to tmux. Second: alarm fatigue — metrics displayed that never change a decision.
Platform	Local web (localhost, docker-compose) + the existing CLI Agent View. Not desktop, not mobile, not SaaS.

Fastest concept test: one-week live trial on the next real wave. Measure (before/after): operator-minutes per day spent locating blocked agents; hours of silent stall discovered late; cost/merged-unit visible at all (yes/no).

Design lenses applied (Ive · Norman · Rams)

Ive (reduction, coherence): the temptation is a cockpit; the product is a doorbell. Every panel must justify itself against “does this change what the operator does next?” — projected removal rate for a typical Grafana LLM dashboard: ~80% of panels.
Norman (mental model, feedback): the operator’s mental model is “my workers raise hands.” The system must make raised hands impossible to miss and everything else invisible. False status is a mapping failure — worse than no status. Stall detection needs an honest confidence signal, not a binary lie.
Rams (less, but better; honesty): four metrics that are true beat forty that are plausible. Numbers carry their passport (MEASURED from ledger vs MODELED from token estimates) per Tomas’s comm standards — in the UI itself.

Open questions the research pass must answer

Rung-2 check: does local fleet tooling already exist on this machine (statusline mirrors a fleetops session_marker set; an agent-type description references “FleetView”)? If yes, the product may be an upgrade, not a build.
Agent View coverage: how much of the needs-input list does claude agents already ship (background sessions, teams, multiple hosts, remote)? Build only the delta.
Zaruba watch scope: which groupon2 deployment/workflow signals belong in v1 of his explicit ask — GitHub Actions status? Temporal workflow-management execution stream? Both?
Market delta: anything new since the 2026-07 sweep (research/12) — new OSS, Anthropic shipping fleet features that obsolete the thin layer?
Buy honestly: does self-hosted Langfuse (or Datadog LLM obs) beat Prom+Grafana assembly for a 2-operator local stack, or is it freight?
Ledger dependency: MVP is specced to join ledger rows — but the work-ledger is itself only decided, not built. Does v1 degrade gracefully to session-level metrics without it?