native: promote macos-15-intel qualification lane into the release matrix

[qnbs]

CURRENT AUTHORITATIVE STATE — Intel macOS post-release hold — 2026-09-29

V1_29_1_BLOCKER = NO
PRODUCTION_MATRIX_PROMOTION = NO
RESUME_AFTER = #872 v1.29.1 VERIFIED

Existing evidence remains: macos-15-intel provisions successfully, while the current lane fails earlier at the pnpm 11 darwin-x64 bootstrap. No WorldScript/Tauri x86_64 product failure has been established.

Do not widen pnpm/updater/signing/release-matrix scope during the recovery cut.

---

v1.29 execution freeze — 2026-09-29

Intel macOS remains non-blocking and non-production for v1.29.

Current useful evidence:

• macos-15-intel successfully provisions;
• the present failure occurs earlier in shared setup because pnpm 11 has no working darwin-x64 standalone binary under the current upstream Node SEA situation;
• no x86_64 Tauri build/artifact parity has therefore been proven.

Do not change pnpm major, the production release matrix, notices/SBOM target counts, updater latest.json expectations or signing semantics before v1.29 merely to force Intel admission.

Resume this issue after v1.29. #906 may later share packaged functional scenarios, but target promotion and runner/toolchain admission remain owned here.

---

Intel qualification result — main b239379 — 2026-09-29

Run: 36553360612
Main SHA: b2393796b9ddd580f0e41063df731e98e2b2ed18
Runner: macos-15-intel

Result classification:

RUNNER_PROVISIONED = YES
JOB_REACHED_IN_PROGRESS = YES
TAURI_BUILD_REACHED = NO
FAILURE_CLASS = TOOLCHAIN_BOOTSTRAP
V1_29_BLOCKER = NO

The historical failure mode that removed macos-13 was not reproduced: GitHub provisioned the Intel runner normally.

The run failed inside ./.github/actions/setup at pnpm/setup before Node/dependency installation. Exact upstream diagnostic:

pnpm v11 does not provide a working binary for Intel macOS (darwin-x64) due to an upstream Node.js SEA bug.

The action suggests installation through system Node/npm or a newer pnpm line. WorldScript currently pins pnpm 11.22.0, so do not use this evidence to smuggle a pnpm-major migration into v1.29.

If further pre-release Intel evidence is worth collecting during otherwise-idle wait time, any workaround should be tightly qualification-only and preserve the repository's current pnpm/toolchain contract (for example, system-Node/npm bootstrap of the pinned pnpm version) rather than changing the production matrix/shared release semantics. Otherwise defer the bootstrap correction to the post-v1.29 #507 promotion slice.

This run is still useful soak evidence: macos-15-intel runner availability/provisioning succeeded; x86_64 application build/artifact parity remains unproven because the job never reached Tauri.

---

v1.29 non-blocking qualification window — 2026-09-29

The Intel lane is now explicitly admitted for parallel, non-blocking evidence collection during remaining v1.29 CI/review wait time, but it is not admitted for production-matrix promotion before v1.29.

Current production truth remains:

tauri-build.yml production macOS target
= macos-latest
= Apple Silicon / aarch64
= darwin-aarch64

Current Intel qualification truth:

tauri-intel-qualification.yml
= workflow_dispatch only
= macos-15-intel
= x86_64 qualification
= contents: read
= no signing secrets
= no GitHub Release mutation
= no latest.json mutation
= no production release dependency

Pre-v1.29 allowed work — evidence only

While another release-critical PR is waiting on CI/review, use otherwise-idle time to accumulate Intel evidence:

1. dispatch tauri-intel-qualification.yml against the current trusted main;
2. let each run finish before starting another — the workflow uses concurrency.cancel-in-progress: true, so overlapping dispatches on the same ref would cancel the older run rather than create useful soak evidence;
3. repeat on multiple independently anchored main SHAs when practical during the remaining release train rather than repeatedly hammering one unchanged SHA;
4. record for every run:
   • run ID;
   • exact main SHA;
   • queue/provisioning time;
   • whether the job reached in_progress;
   • total duration;
   • build conclusion;
   • produced bundle/artifact names;
   • artifact size;
   • observed target architecture;
