release: Qualify exact artifacts before publish

[BenWestgate]

Fixes #5.

Build the wheel and sdist once, then qualify those exact bytes before anything becomes public.

• tag push starts the release workflow;
• supported OS/Python matrix installs and smoke-tests the built wheel and sdist;
• optimized/static/differential checks run before publication;
• the Bitcoin Core v32 job installs the built wheel rather than importing the checkout;
• Python prerelease interpreters are allowed when a supported classifier precedes the final release;
• qualified artifacts and provenance are staged on a draft GitHub release, published to PyPI, then the GitHub release is made public;
• SHA256 and provenance are rechecked immediately before publication.

Review stack

Base: #59 (codex/4-security-boundary-docs). Current head: 9cf9f44.

The reviewed release-qualification patches were replayed onto the current stack. The second patch retains its stable patch ID. The first differs only because import codex32 is already present upstream; its remaining release-qualification changes are unchanged. All prior review threads remain resolved.

Bitcoin Core v32 pin

bitcoin/bitcoin published the cryptographically verified annotated tag v32.0rc3 on 2026-10-01 (verified: true, reason: valid). However, the official Bitcoin Core 32.0 binary index still publishes only test.rc2/; test.rc3/SHA256SUMS currently returns 404. Therefore this workflow deliberately remains pinned to the available, hash-verified rc2 binary until official rc3 binaries are published. Do not invent or substitute an unofficial rc3 hash.

Validation

On the stacked candidate:

• 950 tests passed normally;
• 950 tests passed under python -O;
• Ruff check and format check passed;
• strict mypy passed for 21 source files;
• workflow YAML parsed successfully;
• git diff --check passed.

The workflow-only tag-push publication path cannot execute on the PR itself; the first real release tag still requires the normal PyPI environment approval and exact-artifact checks.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[BenWestgate]

@claude review.

[BenWestgate]

AI-generated review (Claude), posted at the maintainer's request.

Concept ACK f4f9a48. Two things before merge:

• Trigger: it still runs on release: published, so the GitHub release and tag are public before any gate runs, and a failed qualification leaves a public release with no assets. For "qualify before publish", trigger on push: tags: ['v*'] and have publish create the release, or publish a draft from the workflow.
• 3.15 with #36: the matrix comes from classifiers, so once #36 lands it includes 3.15. setup-python here lacks allow-prereleases: true, so a release cut before 3.15.0 final fails that leg.

Smaller:

• The bitcoin-core job tests src/ via PYTHONPATH, not the qualified wheel. Installing the downloaded wheel there would make "exact artifacts" hold for Core too.
• The "legacy … when present" steps become dead once #7 lands. Sequence after #7 and drop them?

[BenWestgate]

AI-generated review, posted at the maintainer's request.

Concept ACK a653876. The release now qualifies on tag push, Core tests the built wheel, prerelease Python is supported, and GitHub stays draft until PyPI publication succeeds.

No remaining code blocker from my review. First tag remains the required end-to-end validation of the release workflow.

[BenWestgate]

Release-gate sequencing: defer final review of this publication workflow until the prerequisite runtime/CI gates settle. In particular, merge #7 then #51 (wallet/Core qualification) and #50 then refreshed #47 (active test-workflow hardening/assurance), then refresh #52 once on the resulting reviewability-v1. The prior review finding about testing the checkout is already resolved on this head: the real-Core job downloads the built distributions and installs dist/codex32-*.whl before integration. Final end-to-end proof still necessarily occurs on the actual release tag/artifacts.

[BenWestgate]

Release-monitor refresh (2026-09-27/28): upstream bitcoin/bitcoin still exposes only v32.0rc1 and v32.0rc2 under v32.0*; both annotated tag objects report valid signature verification. The official Bitcoin Core 32.0 directory still exposes only test.rc2/, containing SHA256SUMS and SHA256SUMS.asc. There is no v32.0rc3 or final v32.0, so the current rc2 pin remains correct. Repin and rerun only when a newer signed RC or final appears before release.

[BenWestgate]

Agent release-gate review at current head a653876: the publication workflow now builds once, qualifies those exact artifacts across the advertised Python/OS matrix, runs optimized/static/differential checks, installs the built wheel for the real-Core job, records hashes/dependency/Core provenance, and grants contents: write/OIDC only to the final publish job after all qualification jobs succeed. The installed-package verifier also asserts it is not importing src/. I found no remaining workflow-design blocker. The tag-triggered publication path cannot be executed by this PR itself, so the first release tag still requires the normal PyPI environment approval and exact-artifact checks. Keep rc2 pinned until the signed v32 tag namespace advances.