Windows Release

Windows release

Ships Murage-<version>-setup.exe and its update feed to FerroxLabs/murage-releases.

Scope: Windows only. The macOS build is a separate flow (dmg + notarytool + staple) that must run on a Mac. This skill never touches mac artifacts — but see Every release ships both before you finish.

Preconditions

• Run on Windows. NSIS packaging from macOS needs Wine; don't.
• Node 24+ (package.json engines). Node 23 builds fine but pnpm warns on every step and CI runs 24 — don't debug a runtime oddity on the wrong major.
• pnpm via corepack pnpm. If corepack enable fails with EPERM (no admin), drop a pnpm.cmd shim containing @echo off / corepack pnpm %* somewhere on PATH — package:win chains pnpm build && … and needs bare pnpm to resolve.

1. Version

Bump version in package.json. It must match the tag on the GitHub release you upload to, and it becomes the version electron-updater compares against.

2. Build

pnpm install
pnpm typecheck
pnpm package:win

package:win deliberately omits build:speech — the dictation helper is a signed macOS Swift binary and has no Windows counterpart.

Output in release/:

3. Verify before uploading

Three things silently produce a broken app if wrong. Check all three:

Test-Path release\win-unpacked\resources\server\index.js   # harness server
Test-Path release\win-unpacked\resources\ui\index.html     # built UI
Get-Content release\win-unpacked\resources\app-update.yml  # feed config

• Missing server/index.js → utilityProcess.fork fails → the 🔥 "Couldn't start the bot server" page.
• Missing ui/index.html → server has nothing to serve → black window.
• app-update.yml must point at FerroxLabs/murage-releases and, while the build is unsigned, must not contain publisherName — electron-updater would reject every update as untrusted.

Then smoke-test the installer itself. Run it, and confirm:

1. It installs per-user with no UAC prompt and launches.
2. The chat window renders (not the error page). Server logs land in %APPDATA%\Murage\logs\server.log.
3. The model picker lists at least one provider — this exercises the .cmd-shim resolution in server/procs.ts, which only ever runs for real on Windows.
4. No update popup appears on launch. Background check failures are silent by design; a popup here means that regressed.

4. Publish

Upload to the same tag as the macOS release for that version, so one release carries both platforms.

Copy-Item release/Murage-<version>-setup.exe release/Murage-setup.exe
gh release upload v<version> --repo FerroxLabs/murage-releases `
  release/Murage-<version>-setup.exe `
  release/Murage-setup.exe `
  release/Murage-<version>-setup.exe.blockmap `
  release/latest.yml

Prefer the repository's Release workflow, which builds every platform from one pinned commit, refuses an incomplete asset set, and proves the uploaded bytes match what it staged. This manual path is for emergencies only, and never replaces the bytes of an already-published asset.

Both names are required, for different consumers:

• Murage-<version>-setup.exe is what latest.yml references by name and sha512. The auto-updater downloads exactly this.
• Murage-setup.exe is a byte-identical copy that gives the README's /releases/latest/download/Murage-setup.exe button a stable URL. This mirrors Murage.dmg sitting beside Murage-<version>.dmg.

latest.yml is not optional

Without it every installed Windows app 404s on check and stays on its version forever. It is generated by package:win even under --publish never.

Never hand-edit it or carry one forward from a previous build. It pins the installer's sha512; a mismatch makes the updater download and then reject the update, which looks like "updates silently do nothing".

Every release ships both

A version that exists on macOS but not on this release is a Windows user stuck on old code with no signal that anything is wrong — the updater reports "up to date" because latest.yml still describes the older build.

So: whenever a new version goes out, this flow runs too. If Windows can't ship for some reason, don't publish the mac-only release under a new version tag either — or accept that Windows is knowingly frozen and say so in the release notes.

Because the two builds must run on two machines, the tag is the join point: cut the release, attach mac artifacts from the Mac, attach Windows artifacts from here.

Known: the build is unsigned

No certificate is configured, so SmartScreen shows "unknown publisher" and users click More info → Run anyway. The README documents this. Auto-update still works because it's unsigned (no publisherName to verify against).

If signing is added later, it goes under win.signtoolOptions or win.azureSignOptions in electron-builder.yml — electron-builder 26 nests these; there is no top-level win.certificateFile. Once signed, keep the certificate subject stable forever, or list both old and new in publisherName; changing it strands every already-installed user.