5. compare the Intel bundle with the corresponding Apple-Silicon qualification/release-style bundle where evidence is available:
   • .dmg presence;
   • app/bundle directory shape;
   • expected executable/app resources;
   • architecture identity;
   • gross artifact-size differences;
   • obvious packaging omissions or path differences.

Do not make these qualification runs required checks for v1.29 and do not delay the release waiting for an arbitrary soak-count target.

Evidence boundary

The current Intel qualification workflow intentionally sets:

bundle.createUpdaterArtifacts = false

and receives no updater-signing secrets.

Therefore pre-v1.29 qualification can prove:

• runner provisioning works;
• the current source/toolchain compiles on Intel macOS;
• Tauri packages an x86_64 macOS bundle;
• basic bundle/artifact parity with Apple Silicon.

It cannot yet prove:

• signed Intel updater artifact parity;
• darwin-x86_64 release-manifest publication;
• signed .app.tar.gz updater behavior;
• production Release-job integration.

Do not weaken that isolation merely to collect stronger evidence before v1.29.

Promotion hold

Even if multiple Intel qualification runs succeed before v1.29:

PROMOTE_MACOS_INTEL_BEFORE_V1_29 = NO

Do not modify the production tauri-build.yml matrix, release asset-count contract, notices/SBOM expected-target count, or latest.json release behavior before the current release.

After v1.29 is published, re-anchor this issue on then-current main and use the accumulated evidence to decide the smallest promotion PR.

That post-release promotion must explicitly cover:

• macos-15-intel production matrix admission;
• release reliability/queue soak evidence;
• ARM ↔ Intel artifact parity;
• per-target third-party notices/SBOM count moving from 3 to 4 where appropriate;
• signed Intel updater artifact generation;
• darwin-x86_64 in latest.json;
• release workflow asset expectations;
• updater behavior;
• documentation/support statement;
• CI-minute/maintenance-cost decision.

If soak evidence shows provisioning instability again, keep Intel qualification separate and document that result rather than blocking v1.29.

---

Context

Part of the post-#477 reconstruction reconciliation program's S5 slice (Intel macOS qualification lane).

macos-13 (the last GitHub-hosted Intel runner) was removed from tauri-build.yml's production matrix on 2026-07-28 after repeatedly failing to provision (queue-hung, not a build failure) — see docs/TAURI-CI.md for the incident. GitHub's tauri-build.yml comment referenced this as "a re-opened follow-up" but no issue previously tracked it; this issue is that tracking artifact.

What's done

• Empirically confirmed (2026-08-26) that GitHub's replacement label macos-15-intel (available since 2025-09-18, through August 2027) schedules and runs successfully on this org's plan.
• New qualification-only workflow: .github/workflows/tauri-intel-qualification.yml — workflow_dispatch only, permissions: contents: read, no signing secrets, no Release/latest.json mutation. Builds the app on macos-15-intel as a real Tauri build to keep proving the toolchain still works there.
• Documented current status in docs/native/INTEL-MACOS-QUALIFICATION.md.

What's open before promoting Intel back into the production release matrix

1. Soak/repeat testing — one successful qualification run doesn't rule out the same queue-availability issue that removed macos-13; needs repeated real-world observation over time, not a single manual dispatch.
2. Artifact parity check against the existing macos-latest (Apple Silicon) bundle.
3. Ongoing maintenance-cost decision — doubling macOS CI minutes per release for the current Intel-Mac user base is a product call, not purely technical.
4. Explicit promotion PR once (1)-(3) are resolved: add macos-15-intel to tauri-build.yml's bundle matrix, add a darwin-x86_64 entry to the latest.json generator's expected-platform set, update docs/TAURI-CI.md's Build matrix table.

Not blocking any other work; this is deliberately kept as a separate, opt-in qualification lane.

[qnbs]

2026-09-23 current-state reconciliation — discovery is complete; promotion evidence remains

