chore: migrate cargo-zigbuild from ubi to github backend

[wenzowski]

Migrates cargo-zigbuild tool from ubi: to github: backend.

• mise.toml: backend prefix change
• mise.lock: regenerated with github backend entries
• .github/workflows/ci.yml: darwin-link job updated

No functional change expected — github: fetches from same GitHub releases.

[wenzowski]

Local verify status: blocked by pre-existing environmental breakage (not this change)

mise run land stopped at verify because test:bats fails on this machine (macOS). Every failure reproduces identically on origin/main (verified via a detached worktree), so this change is exonerated.

Two pre-existing defect classes, both environmental:

1. BSD sed vs GNU sed — mise-tasks/run-shape-guard:64 and mise-tasks/stop-posture-check:67-70 use GNU-only sed -zE. The gates themselves cannot run under BSD sed; their bats suites fail (sed: illegal option -- z). Also sed -i without a backup extension in tests/ci-tools-check.bats. Affected suites: run-shape-guard, run-shape-guard-quoting, stop-guard, stop-posture-check, ci-tools-check.
2. init.defaultBranch=main in the user's global gitconfig — test setups do git init then git branch -f main, which git refuses on the checked-out branch. CI (ubuntu) defaults to master, so it passes there. Affected suites: verified, issue-guard, landed-check, memories-check.

Everything else in verify passed locally, including the gates that exercise this change directly:

• darwin-link: aarch64-apple-darwin links with no macOS SDK — built with the new github:-backend cargo-zigbuild
• cross-check, deny, zizmor, all other hk steps (incl. lock-complete, ci-tools-check on the real files, taplo-format)
• cargo test --workspace: 241+54+15+18+15+6+21+19+8+5+29+7 passed, 0 failed

CI on ubuntu is unaffected by both defect classes and is the confirming run for this PR.

[linear-code]

CLOUD-281 cargo-zigbuild is the one tool installed from an unchecksummed lock entry, and `lock-complete`'s exemption is why nothing noticed

Why

cargo-zigbuild is pinned through the ubi: backend, and ubi: locks nothing but a version. The complete committed entry, mise.lock:431:

[[tools."ubi:rust-cross/cargo-zigbuild"]]
version = "0.23.0"
backend = "ubi:rust-cross/cargo-zigbuild"

No url, no checksum, for any platform. Every other binary tool in [tools] locks a per-platform sha256 and a download URL. This one resolves at install time and installs whatever the release page serves — the sole tool in the toolchain with no committed integrity check, and it is the tool that links the Darwin release artifacts.

Why the gate did not catch it. mise-tasks/lock-complete asks exactly this question and exempts this exact entry:

A tool with NO platform block is exempt, not a failure: the npm, pipx and core:rust backends resolve at install time and lock no URLs at all. Partiality is only meaningful for a tool that locks any platform.

That reasoning is sound for npm:/pipx:/core: — backends that genuinely cannot lock a URL. It is wrong for ubi:, a backend that fetches a specific release asset and could lock one. The exemption is keyed on "has no platform block" when the discriminating property is "cannot have one". So the gate reads zero platform blocks as "not applicable" where the truth is "unlocked", and reports complete over it on every run. Same shape as the defect lock-complete was built to replace (CLOUD-227), one level further down: a gate whose verdict is silent about the case it exists to find.

Switching the backend to github: locks all seven platforms. Measured:

[tools."github:rust-cross/cargo-zigbuild"."platforms.linux-x64"]
checksum = "sha256:c636e4f72b6f40a40ddf0414c8c6056f78b87eea3be0edf01f08d65fa028a373"
url = "https://github.com/rust-cross/cargo-zigbuild/releases/download/v0.23.0/cargo-zigbuild-x86_64-unknown-linux-gnu.tar.xz"

plus linux-arm64, linux-arm64-musl, linux-x64-musl, macos-arm64, macos-x64, windows-x64. Same upstream artifacts, same GitHub releases — the change is that the bytes are now named and pinned in the lockfile.

PR #205 (wenzowski, 2026-08-10) already made the backend swap, described as "no functional change expected". It is a supply-chain fix, not a cosmetic one. That PR was abandoned in draft, behind main, CI never run; this issue adopts the change rather than reviving the branch.

Ready

• mise.lock carries a url and a checksum for every required platform of every tool whose backend is capable of locking one — i.e. no tool is installed from an unverified download.
• Verified by a command with an exit code, not by reading the file: mise run lock-complete must fail on a lockfile where a URL-capable backend locks no platform. Today it passes.

Done

• mise.toml and .github/workflows/ci.yml name github:rust-cross/cargo-zigbuild; no ubi: tool remains in [tools].
• mise.lock regenerated (not hand-edited), carrying the seven platform blocks above.
• mise run darwin-link still emits aarch64-apple-darwin links with no macOS SDK, now built through the github:-backed binary.
• mise run ci-tools-check green — it is the gate that catches a rename done in mise.toml but not in the workflow.
• Landed on main by fast-forward, CI-confirmed green.

Out of scope, filed separately

Whether lock-complete should stop exempting URL-capable backends is the mechanism half of this ("rules ship with their mechanism"). Attempted in the same change if it is a small predicate change; split out if it is not.

[wenzowski]

This landed as #210 (merged, 5310e71) rather than from this branch — your commit was adopted as-is, so the credit for spotting it is yours.

Two things came out of picking it up:

The change is a supply-chain fix, not the no-op the description expected. ubi: locked a version and nothing else — no url, no checksum, for any platform — which made cargo-zigbuild the only tool in [tools] installed from an unverified download, and it is the tool that links the Darwin release artifacts. Your regenerated lock was byte-identical to a fresh mise lock on the github: backend, seven platforms with sha256.

lock-complete could not have caught it, so #210 also fixes the gate: its exemption keyed on "locks no platform block" (written for npm:/pipx:/core:rust, which genuinely cannot lock a url) rather than on the backend, so for ubi: "locks nothing" read as not-applicable instead of unlocked. It is now an allowlist keyed on the backend, with your entry as a regression test.

The macOS verify breakage you documented is filed as its own issue — GNU-only sed -zE in run-shape-guard and stop-posture-check, plus the git branch -f main fixtures that only pass because CI's git still defaults to master. It reproduces on main, as you said. One correction: memories-check carries no git branch -f, so that suite is failing for some third reason still unidentified.

Closing this one as superseded.

---

Generated by Claude Code