v1.10 Release Roadmap — worker upgrade (provisional)

[VijitSingh97]

Single source of truth for the v1.10 release plan — same format as #364. Provisional: two issues, one has an upstream RigForge gate; re-sequence when the cycle opens.

The theme: v1.10 brings the stack's own one-click upgrade down to the worker level. Pithead already shows a new-release badge (#224) and upgrades itself in one click (#59); the rigs it drives have neither. RigForge and Pithead version independently (RigForge already reports its version on every poll via :8081/2/summary), so an operator has no way to see a rig is behind and no way to upgrade it without SSHing to each box. v1.10 closes both — visibility first, then action.

   #596  "new version available" badge (RigForge version)   ─┐ pithead-only, NO RigForge dep.
         reuse w["rigforge"].version already on every poll;   │ notify-only. Ships first, alone.
         mirror the stack-level new-release badge (#224)      │
                 │                                            │
                 ▼                                            │
   #597  one-click remote worker upgrade (orchestration + UI) ┘ button appears where the badge is.
         mirrors the stack's own one-click upgrade (#59),      GATED on rigforge#308 shipping in a
         per-worker. Confirm-click → control_upgrade template. RigForge release first.

The work

• Worker "new version available" badge (RigForge version) #596 — worker "new version available" badge. Pithead-only, notify-only, no RigForge dependency — the low-risk half, ships first. Reuse rigforge.version already attached to each worker (service/data_service.py _merge_direct_stats). Mirrors the stack-level new-release badge (Dashboard: "new release available" badge linking to the GitHub release (notify-only, no upgrade) #224).
• One-click remote worker upgrade — orchestration + UI #597 — one-click remote worker upgrade (orchestration + UI). The upgrade button appears where rigforge_update.available (so Worker "new version available" badge (RigForge version) #596 lands first). Mirrors the stack's own one-click upgrade (Dashboard: new-version warning + one-click upgrade button #59) at the per-worker level, reusing the control_upgrade() host-runner security template.

Upstream gate — RigForge: ✅ SATISFIED (audited 2026-07-19)

• rigforge#308 SHIPPED: ADR 0002 accepted (D-OPEN-1/2 signed off), POST :8082/upgrade +
  control-upgrade verb in v1.11.1, made real-rig-correct in v1.11.2 (test(#295): confirm effective Tari status is surfaced (build_tari); lock in derivation #318 ancestry-guard
  fix). Minimum rig version for One-click remote worker upgrade — orchestration + UI #597: v1.11.2. Both real-rig bugs in the chain were caught by
  hardware e2e, not the stubbed unit suite — see the tier-4 gate below.
• Trust model settled (ADR 0002 D5, signed off): git-tag checkout over TLS, GitHub trust root,
  monotonic + ancestor-of-main guards, immutable releases; NO release signing (minisign removed by
  decision; keyless cosign = D10 roadmap, deferred). One-click remote worker upgrade — orchestration + UI #597's old cosign gate is dropped to match.
• Consumer-contract audit (full detail + poll strategy in One-click remote worker upgrade — orchestration + UI #597): the rig does NOT re-derive
  latest (our Tor-side re-derivation is load-bearing); no in-progress status; refusals collapse
  into failed+reason; bare-vs-v version formats. Upstream follow-ups filed, none blocking:
  rigforge#320 (status lifecycle), rigforge#321 (SECURITY.md/ADR drift + throttle
  fail-open), rigforge#322 (codify the /upgrade real-rig e2e — the producer half of our
  tier-4 gate).

Added to the milestone from the audit

• Shared response-size cap for every external HTTP client (update checker, XvB, price feed, RigForge releases) #660 — shared response-size cap for every external HTTP client. Worker "new version available" badge (RigForge version) #596 adds the next new
  GitHub-client call site; known residual from the feat(dashboard): show XvB raffle wins on the chart and in a log #642/feat(#520): opt-in live XMR/XTM price feed over Tor + fiat estimates on the earnings card #646 security reviews. Small, lands with
  or before Worker "new version available" badge (RigForge version) #596.

• Header still shows 'New release v1.9.1 available' + Upgrade button while already running v1.9.1 #664 — header shows "new release vX available" while already running vX (observed live
  on prod right after its v1.9.1 one-click). The fix — suppress update at the render seam when
  latest <= running — is the same self-consistency guard Worker "new version available" badge (RigForge version) #596's per-worker badge needs (a rig
  on X must never badge "X available"), so it lands with this cycle.

Testing plan

Tier-mapped plans live in the issues (#596 and #597 §Testing plan): tier 1 version/state logic,
tier 2 stack-suite runner vs a stubbed rig + dashboard fakes lifecycle, tier 3 deliberately
skipped (no honest rig-in-docker), tier 4 = one gouda session with a borrowed loaner
(miner-1/2, never miner-0): behind-rig badge → one-click → applied → badge clears, plus the
6h-throttle retry-later surface. Rollback coverage stays rig-side (rigforge#322).

Release status — cycle not open

Gates when it opens: #660 + #596 merged (badge first, no RigForge dep) · #597 merged behind the
default-off rig flag chain (control_upgrade ⇒ control ⇒ token + source pin) · the tier-4
loaner scenario above green · security-reviewer pass on #597 (host-mutation surface, mandatory) ·
CHANGELOG · standard cut.

(Renumbered v1.10 → v1.11 — on 2026-07-18, after "Config UX round 2" took v1.8 and pushed the chain out.)

(Swapped BACK to the v1.10 slot on 2026-07-19 — operator call: worker upgrade is the smaller, better-scoped cycle and goes first; deployment flexibility (#532) moves to v1.11.)

[VijitSingh97]

v1.10 implementation is up as a stacked PR train, all three left open for review:

• security(#660): shared response-size cap for the dashboard's external API fetches #686 — security(#660): shared bounded_get response-size cap, all five external call sites (base: develop)
• feat(#596): per-worker RigForge "new version available" badge #688 — feat(#596): per-worker RigForge new-version badge (stacked on security(#660): shared response-size cap for the dashboard's external API fetches #686)
• feat(#597): one-click remote worker upgrade #691 — feat(#597): one-click remote worker upgrade (stacked on feat(#596): per-worker RigForge "new version available" badge #688)

All three: make lint + make test green (1518 stack tests; patch coverage 98–100%), docs in the house voice, CHANGELOG under Unreleased. #597 had its mandatory security-reviewer pass — one MEDIUM (12-min rig poll could stall the root drain) fixed by capping the poll at 90s, one LOW residual filed as #690 (size caps for the runner's own curl calls).

Merge order: #686 → #688 → #691, retargeting each to develop as its base lands. Still owed before the cut: the tier-4 gouda session with a borrowed loaner (badge → one-click → applied → badge clears; 6h-throttle retry-later), per the release runbook.

🤖 Posted by Claude Code from the v1.10 implementation session.