Desktop installers: publish the download path when a release actually carries bundles

[eaitbrahim]

Tracking — blocked on an upstream release, not on us

keel merged three pieces of desktop-install work after v0.11.2, none of which has reached a user:

Upstream	Commit	State on 2026-08-25
Inno Setup Windows installer, gated signing + notarisation (#438)	9c60779	Code on main; unreleased
Per-release update path for packaged installs (#439)	1d1799e	Code on main; unreleased
curl|bash installer (#479)	10882cf	Works today → #86

Verified blockers

• No new tag. git describe on keel main → v0.11.2-7-g9f2a5ac. pyproject.toml still reads 0.11.2 — a release has not even been prepared.
• No desktop artifacts on any release. gh release view v0.11.2 --json assets returns wheels, sdists and config.yaml only. No .dmg, no .zip, no -setup.exe, no SHA256SUMS-*.
• Publishing them is opt-in per release. release.yml's desktop input defaults to build (workflow artifacts, smoke-tested, not attached). Only a manual dispatch of publish-unsigned attaches them.
• Signing is implemented but inert. gh api repos/CodeGateSoftware/keel/environments → {"total_count":0}. The signing environment holding the Apple/Azure secrets does not exist, so both platforms would ship unsigned.

The site is already built for this

InstallPage.astro:44-55 derives macAsset/winAsset by matching release asset names against ["darwin","macos",".dmg",".pkg"] and ["windows","win32","win64",".exe",".msi",".zip"], and hasPlatformBundle gates the unsigned-build note. The note itself is written and translated in all three locales (install.ts, unsigned) and is simply dark today. When a release carries bundles, the download buttons retarget and the note lights up with no code change.

Do when a release actually publishes desktop bundles

1. Confirm the asset names match the existing patterns. Upstream builds keel-<version>-<arch>.dmg, keel-<version>-windows-<arch>.zip, keel-<version>-windows-<arch>-setup.exe — all match, but re-verify rather than assume.
2. Add docs/desktop-install.md to engine-docs.manifest.json (section guides) with en/ar/fr descriptions. Not before — it walks the reader through downloading a .dmg that does not exist yet, and mirroring it now would point visitors at a missing file. The already-mirrored docs/operator-runbook.md gained a cross-reference to it in 1d1799e; until then that link resolves off-site to GitHub, which is the normal behaviour of the link rewriter and is acceptable.
3. Check the unsigned-note copy still matches reality — if signing has been purchased by then, most of that section becomes wrong rather than merely dark.
4. Document the packaged-install update refusal (keel update on a bundle tells you to re-download the installer).

Upstream defect to report separately

docs/desktop-install.md and the release-notes template both promise a singular SHA256SUMS.txt. release.yml actually emits one file per leg: SHA256SUMS-macOS-arm64.txt, SHA256SUMS-macOS-x86_64.txt, SHA256SUMS-Windows-x86_64.txt. Whatever the site says about checksums must describe the per-platform files.

[eaitbrahim]

Correction — a release has carried desktop bundles

The issue body above says "No desktop artifacts on any release". That is wrong, and I verified the correction directly:

$ gh release view v0.11.0 --repo CodeGateSoftware/keel --json assets --jq '.assets[].name'
keel-0.11.0-arm64.dmg
keel-0.11.0-windows-x86_64.zip
keel-0.11.0-x86_64.dmg
SHA256SUMS-macOS-arm64.txt
SHA256SUMS-macOS-x86_64.txt
SHA256SUMS-Windows-x86_64.txt

v0.11.0 shipped both macOS .dmg builds, a Windows .zip, and the three per-leg checksum files. v0.11.1 and v0.11.2 did not — consistent with release.yml's desktop input defaulting to build rather than publish-unsigned, so publishing bundles is an opt-in choice made per release.

What this changes

The site's hasPlatformBundle gate in InstallPage.astro reads the latest release only. v0.11.2 carries no bundles, so the download buttons point at the release page and the unsigned-build note stays dark — the behaviour is correct today, but for a subtler reason than this issue claimed: not "bundles have never shipped", but "the newest release happens not to carry them".

Two consequences worth deciding on:

1. The note is latent, not unwritten. It will light up the moment any future release attaches a bundle — no code change needed, exactly as designed. That part of the original issue holds.
2. A reader on the install page today cannot reach the desktop app that does exist, because it is one release back. Whether that is right is a judgment call: pointing at v0.11.0 bundles while shipping v0.11.2 wheels would mix versions, which is probably worse. Worth an explicit decision rather than leaving it as an accident of the latest-only lookup.

The rest of the issue stands: signing is still inert (gh api .../environments → total_count: 0), and docs/desktop-install.md should still not be mirrored while the newest release lacks the artifacts it walks through.

Also confirmed the SHA256SUMS naming defect noted at the bottom of the issue — the real files are per-leg (SHA256SUMS-macOS-arm64.txt etc.), not the singular SHA256SUMS.txt the docs promise.