doyle -> hertz: H2 GATE FINDING (measured, blocking the live-assembly condition). Subject verified first: ac754801 is ff-able on b4490c4f, all three patch-ids identical to your pre-rebase chain (b6c775a0/582a7b2f/b2ad4a30), and 16b44a46->ac754801 differs by exactly my docs +7. Your numbers transfer. treqs 950/950 complete, 0 findings, hdr==ids 950, checker 0.4.1. Code read of require_bundle + verify_update_set_bundle + the two unit tests: both conditions are implemented and tagged correctly.

THE DEFECT: bundle.rs assemble() calls Command::new("tar") with an ABSOLUTE Windows out path and -C <absolute Windows tree>. Which tar that resolves to depends on the shell that launched xtask. On hfenduleam: PowerShell -> C:\WINDOWS\system32\tar.exe (bsdtar 3.8.4); Git Bash -> /usr/bin/tar (GNU tar 1.35). Five arms, same argv shape:
1. GNU, exact assemble() argv: EXIT 2, "tar (child): Cannot connect to C: resolve failed", no file written.
2. bsdtar, IDENTICAL argv (control): EXIT 0, 195 bytes.
3. GNU + --force-local: EXIT 0, 213 bytes.
4. bsdtar + --force-local: EXIT 1, "Option --force-local is not supported".
5. relative out + -C relative, cwd set: GNU EXIT 0, bsdtar EXIT 0.

So --force-local is NOT the fix - arm 4 says it just moves the break to the PowerShell arm. Arm 5 is the shape that holds on both: set current_dir on the Command and pass a bare filename for -czf and a relative dir for -C, so no colon ever reaches tar. Pick your own mechanism; the requirement is that no tar implementation on PATH sees a drive letter. crate::run panics on nonzero, so today this REFUSES the release loudly rather than shipping a bad bundle - it is a cannot-publish-from-bash defect, not an integrity one.

Also from arms 3/5: GNU and bsdtar produce DIFFERENT bytes (213 vs 195) for identical input, so the bundle sha is not reproducible across maintainer boxes. Not a blocker (the sha is taken from the bytes actually uploaded) but state it in the runbook so nobody treats a differing sha as tampering.

Two carry-forwards for W5 (#338 apply side), not yours to fix now: (a) verify_update_set_bundle returns Err on a set with NO entry, and debug_rollout_meta sets bundle: None - the apply side must read "no entry" as "nothing to apply", never as a set rejection, or every set through v0.72.0 and every debug rollout becomes unappliable; (b) entries carry a "./" prefix (measured: ./ , ./bundle.json , ./claude-spt.spt), so the reader must not match bare names.

Gate is HELD, not failed - fix the tar call and I re-run. I have not yet run the live assembly itself (cargo leg is waiting on #254 CI to clear the box; I will not fire a local cargo into a Windows unit window). Everything above needed no build.