[TechnicallyComputers]

Why

Only Linux publishes a bare (non-installer) hub archive, so a tool that builds a title app for Windows or macOS (n64lle tools/build_app.sh --platform) has no hub to fetch: hub-manifest.json says "installer only" for those platforms. With these archives, build_app --platform all can fetch the pinned hub for every platform with no flags.

What

• scripts/package_bare_hub.py: archives the flat hub prefix build-local writes (zip for Windows, tar.gz for macOS), never including the runner. It extracts the archive to a clean directory and requires the archived hub to run and report this release's version/commit, Direct mode, the runner lookup, a title-app mode and the Update page, and to refuse --run-core without --rom (exit 2). It writes the same manifest entry as the Linux packager.
• build-local.sh / .ps1: --release-version / -ReleaseVersion, so the hub reports the release.
• release.yml: Windows and macOS jobs package and upload a <platform>-hub artifact; publish expects all four platforms (linux-x86_64, windows-x86_64, macos-arm64, macos-x86_64).
• hub_manifest.py: only linux-arm64 stays unavailable.
• docs/RELEASES.md describes the new assets.

Verification, and what is not

• Run on Linux only: the packager (both formats) against a stand-in prefix with a scripted fake hub, the version-mismatch gate, hub_manifest.py merging the entries, the workflow parsing as YAML.
• Not run: any Windows or macOS build. The new steps rebuild the hub a second time per job (adds CI time). The first release run on each OS is the first real test.
• Open question (macOS): the flat prefix keeps Homebrew dylib install names (the title-app kit's bundle_dylibs.sh copies them into an app), so the archive supports building a native .app on a Mac; it is not confirmed as a runnable portable layout.

🤖 Generated with Claude Code