Automated releases cannot push to a branch protected by the standard ruleset

The default-branch ruleset in the standards requires a pull request, and the release-tag ruleset blocks tag updates. Several release workflows do neither: they push a version bump straight to main and move the release tag. Where both exist, the next release fails. We need to settle which side gives way before more repos adopt the rulesets.

Raised while bringing crowd-depth up to spec in openwatersio/crowd-depth#115, where the rulesets are the one item left unapplied.

Where this stands today

aiscast has both active rulesets and a release workflow that pushes to main. Its rulesets were created on 2026-09-08; its last successful release ran on 2026-09-01. No release has run under them, so the conflict is latent rather than observed.

crowd-depth has the same workflow shape and no rulesets. It also force-pushes the release tag onto the version-bump commit, which the tag ruleset's update rule blocks.

Both rulesets currently bypass only the repository admin role. A workflow pushing with GITHUB_TOKEN acts as the GitHub Actions app, which that bypass does not cover.

Tier 1 and tier 2 sharpen this: they require an approving review, and no bot can supply one for an automated push.

Options

Grant the GitHub Actions app a bypass on both rulesets. Smallest change and no workflow edits. The cost is that every workflow in the repo can then write to main unreviewed, so the protection holds for humans only.

Stop writing to main during a release. The tag becomes the source of truth for the version, and the workflow publishes without committing back. The tracked package.json version then trails the published one, which is a real cost for a plugin whose version users read from the repo.

Move the version bump ahead of the tag. A release pull request carries the bump, merges normally under the ruleset, and the tag is cut from the merged commit. This is the Changesets flow the standard already sanctions, and it needs no bypass, at the price of a second step per release.

To decide

• Which option becomes the baseline for tier 1 and tier 2 repos.
• Whether the standard records an explicit bypass actor for release automation, rather than leaving each repo to invent one.
• Whether release workflows that push to main are worth flagging in the audit checklist.
• Apply the outcome to aiscast, whose rulesets are live and untested against a release.

Start by comparing the release workflows and rulesets in aiscast and crowd-depth, focusing on pushes to main, release-tag updates, and GitHub Actions bypass coverage. Done means selecting the baseline for tier 1 and tier 2 repositories, recording the bypass policy, deciding whether to flag these workflows in the audit checklist, and applying the outcome to aiscast.