[Kernel-Hunter]

Mudroom now tells people when a new version is out, and updates in one step.

Mac app

Sparkle 2.10.0, pinned exactly in Package.swift and only added on macOS, so Linux and Windows builds don't see it.

• Mudroom > Check for Updates…, plus a Settings window with "Check for updates automatically". Sparkle asks on the second launch, which is its default.
• The feed is docs/appcast.xml, served by GitHub Pages at https://kernel-hunter.github.io/mudroom/appcast.xml. Pages already serves docs/ from main, so the feed lives in the repo and gets reviewed like any other file, and it's served from a CDN with the right content type instead of raw.githubusercontent.com with its rate limits.
• The feed and each zip are signed with Mudroom's EdDSA key (SURequireSignedFeed, SUVerifyUpdateBeforeExtraction). System profiling is off, and so is SUAllowsAutomaticUpdates: nothing installs until the user clicks Install.
• build-app.sh embeds Sparkle.framework without its XPC services (the app isn't sandboxed), strips SwiftPM's build-folder rpath, adds @executable_path/../Frameworks and signs inside out. The bundled CLI updates with the app.
• scripts/appcast.sh X [sha256] downloads the release zip, checks it, signs it with sign_update and adds the item to the feed, then signs the feed. The release notes go inline so the feed signature covers them, with a link to the GitHub release; the minimum macOS comes from the app.
• The cask gets auto_updates true.

CLI

Once a day, on the host only, the CLI asks GitHub for the latest release and prints one line to stderr after the command's output. It only does this when stdout and stderr are terminals, and never during run, start or agent, in JSON output, under CI, or for update itself. It delays a command by a second at most, and a network error never changes a command's result.

Turn it off with MUDROOM_NO_UPDATE_CHECK=1 or mudroom update --auto-check off. The CLI inside the app also follows the app's setting.

mudroom update (with --check and --yes) does what fits how Mudroom was installed:

• Homebrew: brew upgrade --cask mudroom.
• install.sh or the zip: opens the app's updater. install.sh installs the app and links the CLI into it, so there's no separate binary to replace.
• A Windows release zip: downloads the new zip, checks its SHA-256 against the release's .sha256 and GitHub's asset digest (and refuses if neither exists), then swaps the files in, with a rollback if anything fails.
• Scoop and winget: prints the command. Both refuse to replace mudroom.exe while it runs.
• Built from source: says to pull and rebuild.

Docs

README sections on updating, on the exact request the check makes and how to turn it off, a FAQ entry, and the release steps. The site's "no telemetry" line now mentions the update check.

Release steps from now on

1. Bump Sources/mudroom/Version.swift, tag vX, push the tag.
2. scripts/appcast.sh X <sha256 from the workflow log>, commit docs/appcast.xml, push to main.
3. scripts/update-cask.sh X --remote, copy to the tap.
4. scripts/update-windows-manifests.sh X, copy to the bucket and the winget fork.
5. README $v = 'X'.

0.5.0 has no updater, so people on it need to update once by hand.

Testing

• swift build and swift test (325 tests) on macOS. The CLI still builds with Command Line Tools only.
• A real Sparkle update with a test bundle id and a throwaway key, served from python3 -m http.server: on 0.5.99 (build 1000) I clicked Install, and it relaunched as 0.6.0 (build 1001) on disk. The bundled CLI reports 0.6.0 and the signature is valid. A wrong archive signature is refused ("The update is improperly signed"), and so is an edited feed ("The update feed is improperly signed").
• The CLI notice against a local stub endpoint (debug builds only), the opt-outs, and a check that a release build ignores the test URL.