XS✔ ◾ Move version/build display to Settings → Releases

[ssw-armada]

Summary

The app version and build (commit hash) were shown at the bottom-left of the main sidebar, under the account details — this was UI clutter on the primary screen. This PR removes that display from the sidebar and surfaces the same information in Settings → Releases, next to the existing "Current Version" card.

Closes #1016

What changed

File	Change
src/ui/src/components/layout/sidebar.tsx	Removed the version/build fetch (useEffect + state) and the v{version} ({commitHash}) display block from the bottom of the sidebar.
src/ui/src/components/settings/release-channels/ReleaseChannelSetting.tsx	Added commitHash state, populated from the same ipcClient.releaseChannel.getCurrentVersion() call already used for the version, and rendered as a Build {commitHash} line under the existing "Current Version" card.
src/ui/src/components/settings/release-channels/ReleaseChannelSetting.test.tsx	Added tests covering the build line showing when a commit hash is present, and staying hidden when it isn't.

Decisions

• Decision: Reuse the existing getCurrentVersion() IPC call (already returns { version, commitHash }) rather than adding a new IPC channel.
  • Why: The sidebar was already calling this exact API; the Releases panel (ReleaseChannelSetting.tsx) already calls it too (just previously discarding commitHash). No new backend surface is needed — this is purely a UI relocation.
  • Alternatives considered: A separate "About" section in Settings — rejected as unnecessary; the Releases page is the more natural home per the issue's suggested solution, and it already has a version card to extend.
• Decision: Show the build line only when commitHash is truthy (same conditional-render pattern the sidebar used).
  • Why: commitHash comes from the COMMIT_HASH env var, which is only set by the release CI workflows (release-electron-app.yml, pr-release.yml) via git rev-parse HEAD. In local/Debug (npm run start) builds it's unset (null), so hiding the line avoids showing "Build " with nothing after it.

Acceptance criteria

• The main page no longer shows the app version number and build — removed from sidebar.tsx.
• The app version number and build are shown in Settings → Releases — added to ReleaseChannelSetting.tsx, which already renders under the "Releases" settings panel (ReleaseChannelSettingsPanel.tsx).

Testing

• Unit tests added/updated
• Build passes
• Tests pass
• Lint / format clean

Ran the project's own gates from a clean npm ci in an isolated worktree:

• npm run build — passes (tsc, no errors).
• npm rebuild better-sqlite3 --build-from-source && npx vitest run --exclude 'src/ui/**' — 83 files / 929 tests passed.
• npm --prefix src/ui test — 45 files / 319 tests passed (includes the 2 new tests for the build line).
• npm run lint — clean (exit 0). One pre-existing info-level finding in Cloud360LiveView.tsx (unrelated file, present on main before this change) does not fail the --error-on-warnings gate.
• npm run format — no additional changes beyond what was already staged.

Debug vs Release build verification (per the issue's task): commitHash is sourced from config.commitHash() → env.COMMIT_HASH, which is only populated by the release workflows (git rev-parse HEAD written to .env before packaging in both release-electron-app.yml and pr-release.yml). In a Debug/dev run (npm run start, no CI) this env var is absent, so commitHash is null/empty and the "Build" line correctly does not render — only "Current Version" (from app.getVersion(), i.e. the package.json version) shows. In a Release/CI-packaged build, COMMIT_HASH is set, so the "Build <sha>" line renders. Both states are covered by the two new tests (commitHash: "abc123" and commitHash: "").

Follow-up items

None — this is a scoped UI relocation with no behavioural changes beyond where the info is displayed.

---

🤖 Generated with Claude Code

[github-actions]

PR Metrics

✔ Thanks for keeping your pull request small.
✔ Thanks for adding tests.

	Lines
Product Code	7
Test Code	16
Subtotal	23
Ignored Code	-
Total	23

Metrics computed by PR Metrics. Add it to your Azure DevOps and GitHub PRs!

[github-actions]

🚀 Pre-release build is available for this PR:
https://github.com/SSWConsulting/SSW.YakShaver.Desktop/releases/tag/0.6.0-beta.1018.1786946905

[ssw-armada]

🔭 crows-nest: ready-PR pipeline started — review → address → re-validate → gated merge.

[ssw-armada]

🔍 Muster review — PR #1018

Bottom line: no blocking findings — review advisory only (degraded, single-lens).

Review status

• Lens A — code-review (conventions + correctness): ran. 0 findings.
• Lens B — codex-rescue (independent second opinion): not run — the codex:codex-rescue agent type is unavailable in this environment. This review is therefore degraded (single-lens), not a full two-lens verdict.

Findings summary

Severity	Count
blocking	0
major	0
minor	0
nit	0

What was checked

The diff (sidebar.tsx, ReleaseChannelSetting.tsx, ReleaseChannelSetting.test.tsx) was reviewed for: dangling references/unused imports after removing the sidebar's version fetch, whether the Settings→Releases panel introduces a duplicate IPC call (it doesn't — reuses the existing loadCurrentVersion() handler), consistency with the existing conditional-render idiom in that panel, repo-wide search for other commitHash/getCurrentVersion/appVersion consumers that might need updating (none found — the only other consumer is a native Electron "About" panel unrelated to this UI), scope vs. issue #1016's acceptance criteria (both satisfied), and test quality (mocks/assertions follow existing file conventions).

