Release workflow

Run the full CI suite successfully on the exact release candidate commit before creating or pushing a version tag or publishing a release. A tag-triggered CI run happens after the tag exists, so it is an additional check and does not satisfy this pre-tag gate.

Required checks

For every release candidate on main:

1. Wait for the Build workflow to finish successfully on the candidate commit. It runs bash gradlew clean build, including the Java test suite.
2. Run the Documentation build workflow on the same candidate commit, even when its path filters would otherwise skip it. It checks generated planner and preset data, the planner and unlock suites, the hosted player-guide tests, and the documentation build.
3. Confirm every job in both workflow runs completed successfully for the exact candidate commit SHA. Pending, skipped, cancelled, or failed jobs do not pass this gate.
4. Create and push the version tag only after those checks pass. The tag must point to that exact commit. Publish the release only after the tag is in place and the tag-triggered Build workflow also succeeds.

If any source, configuration, generated data, release notes, or documentation changes after the checks pass, the commit has changed: rerun both workflows on the new candidate SHA before tagging or publishing.

Release records

Record the candidate SHA and links to both successful workflow runs in the release notes or release checklist. Keep build/CI evidence separate from live server, gameplay, deployment, and owner-acceptance evidence; CI success does not prove those separate checks.