Align release authorization and post-release docs

[IlyaasK]

Summary

• document two active rulesets for v* release tags
• keep tag creation available to the Write, Maintain, and Admin repository roles
• prohibit tag updates and deletion with a separate ruleset that has no bypass actors
• keep release authorization aligned with the current self-release workflow, which does not use a GitHub release environment
• update security, local-development, example, and release-checklist wording now that v0.0.1 is public

Why

GitHub applies a ruleset's bypass list to every rule in that ruleset. Combining creation, update, and deletion restrictions with write-capable role bypass allowed those roles to bypass the immutability controls too.

Separating creation authorization from update/deletion protection preserves the intended operating model: any trusted Kernel engineer with write-capable access may create a release tag, but an existing release tag cannot be moved or deleted while the immutability ruleset is active.

This is release documentation only. It does not change provider behavior, acceptance coverage, artifact generation, signing, or publication workflows. The live repository rulesets were updated to match the documented model, and stale pre-release wording was removed after the successful v0.0.1 publication.

Live Configuration

• release tag creation: targets refs/tags/v*, restricts creation, and grants bypass to Write, Maintain, and Admin
• immutable release tags: targets refs/tags/v*, restricts update and deletion, and has an empty bypass list
• no GitHub release environment is required by the current workflow; signing credentials remain repository Actions secrets and variables

Verification

• git diff --check
• bash scripts/check-markdown-links.sh
• verified the touched release documentation no longer describes the provider as unreleased
• verified both live rulesets are active, target refs/tags/v*, and have the expected rules and bypass lists
• verified the repository currently has no GitHub environments and .github/workflows/release.yml on main does not reference one
• go test -short -timeout=2m ./... was already green for the documentation-only PR
• go vet ./... was already green for the documentation-only PR
• gofmt -l cmd internal previously returned no files

Before And After

Before, one ruleset combined release authorization and immutability while its bypass list exempted every release-authorized role from both. The documentation also retained first-release wording after v0.0.1 was public. After, one ruleset authorizes tag creation, a separate no-bypass ruleset protects published tags from update and deletion, and public documentation reflects the released provider.

[Sayan-]

Approving because the docs are now accurate. The contradiction you identified was real. But the thing they've become accurate about is worth fixing, and I'd rather flag it here than have it discovered after the first tag.

I pulled the live ruleset. release tags (id 20078843) is active on refs/tags/v* with creation, update, and deletion rules, and its bypass_actors are RepositoryRole:2/always, RepositoryRole:4/always, RepositoryRole:5/always — the three write-capable roles, matching what this PR describes. GitHub applies bypass at the ruleset level rather than per-rule, so every account that could push a v* tag in the first place is exempt from all three rules. As configured, the ruleset constrains nobody.

The consequence that matters: a published v* tag can be moved or deleted by anyone with write access. Immutable Releases protect the release object, but the tag is what the Registry resolves and what the signed checksums correspond to, and docs/release.md elsewhere instructs operators never to mutate a published version. The ruleset was the only mechanism actually preventing that.

It also means check-release-protections.sh will report the release path as protected when it isn't. The script asserts the ruleset is active and carries all three rule types, and by design it cannot read bypass_actors — you documented that limitation yourself in #98. So the single field that determines whether the ruleset does anything is invisible to the check that exists to validate it.

The fix that preserves self-release is two rulesets rather than one. Give the first only creation, with bypass for the write-capable roles, so any Kernel engineer can tag a release. Give the second update and deletion with an empty bypass list, so a published tag cannot be moved or removed by anyone, admins included. The main ruleset in this repo already uses exactly that shape — deletion with bypass=[]. check-release-protections.sh would then need to verify two ruleset IDs instead of one, which is a small follow-up rather than part of this documentation change.

Unrelated, but I noticed it while looking: the release environment doesn't exist yet. check-release-protections.sh fails on its first API call until it's created, so neither preflight nor publish can run today.

[IlyaasK]

Approving because the docs are now accurate. The contradiction you identified was real. But the thing they've become accurate about is worth fixing, and I'd rather flag it here than have it discovered after the first tag.

I pulled the live ruleset. release tags (id 20078843) is active on refs/tags/v* with creation, update, and deletion rules, and its bypass_actors are RepositoryRole:2/always, RepositoryRole:4/always, RepositoryRole:5/always — the three write-capable roles, matching what this PR describes. GitHub applies bypass at the ruleset level rather than per-rule, so every account that could push a v* tag in the first place is exempt from all three rules. As configured, the ruleset constrains nobody.

The consequence that matters: a published v* tag can be moved or deleted by anyone with write access. Immutable Releases protect the release object, but the tag is what the Registry resolves and what the signed checksums correspond to, and docs/release.md elsewhere instructs operators never to mutate a published version. The ruleset was the only mechanism actually preventing that.

It also means check-release-protections.sh will report the release path as protected when it isn't. The script asserts the ruleset is active and carries all three rule types, and by design it cannot read bypass_actors — you documented that limitation yourself in #98. So the single field that determines whether the ruleset does anything is invisible to the check that exists to validate it.

The fix that preserves self-release is two rulesets rather than one. Give the first only creation, with bypass for the write-capable roles, so any Kernel engineer can tag a release. Give the second update and deletion with an empty bypass list, so a published tag cannot be moved or removed by anyone, admins included. The main ruleset in this repo already uses exactly that shape — deletion with bypass=[]. check-release-protections.sh would then need to verify two ruleset IDs instead of one, which is a small follow-up rather than part of this documentation change.

Unrelated, but I noticed it while looking: the release environment doesn't exist yet. check-release-protections.sh fails on its first API call until it's created, so neither preflight nor publish can run today.

Addressed the ruleset issue. The live configuration now uses two active rulesets targeting refs/tags/v*:
release tag creation restricts creation with Write/Maintain/Admin bypass.
immutable release tags restricts update and deletion with an empty bypass list.
I updated the release documentation to match.
I also checked the environment point against the final merged #98 design and current main. check-release-protections.sh is not present, and the release workflow intentionally does not use a release environment or runtime ruleset API check. That was explicitly removed when we adopted self-release for trusted Kernel engineers; v0.0.1 successfully used the resulting workflow.