Build universal macOS release artifact

[TurboTheTurtle]

Closes #57.

Builds the macOS release artifact through a shared universal binary packaging script so the Homebrew-consumed zip contains both arm64 and x86_64 slices. The release workflow now validates the packaged archive with lipo/file checks, and the notarization helper reuses the same universal build path.

Real behavior proof:

• Real environment tested: macOS 27.0 (26A5353q), arm64 host, Xcode 26.5, Swift 6.3.2.
• Exact steps or command run after this patch: make macos-artifact; unzip dist/remindctl-macos.zip; run file, lipo -info, and scripts/check-macos-artifact.sh dist/remindctl-macos.zip on the generated archive.
• Evidence after fix: the archive extracted to one top-level remindctl binary; file reported Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]; lipo -info reported Architectures in the fat file ... are: x86_64 arm64.
• Observed result after fix: scripts/check-macos-artifact.sh dist/remindctl-macos.zip passed.
• What was not tested: execution on physical Intel Mac hardware and notarized release upload.

[TurboTheTurtle]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 27, 2026, 5:06 PM ET / 21:06 UTC.

Summary
The PR replaces the macOS release artifact build with shared universal build, package, and verification scripts, updates notarization to reuse that path, and documents make macos-artifact.

Reproducibility: yes. for the source-level release packaging path: current main builds and zips one default-architecture macOS binary, matching the linked Intel Mac artifact failure. I did not rerun the shipped artifact on physical Intel macOS in this review.

Review metrics: 2 noteworthy metrics.

• Release automation surface: 1 workflow modified; 3 executable scripts added; 1 signing helper changed. The changed files sit on the tag release path that publishes the Homebrew-consumed macOS artifact.
• Patch size: 7 files changed, +125/-35. The diff is bounded, but it is broad enough to warrant focused maintainer release-path review.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #57
Summary: This PR is the open implementation candidate for the canonical Intel Mac arm64-only release artifact bug.

Members:

• canonical: remindctl ships arm64-only — "Bad CPU type in executable" on Intel Macs #57 - The PR body uses closing syntax for the issue, and the diff directly changes the macOS release artifact path that produced the reported arm64-only zip.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• A maintainer release dry run would further reduce confidence risk for the tag workflow and notarization path.

Risk before merge

• [P1] The PR changes the tag release packaging path that publishes the Homebrew-consumed archive, while ordinary PR checks do not exercise the full tag release, upload, and tap-dispatch path end to end.
• [P1] The provided proof validates local macOS artifact creation and architecture checks, but not physical Intel Mac execution or a notarized release upload.

Maintainer options:

1. Accept artifact proof and merge after normal gates (recommended)
   Maintainers can accept the PR body's macOS artifact output as sufficient for merge, with the first full tag-release run still validating upload and tap-dispatch behavior.
2. Run a controlled release dry run first
   A maintainer can run the packaging path or a controlled tag-release dry run before merge to reduce the remaining automation uncertainty.

Next step before merge

• [P2] No repair PR is queued because there is no concrete patch defect; maintainers should decide whether the provided artifact proof is enough for release automation merge risk.

Security
Cleared: The diff changes release automation but does not add third-party actions, dependencies, broader workflow permissions, or new secret exposure.

Review details

Best possible solution:

Land this shared universal packaging path, or an equivalent maintainer-approved release-path fix, after maintainer review accepts the artifact proof and release automation risk; then let the linked Intel Mac issue close when the fix merges and ships.

Do we have a high-confidence way to reproduce the issue?

Yes for the source-level release packaging path: current main builds and zips one default-architecture macOS binary, matching the linked Intel Mac artifact failure. I did not rerun the shipped artifact on physical Intel macOS in this review.

Is this the best way to solve the issue?

Yes: the shared universal build, package, and check path is the narrow maintainable fix for the release artifact bug. The remaining question is release automation acceptance, not a different implementation direction.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against 4e8643ff0ed9.

Label changes

Label justifications:

• P2: The PR addresses a bounded release-packaging bug that blocks Intel Mac users from running the distributed CLI.
• merge-risk: 🚨 automation: Merging changes the GitHub release packaging workflow and local release scripts that ordinary PR CI does not run end to end.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body provides after-fix macOS live output for building, unzipping, inspecting, and checking the generated universal zip.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body provides after-fix macOS live output for building, unzipping, inspecting, and checking the generated universal zip.

Evidence reviewed

What I checked:

• Current main release workflow is single-architecture: The tag release workflow on current main runs one swift build -c release --product remindctl, signs .build/release/remindctl, and zips that one binary as dist/remindctl-macos.zip. (.github/workflows/release.yml:53, 4e8643ff0ed9)
• Universal build is only in the local notarization helper on main: Current main already has dual-arch swift build --arch plus lipo logic in scripts/sign-and-notarize.sh, but the publishing workflow does not call that helper. (scripts/sign-and-notarize.sh:32, 4e8643ff0ed9)
• PR commit adds executable shared release scripts: The PR commit adds scripts/build-macos-universal.sh, scripts/check-macos-artifact.sh, and scripts/package-macos-release.sh with executable mode, and the package script calls the universal helper before signing and checking the archive. (scripts/package-macos-release.sh:20, 458c13cd3329)
• Linked issue is the canonical bug report: GitHub reports that this PR has a closing reference to remindctl ships arm64-only — "Bad CPU type in executable" on Intel Macs #57, which describes the Homebrew-installed v0.3.1 artifact failing on Intel Macs with Bad CPU type in executable.
• Latest release still contains the old release path: The release-prep commit that owns the current release workflow is contained in tag v0.3.1, so the shipped release line does not include this PR's universal packaging fix. (.github/workflows/release.yml:53, 04fbfd02e76f)
• Feature history points to the release-prep commit: Blame and log history attribute the current release workflow packaging lines and notarization helper to the v0.3.1 release-preparation work, with later release-doc updates in the same area. (.github/workflows/release.yml:53, 04fbfd02e76f)

Likely related people:

• Peter Steinberger: Current-main blame and file history attribute the release workflow packaging path, release docs, Makefile release targets, and notarization helper to the v0.3.1 release-preparation and release-doc commits. (role: release workflow author and recent area contributor; confidence: high; commits: 04fbfd02e76f, f94c15df25e5; files: .github/workflows/release.yml, scripts/sign-and-notarize.sh, docs/RELEASING.md)
• Vincent Koc: Recent history includes macOS runner-label work in the same release workflow surface, which is adjacent to the release automation changed by this PR. (role: adjacent workflow contributor; confidence: medium; commits: 569b249b1984; files: .github/workflows/release.yml)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[TurboTheTurtle]

@clawsweeper re-review