Adopt issue-driven development with automated release publishing

[firejune]

Goal

Bring this repo to the same operating model as sibling packages (e.g. spine-html, headerless):

• Open items live as GitHub issues — known gaps, deferred work, and roadmap items are filed here and closed with Closes #N commits/PRs.
• Releases are cut by automation, not by hand: a release-please workflow opens the release PR, and merging it publishes to npm via Trusted Publishing (OIDC — no long-lived npm tokens in the repo).
• End state: an automation agent can pick up an issue, resolve it on a branch, open a PR, and the merge triggers the release pipeline — maintainer involvement reduced to review/merge.

Steps

1. Align the in-repo package versions with the registry: byteguard@0.4.1 and vite-plugin-byteguard@0.4.1 were published as a version-bump-only republish of the v0.4.0 tree (the tarballs are byte-identical to 0.4.0 apart from the version fields and the plugin's dependency range), but the bump never landed here — the repo still says 0.4.0. Record it so the pipeline starts from the registry's reality instead of re-cutting a version that already exists.
2. Add a GitHub-hosted release workflow (release-please, manifest mode) covering both published packages in this repo.
3. Configure npm Trusted Publishing for both packages on npmjs.com (maintainer action — the npm-side form must be filled by the package owner).
4. Enable the repo setting that allows Actions to create pull requests (required for the release PR).
5. Retire manual npm publish once the pipeline has cut one verified release.

Notes

• Trusted Publishing requires GitHub-hosted runners (it does not work from self-hosted runners) — keep the release job on ubuntu-latest.

[firejune]

Steps 1, 2, and 4 landed:

• Step 1 — c8f53b6 (chore: align package versions with the published 0.4.1): both packages now say 0.4.1, the plugin's dependency range says ^0.4.1, and that commit is tagged byteguard-v0.4.1 / vite-plugin-byteguard-v0.4.1 — it is the source of what the registry serves as 0.4.1 (verified by diffing the published tarballs: 0.4.1 is byte-identical to 0.4.0 apart from those version fields).
• Step 2 — 36269b8 (ci: adopt release-please with npm trusted publishing): .github/workflows/release.yml runs release-please in manifest mode over both packages (node-workspace plugin: a core release bumps the plugin's dependency range and releases it too), then npm publish --provenance over OIDC, core before plugin. ci.yml builds both workspaces and runs vitest on every push and PR — first runs are green. RELEASING.md documents the loop and the manual fallback.
• Step 4 — repo setting Allow GitHub Actions to create and approve pull requests is now enabled (verified via API).

Remaining before the first automated cut (maintainer, npmjs.com — step 3):

Trusted Publisher form, filled identically for byteguard and vite-plugin-byteguard:

Field	Value
Organization or user	firejune
Repository	byteguard
Workflow filename	release.yml
Environment name	leave blank

Then land the next feat/fix on main, merge the release PR it opens, and watch the publish steps — the first automated release proves the OIDC exchange end to end, after which this issue can close (step 5).

[firejune]

Automation status: the release pipeline here is now fully zero-touch on the GitHub side, identical to the sibling headerless repository where it was proven live today (its release PR was tested, merged, tagged, and GitHub-released with no human clicks).

In place as of #2–#5:

• release-please (manifest mode) + OIDC publish in release.yml; the run drives its own release PR: dispatches ci.yml onto the release branch for the required test check, squash-merges once green, and dispatches the tag-and-publish run. Daily scheduled sweep as the safety net; workflow_dispatch (with an optional republish input for a tagged-but-unpublished release) as the manual lever. No PAT, no stored credential.
• main branch protection now matches headerless: required test check, applying to admins too; auto-merge enabled.

Two things stand between here and the first automated publish:

1. Owner-side, once: the npmjs.com Trusted Publisher form for both byteguard and vite-plugin-byteguard (user firejune, repository byteguard, workflow release.yml, environment blank — see RELEASING.md). The sibling repo's live runs showed exactly how its absence fails (ENEEDAUTH), so do this before the next release.
2. A releasable commit: the next feat/fix on main opens the release PR and the chain takes it from there.

Leaving this open until that first publish lands on the registry.