ci(release): gate publishing on accepted exact-main artifacts

[bokelley]

Summary

The current Release Please workflow can enter release-capable behavior from a main push and its publish=false dispatch path does not prove that release creation is disabled. Add a permanent, fail-closed acceptance guard before the Python reporting stack is integrated or publication is re-enabled.

Release Please workflow 204238826 is currently disabled_manually and must remain disabled throughout implementation, stack integration, and actual-main acceptance.

Required behavior

• Separate release-PR proposal from tag/GitHub-release/PyPI publication. A proposal-only invocation must be technically incapable of publishing.
• Bind every release-capable invocation to an explicit immutable main commit and reject stale, missing, non-main, or moving targets.
• Require fresh successful protected CI and the approved release-acceptance workflow for that exact commit.
• Require candidate wheel/sdist identity, hashes, package inventory, version, and installed acceptance for that exact source commit before publication.
• Reapply the complete gate after the generated release PR merges; the release-PR merge commit is a new target and must not inherit evidence from its parent.
• Keep recovery/manual publishing behind the same gate. Do not leave an alternate publish=true, legacy rerun, tag, or branch-ref bypass.
• Use least-privilege permissions, concurrency controls, idempotent retries, and explicit environment approval where supported.
• Preserve a safe proposal route while the publication writer remains disabled.

Acceptance criteria

• Proposal-only and release-capable paths are structurally separate and tested.
• Wrong SHA, stale SHA, non-main ref, incomplete/failed/skipped CI, missing artifact evidence, mismatched version/hash, and replay attempts all fail closed.
• Exact accepted M_impl can create/update the normal release PR without publishing.
• Exact accepted M_release can publish once after fresh artifact and installed-package validation.
• Reruns and recovery dispatches cannot reuse stale acceptance.
• Workflow security validation and an independent review pass on the final exact head.
• Operational documentation covers disable/drain, guarded enable, proposal, final validation, publish, and rollback.

Integration boundary

Implement and review independently, but merge after the reporting stack and #1172. Do not re-enable Release Please, publish, create tags/releases, or weaken existing branch protection as part of this issue.

Related: #1172, #1192, #1193.

[bokelley]

Triage

Classification: Feature request (CI/CD security enhancement)
Bucket(s): — (CI/CD pipeline; no matching scope-label bucket)
Status: deferred

What the experts said:

• (Deferred before expert review — merge ordering declared in issue body; issue is well-specified by the maintainer)

My take: The issue itself states "merge after the reporting stack and #1172"; #1172 is open and PRs #1192 and #1193 (the reporting stack) are open as well — the child-of-open-parent rule puts this squarely in Blocked-on. Separately, the scope is .github/workflows/** (outside the execution safety gate for the triage bot) and the change is security-sensitive (fail-closed SHA binding, replay prevention, least-privilege workflow permissions), so even absent the merge ordering, this would require human review before any branch is opened.

Blocked-on: #1172 — resurfaces on merge.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01M6N8EVSDeQ6Th1dija5rCW

---

Generated by Claude Code