feat(rollout): rollout framework presentational layer + Storybook

[jmarrxyz]

Reviewable diff: +2698/-2 across 18 files (excludes generated, test, and story files).

Summary

Adds a presentational rollout-framework layer + Storybook for fleet rollouts (firmware updates, reboots, firmware release channels), modeled on the shipped curtailment experience. It gives reviewers a runnable reference for the rollout UX direction — the config surfaces, the in-progress lifecycle, and the release-channel management flow — before any of it is wired to live RPCs.

Everything is additive under client/src/protoFleet/features/rollout/, plus one backward-compatible prop on the shared TargetSelectButton. No shipped behavior changes. The components are driven by fixtures and rendered in Storybook, so this is a design-exploration branch, not product code. Unrelated in-flight fleetManagement work in the working tree is intentionally excluded; this branch is rollout-only.

How it works

The layer is a set of presentational React components composed almost entirely from shipped primitives, fed by static fixtures:

• Config path. A rollout is configured through RolloutControls (strategy / order / batch size / interval), surfaced either in the generic RolloutConfigModal or grafted onto the shipped firmware "Add payload" flow. useRolloutConfigModalState holds the transient form state; rolloutDisplayUtils maps enum values to human labels.
• Release channels. On the Firmware settings page, a shipped TabStrip adds a Release channels tab beside Files. The tab body is a shared List (ReleaseChannelsTable) with a per-row Manage action that opens ReleaseChannelModal — a full-screen two-pane modal (the shell CurtailmentStartModal uses) with General / Firmware / Applies-to / Rollout on the left and a coverage summary on the right.
• In-progress path. ActiveRolloutStatus is the in-situ status card (stat grid, progress bar + key, elapsed / est-remaining, excluded-count annotation), mirroring curtailment's ActiveCurtailmentStatus. ActiveRolloutBanner and RolloutPill are the shell-level banner and header pill; ViewRolloutModal is the read-only detail view.
• In-situ stories. Rather than rendering components in isolation, the stories mount them inside the real app shell + navigation on the pages they'd actually appear on (Firmware settings, Fleet, Energy, Activity), seeding permissions so gated CTAs show. activeRolloutStoryHelpers provides the shared decorators/fixtures for the lifecycle states (scheduled → in progress → paused → pilot review → completed / completed-with-failures) plus a live animated lifecycle.

State lives only in component/store memory for the demo; nothing crosses a network boundary or persists.

Diagrams

flowchart TD
    subgraph Shipped["Shipped primitives (reused)"]
        FSTP["FullScreenTwoPaneModal"]
        LIST["List"]
        TABS["TabStrip"]
        TSB["TargetSelectButton (+ size prop)"]
        PC["ProgressCircular"]
        CSM["CurtailmentStartModal shell"]
    end

    subgraph Rollout["features/rollout (new, presentational)"]
        RC["RolloutControls"]
        RCM["RolloutConfigModal"]
        ARS["ActiveRolloutStatus"]
        ARB["ActiveRolloutBanner / RolloutPill"]
        RCT["ReleaseChannelsTable"]
        RCHM["ReleaseChannelModal"]
        VRM["ViewRolloutModal"]
        FX["fixtures + rolloutDisplayUtils + types"]
    end

    FX --> RC
    FX --> ARS
    FX --> RCT
    RC --> RCM
    RC --> RCHM
    TABS --> RCT
    LIST --> RCT
    FSTP --> RCHM
    CSM --> RCHM
    TSB --> RCHM
    PC --> ARS
    RCT --> RCHM
    ARS --> ARB

    subgraph Stories["Storybook (in-situ)"]
        ST["real AppShell + nav + seeded perms"]
    end
    RCM --> ST
    RCHM --> ST
    ARS --> ST
    ARB --> ST

Loading

stateDiagram-v2
    [*] --> Scheduled
    Scheduled --> InProgress
    InProgress --> Paused
    Paused --> InProgress
    InProgress --> PilotReview
    PilotReview --> InProgress
    InProgress --> Completed
    InProgress --> CompletedWithFailures
    CompletedWithFailures --> [*]
    Completed --> [*]

Loading

Areas of the code involved

