Release

6.1 Trusted Publisher contract and recovery

Each npm package's Trusted Publisher settings must match:

• repository owner/name: the GitHub repository that contains this workflow;
• workflow filename: publish-npm.yml (exact filename);
• Environment: blank when the workflow has no environment, or the exact same Environment name on both npm and the publish job.

The workflow file path is .github/workflows/publish-npm.yml; npm's Trusted Publisher form takes the filename, not the full path. The job runs on a GitHub-hosted runner with id-token: write, does not use NPM_TOKEN or NODE_AUTH_TOKEN, and leaves automatic provenance enabled. A zero exit status from npm publish is sufficient for the workflow to record accepted-by-npm and continue. Registry visibility and provenance metadata can lag behind npm's acceptance; do not wait for them or fail an accepted upload because they are not yet visible.

New package — one-time ops step for @chorus-aidlc/chorus-pi. chorus-pi is the 4th coordinated package and was added after the first three. Before its first coordinated publish, a maintainer with npm publish rights MUST register its Trusted Publisher on npmjs.org (Settings → Publishing access → Trusted Publisher): same GitHub repository owner/name, workflow filename publish-npm.yml, and a blank Environment (matching the other three). This is a human/npm-console action that cannot be scripted from this repo — until it is done, the OIDC publish step for chorus-pi will be rejected and the run will stop at chorus-pi with the earlier three already published (a partial-publish state; recover via Re-run jobs once the Trusted Publisher is registered). Do not create a placeholder token or disable provenance to work around it.

If a run partially publishes the fixed sequence, fix the external failure and use Re-run jobs on the same failed GitHub Actions run. Do not create another tag or GitHub Release and do not bump the version. The rerun queries every exact name@version, records existing versions as skipped-already-published, and continues with the first missing package. Registry lookup errors remain fatal; never assume an ambiguous lookup means “not published.”

7. Sync develop with main and verify

# Pull the merge commit back into develop
git checkout develop
git pull origin develop

# Confirm tag exists
git tag -l 'vX.Y.Z'

# Confirm release is visible
gh release view vX.Y.Z

Checklist

• git fetch --tags origin run — local tags are up to date
• git log v<PREV>..develop reviewed — no commits missed
• CHANGELOG draft presented to user and approved
• CHANGELOG.md written with approved content
• Root, OpenClaw, dsh, and chorus-pi package versions are the same X.Y.Z
• Hermes chorus/plugin.yaml, chorus-mcp/plugin.json and every chorus/skills/*/SKILL.md metadata.version are the same X.Y.Z
• OpenClaw package-lock.json refreshed for X.Y.Z (chorus-pi needs no lockfile refresh)
• Changes committed and pushed to develop
• PR from develop → main created, CI passed, and merged
• gh release create with tag targeting main
• @chorus-aidlc/chorus-pi Trusted Publisher registered on npmjs.org (one-time, before its first coordinated publish)
• publish-npm.yml run passed for all four packages (accepted-by-npm or safely skipped)
• Automatic provenance remained enabled; registry propagation was not a release gate
• Release notes contain only the new version's section
• develop synced with main after merge
• gh release view confirms everything looks correct