release(mcp): decide and publish Darwin archives without overstating host support

[Rul1an]

Measured current state

Reconciled on origin/main 3dd32b8f452f48d7aac736b781a68ccc3417edc4 and published release v5.5.2 / d813af0e52f2846d3e5f47a53c042aa169304dc3.

The absence is currently deliberate and internally consistent:

• scripts/ci/release_asset_contract.sh marks both Darwin assay-mcp-server targets unsupported;
• .github/workflows/release.yml builds MCP-server archives only in build-mcp-server-linux;
• docs/reference/release.md renders both Darwin rows as unsupported;
• docs/data/product-capabilities.v0.json and generated support docs claim only Linux MCP-server archives.

A credential-free Phase-A run for #2684 verified the published macOS arm64 CLI asset, then installed exact assay-mcp-server =5.5.2 --locked from crates.io because no Darwin MCP-server release archive exists. That satisfies #2684's published-package boundary, but it requires a Rust toolchain and minutes of compilation. It does not make the route good general-user DX.

Decision before implementation

Choose and record one posture before changing the matrix:

1. keep Darwin MCP-server archives unsupported and retain the crates.io route; or
2. publish them as manual_step assets with an explicit Gatekeeper disposition.

A GitHub/Sigstore attestation is not Apple code signing or notarization. A quarantined, unnotarized download may be blocked when a GUI host spawns it even though a local cargo-built binary runs. Do not add release rows without deciding either:

• Developer ID signing and notarization, including the new CI credential boundary; or
• an explicit manual-step limitation and documented quarantine handling.

Smallest bounded implementation if option 2 is chosen

1. RED contract: change only the two Darwin MCP rows in release_installability_matrix() from unsupported to manual_step with their exact archive names. Existing release-contract tests must fail because no producer exists.
2. Producer: extend/rename the MCP build job with x86_64-apple-darwin and aarch64-apple-darwin, preserving the Linux packaging/checksum/attestation contract.
3. Generated truth: regenerate the release matrix and product-capability/support surfaces. New claims begin with the next release; never backfill v5.5.2.
4. Host observation: before installer promotion or host-support wording, run a release(host proof): drive Codex discovery and one Assay tool on published v5.5.2 #2684-style macOS host journey against the downloaded archive itself.

Acceptance criteria

• The notarization/manual-step posture is explicitly recorded before producer work.
• Contract RED is demonstrated before the producer makes it green.
• Both Darwin archives and .sha256 sidecars are covered by the same bounded release preflight and attestation policy as Linux MCP archives.
• Generated docs match the shared contract exactly.
• A downloaded-asset macOS host observation is retained and independently reviewed before any host-support claim.
• MCPB-on-Darwin remains a separate decision.

Priority and release disposition

P2 / post-MVP. This does not block the current Codex launch proof: #2684 explicitly admits a published package and the exact crates.io route is provenance-bound. The next implementation belongs in v5.5.3 or a later release because v5.5.2 is immutable.

Non-claims

Publishing an archive does not prove installation, Gatekeeper compatibility, editor discovery, skill discovery, MCP startup, or tool invocation. This issue does not claim user demand, acceptable general-audience cargo-install DX, a need for MCPB on macOS, or anything about Windows.

[Rul1an]

Decision recorded on origin/main 2b1339e309c7027d63970dd5913b28b3bab36409: choose posture 1 / A.

Keep both Darwin assay-mcp-server archives unsupported for the September launch and retain the crates.io route. Do not add unsigned/unnotarized manual_step assets. A browser-downloaded quarantined binary that an editor must spawn headlessly creates worse first-run behavior than the current cargo-built route; GitHub/Sigstore attestation does not change Apple Gatekeeper disposition. If an adoption trigger fires, move directly to a product-wide Developer ID signing/notarization lane for CLI + MCP rather than shipping an unsigned intermediate.

Triggers that reopen this decision:

1. a verified external Mac user or design partner reports the Rust-toolchain requirement as an adoption blocker;
2. a required host integration cannot invoke cargo, including a separately decided MCPB-on-Darwin journey; or
3. the exact cargo route fails on a supported macOS/Xcode combination.

One prerequisite was false in the issue text: the public editor recipe does not yet retain an exact crates.io route. It floats both package installs. Subissue #2743 is the bounded P1 fix and must land before this issue closes.

Under posture A, the option-2 producer/archive/host-observation acceptance rows are N/A, not incomplete work. Close this issue after #2743 lands and the exact published-version recipe is guarded. No release producer, matrix, generated capability, notarization, or immutable v5.5.2 asset changes are authorized by this decision.