XS✔ ◾ Include version number in release installer filename

[ssw-armada]

Summary

• The Windows installer's stable download link was always uploaded as the generic YakShaver-latest-Setup.exe, so when multiple installers are downloaded over time there's no way to tell which version is which just from the filename.
• Changed the "Create fixed-name artifacts for stable download links" step in the release workflow to name the file YakShaver-ai-Setup-v<version>.exe instead, embedding the release version directly in the filename, per the acceptance criteria in the issue.

Closes #1017

What changed

• .github/workflows/release-electron-app.yml: the Windows release job now names the copied installer YakShaver-ai-Setup-v$VERSION.exe (where $VERSION is the same release version/tag already used elsewhere in that job to bump package.json and to select the GitHub release to upload to), instead of the old generic YakShaver-latest-Setup.exe.
• No other files reference the old fixed filename (verified via repo-wide search) — the app's own update-check code builds download URLs from the GitHub Releases API using the release tag, not this fixed-name asset, so this is a workflow-only, non-breaking rename of a convenience download link.
• macOS YakShaver-latest-{arm64,x64}.dmg fixed-name artifacts were intentionally left as-is — the issue's acceptance criterion is specific to the Windows ...Setup.exe filename format (YakShaver-ai-Setup-v<version number>.exe).

Acceptance criteria mapping

• Release format is YakShaver-ai-Setup-v<version number>.exe → implemented in the "Create fixed-name artifacts for stable download links" step of release-electron-app.yml.

Testing performed

This is a CI workflow (YAML) change with no source code impact; ran the full project validation suite to confirm nothing else was affected:

• npm run build — passed (tsc clean)
• Backend tests: npm rebuild better-sqlite3 --build-from-source && npx vitest run --exclude 'src/ui/**' — 83 files / 929 tests passed
• UI tests: npm --prefix src/ui test — 45 files / 317 tests passed
• npm run lint — clean (biome, 0 errors)

The workflow step itself can't be exercised locally (it only runs in the release: published GitHub Actions context), so it was reviewed carefully against the existing, working pattern in the same job (the $VERSION variable is already used the same way a few lines below, in the gh release upload "$VERSION" ... call), and the string-interpolation syntax was double-checked for correctness.

[github-actions]

PR Metrics

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

	Lines
Product Code	-
Test Code	-
Subtotal	-
Ignored Code	2
Total	2

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.1019.1786950664

[ssw-armada]

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

[ssw-armada]

🔭 muster review — PR #1019

Verdict: no blocking findings — review advisory only.

⚠️ Degraded review — single lens only. The codex-rescue second-opinion lens is unavailable in this environment (agent type not found), so this review reflects only the code-review (conventions + correctness) lens. Treat as advisory, not a full two-lens clearance.

code-review lens: 0 findings. The one-line change to .github/workflows/release-electron-app.yml renames the fixed-name Windows installer artifact from YakShaver-latest-Setup.exe to YakShaver-ai-Setup-v$VERSION.exe. Verified:

• $VERSION is defined earlier in the same job and already used unmodified in npm version $VERSION and gh release upload "$VERSION" ... a few lines below — this usage is consistent with existing convention, not a new pattern.
• PowerShell string interpolation ("YakShaver-ai-Setup-v$VERSION.exe") is syntactically correct.
• Change stays within the issue's acceptance criteria (Windows-only rename; macOS .dmg fixed-name artifacts intentionally untouched per the PR description, matching ✨ Release Pipeline - Simplify versionnumber #1017's scope).
• No other files in the repo reference the old fixed filename (workflow-only change).

Summary: 0 blocking, 0 major, 0 minor, 0 nit.

— posted by ARMADA muster (single-lens, degraded: codex-rescue unavailable)

[ssw-armada]

🔭 crows-nest: blocked — review degraded (codex-rescue lens unavailable in this environment) — a missing review is not a green light per the merge gate. Zero findings from the code-review lens (single lens); CI is green and the PR is mergeable, so once a second-lens review can run cleanly (or a human overrides), this should clear quickly. Needs a human look.

[tomek-i]

On our product page we are linking to the file YakShaver-latest-Setup.exe which this PR will modify. Is it possible to create an alias or automatically link to the latest file at all times so that we do not have to update the link on our product page?

[github-actions]

Hi there!

This PR has been here a while.

Did you know you should avoid merge debt?

Please review and merge or close.

Thanks!

[ssw-armada]

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

[ssw-armada]

🔭 muster review — PR #1019

Verdict: 1 blocking finding — do not merge as-is.

⚠️ Degraded review — single lens only. The codex-rescue second-opinion lens is unavailable in this environment (no codex agent/plugin installed) — only the code-review conventions+correctness lens ran. Per the merge gate, a degraded review is never treated as a green light, regardless of what the running lens found.

