fix(ui): keep update release link visible

[pascalandr]

Summary

• Keep a stable release link visible in the home screen version pill whenever update metadata is available.
• Leave the existing one-time update toast behavior unchanged while giving users a permanent place to reopen the release page.
• Reuse the existing release i18n strings instead of adding new UI copy.

Fixes #267

Verification

• npm run typecheck --workspace @codenomad/ui
• npm run build --workspace @codenomad/ui

[pascalandr]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[codenomadbot]

Gatekeeper review for latest PR state complete.

Assumptions: I reviewed the checked-out codenomad/pr-410 branch against dev, and treated the request as a strict code-quality/regression review rather than an implementation request.

Findings:

1. Blocking: the “permanent” release link is only populated from a one-shot metadata fetch, so it can miss updates discovered by the existing refresh loop. In packages/ui/src/components/version-pill.tsx:10-19, VersionPill calls getServerMeta() once and stores the result in component-local state. But the dev update monitor in packages/ui/src/stores/releases.ts:147-160 can later force-refresh metadata every 10 minutes and show the one-time toast when a new update appears. That refreshed meta.update never flows back into VersionPill, so if the app was already open before the dev release became available, the toast may appear but the footer pill still has no stable “View release” link after the toast is dismissed or missed. This directly weakens the stated goal of giving users a permanent place to reopen the release page. Better implementation: expose the current update metadata as a signal from stores/releases and update it in refreshFromMeta(), then have VersionPill consume that shared state instead of doing an independent one-shot fetch.

2. Desktop/Tauri regression risk: the new link bypasses the app’s external URL opener. packages/ui/src/components/version-pill.tsx:46-49 renders a raw <a target="_blank">. On the same folder-selection screen, existing external links prevent default navigation and call openExternalUrl(...) specifically to route through @tauri-apps/plugin-opener when running in Tauri (packages/ui/src/components/folder-selection-view.tsx:571-581). The release link should follow that pattern; otherwise the desktop app can fail to open the browser or navigate the webview unexpectedly, making the newly added permanent link unreliable on the main desktop target.

Validation:

• git diff --check dev...HEAD passed.
• npm run typecheck --workspace @codenomad/ui could not complete in this workspace because dependencies are missing (solid-js, Tauri packages, SDK packages, etc.).
• npm run build --workspace @codenomad/ui could not complete because vite is missing.

Gatekeeper status: not ready as-is. The feature direction is good, but the implementation should be wired into the existing release metadata source and should use the established external-link opener before merge.

--
Yours,
CodeNomadBot

[pascalandr]

@CodeNomadBot

same review again

[codenomadbot]

Gatekeeper review for the latest PR state complete.

Assumptions: I reviewed the current checked-out codenomad/pr-410 branch against dev, including the new f2bf778 fix(ui): sync version pill with release refresh commit. I treated “same review again” as a strict regression/code-quality review only, with no code changes requested.

Findings:

1. Blocking: the new shared update state can still render a stale release link after the server reports that no update is available. packages/ui/src/stores/releases.ts:84-86 correctly sets availableUpdate to meta.update ?? null on each forced refresh, but packages/ui/src/components/version-pill.tsx:22 computes availableUpdate() ?? meta()?.update ?? null. That fallback cannot distinguish “the shared refresh has not loaded yet” from “the shared refresh loaded and there is no update”. If VersionPill initially loaded metadata containing an update, then a later refresh returns meta.update = null after the user updates, the release is yanked, or the channel changes, availableUpdate() becomes null and the component falls back to the old local meta()?.update, keeping a stale “View release” link visible. This violates the stated behavior of showing the link when update metadata is available. Better implementation: make the shared update signal able to represent an uninitialized state separately from a loaded-empty state, e.g. initialize it as undefined and only fall back to local metadata while it is undefined; or remove the component-local update fallback once the release store is the source of truth.

Resolved from the prior review:

• The version pill now observes release refresh state through useAvailableUpdate(), addressing the prior one-shot metadata concern for newly available updates.
• The link now calls openExternalUrl(..., "version-pill"), matching the existing desktop/Tauri external-link pattern.

Validation:

• git diff --check dev...HEAD passed.
• npm run typecheck --workspace @codenomad/ui still cannot complete in this workspace because dependencies are missing (solid-js, Tauri packages, SDK packages, etc.).
• npm run build --workspace @codenomad/ui still cannot complete because vite is missing.

Gatekeeper status: still not ready as-is. The main regression is narrower now, but the current fallback logic can keep outdated update metadata visible indefinitely.

--
Yours,
CodeNomadBot

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/25572525695

Artifacts expire in 7 days.
Artifacts:

• pr-410-c38b0c21987c7874ec66ff971a9abd573de8f5d4-tauri-macos-arm64
• pr-410-c38b0c21987c7874ec66ff971a9abd573de8f5d4-electron-windows
• pr-410-c38b0c21987c7874ec66ff971a9abd573de8f5d4-electron-linux

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/25573160360

Artifacts expire in 7 days.
Artifacts: (none found on this run)

[pascalandr]

@CodeNomadBot

same review again

[codenomadbot]

Gatekeeper review for the latest PR state complete.

Assumptions: I reviewed the current checked-out codenomad/pr-410 branch against dev, including 7bcc8c1 fix(ui): keep version pill update link opt-in and the merge commit d5271ef. I treated “same review again” as a strict regression/code-quality review only, with no code changes requested.

Findings:

No blocking findings in the current diff.

The prior false-positive CTA path is gone: packages/ui/src/components/version-pill.tsx no longer renders support.latestServerUrl; the persistent link is now tied to update() only. The prior stale update fallback remains addressed by using undefined as the shared update signal’s uninitialized state and null as the loaded-empty state.

Residual risks / notes:

• I could not fully validate compilation locally because this workspace is still missing dependencies.
• The latest artifact bot comment says artifacts were not found for its run, which may be a CI/artifact publishing issue outside this source diff.

Validation:

• git diff --check dev...HEAD passed.
• npm run typecheck --workspace @codenomad/ui could not complete locally because dependencies are missing (solid-js, Tauri packages, SDK packages, etc.).
• npm run build --workspace @codenomad/ui could not complete locally because vite is missing.

Gatekeeper status: source review passes. I do not see remaining code-quality or regression blockers in the current PR diff, but merge confidence still depends on CI running with dependencies installed.

--
Yours,
CodeNomadBot

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/25573405726

Artifacts expire in 7 days.
Artifacts: (none found on this run)