ci: unified tag-triggered release pipeline with SLSA provenance on the Release (Scorecard Signed-Releases → 10)

.github/workflows/ci.yml

@@ -163,11 +163,17 @@ jobs:
         run: cargo publish -p ordvec --dry-run --locked
 
   # ----------------------------------------------------------------------
-  # Pin the release-publish SBOM invariants. release-*.yml are
-  # workflow_dispatch-only, so their "generate SBOM then publish" flow never runs
-  # in push/PR CI — a generated *.cdx.json once broke both publish paths and would
-  # only have surfaced at manual release. This exercises the invariants every
-  # push/PR (see tests/release_publish_invariants.sh).
+  # Pin the release-publish invariants. release.yml is tag-triggered (with the
+  # two registry publishes gated behind GitHub Environments), so its release-
+  # specific flow runs only on a real release. Two structural lints guard it
+  # on every push/PR so regressions can't sneak in between releases:
+  #   * release_publish_invariants.sh — the *.cdx.json SBOM never reaches PyPI
+  #     (a generated SBOM once broke both publish paths).
+  #   * release_signed_release_invariants.sh — the signed-release / provenance
+  #     graph stays intact: release-assets-draft stays draft, the SLSA
+  #     generator emits a .intoto.jsonl, both publishes need the draft assets,
+  #     publish-crate proves byte-identity vs the attested .crate, and
+  #     publish-github-release un-drafts ONLY after both publishes succeed.
   # ----------------------------------------------------------------------
   release-guard:
     name: release-publish invariants
@@ -186,6 +192,8 @@ jobs:
           persist-credentials: false
       - name: release-publish SBOM invariants
         run: bash tests/release_publish_invariants.sh
+      - name: signed-release / provenance invariants
+        run: bash tests/release_signed_release_invariants.sh
 
   # ----------------------------------------------------------------------
   # Supply-chain policy gate. The `deps` job's cargo-tree grep is a coarse

.github/workflows/python.yml

@@ -6,7 +6,7 @@ name: python
 # the core checks, and so a green run proves the bindings build cold from a
 # checkout (the paper's reproducibility requirement).
 on:
-  # Push runs on EVERY commit to main (no paths filter): release-python.yml's
+  # Push runs on EVERY commit to main (no paths filter): release.yml's
   # require-ci-green gate asserts a successful python.yml run exists for the exact
   # release SHA on main, so a docs-only or workflow-only release tip must still
   # produce a run here or the wheel gate would be unsatisfiable. Feature branches
@@ -56,19 +56,18 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        # release-python.yml builds one wheel per platform; this matrix makes
+        # release.yml builds one wheel per platform; this matrix makes
         # sure every one of those targets is *behaviourally* tested (build →
         # install → pytest), not merely compiled. abi3 means a single wheel
         # covers all CPython 3.10+, so the python axis only needs its 3.10↔3.13
         # floor/ceiling checked once (linux/x86_64); the other targets exercise
         # the native code on 3.13. The aarch64 runners (ubuntu-24.04-arm,
         # macos-latest) are what exercise the NEON kernels through the bindings.
-        # NB: ubuntu-24.04-arm hosted runners are free on public repos / paid
-        # plans; until this repo is public the ARM leg may queue or bill.
-        # macOS-Intel (macos-13) is intentionally NOT tested here: that runner
-        # image is deprecated + scarce, so the jobs sit queued and block PRs. The
-        # Intel wheel is still built + shipped by release-python.yml, and its
-        # x86_64 code is covered by the linux-x86_64 legs (logic) + macos-arm64
+        # macOS-Intel (macos-13) is intentionally NOT tested here AND not shipped
+        # by release.yml: the runner image is deprecated + scarce, so the jobs
+        # sit queued and block PRs. Intel-mac users install from the sdist;
+        # adding a cross-compiled Intel wheel is tracked in issue #29. The x86_64
+        # code is still covered by the linux-x86_64 legs (logic) + macos-arm64
         # (Mach-O), so the lost test coverage is marginal.
         include:
           - { os: ubuntu-latest, python: "3.10" } # linux x86_64 — abi3 floor