release-and-publish

# Release and publish Requires explicit publishing authorization and a completed `git-wrapup`: synchronized version/changelog, reviewed commits, annotated `v<version>` at HEAD, and no unresolved working-tree changes. Read `CLAUDE.md`. This CLI targets npm and GitHub Releases; no MCP Registry, MCPB, Docker, or hosting steps apply. ## 1. Verify wrapup Read package version, current branch, origin, tag target, annotation and status. Verify tag signing when configured; a signature block must never be interpreted as release text. An existing tag conflict is a stop, not permission to replace it. ## 2. Run the gates Run `bun run devcheck`, `bun run rebuild`, `bun run test:package`, and `bun audit`. Inspect output and resolve failures/warnings. Confirm the package allowlist excludes local configs, reports, tests, backups and credentials. Review any transitive advisory by its actual installed dependency path. ## 3. Push the reviewed commits and exact tag Push the intended branch, then the exact release tag. Do not push unrelated tags. A rejection requires reconciliation, never force-push or stash. A PR route does not authorize merging. ## 4. Publish npm Run `bun publish --access public`. Verify the name is still `mcp-reporter`. Complete configured interactive authentication when requested by the registry. An already-published version is successful only after querying and verifying that exact package/version; never treat arbitrary publish errors as success. ## 5. Record skipped server destinations There is no `server.json`, MCP Registry registration, MCPB bundle or container deployment for this client. Do not create placeholder metadata or destinations to satisfy a server workflow. ## 6. Create the GitHub Release Run `bun run release:github`. It uses the annotated tag and creates the title `v<VERSION>: <tag subject>` with `--verify-tag --notes-from-tag`. The annotation's subject omits the version and its flat digest ends in a per-version changelog link. Existing-release recovery updates the title; inspect the existing body before replacing any published content. ## 7. Reconcile tracked work After verifying delivery, add concise resolution comments on addressed first-party issues with release/commit links, then close completed issues. Do not close another contributor's issue without authorization. Keep incomplete or blocked work open with accurate scope. ## 8. Report artifacts and partial failures Return the npm version URL and GitHub Release URL. On a failure, state which destinations succeeded and the exact failing step. Retry transient network errors at most twice with brief backoff; do not retry authentication, integrity or semantic failures blindly. ## 9. Verify reachability Query the exact npm version and `gh release view v<version> --json url,tagName,name,isDraft`. Check the title and tag against local metadata. Distinguish a blocked verification from evidence that publication failed. Never report a release as complete based only on a push exit code.