test(e2e): cover release channels end to end

[rl-block]

Summary

Adds five browser scenarios that exercise release-channel firmware updates through the complete stack against fake Proto rigs. The tests cover assignment and scope conflicts, rollback, pilot review, automatic batches, and canceling remaining work, including the global header indicator and its deep link.

Reviewable diff: +498/-1 across 1 file (excludes generated, test, and story files).

The counted file is the shared page object; the scenario spec is excluded by the repository's counting rules.

Stack and scope. Diff is relative to #1022. The tests use the channel/progress/header UI from #1020–#1022, API/runtime wiring from #1018, and the upstream engine, storage and artifact dispatch. The merged contract is #1014. Full chain:

#1014 contract → #1015 storage/dispatch → #1016 channel operations → #1017 engine → #1018 API/runtime → #1019 client data → #1020 channel UI → #1021 active updates → #1022 header/activity → #1023 E2E.

This is the top test slice. Real hardware, delegated control and the deferred rollout events feed are outside its coverage.

How it works

1. Exercise operator workflows

Scenario	What the assertions establish
Assignment and exclusivity	Assigned miners update, header navigation opens the channel view, overlapping scope is rejected, and removing a miner frees it for another channel
Rollback	Apply v1 then v2, restore v1 through history, and expose the reverse lineage action
Pilot review	Exactly one miner updates before review, attention/evidence appears, pause/resume works, and Continue releases the rest
Automatic batches	Two batches complete without manual Continue, with a configured health threshold and zero stabilization delay
Cancel remaining	The pilot keeps the new version while remaining work stops, and rollback restores the base version

2. Observe completion through the UI

SettingsFirmwarePage centralizes channel forms, miner selection, behavior controls, assignment, progress details, history and header interactions. Completion waits for miners to report the target version, the updating indicator to clear, and a completed history entry. This accommodates the engine's enforcement interval and persisted verification.

3. Keep runs repeatable

Each run uses unique channel names, firmware versions and payload bytes, so firmware retained by fake rigs cannot turn the next assignment into a no-op. Setup clears uploaded firmware. Cleanup opens a fresh browser context, removes the run's channels and clears firmware uploads even if the original page is left inside a modal. The suite requires a disposable fake-rig environment and skips E2E_TARGET=real.

Diagrams

flowchart LR
    A["Playwright scenarios"] --> B["SettingsFirmwarePage"]
    B --> C["Channel UI and header"]
    C --> D["Rollout API and engine"]
    D --> E["Verified firmware dispatch"]
    E --> F["Fake rigs update and report"]
    F --> D
    D --> G["Progress and history"]
    G --> B

Loading

Areas of the code involved

Area / package / file	What changed	Why it matters for review
client/e2eTests/protoFleet/spec/firmwareRollout.spec.ts	Five scenarios, artifact setup and cleanup	Start with outcomes and environment isolation
client/e2eTests/protoFleet/pages/settingsFirmware.ts	Shared UI operations and state-based waits	Check selectors and what each assertion actually proves

Key technical decisions & trade-offs

• Unique versions and bytes avoid resetting persistent fake rigs between scenarios.
• UI state-based waits tolerate enforcement timing without fixed sleeps.
• A shared page object keeps selectors centralized and scenarios readable.
• Cleanup clears all firmware uploads, so the fixture is intended for an isolated environment.

Testing & validation

The previously recorded Playwright --list check verified scenario discovery only. Browser execution on the current stack has not been verified, and no tests were rerun for this description-only update. Upstream server/unit checks do not establish an E2E pass.

Run this spec with just _e2e protoFleet --project=desktop spec/firmwareRollout.spec.ts; just test-e2e-fleet runs the full desktop suite. Coverage is limited to the five fake-rig workflows above, rather than every server failure or concurrency race.

[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 (a4b02980d5487da83611a54c55a692f0a360e754...7a93daf8436df322fec5aed12f346f7226013b8b, 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 a4b02980d5487da83611a54c55a692f0a360e754...7a93daf8436df322fec5aed12f346f7226013b8b (workflow run 34631335771; 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}