What

Keep semantic-release's own GitHub Actions outputs separate from the tag and source commit selected for publishing. Require both a tag and an explicit source commit before starting distribution builds.

Why

After #82 merged, semantic-release correctly decided that the build commit didn't warrant a new version, but it still appended tag=v0.40.0 and released=false to GITHUB_OUTPUT. The workflow forwarded that tag while its commit output was empty, which started distribution builds using the fallback main commit. I canceled that run before publication.

Explicit-tag recovery selects the original commit correctly and is unaffected. Recovery run 34009001457 succeeded: 0.40.0 is now on PyPI with ten wheels and its source archive. All eleven hashes match the GitHub release assets, the original tag/source are preserved, and fresh binary-only PyPI installations on Python 3.13 and 3.14 each passed all 79 layout tests and the CLI version check.

How

• Set and forward our own release_tag and release_commit step outputs.
• Gate distribution builds on both job outputs being present.
• Exercise the actual YAML shell step with real Git repositories and controlled external tools for no-release, new-release, and existing-tag recovery cases.
• Add PyYAML to contributor tooling to read the workflow in tests. Include the workflow as test input in the source archive. No runtime dependencies or dependency versions change.

Testing

• All three selection regressions pass. Against the merged workflow, the no-release test fails while the other two pass.
• Replayed both versions with the real pinned python-semantic-release 9.21.2 and GITHUB_OUTPUT set in a temporary clone. The original forwards tag=v0.40.0 with no commit; the fix forwards neither. Pushing and GitHub release creation were disabled for that rehearsal.
• Full Python suite, Ruff, Black, MyPy, and actionlint passed locally.
• CI Python 3.13/3.14 checks, native unit tests, docs, PR lint, and Linux/Windows wheel builds passed. The remaining macOS wheel and device checks are running.

Risks/Impact

No library behavior or version changes. New releases and manual recovery still select the exact tagged source. Use this PR's ci(workflows): ... title for the squash merge so this correction doesn't trigger a version bump.

Docs/Follow-ups

This restores the release behavior already documented in CONTRIBUTING.md. The separate explicit-tag recovery has finished successfully; this PR prevents the automatic no-release path from starting another build.