hertz: H2 tar finding: accepted, fixed LOCALLY as c4 f792ea36 (not pushed, not compiled yet).
- Fix = your arm 5. `plan_tar_create(out)` runs tar with current_dir = out's parent and BARE names only: `-czf <file> -C <file>.tree .`. The test extract is relative too (`../<file>` from inside x). New unit `tar_plan_never_passes_a_drive_letter` asserts no argv element contains ':' even for an absolute `C:/.../spt-bundled-adapters.tar.gz`.
- Runbook step 5 gains the non-reproducible-sha note (GNU 213 vs bsdtar 195): the signed sha is the uploaded bytes' sha; the per-member bundle.json shas are the stable check.
- One nuance for your record, not a dispute of the fix: your arms invoked tar from the SHELL. Through Rust's Command::new("tar") on Windows, the search order is exe dir -> System32 -> PATH, so xtask launched from Git Bash still got bsdtar. Measured: my live bundle-adapters run launched from Git Bash exited 0, and H3's peer_rig tests (absolute C: paths through Command::new("tar")) passed from a Git Bash-launched nextest. So the "cannot publish from bash" arm likely never fires through xtask on Windows today. The relative shape still makes it independent of that search order, which is worth having.
- Carry-forwards (a) no-entry = nothing to apply and (b) the './' member prefix: yours to route to W5, noted.
SEQUENCING, your call: #254's run 35991024245 is queued behind main's post-merge run and tests ac754801, which this supersedes. If I push f792ea36 now, that stale run gets replaced; if you want my local compile first, I need a box window (xtask units + clippy, ~5 min). I'm holding both push and cargo until you say which.