Findings (code-review lens)

🔴 Blocking — publish-release still checks for the old fixed Windows filename (.github/workflows/release-electron-app.yml:696)
This PR's branch (1017-release-filename-version) was cut before PR #1043 landed on main. #1043 added a publish-release job whose asset-existence check does:

for ASSET in YakShaver-latest-Setup.exe YakShaver-latest-arm64.dmg YakShaver-latest-x64.dmg latest.yml latest-mac.yml

This PR changes build-windows to upload YakShaver-ai-Setup-v$VERSION.exe instead of YakShaver-latest-Setup.exe, so that literal will never be found among the release assets — publish-release will never un-draft the release, and every release after this merges would get stuck as a draft.

🟠 Major — AGENTS.md still documents the retired fixed Windows filename (AGENTS.md:635)
The "Updating Release Workflows" section documents the five fixed-name assets publish-release asserts, including YakShaver-latest-Setup.exe. This should be updated alongside the workflow change.

Summary

blocking	major	minor	nit
1	1	0	0

Dispatching shipwright in address-review mode to fix the blocking finding before re-validating.

[ssw-armada]

🔭 crows-nest: address-review — investigated the blocking finding before implementing, and found the fix is not as simple as updating the asset-name check.

What I confirmed:

• The PR branch (1017-release-filename-version) is a fleet-owned branch (all commits by armada-lookout), badly stale relative to main (predates the pnpm migration and PR XS✔ ◾ 🐛 Publish the release only after every artifact is uploaded #1043's publish-release job). A merge into a scratch worktree confirmed the PR's actual diff against current main is still just the original 2-line build-windows change — syncing the branch itself is mechanical and safe, that part is not the blocker.
• Confirmed on main: publish-release (added by XS✔ ◾ 🐛 Publish the release only after every artifact is uploaded #1043) checks for the literal YakShaver-latest-Setup.exe (.github/workflows/release-electron-app.yml:696), which build-windows would stop producing under this PR — so every release would get stuck as a draft, exactly as flagged above.

Why I'm not just patching the ASSET check — a deeper conflict:
AGENTS.md (§ "Updating Release Workflows") and the workflow's own comments are explicit that this is a fixed, version-independent filename by design: https://www.yakshaver.ai/install's download button hardcodes /releases/latest/download/YakShaver-latest-Setup.exe, and GitHub resolves .../releases/latest/... to whatever the newest release's asset with that exact name is. That's the whole point of a "fixed-name artifact for stable download links" — the URL never changes even though the file behind it does, release to release.

Issue #1017 asks to embed the version into that same filename (YakShaver-ai-Setup-v<version>.exe). If we do that, the literal name YakShaver-latest-Setup.exe is never produced again, so:

1. publish-release's asset check needs updating (the finding above) — but more importantly,
2. the public install page's download button would 404 on every future release, because the stable, version-independent name it depends on no longer exists — unless the install page (a separate site/repo I don't have visibility into here) is also changed to resolve the current version dynamically, e.g. via the GitHub Releases API.

I don't have access to the yakshaver.ai site's repo to confirm how its download button resolves the asset name, so I can't verify whether this actually 404s in practice or whether the site already avoids hardcoding it. Given AGENTS.md's explicit warning ("do not shorten that list without checking what https://www.yakshaver.ai/install links to"), I'm treating this as a real risk rather than guessing a fix.

Recommendation for a human: pick one before merging —

• (a) Upload both — keep the fixed YakShaver-latest-Setup.exe for the stable link and additionally upload a versioned copy (YakShaver-ai-Setup-v<version>.exe) for people who want to see the version in the filename — satisfies ✨ Release Pipeline - Simplify versionnumber #1017 without breaking the install page, and publish-release's check needs no change; or
• (b) Confirm the install page already resolves the asset dynamically (not hardcoded) and only then rename outright, updating publish-release's ASSET check (release-electron-app.yml:696) and AGENTS.md:635 to match.

I haven't pushed any change — this needs a product/design call, not a mechanical fix, so I'm leaving this blocked for a human rather than guessing. (Separately: the codex-rescue second-opinion lens remains unavailable in this environment, so this review is single-lens/degraded regardless — noted above.)

[ssw-armada]

🔭 crows-nest: blocked — 1 unresolved blocking finding (publish-release asset-check drift, needs a product decision on the stable-download-link tradeoff — see comment above) + review degraded (codex-rescue lens unavailable in this environment) + branch protections not satisfied (review required, no approving review yet). Needs a human. Not retried automatically until the blocking finding is resolved or armada:blocked is removed.