Revalidated against current repository state and current GitHub-hosted runner documentation.

The original "find a working Intel runner replacement" problem is no longer the active phase:

• .github/workflows/tauri-intel-qualification.yml exists;
• it runs a real pnpm exec tauri build on macos-15-intel;
• docs/TAURI-CI.md and docs/native/INTEL-MACOS-QUALIFICATION.md record successful empirical provisioning/build evidence;
• GitHub currently lists macos-15-intel as a standard hosted Intel macOS runner.

#507 therefore remains OPEN, but the remaining contract is narrower:

1. accumulate repeated/soak scheduling evidence sufficient to address the old queue-availability failure class;
2. qualify release-time reliability/cost;
3. decide whether Intel x86_64 artifacts are still a supported product target;
4. if yes, promote the lane into the production release matrix without letting one unavailable leg stall all other release assets indefinitely;
5. wire artifact/manifest/updater behavior and release evidence for x86_64 deliberately;
6. if no, document the support decision truthfully rather than retaining a permanent pseudo-roadmap item.

The successful v1.28.8 ARM macOS release does not satisfy Intel qualification.

Do not redo runner discovery; the remaining work is admission/promotion/release integration.

[qnbs]

Intel macOS qualification evidence — 2026-09-29 (background lane of the v1.29 fast track, non-blocking)

Correction to the prior evidence base: tauri-intel-qualification.yml (workflow 342814895) had zero runs before today. The only earlier Intel signal was intel-probe-throwaway.yml run 32953253222 (2026-08-26, throwaway branch, ~10 s). That was a provisioning probe, not a Tauri build.

Run	Main SHA	Dispatch → start	Classification	Failed step	Artifact
36553360612	b2393796 (trusted: CI/CD 36550520713 ✅, CodeQL ✅)	10:05:22Z → 10:05:27Z (~5 s, provisioned)	RUNNER STARTED / SETUP FAILURE	./.github/actions/setup → pnpm/setup	none (build skipped)

Root cause (from the log): Error: pnpm v11 does not provide a working binary for Intel macOS (darwin-x64) due to an upstream Node.js SEA bug (pnpm/pnpm#11423). The repository pins pnpm 11.22.0; the action suggests pnpm 12 (npx get-pnpm 12), npm install -g pnpm, or Homebrew.

Conclusions

• Provisioning of macos-15-intel worked immediately. That is one data point against the old macos-13 queue failure class.
• The lane is currently blocked by toolchain policy: it cannot reach tauri build while the repo-wide pnpm pin is 11.x. This is Intel-specific. Production targets (macos-latest/aarch64, Windows, Linux) are unaffected and were green on the feat(release): ship third-party notices and CycloneDX SBOM with desktop builds (#871) #881 qualification (run 36504123786).
• Further soak dispatches are paused: they would fail identically and give no new information.
• Not a v1.29 blocker; no production matrix change before v1.29.

Post-release decision needed (owner #507, related to pnpm toolchain policy and #893 pnpm/setup 3): either (a) an Intel-only pnpm installation path in the qualification lane (for example pnpm installed via the Node that setup-node provides), which diverges from the pinned-binary policy, or (b) wait for the repository-wide move to pnpm 12. Either choice is a toolchain-policy change and is out of scope before v1.29.

[qnbs]

Release-recovery hold — 2026-09-29

The Intel lane remains useful evidence but is not active release work.

Because v1.29.0 did not reach VERIFIED, the prior “post-v1.29” boundary now means:

RESUME_AFTER = #872 v1.29.1 VERIFIED
V1_29_1_BLOCKER = NO
PRODUCTION_MATRIX_PROMOTION = NO

Existing evidence remains authoritative:

• macos-15-intel provisioned successfully;
• the current blocker is pnpm 11 darwin-x64 bootstrap before Tauri build;
• no WorldScript/Tauri x86_64 product failure has been established.

Do not spend recovery-critical time changing pnpm, updater manifests, asset counts, signing expectations or the production release matrix. Re-anchor this issue after v1.29.1 VERIFIED and then make the explicit Intel support/promotion decision.