Witnora has one maintained npm implementation: packages/witnora-cli.
agentcert@0.9.0 is a frozen compatibility facade and is never versioned or
published again.
Operator path
Prepare the next stable version from a clean branch:
npm run release:prepare -- patch
patch may be replaced by minor, major, or an explicit stable version such
as 1.0.0. The command updates only:
packages/witnora-cli/package.json;packages/witnora-cli/package-lock.json.
Review, commit, and merge those files with the release changes. After the maintainer's manual product acceptance, push the matching tag:
git tag -a vX.Y.Z -m "Witnora vX.Y.Z"
git push origin vX.Y.Z
No npm token, legacy package update, handwritten GitHub Release, or manual artifact upload is part of the normal path.
Stable SemVer contract
Only vX.Y.Z tags are accepted. Pre-release identifiers and build metadata are
rejected by v1 of this policy.
patch: backward-compatible fixes and internal hardening;minor: backward-compatible commands, options, exports, or evidence fields;major: intentional breaking changes to CLI or public module contracts.
Stable agentcert.* evidence schema identifiers have their own explicit schema
versioning policy. Changing an npm major version does not silently rewrite an
evidence schema.
The tag, canonical package, lockfile root, and repository metadata must agree.
The policy also verifies that the legacy package remains exactly
agentcert@0.9.0 -> witnora@0.9.0.
Automated publication chain
.github/workflows/publish-witnora-npm.yml performs the following sequence:
- verifies the release policy and exact tag;
- requires a new version to be greater than npm's highest stable version;
- installs the lockfile without a release cache;
- builds the CLI;
- packs one canonical npm tarball;
- publishes that same tarball through npm Trusted Publishing;
- confirms the registry exposes the version and that its bytes match;
- creates the GitHub Release.
Product behavior, onboarding usability, and customer acceptance are decided by the maintainer's manual walkthrough. Automated onboarding contracts, full test suites, dependency audits, SBOM generation, compatibility matrices, attestations, external canaries, and production smoke runs do not block npm publication. The production smoke workflow remains available as a manual or scheduled diagnostic.
The workflow is retry-safe. If npm already contains the version, the registry tarball must match the locally reconstructed tarball before the workflow can continue. npm versions remain immutable; a bad release is corrected by a new patch release, never by replacing bytes.
Release evidence
Every successful GitHub Release contains the exact witnora-X.Y.Z.tgz tarball
published to npm. npm Trusted Publishing records provenance linking the
registry package to the source repository and workflow identity. This proves
publication identity only; it is not evidence that the product behavior is
correct, secure, or accepted by a customer.
Local checks
npm run release:verify
npm run release:governance:test
npm run release:package-smoke
npm run release:public-canary -- --version latest
These checks are optional maintainer diagnostics. They are not part of the tag publication workflow.
Recovery
- Tag mismatch: delete the unpushed local tag, prepare the correct package version, and tag again.
- Failure before npm publish: fix the source and move the tag only if it has not been published or consumed.
- Failure after npm publish: do not move or reuse the tag; prepare a patch release.
- Manual acceptance failure after publication: keep the immutable tag and npm version, fix the defect, and publish a new patch version.