## The decision needed `npm.publish.latest-tag-semver` currently fails Artifact Registry, and the reason S06 gives for the row is a factual claim about npmjs.org that now looks wrong. Three things need deciding together, because each one's answer changes the others: 1. Does the claim "npmjs.org implements this" stay, get a source, or go? 2. Does the row keep its verdict, change it, or get withdrawn? 3. If the protection lives in the npm CLI rather than the registry, should the row drive the CLI instead of the HTTP client? Until they are answered, "Artifact Registry is non-conformant on this row" is not a claim the suite can support. ## The rule and where its authority comes from S06 §Operation: Publish: > Server-side reconciliation of `dist-tags.latest` across publishes is > semver-aware: the first publish for a package sets `dist-tags.latest`; a > subsequent publish whose version is higher than the current `latest` MUST > update it; a subsequent publish whose version is lower than the current > `latest` MUST NOT regress it (`npm.publish.latest-tag-semver`). > Source: catalog-bound; `docs/catalog/npm.md` row > `npm.publish.latest-tag-semver` ("Publish lower semver → `latest` must NOT > update") is the binding assertion. > **npmjs.org implements this**; GitLab Package Registry's last-write-wins > overlay does not, and is non-conformant per the catalog row. The source chain is circular. S06 sources the rule to the catalog row, and the catalog row states the assertion with no external citation of its own: | Row | Behavior | Kind | Priority | Status | Assertions | | --- | -------- | ---- | -------- | ------ | ---------- | | `npm.publish.latest-tag-semver` | `latest` tag auto-assignment and semver-aware update | HTTP | critical | done | First publish → `latest` points to it. Publish higher semver → `latest` updates. Publish lower semver → `latest` must NOT update. | So "npmjs.org implements this" is the load-bearing sentence, and nothing in either document backs it. ## What Artifact Registry decided, and why [AR#1125](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1125) was closed 2026-09-09 as **working as intended**, not as fixed. Three notes on it, in order: - 2026-09-03: "publish writes whatever `dist-tags` the client sends, bound to the version being published. S11 specifies exactly this ('a passive registry for dist-tags'), so the code matches the spec. **What npmjs does: the same thing on the server.** The protection does exist, but npm put it in the CLI, not the registry. npm RFC 0007 landed in npm CLI 11.0.0 as a breaking change." - 2026-09-04: "I think we should stay passive for this now. It's better to follow what npm's public registry does as the standard." - 2026-09-07: "Tim confirmed we should stay passive here and match npm's public registry, which behaves the same way." So AR conforms to AR's own spec, deliberately, after a product call. Two specs disagree about the same behaviour, and the tiebreaker both of them reach for is npmjs.org's actual server behaviour. ## What the external evidence says The npm-side protection is in the CLI. [npm/cli!7939](https://github.com/npm/cli/pull/7939), "feat!: no implicit latest tag on publish when latest > version", shipped in npm v11: > Upon publishing, in order to apply a default 'latest' dist tag, **the > command** now retrieves all prior versions of the package. It will require > that the version you're trying to publish is above the latest semver > version in the registry, not including pre-release tags. The CLI fetches prior versions and does the comparison itself. Two details make this more than incidental: - It shipped as a **breaking** change. A registry that already refused the regression would make the CLI change unnecessary, and harmless rather than breaking. - The PR discussion notes it could make [safe-publish-latest](https://github.com/ljharb/safe-publish-latest) obsolete. That package exists because the registry does not protect `latest`. ## What is not established **Whether npmjs.org's server refuses the regression.** Proving it needs a low version published to npmjs.org, which nobody should do to settle this. Both guards could in principle coexist. The evidence above is strong but circumstantial, so this issue records it as unsettled rather than as AR being right. ## Why the row cannot simply be kept The row is HTTP-only. `pkg/conformance/npm/publish_tags.go`: > latest-tag-semver (HTTP-only): default-tag publishes in ascending then > descending order; dist-tags.latest must follow ascending semver only It drives the protocol client directly, so it bypasses any CLI-side guard entirely. If the protection is the CLI's, then **npmjs.org itself would fail this row**, and the suite's own reference implementation being non-conformant is a signal the row is measuring the wrong layer. That points at making it a driver row, the way `npm.publish.custom-tag` already is. One wrinkle to size before choosing that: the guard is npm 11, and the 2026-09-15 staging run used npm 10.9.2, so a driver row would not exercise it on the current toolchain. ## Measurement Artifact Registry staging, slug `ar-registry`, repository `conformance-npm`, registry-conformance `9b7bd98b`, run `1d383eea80ad4292`, 2026-09-15T12:20Z. Read directly off the fixture the run left behind, not through the suite's verdict: ``` GET /ar-registry/npm/conformance-npm/@conformance%2Fconformance-1d383eea80ad4292-latest-tag-semver 200 dist-tags={"latest":"1.5.0"} versions=["1.0.0","1.5.0","2.0.0"] ``` Three versions published ascending then descending; `latest` tracks the last publish rather than the highest semver. Exactly the behaviour AR#1125 describes and decided to keep. ## Scope Whatever is decided, it lands as a spec amendment plus a catalog row change, not as an edit in passing. The row is `critical` and `done`, and its verdict currently marks both Artifact Registry and GitLab Package Registry non-conformant. Recorded as S5 on the 2026-09-15 staging run section of #54.