[Feature] Dashboard: consume RigForge's enriched feed (rigforge#99) — update badge + per-worker health / power / tune / firmware

[VijitSingh97]

Problem / motivation

p2pool-starter-stack/rigforge#99 will expose a rich, read-only per-worker feed — a strict superset of XMRig's /1/summary with a namespaced rigforge block carrying provenance, tune state, power/efficiency, health, and firmware identity:

"rigforge": {
  "version": "…", "xmrig_commit": "…",
  "tune":   { "applied": { /* winning knobs */ }, "target": "perf", "last_best_hs": 12345,
              "autotune": { "enabled": true, "next": "…", "recent": [/* decisions */] } },
  "power":  { "watts": 142.0, "hs_per_watt": 86.9 },
  "health": { "hugepages_pct": 100, "msr": "applied", "governor": "performance",
              "ram": { "channels": 2, "mts": 6000, "rated_mts": 6000 },
              "clock_pct_of_boost": 96, "throttling": false,
              "firmware": { "board": "…", "bios": "…", "xmp": true, "smt": "on" } }
}

The dashboard reads each worker's /1/summary today (build/dashboard/mining_dashboard/client/xmrig_client.py → get_stats) but does nothing with version or provenance, and would throw away the entire enriched block. The workers table (WORKER_COLUMNS in build/dashboard/mining_dashboard/web/static/logic.mjs) shows only name / IP / uptime / hashrate / shares. To learn that a rig is out of date, throttling, running single-channel RAM, has hugepages < 100%, hasn't been tuned, or is below its last tuned best, an operator currently has to SSH in and run doctor / tune --history — exactly the signals this feed surfaces.

This issue is the dashboard-side consumer of rigforge#99: parse the feed once and surface it — both as an "update available" badge for stale miners and as at-a-glance health/efficiency read-outs. It's one parse path and one set of components, so it's tracked as one piece of work.

Proposed solution

1. Parse the feed once.
In the collector / get_stats path, parse the worker's XMRig version (already present in stock /1/summary) plus the full rigforge block (version, xmrig_commit, tune, power, health, firmware) and carry them onto the worker model that feeds WorkersTable.

