macOS work for the Xianyun (閑雲) rewrite

This rewrite was developed on Linux. Most of it is platform-independent and verified there. A small, well-scoped slice is macOS-only. This document lists exactly what that slice is and how the macOS build/test environment is set up.

Status: a macOS build host is now available

An AWS EC2 mac2 (Apple silicon, aarch64-darwin, macOS 27) instance is set up as a build/test host. scripts/bootstrap-nix-macos.sh installs Nix on it and configures the environment; nix develop -c cargo test --workspace runs the full suite there.

Verified on macOS as of this writing: the entire workspace builds on aarch64-darwin — including truststore::system_darwin, which is #[cfg(target_os = "macos")]-gated and never compiled on Linux — and the full suite was green with 0 failed and 23 ignored (the remaining ignores are live docker/k8s integration tests, not platform gaps). The passing total was reported as 1,076 here and 1,090 in crates/README.md; neither was re-measured, so see the README for the current figures. The 10 macOS Keychain tests are implemented and passing; see below.

Headless-macOS Nix gotcha (captured in the bootstrap script)

On this macOS 27 host the stock multi-user org.nixos.nix-daemon LaunchDaemon can’t start: launchd sandboxes it so it can’t read the synthetic /nix firmlink volume (dyld: ... file system sandbox blocked open() → big-lock: Permission denied). There’s no GUI to grant Full Disk Access and SIP is on, so the sandbox/TCC can’t be edited. Direct (daemonless) builds work fine, so scripts/bootstrap-nix-macos.sh switches the box to daemonless single-user operation (store owned by ec2-user, NIX_REMOTE= exported in the login profile, plus a small RunAtLoad LaunchDaemon that mounts /nix at boot). This is only safe because the instance is single-user; do not do it on a shared Mac.

What was deferred

This rewrite was developed primarily on Linux. The macOS-only slice below was read against its Go original first and implemented once the macOS host above became available.

xianyun-pki’s macOS Keychain integration (10 tests) — DONE

crates/xianyun-pki/src/truststore/system_darwin.rs ports Go’s internal/truststore/system_darwin.go — installing/removing the dev CA from the macOS system Keychain via security add-trusted-cert / remove-trusted-cert / find-certificate / delete-certificate. The 10 tests are gated #[cfg(target_os = "macos")] (matching the Go original’s //go:build darwin tag) and don’t compile on Linux.

These are now implemented and verified on the macOS host described above. cargo test -p xianyun-pki on macOS runs 43 tests (the 33 shared plus these 10), all passing. The implementation drives the mocked CommandRunner, so it does not touch the real Keychain or prompt during the test run. removeSupersededSystem and sameKeyCert — the two pieces left stubbed in Phase 3 — are ported (supersede.rs, system_darwin.rs, ca::reissue_same_key); see crates/xianyun-pki/PORT_NOTES.md’s “macOS tests” section for the detail and the one deterministic-temp-path adaptation.

Live-cluster integration tests that assume a Darwin-flavored colima (subset)

A handful of #[ignore = "integration: ..."] tests across crates/xianyun-cluster/ and crates/xianyun-cli/ exercise the colima driver against a real colima binary and a real Docker/Lima VM. These aren’t macOS-exclusive in principle — colima also runs on Linux via QEMU — but Caproni’s own Go test suite and this port both treat colima as the macOS development path, with k3d as the Linux-native equivalent. The driver logic itself is already fully ported and unit-tested against mocks (crates/xianyun-cluster’s colima module: 32/32 passing on Linux), so this is a live-integration verification gap, not an implementation gap.

On the macOS host above, run the full suite with --include-ignored and colima/docker actually working, and spot-check that the colima-specific integration tests pass against a real VM. The repository has no record of that run.

What’s NOT deferred (already fully covered on Linux)

Everything else in the workspace — including the colima driver implementation (as opposed to a live colima integration run), k3d, vcluster, external, and mock drivers, every backend, every deployer, the executor/async layer, and the CLI wiring — is implemented and tested on Linux already. macOS access unblocks exactly the two items above, not a general “finish the rewrite on macOS” task.

flake.nix readiness

flake.nix’s devShells.default already adds colima conditionally via lib.optionals stdenv.hostPlatform.isDarwin, so nix develop on macOS picks it up automatically with no changes needed — the Linux shell simply omits it since it isn’t meaningfully usable there in this project’s context (Caproni expects it on Darwin, QEMU-backed Linux colima is a different support story the Go original doesn’t document either).