test(e2e): cover release channels end to end

[rl-block]

Reviewable diff: +498/-1 across 1 files (excludes generated, test, and story files). Figures are for the pre-rebase head; see Contract alignment.

Summary

Covers release channels end to end against the fake proto-rig setup: creating channels, enforcing firmware per model, keeping miners exclusive to one channel, rolling back, pilot and batched updates with review gates and auto-continue, cancelling the remaining updates, and the header pill's attention state and deep-link. Top of the stack; no product code changes.

Stack. #1014 (merged: API contract) -> #1015 -> #1016 -> #1017 -> #1018 -> #1019 -> #1020 (Release Channels tab) -> #1021 (active updates UI) -> #1022 (header pill and activity log) -> #1023 (this PR). Diff is relative to #1022 and exercises the whole series; nothing here needs to be re-reviewed for behaviour, only for what the spec asserts. Upstream context: the UI test ids and flows from #1020–#1022, and the engine timings from #1017 (verification happens on the next enforcement tick after a fake rig reports the new version). Out of scope: running against real hardware (test.skip when target === "real"), and console-error assertions.

How it works

The spec (firmwareRollout.spec.ts) drives the app as an admin. Each test uploads Rig firmware files with a per-run version (3.x.<runId>) so the fake rigs, which keep their firmware between runs, are always mismatched and an assignment always starts a rollout; afterEach deletes the run's channels and files in a fresh browser context so a failing test does not leave state behind. Five scenarios:

1. Create, enforce, exclusivity — create a channel over Rig miners, assign firmware, watch the header pill appear and follow it to the tab, wait for the miners to report the new version; a second channel that tries to claim the same miners is rejected with the first channel's name; moving a miner out of scope leaves it untouched.
2. Roll back — assign v1 then v2; v2's history entry offers "Roll back to v1"; taking it restores v1, and the rollback's own entry then offers a roll forward to v2.
3. Pilot — a pilot-then-continue channel updates one miner, the pill flags attention and the detail shows "Awaiting review"; Continue updates the rest.
4. Batches with auto-continue — a batched channel with auto-continue and zero stabilization completes without a manual review.
5. Cancel remaining — a batched update is cancelled after the first batch; updated miners keep the new version, the rest keep the base, and rolling back restores everyone.

The page object (settingsFirmware.ts) hides the DOM behind intent-level methods: tab switching, channel create/edit/delete, scope selection through the shared miner modal, behaviour controls (method, sizes, auto-continue toggle), firmware assignment, banner and detail interactions (continue, cancel remaining, roll back, view miners), history, and the header pill (validateAppRolloutPill, validateAppRolloutPillNeedsAttention, followAppRolloutPillToChannels). Waits are on server-derived state (device versions, rollout state labels), not fixed sleeps.

Diagrams

flowchart LR
    Spec["firmwareRollout.spec.ts: 5 scenarios, per-run versions, afterEach cleanup"] --> PO["SettingsFirmwarePage page object"]
    PO --> UI["Firmware page: tabs, manage view, banners, detail, history, header pill (#1020-#1022)"]
    UI --> API["RolloutService (#1018)"]
    API --> Engine["enforcement loop (#1017)"]
    Engine --> Rigs["fake proto rigs: accept FirmwareUpdate, report new version"]
    Rigs --> Engine

Loading

Areas of the code involved

Area / file	What changed	Why it matters for review
client/e2eTests/protoFleet/pages/settingsFirmware.ts	Page object extended with release-channel, update-monitoring, history and header-pill methods (labels clicked instead of check() for the hidden switch input; modal default data-testid used; waits for the miners modal's paged fetch; rollback located by its "Roll back to " action, which lives on the entry that replaced the version)	The only reviewable file; check selectors match the testIds in #1020–#1022 and that waits are state-based
client/e2eTests/protoFleet/spec/firmwareRollout.spec.ts (new)	The five scenarios and their cleanup	test — skip

Key technical decisions & trade-offs

• Per-run firmware versions rather than resetting the fake rigs, because the rigs persist firmware between runs and a version they already report would make the assignment a no-op.
• Cleanup in a fresh browser context in afterEach, so a scenario that fails mid-modal still deletes its channels and files.
• Waits on server-derived state (reported version, rollout state label) rather than fixed timeouts, since verification depends on the 15 s enforcement tick and rig response time.
• Skipped against real hardware: the scenarios flash firmware, which is only safe on the fake rig setup.

Contract alignment (after the #1014 merge)

#1014 merged on 2026-09-08 as 74454ed9. This stack was cut against the contract as it stood on 2026-09-04 (4256f05f); the contract then absorbed thirty Codex review rounds before merging. On 2026-09-08 the branch was rebased onto main so it carries only its own commit. Head on GitHub is pre-rebase. The rebased branch does not compile against the merged contract (the pre-push typecheck/lint hooks reject it), so it has not been pushed; until the reconciliation below lands, the diff GitHub shows against the moved base branch is inflated with the pre-merge contract commits.

This PR implements: Playwright coverage of the Release Channels flow end to end.

Contract surface added after the stack was cut, not in this PR:

• Assertions reference model-only groups and file-id rollback; they follow the UI changes above.

These gaps are tracked in the stack status note and are the subject of the reconciliation plan for the next revision of this stack.

Testing & validation

• eslint --max-warnings 0 on both files.
• The spec passed locally (just test-e2e-fleet --grep firmwareRollout, desktop project) on the functionally identical tree of the previous stack (feat(rollout): active firmware updates, history and header pill #1011); this stack only reshuffles server test files and rebases onto current main plus the fix(client): stop MinerSelectionModal re-rendering in a loop #1013 test commit.
• Not yet: E2E re-run on this branch in CI.

[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 (242fc09c5b18f11b8f540bbe0a6e89fe04d822db...9486cabf6a9da1a913fc48287706debfeff23b91, exact PR three-dot diff)
• Model: gpt-5.6-sol

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

---

Review Summary

Overall Risk: HIGH

Findings

[HIGH] Automated review incomplete

• Category: Other
• Description: The automated review produced no usable result for 242fc09c5b18f11b8f540bbe0a6e89fe04d822db...9486cabf6a9da1a913fc48287706debfeff23b91 (workflow run 34180590561; reason: codex-job-timeout, elapsed: unknown, budget: 9 minutes).
• Impact: The pull request has not received complete automated security, correctness, and reliability analysis.
• Recommendation: Require human review before merging. Do not treat this result as approval-free or low risk.

Notes

Human review is required because the bounded automated review was incomplete.

---

_{Generated by Codex Security Review |
Triggered by: @rl-block |
Review workflow run}