2. "Update available" badge (mirror #58/#59).

• Compare each worker's running RigForge/XMRig version against the latest published release (GitHub releases API for p2pool-starter-stack/rigforge), cached (e.g. hourly) like Dashboard: new-version warning + one-click upgrade button #59's detector; semver, flag only when latest > running.
• Opt-out / offline-safe: disable-able, fails silently with no connectivity (the stack can run Tor-only / offline) — never block or error a row on a failed check.
• Render an accent "Update available" badge next to the miner, reusing the existing UpdateBadge / badge-accent pattern in build/dashboard/mining_dashboard/web/static/components.mjs (built for the stack header in Dashboard: show the stack version on every screen (released version, or branch+hash in dev) #58/Dashboard: new-version warning + one-click upgrade button #59) with a tooltip + release link. Current workers show the muted VersionBadge / nothing.

3. At-a-glance health & efficiency chips in the workers table.
Reuse the existing Badges / badge-row + badge-bad/badge-ok components for the highest-value signals:

• Throttling (clock_pct_of_boost, throttling).
• RAM when channels < expected or mts < rated_mts (single-channel / XMP-off — a common silent hashrate killer).
• HugePages / MSR / governor not-optimal (hugepages_pct < 100, msr != applied, governor != performance).
• Efficiency: H/s per watt (power.hs_per_watt) + live watts — column and/or a fleet total in the header StatCards.
• Not tuned / below best (no tune applied, or current H/s materially below tune.last_best_hs).

4. Full detail in a per-worker view.
The complete block — tune history + applied knobs, firmware identity (board / BIOS / XMP / SMT), the full health checklist, power/efficiency, provenance — laid out on the Worker Inspect page (#185) as a panel. Until #185 lands, an expandable table row or a hover/click popover hosts the long-form view.

Graceful degradation: the XMRig-version badge works against stock /1/summary even before rigforge#99 ships. Everything else only renders when the rigforge block is present — a stock-XMRig worker shows no extra chips and no detail block, never an error or empty placeholder.

Alternatives considered

• Two separate issues (update badge vs. telemetry display): rejected — same feed, same parse path, same WorkersTable/badge components; splitting them just creates two issues colliding on the same code. The version fields and the rest of the block are one JSON object parsed in one place.
• Read only XMRig's native version (no rigforge#99): cheaper and works today, but can't surface the RigForge-layer version or any health/tune/power data. Kept as the graceful-degradation fallback for the badge, not the whole feature.
• Fold entirely into Dashboard: Worker Inspect page — read/edit each miner's XMRig config over its API, with versioned config history + per-config hashrate stats #185 (Worker Inspect): Dashboard: Worker Inspect page — read/edit each miner's XMRig config over its API, with versioned config history + per-config hashrate stats #185 is scoped to read/edit XMRig config + version history + per-config hashrate — different data and a big feature on its own. The display here is valuable before Dashboard: Worker Inspect page — read/edit each miner's XMRig config over its API, with versioned config history + per-config hashrate stats #185's edit machinery exists, and slots into its page as a panel when it lands.
• Time-series instead of live display ([Epic] Persist valuable telemetry as time-series — stop discarding block / share-health / disk-growth / XvB / per-worker data #196): [Epic] Persist valuable telemetry as time-series — stop discarding block / share-health / disk-growth / XvB / per-worker data #196 persists per-worker telemetry; this is the live read-out. They compose (historize what we display).

Additional context

Depends on / relates to:

• Producer: Sister HTTP API: serve a superset of XMRig's stats, enriched with RigForge-captured data rigforge#99 — serves the rigforge block (provenance / tune / power / health / firmware), reusing doctor + tune --history readers.
• Badge pattern to reuse: Dashboard: show the stack version on every screen (released version, or branch+hash in dev) #58 (running-version badge), Dashboard: new-version warning + one-click upgrade button #59 (update-available badge + one-click upgrade) — same detection + badge mechanism, applied per-worker.
• Detail home: Dashboard: Worker Inspect page — read/edit each miner's XMRig config over its API, with versioned config history + per-config hashrate stats #185 — Worker Inspect page; the full block becomes a panel there.
• Custom token/port fleets: Dashboard: config to read workers that use a custom XMRig API token #171 / Configurable worker ports & endpoints: non-standard stratum/API ports + per-worker host/port/token overrides (later) #172 — needed to read non-default workers; same get_stats path.
• Security: keep the SSRF: miner-controlled worker name/IP becomes an outbound request host from the host-networked dashboard #122 SSRF guard (_safe_probe_host) on the fetch — no new outbound path to miner-controlled hosts.
• History: [Epic] Persist valuable telemetry as time-series — stop discarding block / share-health / disk-growth / XvB / per-worker data #196 — persist the per-worker series this displays.

Acceptance criteria

• Collector parses XMRig version + the full rigforge block (provenance / tune / power / health / firmware) and carries it to the worker model.
• A cached, opt-out, offline-safe release check marks workers behind latest (semver, latest > running); stale miners get an accent "Update available" badge with tooltip + release link, reusing UpdateBadge.
• Workers table shows at-a-glance health/efficiency chips (throttling, RAM channels/speed, hugepages/MSR/governor, H/s·W, not-tuned/below-best), reusing the existing badge components.
• A per-worker detail surface (Worker Inspect Dashboard: Worker Inspect page — read/edit each miner's XMRig config over its API, with versioned config history + per-config hashrate stats #185 panel, or an interim expandable row) renders the complete block in human-readable form.
• Graceful degradation: with only stock XMRig /1/summary, the XMRig-version badge still works; workers without a rigforge block show nothing extra and never error; only present fields render.
• Tests cover the version parse, semver compare, and chip/threshold logic; docs note the opt-out and the rigforge#99 dependency.