Support dashboard deployment via fips-agents deploy

[rdwj]

Summary

fips-agents deploy currently supports deploying agents scaffolded from agent-template and workflow-template. We need to extend it to also deploy dashboards from agent-dashboard.

Context

agent-dashboard is a new repo providing a single-page HTML scoreboard for fipsagents-based agents. It follows the same deployment pattern as ui-template and gateway-template: standalone container, Helm chart, OpenShift route.

The dashboard needs one configuration value at deploy time: AGENT_URL (the base URL of the agent whose scoreboard endpoints it polls).

Proposed UX

# Deploy a dashboard pointing at a specific agent
fips-agents deploy dashboard --agent-url http://my-agent:8080 --project my-ns

# Or with multiple agents
fips-agents deploy dashboard --agent-urls http://agent-1:8080,http://agent-2:8080

Implementation notes

• The dashboard repo will have a chart/ directory with a standard Helm chart
• AGENT_URL / AGENT_URLS are the only required values
• Build follows the same pattern as agent-template: podman build with UBI base
• The dashboard is a static HTML file served by nginx — no Python runtime needed
• Should work with the existing fips-agents deploy infrastructure (Helm install, route verification)

Relationship to other deploy targets

Target	Repo	Template type
Agent	agent-template	agent-loop / workflow
Gateway	gateway-template	gateway
UI	ui-template	ui
Dashboard	agent-dashboard	dashboard (new)

Acceptance criteria

• fips-agents deploy dashboard works from within an agent-dashboard repo
• --agent-url flag sets the AGENT_URL Helm value
• Route verification confirms the dashboard is reachable
• fips-agents deploy --help lists dashboard as a supported target

[Snailflyer]

For fips-agents deploy dashboard, I would make the first version verify more than "the route is reachable".

The dashboard is going to become a control surface, so the deploy receipt should probably include:

• which AGENT_URL / AGENT_URLS were bound
• whether each target answers a live health/status endpoint
• a stable agent or project id shown by the dashboard
• the last poll time per target
• a warning state for "dashboard reachable, agent unreachable"

Without that split, a successful Helm route can be mistaken for a working operations surface.

Faryo has the same boundary in a smaller shape: the browser/phone workbench is only considered successful when the action is consumed by the same live tmux-backed session, not merely accepted by the web layer. This GIF is the public proof pattern I mean: https://github.com/Snailflyer/faryo/releases/download/v1.0.7/faryo-public-redacted-same-session-handoff-walkthrough-20260528-0120.gif