feat(ci): propose the next release as a reviewable pull request

[abrichr]

Automates everything up to the merge. You read one pull request and click Merge; the bot writes it.

What it does

On every push to main, propose-release.yml computes the next version from the conventional commits since the last tag, writes the three release-metadata files, and opens one pull request titled chore(release): prepare X.Y.Z. If a later commit lands before you merge it, the same pull request updates in place.

Right now, against real history, it computes:

previous=0.92.0
next=0.93.0
released=true
changes=6

Why not python-semantic-release

It cannot run. GitPython 3.1.60 removed Actor.name_email_regex, every released version reads it while loading its config, and the upstream fix is unmerged. That is what has been failing the release job since 24 August, diagnosed in #298.

scripts/plan_release.py does the arithmetic instead. It reads the policy already declared in pyproject.toml rather than hardcoding it, so major_on_zero = false keeps a breaking change on the 0.x line at a minor bump, and a test asserts the file still says that.

What it deliberately cannot do

The whole point of #296 was that one identity proposes and a different one publishes. This keeps that:

• The lifecycle App is never granted contents access, so it cannot push code.
• The branch push uses the built-in token. The App token opens the pull request, which is the only reason CI runs on the proposal at all; a pull request opened with the built-in token starts no further workflow.
• The workflow never pushes to main.

test_release_proposal_can_only_propose asserts there is no gh pr merge, no --auto, no git tag, no gh release, no publish action, and no reference to the release App anywhere in the file. Two mutation checks confirm the guards bite: adding an auto-merge fails that test, and dropping needs: reject-lifecycle-app fails the identity contract.

Quiet by default

Between releases the workflow does nothing and says so. A push with no releasable commits prints "No releasable change since the last tag". A push while a bump is already staged and waiting to publish prints that instead. Neither is a failure, so main does not turn red in the gaps.

Verification

• 316 tests pass across the plan, identity, release, evidence, and importer suites.
• 28 new tests cover the version arithmetic on both 0.x and 1.x lines, breaking changes under both major_on_zero settings, changelog rendering against the exact regex the release workflow greps with, and the write path.
• ruff check . passes. The workflow parses as YAML with the expected jobs and triggers.

The one manual step left

Read the proposal, merge it, then dispatch Release and publish with that version and the merge commit. The bot writes the numbers; a person still decides they are right before anything reaches PyPI.

🤖 Generated with Claude Code