Support a documented, native Intel macOS source-build path

[ivandrueda]

Before filing

• I searched open and closed issues for duplicates.
• I am using a recent release and this doesn't already exist.
• This is one request, not several bundled together.

Closest existing issue

none found

Is this new, or an improvement?

New capability — Berd can't do this at all today

The problem, in your terms

I use an Intel Mac and want to run Berd without Rosetta. The published macOS artifacts are Apple-silicon-only, so the only possible route is building from source. The public documentation gives the general just setup and just dev flow, but it does not say whether native Intel macOS is supported, identify an Intel-tested toolchain, or provide a way to verify that the app and all bundled sidecars are actually x86_64.

I attempted the current source build on macOS 15.7.7 / x86_64. Before native compilation, just setup picked up pnpm 11.19.0 from PATH even though package.json pins pnpm 10.33.0. pnpm then modified tracked pnpm-workspace.yaml and exited with ERR_PNPM_IGNORED_BUILDS. Routing pnpm through Corepack allowed the workspace and SDK steps to continue, but the managed Goose checkout is large and the validation was stopped during that clone. I therefore cannot tell whether Intel is intentionally supported, happens to work, or fails later in bundling.

What you do today

There is no published Intel artifact I can install. My workaround is a manual source-build investigation: install the repository's pinned Rust toolchain, supply a native just, force the pinned pnpm through Corepack, keep the checkout clean, wait for the managed Goose build, and then inspect every Mach-O binary by hand. I stopped before the build completed because this still would not establish whether the path is supported or merely incidental.

What you'd like to see

Please provide an explicit, reproducible native Intel macOS source-build path, if Intel remains within Berd's intended platform scope. At minimum:

1. State whether Intel macOS source builds are supported and retain the existing macOS 14.0 minimum.
2. Preflight the host architecture and the pinned Rust/pnpm prerequisites before setup mutates the checkout.
3. Document the exact commands for just setup, just dev, and just bundle-macos on x86_64-apple-darwin.
4. Verify the architecture of the Berd executable and bundled goosed, berdctl, and catch sidecars.
5. Add a maintainer-owned Intel validation lane or documented periodic test so support does not silently regress.

If Intel is intentionally unsupported, an explicit statement and an early, clear setup error would still resolve the ambiguity.

Why this belongs in Berd itself

This cannot be implemented by a Berd skill, agent, extension, or automation. Host-target selection, dependency preflights, Tauri bundling, sidecar staging, and architecture/signing verification all live in Berd's build and packaging layer. A user-local extension only runs after a working app exists.

Non-goals

• No Intel or universal release artifact is required by this request; a reliable source-build path is sufficient.
• No Rosetta-based workaround.
• No lowering MACOSX_DEPLOYMENT_TARGET below the current 14.0 default.
• No change to upstream signing, notarization, or release infrastructure.
• No broad refactor of Berd, Goose, or Catch.

Alternatives you considered

• Rosetta: rejected because the goal is a native x86_64 application and native sidecars.
• A maintained fork: possible, but it leaves one user responsible for tracking build-script and sidecar changes indefinitely.
• Manual local patches and architecture inspection: useful for investigation, but not a stable support contract.
• Continue using pnpm 11: it modified the tracked workspace configuration and failed before native compilation; forcing the repository-pinned pnpm is safer.

Mockups, prior art, or other context

Source snapshot tested: b621258f7f5d9c03e5130a1ea18f410caaeb1033 (2026-08-19).

Host/toolchain:

• macOS 15.7.7 (24G720), Intel x86_64
• Command Line Tools 16.4; Apple clang 17.0.0 targeting x86_64-apple-darwin
• Berd-pinned Rust 1.94.1, host x86_64-apple-darwin
• Node v24.1.0 (x86_64)
• repository pin pnpm 10.33.0; initially active pnpm 11.19.0
• just 1.58.0 (x86_64)
• jq 1.7.1

There are encouraging source-level signs but they are not proof of a working bundle: the managed Node code recognizes x86_64-apple-darwin; the Catch staging script maps that triple to an x86_64 slice and ad-hoc signs it; and build_darwin.sh uses the native host while defaulting to MACOSX_DEPLOYMENT_TARGET=14.0.

Observed setup failure with pnpm 11:

[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts:
@modelcontextprotocol/ext-apps@0.3.1, esbuild@0.28.2

Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.
error: recipe `_setup-dev-deps` failed on line 67 with exit code 1

The upstream checkout was returned to a clean state. I did not reach just dev, bundling, binary-architecture verification, signing checks, or launch testing, so this is a request for a supported validation path rather than a claim that the current Intel build definitively fails.