Release-process gaps: macOS wheel + sdist published without install/import test; only py3.11 tested (claims 3.9-3.14); crates.io publishes without running tests / ungated on CI

[RyanCodrai]

Four confirmed release-process gaps in .github/workflows/ that can ship broken artifacts or publish on a red build. Found by a systematic bug-hunt pass (wave 17); each is verified by unambiguous YAML (workflows can't be run locally, so verification is static + cross-referenced against pyproject classifiers / Cargo.toml). Build/packaging is an in-scope hunt area.

1. macOS wheel published with NO install/import test (ships-broken-artifact)

.github/workflows/release-pypi.yml:64-82 — the macos job builds and uploads only; there is no pip install dist/*.whl + pytest step. The linux (:50-57) and windows (:98-105) jobs both do. The linux job's own comment (:45-49) explains why: it "catches linkage regressions that produce structurally-correct .so files which fail at Python import time — exactly the class of bug that was silently shipping in Linux wheels." macOS is a first-class claimed platform (Operating System :: MacOS) and the primary dev platform, yet its wheel gets zero import verification pre-publish. Fix: add the same install+test step to the macos job.

2. sdist published but never installed / built-from-source (ships-broken-artifact)

.github/workflows/release-pypi.yml:112-127 — the sdist job builds + uploads, and release (needs: [...sdist], :132) publishes it, but it is never pip install'd from the tarball. A source tarball missing files (Rust path-dep sources, README, LICENSE) or that fails to compile ships green. Users without a matching wheel (musl, other arches, future free-threaded builds) fall back to the sdist — the exact broken path. Fix: add pip install --no-binary :all: dist/*.tar.gz + import test.

3. Python-version matrix hole — only 3.11 ever exercised; claims 3.9–3.14 (untested-target)

ci.yml:51-53 hardcodes python-version: "3.11"; the release build jobs also all pin 3.11. pyproject declares requires-python >=3.9 + classifiers 3.9–3.14. The abi3-py39 build correctly emits a single cp39-abi3 wheel (so a full build matrix isn't needed), but nothing ever imports it on the 3.9 floor or the 3.14 ceiling — precisely where abi3 forward-compat breakage hides (limited-API changes, numpy not yet publishing 3.14 wheels). Fix: import-test the abi3 wheel on at least 3.9 and 3.14.

4. crates.io release runs no tests and isn't gated on CI — can publish on red (publishes-on-red)

.github/workflows/release-crates.yml:12-32 — the only build step is cargo publish -p turbovec (:32); no needs: on CI, no cargo test. cargo publish does a verification build, not the test suite, so a commit whose cargo test -p turbovec fails but still compiles will publish. Trigger is a bare tag push independent of CI status. Fix: add cargo test -p turbovec --release before publish, or gate on the CI workflow being green.

5. (Suspected, minor) release smoke tests narrow the test set

release-pypi.yml:57,105 run only tests/test_index.py tests/test_id_map.py tests/test_filtering.py; the tree also has test_dedup.py, test_security.py, and the 4 integration files. CI (ci.yml:84-85) runs the full suite, so this is a release-time narrowing, not a total hole. Fix: point the release smoke test at the full tests/ dir (integration files self-skip when extras absent).

Verified sound (no action)

abi3 wheel tagging (single cp39-abi3 wheel, correct); Rust OS matrix (ubuntu/macos-14/windows, fail-fast: false); PyPI release job needs: [linux, macos, windows, sdist] + correct py-v* tag trigger (blocks publish on any build failure); cargo test -p turbovec --release in ci.yml runs the full core suite.