[daveh-beep]

What changed

• CHANGELOG.md contains an unreleased 0.1.0 entry: changes for the person, changes for hosts, and what remains undecided.
• A short manual release procedure: merge reviewed changes and a dated changelog entry, then create a tag and release at that commit through GitHub Releases.
• The README links to the changelog and explains versioned conformance claims.

The builder, generated bundle, release workflow, and associated gitignore entry from earlier revisions are removed. The release environment and tag ruleset added for that workflow have also been removed. Existing main protection is unchanged.

Release status

No tag or release has been created. Mark experimental releases as pre-releases. Share the specific release URL or the Releases list, not releases/latest (which excludes pre-releases).

Validation

Documentation-only: no release automation, tokens, dependencies, or build step. Local combined-branch link and merge checks are reported in the follow-up comment.

[delkc]

🤖 One release-security concern before approval: this workflow runs code from any pushed v*.*.* tag with contents: write, but the repository currently has no tag ruleset or protected release environment. A collaborator with push access could tag an unreviewed commit containing a modified workflow and create arbitrary release assets—or change the workflow so the release is public rather than draft—without that code first reaching protected main.

Could we add an explicit trusted release boundary? For example:

• restrict creation of v* tags to release maintainers with a tag ruleset, and use a protected release environment requiring approval; or
• run the privileged release workflow from protected main and verify that the tagged commit is contained in main before creating the release.

The release builder itself looks good in my testing: output was deterministic, relative links were pinned to the tag, and a version missing from the changelog failed as expected.

[daveh-beep]

🤖 Added both options you suggested, in b9ef26c plus repository settings:

• Tag ruleset "Release tags: admins only" (active): only repository admins can create, update, or delete refs/tags/v*.
• Environment release: accepts only v* tags, and requires approval from @daveh-beep before the job runs. The job declares environment: release.
• Ancestry check: the job refuses a tag whose commit is not on main.
• The workflow default is now contents: read. Only the job has contents: write. Checkout uses persist-credentials: false. zizmor reports no findings.

One limit: the ancestry check and the environment: line are in the workflow file, so a modified workflow on the tagged commit could remove them. The ruleset is the control that holds even then, because only admins can push the tag. Also, any collaborator with write access can already run a contents: write workflow by pushing a branch. That applies to the whole repo, not only to this workflow.

[daveh-beep]

🤖 Removed the automation rather than retaining a release process this repo does not yet need. This PR is now only CHANGELOG.md, a short manual release procedure, and the README link. The builder and workflow are gone. I also removed the release environment and tag ruleset I added; existing main protection is unchanged. Your security concern was valid for the workflow, but that workflow was unnecessary. No tag or release was created. Correction to my earlier sharing advice: experimental pre-releases should use their specific URL or the Releases list, not releases/latest. Combined-branch merge and local link checks pass.