No issues identified by the lens that ran. Note: because only one lens executed, treat this as advisory rather than a full inspection — no independent second opinion was obtained.

[ssw-armada]

✅ reviewed, addressed, green — awaiting human merge (auto-merge off). Muster review (degraded: codex-rescue lens unavailable) found 0 findings; local build/test/lint and all CI checks are green; PR is mergeable.

[ssw-armada]

🔭 crows-nest: ready-PR pipeline started — review → address → re-validate → gated merge.

[ssw-armada]

[nit] commitHash left stale if loadCurrentVersion fails after a prior success

loadCurrentVersion() only calls setCommitHash(info.commitHash ?? "") on success; on error only a toast fires and neither currentVersion nor commitHash are cleared. If the panel is reopened (isActive toggles) and the IPC call transiently fails after a previous successful load, the 'Build ' line (and the version) keeps showing stale data with no visual indication of the failure. This matches the pre-existing convention for currentVersion in this same function, so it is not a regression introduced by this PR — flagging for awareness only.

flagged by: code-review

[ssw-armada]

Declined: this mirrors the pre-existing pattern already used for currentVersion in the same function (no clearing on error) — this PR reuses that exact convention rather than introducing new stale-state behavior. Fixing it would mean changing error-handling semantics for currentVersion too, which is out of scope for #1016's UI relocation. Tracked as a follow-up if desired, not addressed here.

[ssw-armada]

🔭 crows-nest / muster review — PR #1018

Lenses: code-review + codex-rescue (both ran independently)

Findings: 0 blocking, 0 major, 0 minor, 1 nit

• [nit] ReleaseChannelSetting.tsx:112 — commitHash left stale if loadCurrentVersion fails after a prior success (pre-existing pattern, not a regression from this PR)

Bottom line: no blocking findings — review advisory only, PR is clean and correctly scoped to #1016.

[ssw-armada]

🔭 crows-nest / shipwright — address-review pass on PR #1018

Triage: 1 comment reviewed, 0 agreed, 0 discussed, 1 declined.

• Declined — ReleaseChannelSetting.tsx:112 stale-commitHash nit: mirrors the pre-existing currentVersion error-handling convention in the same function; fixing it is out of scope for ✨ Move version/build display to Settings → Releases #1016's UI relocation.

No code changes made. No blocking disagreement — head sha unchanged.

[ssw-armada]

🔭 crows-nest: pipeline complete — blocked.

Reason: branch protections / required reviews not satisfied (reviewDecision: REVIEW_REQUIRED, no approving review yet). Everything else is clean: 0 blocking findings, CI green, mergeable, not draft.

This isn't a fleet failure — the PR is ready; it just needs a human's approving review before it can merge (auto-merge is off anyway). Please review and approve when convenient.

[github-actions]

✅ Automated Release Created Successfully

Release Details:

• Version: 2026.8.17-BUILD.298.9ad2693
• Tag: 2026.8.17-BUILD.298.9ad2693
• Release: https://github.com/SSWConsulting/SSW.YakShaver.Desktop/releases/tag/2026.8.17-BUILD.298.9ad2693

You can monitor the build progress in the Actions tab.