Area / file	What changed	Why it matters for review
components/TargetSelectButton/TargetSelectButton.tsx	Added opt-in size prop (defaults to base)	Only edit outside features/rollout/. Shared by curtailment + schedule modals; default preserves their rendering.
features/rollout/RolloutControls.tsx, RolloutConfigModal.tsx, RolloutColumnState.tsx, RolloutFieldInfo.tsx, useRolloutConfigModalState.ts	New config controls + generic config modal	Core reused config surface; check the control set matches the intended strategy/order/batch model.
features/rollout/ActiveRolloutStatus.tsx, ActiveRolloutBanner.tsx, RolloutPill.tsx, ViewRolloutModal.tsx	New in-progress status card, banner, header pill, detail modal	Mirrors curtailment's ActiveCurtailmentStatus; confirm parity is desirable.
features/rollout/ReleaseChannelsTable.tsx, ReleaseChannelModal.tsx	New Files/Release-channels tab table + full-screen Manage/Create modal	Composed from TabStrip, List, FullScreenTwoPaneModal, TargetSelectButton, RolloutControls.
features/rollout/rolloutTypes.ts, releaseChannelTypes.ts, rolloutDisplayUtils.ts	New types + label/format helpers	Display-only; no API contract.
features/rollout/rollout.fixtures.ts, releaseChannel.fixtures.ts	Static demo data	Drives the stories; not shipped data.
features/rollout/*.stories.tsx, activeRolloutStoryHelpers.tsx	Storybook stories + shared decorators (excluded from reviewable count)	In-situ renders inside real shell/nav; the intended review surface.

Key technical decisions & trade-offs

• Presentational + fixture-driven, not RPC-wired. Deliberate: this is a UX reference branch. Landing it as product code is a separate effort.
• Reuse-first over new patterns. Composes shipped primitives (FullScreenTwoPaneModal, List, TabStrip, TargetSelectButton, ProgressCircular, SecondaryNavigation, CurtailmentStartModal) instead of reinventing. Trade-off: the rollout surfaces inherit those components' behavior/appearance, including the shipped defaults noted below.
• One additive shared edit. TargetSelectButton gained an opt-in size prop rather than a global restyle, so curtailment/schedule are provably unchanged (default = base; consumer suites green).
• Curtailment parity for the active-rollout card. Chosen so the two operator experiences read consistently; worth confirming that's the desired direction.
• Two open UX flags (deliberate, shipped-default): (1) reboot has no page of its own, so its in-situ states render on the Fleet page — a judgment call, easy to relocate. (2) the active TabStrip tab reads orange (shipped TabStrip default, same as FleetLayout/Team tabs) where the mock drew it black; kept the component default rather than override.

Testing & validation

Validated at the pushed HEAD c192222d in a clean worktree pinned to that SHA (working tree carries unrelated in-flight work, so checks were isolated to committed content):

• tsc --noEmit — clean (exit 0).
• eslint . --max-warnings 0 (the just lint client step, full client) — clean (exit 0). Covers the client-boundaries import/console rules.
• Targeted tests — the two existing TargetSelectButton consumers, CurtailmentStartModal.test.tsx + ScheduleModal.test.tsx: 81/81 passing, confirming the additive size prop doesn't regress shipped modals.
• Hygiene — client-only diff (no proto/db/migration/Go/asicrs/fake-rig skills apply), no console.*, no --no-verify bypass, all 30 commits carry Signed-off-by + Co-authored-by: Jared Marrz.
• Visual — every story screenshot-verified on Storybook (port 6007): lifecycle states, in-situ surfaces, release-channels tab, Manage modal.

Not run: unit tests for the rollout components themselves (none exist — presentational/fixture-driven) and E2E (slow, no behavioral API change to exercise).

[github-actions]

🔐 Codex Security Review

Note: This is an automated security-focused code review generated by Codex.
It should be used as a supplementary check alongside human review.
False positives are possible - use your judgment.

Scope summary

• Reviewed pull request diff only (edf2266530fa0024e298b0583d7626e5404d7908...e476385cb8b9dc06b3065e5a665a19eb26afa3aa, exact PR three-dot diff)
• Model: gpt-5.6-sol

💡 Click "edited" above to see previous reviews for this PR.

---

Review Summary

Overall Risk: LOW

Findings

[LOW] Completed rollouts use viewing time as their completion time

• Category: Frontend
• Location: client/src/protoFleet/features/rollout/ActiveRolloutStatus.tsx:178
• Description: Elapsed time is always calculated from startedAt to the component's mount-time now. The timer stops for paused or terminal states, but the event model has no ending timestamp. Reopening a completed rollout therefore includes all time since completion.
• Impact: Historical rollout duration and SLA information becomes increasingly inaccurate, misleading operational investigations.
• Recommendation: Add an ending or paused timestamp (or authoritative elapsed duration) and use the current time only for actively running rollouts.

[LOW] Scheduling state ignores the plan timestamp and defaults to an expired date

• Category: Frontend
• Location: client/src/protoFleet/features/rollout/useRolloutConfigModalState.ts:12
• Description: The helper ignores initial.scheduledStartAt and always initializes the date to August 4, 2026, which is already in the past at the reviewed commit. This also makes editing an existing scheduled plan display state inconsistent with its configuration.
• Impact: Operators can be shown the wrong schedule, while a future RPC integration could reject the plan or execute it immediately.
• Recommendation: Initialize from scheduledStartAt; otherwise use an empty or dynamically future value, and reject missing or past schedules before submission.

[LOW] Device-status mapping treats a firmware attention state as active work

• Category: Frontend
• Location: client/src/protoFleet/features/rollout/rolloutDisplayUtils.ts:101
• Description: REBOOT_REQUIRED means firmware installation finished but requires a reboot, yet the new generic mapper labels it inProgress without considering the rollout process or active batch. It can consequently label an unrelated firmware condition as an active reboot or curtailment.
• Impact: Per-miner progress may remain stuck or display the wrong operation once this helper is integrated.
• Recommendation: Derive phases from rollout-target or correlated active-batch state. Use the generated enum and return no rollout phase for unrelated device statuses.

Notes

The change is currently unintegrated Storybook and presentational scaffolding, limiting immediate production exposure. No auth, SQL, command execution, plugin, infrastructure, pool-address, wallet, or protobuf-source changes were present. TypeScript and ESLint could not be run because client dependencies were unavailable; git diff --check passed.

---

_{Generated by Codex Security Review |
Triggered by: @jmarrxyz |
Review workflow run}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c192222d25

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Use the process verb for all-at-once rollouts

When a non-firmware rollout is inProgress and uses the allAtOnce strategy, ActiveRolloutStatus calls this helper and renders Updating all at once. The generic rollout controls expose this strategy for reboot and curtailment as well, so those active rollouts would be mislabeled as firmware updates; derive this branch from event.processType like the other phase labels do.

Useful? React with 👍 / 👎.