BAD CODE: release flow requires protected-main bypass

[flyingrobots]

Observation

During the v0.7.2 release on 2026-06-23, the release commit 098a823f65add42bc02d246743a83c1b70a11d7d was pushed directly to main with tag v0.7.2.

GitHub accepted the push, but reported a bypassed branch protection rule:

Changes must be made through a pull request.

Why this is bad

The release path currently depends on an admin/protected-branch bypass for the version/changelog/tag step. That makes release discipline rely on operator privilege instead of repo policy, and it gives agents a path that is easy to misuse during routine release work.

This is especially awkward because normal feature work is PR-gated, while release bookkeeping escapes that same review lane.

Desired direction

Make the release path obey the same protected-branch invariant as normal code changes, or make the exception explicit and mechanically guarded.

Acceptance criteria

• The documented release flow explains whether release commits are PR-based or explicitly admin-bypass-based.
• If release commits should be PR-based, add a command/checklist path that opens a release PR for package.json, package-lock.json, and CHANGELOG.md before tagging.
• If release commits must remain direct-to-main, add an explicit preflight that warns the operator before bypassing protected-main rules.
• The tag should only be pushed after the release commit is present on origin/main and validation has passed.
• The flow should leave a clear audit trail tying the PR/merge/release commit/tag together.