publish-npm attempts a publish without asking whether the version already exists

[beyondnetPeru]

publish-npm in .github/workflows/sdk-cli-release.yml runs:

- name: Publish to NPM
  run: npm publish --provenance --access public

with no check that the version is not already on the registry. Any re-run of the workflow
against a tag whose version was already published — a retry after an unrelated flake, a
workflow_dispatch with release_tag set, a re-pushed tag — fails at that step with npm's
"You cannot publish over the previously published versions".

The failure then reaches failure-notification, which files a "Release Pipeline Failed"
issue. So a harmless re-run manufactures a bug report.

The same repository already solved this, two workflows over

.github/workflows/npm-release.yml resolves a plan first, via
.harness/scripts/release/plan-npm-release.mjs, which asks the registry whether each exact
version exists and skips the ones that do:

1. @beyondnet/evolith-core-domain   1.3.0   already on registry
7. @beyondnet/evolith-mcp           1.3.1   WILL PUBLISH
→ 1 of 8 package(s) would be published

That planner is idempotent by design and has a self-test
(.harness/scripts/release/plan-npm-release.test.mjs). sdk-cli-release.yml predates it and
never adopted it.

The fix

Before publishing, ask the registry. Either reuse the planner, or inline the same question:

VERSION=$(node -p "require('./src/sdk/cli/package.json').version")
if npm view "@beyondnet/evolith-cli@${VERSION}" version >/dev/null 2>&1; then
  echo "@beyondnet/evolith-cli@${VERSION} is already on the registry — nothing to publish."
  exit 0
fi
npm publish --provenance --access public

Reusing the planner is the better answer if it fits: two implementations of "is this version
published" will drift, and this repository has been bitten by that shape before.

What NOT to do

Do not wrap the publish in continue-on-error or || true. That would hide a real publish
failure — a bad token, a registry outage, a rejected provenance attestation — which is a much
worse outcome than a noisy issue. The point is to not attempt a publish that cannot succeed,
not to ignore one that failed.

Done when

Re-running sdk-cli-release.yml against an already-published version completes green, prints
that it skipped, and files no issue. Verify with a workflow_dispatch using
release_tag: v1.3.0, which is published today.

Related

Found while fixing #562, which is the other half of this noise: the SBOM step failed on every
tag push for an unrelated reason and filed the same kind of issue. #492, #552 and #553 are the
accumulated result.

---

What is not your problem

This repository runs a large number of governance checks against itself. If one goes red on
your PR for a reason unrelated to your change, say so in a comment and a maintainer will sort
it out — do not try to fix the harness to get green. Specifically not yours: anything under
.harness/scripts/ci/ reporting on the gap board, ADR registry, maturity or coverage floors;
Governance guards; and bilingual findings on documents outside the sixteen-file entry
surface.

New here? CONTRIBUTING.md has the setup. Short version: fork,
npm install, npm run build. Commits need a Signed-off-by line — git commit -s, and a
hook adds it if you forget.