feat(ENG-671): user-facing "Check for updates" control

[pnewsam]

Description

Adds a user-facing Check for updates control to Settings → Updates (desktop only), closing the last gap in the update UX: today an update check only happens on boot and the 4-hour periodic poll, surfaced via the sidebar banner — there is no explicit way for a user to check or trigger one.

The button runs an on-demand check and reports the result:

• Checking… while it runs
• You're up to date.
• Update available (with the new version) + an Update now button
• Couldn't check — you appear to be offline / please try again.

Why "Update now" still matters after ENG-858: updates now always auto-apply at boot, but the mid-session periodic (4h) check still never auto-applies — it only shows a banner. So this control is how a user acts on a detected update immediately, instead of waiting for the next launch. "Update now" runs the same server-first + UI apply + reload path as the boot check.

Why the check reports UI and server together: it mirrors exactly what the periodic poll detects (minus the apply). The apply path (UI_UPDATE_APPLY) updates both server and UI, so a UI-only check would have reported "up to date" while a server update was pending. A connectivity probe runs first so an unreachable network becomes an explicit "couldn't check" rather than a misleading "up to date".

Implementation

• update-logic.ts — new pure summarizeUpdateCheck({offline, ui, server}) → display summary (ok / offline / updateAvailable / per-component flags + versions). Fail-closed: a failed check can't surface a spurious update. Covered by 6 new unit tests.
• updater.ts — new checkForUpdates() orchestrator: connectivity probe → parallel checkForUIUpdate + checkForServerUpdate → summarize, applying nothing. Repointed the existing UI_UPDATE_CHECK IPC handler at it (it was UI-only and unused by the renderer — no channel rename, IPC snapshot untouched).
• host.ts / global.d.ts — surface checkForUpdates() through the bridge (host.ts didn't expose it before); web resolves to a benign "up to date".
• SettingsView.jsx — the control, gated behind isElectron, styled to match the existing sidebar update banner.

Fixes ENG-671.

Screenshots

Pending — desktop smoke on a packaged prod/staging build (see below).

Type of change

• ⚡ New feature (non-breaking change which adds functionality)

Checklist:

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have checked my code and corrected any misspellings

Verification

• ✅ npm run typecheck (main + renderer + tests)
• ✅ npm test — 363 passed, incl. 6 new summarizeUpdateCheck cases (offline, up-to-date, server-only, UI-only, both, missing-version)
• ✅ IPC channel snapshot unchanged · ✅ check:cowork-purity · ✅ npm run build:renderer
• ⏳ Not yet done: interactive smoke in a running app. A dev build has OTA off (build kind dev), so the interesting paths only light up in a packaged prod/staging build against the manifest host (or via the COWORK_OTA_MANIFEST_URL QA seam). Left as draft until that smoke + screenshots are attached.

🤖 Generated with Claude Code

[pnewsam]

Code Review

Verdict: COMMENT (would request changes)

Two failure-path issues should be addressed before merge. The combined check can report "You're up to date" when one update channel actually failed, and the apply control can remain permanently busy when the updater resolves false. This is submitted as COMMENT because it is a self-review.

Summary of findings

Severity	File	Issue
Major	src/main/updater.ts:148	Partial check failures are collapsed into a successful up-to-date result
Major	src/renderer/cowork/views/SettingsView.jsx:770	A resolved apply failure leaves the UI stuck on Updating

What's working well

The unified result shape is clear, the pure summary cases are well covered, and the existing test/build/type checks pass. The remaining test gap is orchestration and UI failure behavior, which would directly exercise these two findings.

---

Reviewed by Codex · paul/eng-671-add-a-user-facing-check-for-updates-control → staging · 2026-07-22

[pnewsam]

Addressed both findings in 073799d:

checkForUpdates() partial-failure collapse (updater.ts:148) — checkForUIUpdate()/checkForServerUpdate() now carry an explicit error flag distinct from a completed "no update" result (set on manifest-fetch failure, missing uv, failed remote/version lookups, or a thrown exception — never on a deliberate disabled-via-env state). summarizeUpdateCheck only reports ok:true/"up to date" when both channels completed without error. The manifest-host-unreachable case now mirrors the periodic poll() exactly: it only skips the UI check, never the independent server check.

Stuck "Updating…" on a resolved false (SettingsView.jsx:770) — handleApplyUpdateNow now inspects applyUpdate()'s boolean result via a small pure nextApplyUpdateState() helper instead of only resetting state in catch. A resolved false now returns the control to idle with a "Try again" / retryable error message.

Both fixes are backed by directly-tested pure decision functions (summarizeUpdateCheck +3 new cases, nextApplyUpdateState new colocated test) rather than testing orchestration/JSX directly, per this repo's existing pattern. npm run typecheck, npm test (368 passed, up from 363), npm run test:coverage (update-logic.ts still 100/100), check:cowork-purity, and build:renderer all pass.

[pnewsam]

Follow-up Code Review

Verdict: COMMENT (would request changes)

The prior stuck Updating… issue is resolved with a retryable failure state, and partial failures no longer produce a false You're up to date result. One material issue remains: the new summary discards an independently confirmed update whenever the other channel fails, so the manual check still diverges from the periodic poll and withholds the Update now action during a partial outage.

Summary of findings

Severity	File	Issue
Major	src/main/update-logic.ts:248	A confirmed update is discarded when the other channel is inconclusive

What's working well

The resolved-false apply path now returns to idle, displays a clear retry state, and is directly tested. The updated targeted tests, type checks, purity validation, and CI all pass.

---

Reviewed by Codex · paul/eng-671-add-a-user-facing-check-for-updates-control → staging · 2026-07-22

[pnewsam]

Major: This still suppresses an independently confirmed update whenever the other channel fails.

For example, if the UI manifest is unavailable but the server check successfully finds an update, this branch returns updateAvailable: false; Settings renders only Couldn't check and provides no Update now action. The periodic poll continues with and surfaces/applies that same confirmed server update, so the manual check still does not mirror it. This also makes an unavailable manifest relevant in builds where UI OTA is disabled.

Please let a confirmed positive result win. The error outcome should apply when no channel found an update and at least one channel was inconclusive, or the result shape should represent both updateAvailable and a partial-check warning.

[pnewsam]

Addressed in c9df8ba:

A channel's own error no longer invalidates a different channel's confirmed positive result — updateAvailable now surfaces whichever channel(s) actually completed and found something, even if the other channel is inconclusive. "Couldn't check" (ok:false) only applies when neither channel found an update and at least one was inconclusive; offline now requires both channels to have failed.

Also removed the hasInternet() pre-gate from checkForUpdates() entirely — checkForUIUpdate() already returns instantly with no network call when OTA is disabled for the build, so gating on manifest reachability was exactly what made an unrelated manifest-host outage relevant in builds where the UI channel isn't even applicable. Both channels now run fully independently, no gating at all.

update-logic.ts stays at 100% coverage — 3 new cases (both-channels-failed → offline, confirmed-update-wins on each side) plus the existing failure-path tests updated to the corrected expectation. Typecheck, full suite (371 passed), purity check, and renderer build all pass.

[pnewsam]

Follow-up Code Review

Verdict: COMMENT (would request changes)

The cross-channel partial-success case is fixed, but the same confirmed-positive rule is not yet applied within an aggregated channel result. checkForServerUpdate() can return both updateAvailable: true and error: true when one Git remote confirms a change while the sibling remote lookup fails; the summary currently discards that confirmed update.

Summary of findings

Severity	File	Issue
Major	src/main/update-logic.ts:260	A positive result carrying a partial-error flag is still suppressed

What's working well

The manifest pre-gate has been removed, cross-channel confirmed updates now win, the retryable apply failure is resolved, and current CI passes.

---

Reviewed by Codex · paul/eng-671-add-a-user-facing-check-for-updates-control → staging · 2026-07-22

[pnewsam]

Superseded by #453. All of this PR's commits have been folded into #453, and the manual "Check for updates" control is now integrated with the shell reinstall notice there (the check reports UI + server and shell, so it can't say "up to date" while a newer app version is available). Closing this and deleting the branch; ENG-671 will be closed by #453.