[nmehlei]

Why

install.sh maps an Intel Mac to macos-x64, but no release has ever published that
artifact, so installs fail with a 404. The matrix row was already written and commented out.

What

• release.yml: enable the macos-x64 row on the existing macos-14 runner with
  bun-darwin-x64-baseline, cross-compiled. No Intel runner, no second nixpkgs input,
  flake.nix / flake.lock untouched.
• The sealing step cannot run an x86_64 binary on that arm64 runner (under Rosetta, Bun dies
  with SIGILL: no AVX). For this row it checks check-payload-links, then requires
  lipo -archs to be exactly x86_64, and does not run collie version / docs crew.
• Tests: the release matrix test now expects four rows.
• docs: install.md (the table and the macOS paragraph) and five-minute-install.md no
  longer say Intel builds from source.

Verified

• Full Release workflow on a fork, tag v1.19.2-x64.cross2: all five payloads and release green
  https://github.com/nmehlei/collie/releases/tag/v1.19.2-x64.cross2
• On an Intel Mac (i7-9750H): sha256 matches, thin x86_64 Mach-O with an ad-hoc signature,
  collie version and docs crew run, links only system libraries.
• CI on these commits, run on the fork: typecheck + tests, crew drill, windows and browser
  pass (one WebKit timing test passed on re-run). llm labels fails there only because
  OPENROUTER_API_KEY is not set on the fork.

Caveats

• Not touched: packaging/nix/collie.nix / sources.json (still three platforms) and
  refresh-packages, which was skipped on the fork. A fourth manifest platform is untested there.
• Fork PR, so no version bump, per CONTRIBUTING.

CHANGELOG entry (### Packaging): Intel Macs get a prebuilt binary. Releases now publish macos-x64, so install.sh and collie update work on Intel.

[AltanS]

Thanks @nmehlei, I am not taking this as it stands yet, and I would like to try one other route first. The fork run proves the build and the other three payloads do not change, but the Intel row depends on the Nix installer's fallback for Intel, which Determinate Systems calls temporary, and the payload matrix is fail-fast, so a broken Intel row would stop every release. Could you try to cross-compile the x64 binary on the existing macos-14 row instead, with the same flake and your pinned bun-darwin-x64-baseline archive, so there is no second nixpkgs input and no Intel runner? If that works, I would take it in that shape. If it does not, I would take this PR with the Intel row in its own job that cannot cancel the others, a pinned installer version, the packaging half (collie.nix, sources.json and refresh-packages.ts, as abd1d1b had it), the two docs pages that still say Intel builds from source, and a note of the end-of-2026 limit. Either way your commits and authorship stay, with credit in the changelog.

[nmehlei]

Thanks @AltanS, that worked. I've replaced the PR's contents with the cross-compile shape you described.

• macos-x64 is now a row on the existing macos-14 runner with bun-darwin-x64-baseline. There is no Intel runner, no second nixpkgs input, and flake.nix / flake.lock are untouched, so the fail-fast concern goes away.
• One trade-off: that arm64 runner cannot run the x86_64 binary. Under Rosetta, Bun dies with SIGILL (no AVX), baseline target or not. So the sealing step checks this row statically (check-payload-links, then lipo -archs must be exactly x86_64) instead of running collie version / docs crew.
• I checked the real thing on an Intel Mac (i7-9750H): the tarball's sha256 matches, it is a thin x86_64 Mach-O with an ad-hoc signature, and collie version and docs crew both run. It links only system libraries.
• Full Release workflow on my fork, all five payloads and release green: https://github.com/nmehlei/collie/releases/tag/v1.19.2-x64.cross2
• CI on these exact commits, run on my fork: typecheck + tests, crew drill, windows and browser (chromium, webkit) pass. One WebKit test (pane-glide) failed once on timing and passed on re-run. llm labels fails on the fork only because OPENROUTER_API_KEY is not set there.
• Docs: install.md (the table and the macOS paragraph) and five-minute-install.md no longer say Intel builds from source.
• Not touched, since you listed them for the other route: packaging/nix/collie.nix, sources.json and refresh-packages.ts. That job was skipped on my fork, so a fourth manifest platform is untested there.

Since the branch changed, CI and Windows will need your approval to run again.

For the changelog (### Packaging): Intel Macs get a prebuilt binary. Releases now publish macos-x64, so install.sh and collie update work on Intel.

[AltanS]

Thanks @nmehlei, this lands in 1.20.0 with your two commits as they are and your authorship kept. On top I add macos-x64 to the platforms refresh-packages.ts deliberately does not package, because that job refuses an unmapped platform and the Nix pin has no x86_64-darwin, and install.sh now gives a shell running under Rosetta the arm64 build, because the x64 build dies there with an illegal instruction. If you can run bin/collie version from your cross2 tarball on your Intel Mac before the tag, that confirms the one thing no run has checked yet. The changelog credits you under Packaging, and I close this PR once it is on main.

[nmehlei]

Confirmed on a real Intel Mac (i7-9750H, macOS, native x86_64, not Rosetta): from the v1.19.2-x64.cross2 tarball, bin/collie version prints 1.19.2-x64.cross2+a64d6db and bin/collie docs crew prints the embedded page. The sha256 matches the sidecar, lipo -archs is x86_64, and it is ad-hoc signed. Thanks for taking it, and the Rosetta fallback in install.sh makes sense.

[AltanS]

Thanks @nmehlei, this is on main and shipped in 1.20.0 with the macos-x64 payload, your authorship kept and the credit in the changelog. Your run on a real Intel Mac was the one check no workflow could make, and it matches what the release publishes. I am closing the PR now. If a later release breaks the Intel build, please open a new issue with the collie version output.