release: 2.0.0, one major with the client SDKs

[dkijania]

Release 2.0.0: an alignment major. No breaking change against 1.0.0.

Why 2.0.0 and not 1.1.0

By the rules in docs/versioning.md, the changes since v1.0.0 would be a minor. We take a major anyway, for these reasons:

1. The SDKs need 2.0. mina-archive-sdk-js/go/rust have breaking changes to their own API since their 1.0.x releases. Examples: Rust #[non_exhaustive] on all output structs, new Error variants and i32 builders; Go DateTimeGte/DateTimeLt as *time.Time. These changes are what make future server minors non-breaking for SDK users, so we do not revert them.
2. One rule instead of a lookup table. If the versions are not aligned, users must remember that "SDK 2.x works with server 1.1". With one shared major, the rule is: same major means compatible. A higher server minor only adds features that the SDK does not wrap yet.
3. Semver allows it. Semver forbids a breaking change without a major. It does not forbid a major without a breaking change. The only cost is one upgrade decision for operators, and the upgrade notes cover it.
4. The cost is low now. npm never received 1.0.x (it has only 0.0.6), so npm users see 0.0.6 → 2.0.0. schemaVersion never shipped in a tag. The Go SDK module path is already /v2.

Changes

• package.json 2.0.0, SCHEMA_VERSION "2.0".
• docs/versioning.md:
  • "One major across the server and the SDKs";
  • MAJOR now also covers an alignment major;
  • "Upgrading to 2.0.0" (from 0.0.6 and from 1.0.0);
  • tag-based releases (do not run npm version on main).
• docs/runbook.md: you can roll back to any image from 1.0.0 or later.

Compatibility checked

• Schema 2.0 against v1.0.0: graphql-inspector reports only safe changes (additive, plus output-only [T] → [T!] from schema: declare non-null elements on eight list positions #244).
• The integration suites of the published SDKs (Go v1.0.0, JS v1.0.1, Rust v1.0.1) and of the SDK 2.0 branches (js#30, go#30, rust#29) pass 5/5 against a build of this branch.

Before tagging v2.0.0

• Fix npm publish auth. The v1.0.0 publish failed with ENEEDAUTH (run 33921445418).
• Merge fix(tests): stop the NetworkState height check racing block production #246 (height race in tests/resolvers.test.ts).
• Tag the merge commit as described in "Releasing". Then merge the SDK PRs and tag them v2.0.0.

Draft release notes

2.0.0 is an alignment major: no breaking change against 1.0.0. The server, its schema and the client SDKs now share one major version, so the same major means compatible. See Upgrading to 2.0.0. npm users come from 0.0.6, so they must read both lists.

🤖 Generated with Claude Code

https://claude.ai/code/session_01StPY7C6STPhukrgZvVhqZX

[SanabriaRusso]

The code change is fine; the requested changes are to the release docs and the merge order.

• Schema 2.0 against v1.0.0. The changes are additive, plus output-only [T]→[T!] from schema: declare non-null elements on eight list positions #244. graphql-inspector agrees, so no expected-breaking-change label is needed. zkappCommands stays off unless ENABLE_ZKAPP_COMMANDS_QUERY=true.
• schemaVersion. It never shipped in a tag, so the "1.1"→"2.0" move is invisible to deployed consumers.
• Build and packaging. npm run build && npm run test:unit pass. The bin shebang, files and engines are intact.

There are four issues to fix. They are about the release docs and merge order, which are what operators read for a major release.

1. Merge order and red CI

Problem. Run-Tests (24) fails at tests/resolvers.test.ts:350 (9 !== 10). That is the race where the daemon is one block ahead of the archive, and #246 fixes it; this PR doesn't cause it. The PR is still the release commit, though, and it is stacked on #244 (base schema/non-null-list-elements).

Repro.

gh pr checks 245
gh run view 37622204939 --log-failed | grep -A8 "failing tests"

Solution. Merge in this order:

1. schema: declare non-null elements on eight list positions #244 merges (approved).
2. fix(tests): stop the NetworkState height check racing block production #246 merges.
3. Rebase this PR onto main and retarget its base to main. If schema: declare non-null elements on eight list positions #244 was squash-merged, drop 9cf560e.
4. Once CI is green, merge this PR.
5. Tag v2.0.0 only after the ENEEDAUTH publish failure is fixed, as the description already says.

#233 (arm64) is independent. Land it first only if the 2.0.0 images should be multi-arch.

Acceptance criteria.

• gh pr view 245 --json baseRefName shows main.
• gh pr checks 245 is all green, including both Run-Tests (22) and Run-Tests (24).
• git log origin/main.. shows only release: 2.0.0.

2. The migration section is stale: npm users go from 0.0.6 straight to 2.0.0

Problem. "Migrating from npm 0.0.6" in docs/versioning.md (around line 165) says npm consumers "should treat 1.0.0 as an upgrade from 0.0.6". It also says "the 1.0.x container image runs Node 22". But npm still has only 0.0.6: 1.0.0 failed to publish and v1.0.1 was never tagged. So the first npm release after 0.0.6 will be 2.0.0.

Nothing in the repo lists what changed for operators between v1.0.0 and 2.0.0:

• the license moves from ISC to Apache-2.0;
• the image moves from Node 22 to Node 24;
• three new env vars;
• ENABLED_QUERIES accepts new names;
• schemaVersion is always served;
• eight list elements become non-null.

Repro.

npm view @o1-labs/mina-archive-node-graphql versions   # ["0.0.6"] or "0.0.6"
git diff v1.0.0..HEAD --stat -- src Dockerfile package.json .github

Solution.

-## Migrating from npm `0.0.6`
+## Upgrading to 2.0.0

-Tags `0.0.7` through `0.0.9` existed in git but were not published to npm, so
-npm consumers should treat `1.0.0` as an upgrade from `0.0.6`. Review these
-operator-visible changes before rolling out:
+npm never received 1.0.x (only `0.0.6` is published), so npm consumers go
+straight from `0.0.6` to `2.0.0`: apply both lists below. Container users on
+1.0.0 need only the second.
+
+### From `0.0.6` (changes that shipped in git tag 1.0.0)

 - Browser deployments must set `CORS_ORIGIN` deliberately.
 - Rate limiting is enabled and depends on the correct `TRUST_PROXY` hop count.
-- The supported Node.js runtime moves to Node 22.12 (`engines`); the 1.0.x
-  container image runs Node 22.
+- The supported Node.js runtime moves to Node 22.12 (`engines`).
 - Boolean environment variables reject junk values instead of relying on
   JavaScript truthiness.
 - `actions` result semantics include correctness fixes called out in the release
   notes.
+
+### From 1.0.0
+
+No query that worked against 1.0.0 changes its result shape. Review:
+
+- The container image runs Node 24 (LTS). `engines` is unchanged (`>=22.12.0`).
+- License: Apache-2.0 (was ISC).
+- New query `schemaVersion`, always served, even when `ENABLED_QUERIES`
+  restricts the data queries.
+- New query `zkappCommands`, off unless `ENABLE_ZKAPP_COMMANDS_QUERY=true`;
+  bounded by `ZKAPP_COMMAND_RANGE_SIZE` (1000) and
+  `ZKAPP_COMMAND_ACCOUNT_UPDATE_LIMIT` (5000).
+- `ENABLED_QUERIES` now accepts `verificationKeyUpdates` and `zkappCommands`.
+- Eight list positions declare non-null elements (`[T]` → `[T!]`). Responses
+  are unchanged; codegen'd clients see stricter element types.

Also, in docs/runbook.md:107, change "Roll back within the 1.0.x line" to "Roll back to any 1.0.0 or later image". Rolling back from 2.0.0 to 1.0.0 is safe: the service is stateless and /readiness exists in 1.0.0.

Acceptance criteria.

• grep -n "1.0.x container\|treat .1.0.0. as an upgrade" docs/versioning.md returns nothing.
• Every operator-visible item in git diff v1.0.0..HEAD -- src/config.ts src/server/server.ts src/envionment.d.ts Dockerfile package.json appears in the "From 1.0.0" list.
• The v2.0.0 GitHub release notes link to this section.

3. Following the documented release steps would tag v3.0.0

Problem. "Releasing" (around line 130) says to run npm version <major|minor|patch>. The exception for bumping package.json directly is scoped to "the initial 1.0.0 release only". This PR already sets package.json to 2.0.0, so a maintainer who follows the doc after merge gets 3.0.0/v3.0.0. The same drift already happened once: #234 bumped to 1.0.1, and v1.0.1 was never tagged.

Repro, at this PR's head:

npm version major --no-git-tag-version && grep '"version"' package.json   # "3.0.0"

Solution.

-Releases are cut from `main` by a maintainer:
-
-```sh
-npm version <major|minor|patch>   # bumps package.json + creates a git tag
-git push --follow-tags            # tag push triggers the publish pipeline
-```
-
-For the initial `1.0.0` release only, `package.json` on `main` already carries
-the version to release. Tag it directly (`git tag v1.0.0 && git push
---follow-tags`) rather than running `npm version`, which would bump past it.
+Releases are cut in two steps:
+
+1. A release PR bumps `package.json`/`package-lock.json` (and
+   `src/schema-version.ts` if the schema moved) and merges to `main`.
+2. A maintainer tags that merge commit; the tag push triggers the publish
+   pipeline:
+
+   ```sh
+   git tag v$(node -p "require('./package.json').version") <merge-sha>
+   git push origin v<version>
+   ```
+
+Do not run `npm version` on `main`: `package.json` already carries the version
+being released, and `npm version` would bump past it.

Acceptance criteria.

• grep -n "npm version <major" docs/versioning.md returns nothing.
• After merge and tagging, git describe --tags --exact-match <merge-sha> prints v2.0.0.
• The publish run uploads 2.0.0.

4. The doc still defines MAJOR as "backwards-incompatible"

Problem. The new section says "Semver allows a major without a break". But two older lines in docs/versioning.md were not updated:

• Line 11 still defines MAJOR as "a backwards-incompatible change … Consumers may need to update queries or config".
• Line 203 says the schema's "MAJOR [moves] on one that can break a client".

The released SDK 1.0.1 README also says "A breaking schema change moves both" majors. So a reader who sees schemaVersion: "2.0" will conclude something broke, which is the opposite of "A 1.0.x client keeps working against it".

Solution.

 - **MAJOR** — a backwards-incompatible change to the public contract (see
-  "Breaking changes" below). Consumers may need to update queries or config.
+  "Breaking changes" below), or an alignment major shared with the client SDKs
+  (see "One major across the server and the SDKs"). Release notes say which;
+  an alignment major needs no consumer action.

-  change, its MAJOR on one that can break a client.
+  change, its MAJOR on one that can break a client or on an alignment major
+  shared with the SDKs.

Acceptance criteria.

• grep -n "backwards-incompatible change to the public contract" docs/versioning.md shows the amended bullet.
• The wording matches the doc comment in src/schema-version.ts.
• The 2.0.0 release notes say "alignment major — no breaking change against 1.0".

[SanabriaRusso]

Re-review at 592f6e1: issue 1 is resolved; issues 2–4 are still open.

The push rebased the branch onto main and dropped 9cf560e. The release commit's content is unchanged: it was authored at 14:29 +02:00, before my previous comment. So the three doc issues from that comment still apply. The repro steps below run against the current head.

What I verified

• Base is main. git log origin/main.. shows only release: 2.0.0.
• gh pr checks 245 is all green, including Run-Tests (22) and Run-Tests (24).
• Locally, npm ci && npm run build && npm run test:unit passes: 25 files, 0 failures.
• Backwards compatibility: no new behavior change. zkappCommands stays behind ENABLE_ZKAPP_COMMANDS_QUERY (default off).
• Merge-order note: fix(tests): stop the NetworkState height check racing block production #246 is still open. It doesn't block this PR, but merge it before or right after this one so main stops flaking on the height race.

2. "Migrating from npm 0.0.6" is still stale

Problem. docs/versioning.md:162-175 still tells npm users to "treat 1.0.0 as an upgrade from 0.0.6". It also still says "the 1.0.x container image runs Node 22". npm has only 0.0.6, so the first npm release after it will be 2.0.0. Nothing lists the operator-visible changes since v1.0.0. docs/runbook.md:107 still says "Roll back within the 1.0.x line".

Repro.

grep -n "1.0.x container\|treat .1.0.0. as an upgrade" docs/versioning.md
grep -n "1.0.x line" docs/runbook.md
git diff v1.0.0..HEAD -- src/config.ts src/server/server.ts src/envionment.d.ts Dockerfile package.json

Solution. This is the diff from my previous comment, plus two items that git diff v1.0.0..HEAD turns up:

• arm64 images (ci: publish the container for linux/arm64 as well as linux/amd64 #233, now on main);
• ENABLED_QUERIES tolerating schemaVersion. 1.0.0 also failed startup on verificationKeyUpdates, so accepting it is a fix worth saying.

-## Migrating from npm `0.0.6`
+## Upgrading to 2.0.0

-Tags `0.0.7` through `0.0.9` existed in git but were not published to npm, so
-npm consumers should treat `1.0.0` as an upgrade from `0.0.6`. Review these
-operator-visible changes before rolling out:
+npm never received 1.0.x (only `0.0.6` is published), so npm consumers go
+straight from `0.0.6` to `2.0.0`: apply both lists below. Container users on
+1.0.0 need only the second.
+
+### From `0.0.6` (changes that shipped in git tag 1.0.0)

 - Browser deployments must set `CORS_ORIGIN` deliberately.
 - Rate limiting is enabled and depends on the correct `TRUST_PROXY` hop count.
-- The supported Node.js runtime moves to Node 22.12 (`engines`); the 1.0.x
-  container image runs Node 22.
+- The supported Node.js runtime moves to Node 22.12 (`engines`).
 - Boolean environment variables reject junk values instead of relying on
   JavaScript truthiness.
 - `actions` result semantics include correctness fixes called out in the release
   notes.
+
+### From 1.0.0
+
+No query that worked against 1.0.0 changes its result shape. Review:
+
+- The container image runs Node 24 (LTS) and is published for linux/amd64 and
+  linux/arm64. `engines` is unchanged (`>=22.12.0`).
+- License: Apache-2.0 (was ISC).
+- New query `schemaVersion`, always served, even when `ENABLED_QUERIES`
+  restricts the data queries. Listing it in `ENABLED_QUERIES` is accepted.
+- New query `zkappCommands`, off unless `ENABLE_ZKAPP_COMMANDS_QUERY=true`;
+  bounded by `ZKAPP_COMMAND_RANGE_SIZE` (1000) and
+  `ZKAPP_COMMAND_ACCOUNT_UPDATE_LIMIT` (5000).
+- `ENABLED_QUERIES` now accepts `verificationKeyUpdates` (1.0.0 failed startup
+  on it) and `zkappCommands`.
+- Eight list positions declare non-null elements (`[T]` → `[T!]`). Responses
+  are unchanged; codegen'd clients see stricter element types.

-- Roll back within the 1.0.x line — the service is stateless and carries no
+- Roll back to any 1.0.0 or later image — the service is stateless and carries no

Also fix one detail in the new "Its changes against 1.0" list: change (`[T]!` → `[T!]!`) to (`[T]` → `[T!]`). eventData and actionData keep a nullable outer list.

Acceptance criteria.

• grep -n "1.0.x container\|treat .1.0.0. as an upgrade" docs/versioning.md returns nothing.
• grep -n "1.0.x line" docs/runbook.md returns nothing.
• Every operator-visible item in the git diff v1.0.0..HEAD above appears under "From 1.0.0": Node 24, arm64, Apache-2.0, ENABLE_ZKAPP_COMMANDS_QUERY, the two ZKAPP_COMMAND_* limits, and the ENABLED_QUERIES names.
• The v2.0.0 GitHub release notes link to this section.

3. Following "Releasing" would still tag v3.0.0

Problem. docs/versioning.md:130 still says npm version <major|minor|patch>. The "tag it directly" exception is still scoped to "the initial 1.0.0 release only". package.json is already 2.0.0, so following the doc after merge produces 3.0.0/v3.0.0.

Repro, at 592f6e1:

grep -n "npm version <major" docs/versioning.md
npm version major --no-git-tag-version && grep '"version"' package.json   # "3.0.0"

Solution. Use the same diff as before:

-Releases are cut from `main` by a maintainer:
-
-```sh
-npm version <major|minor|patch>   # bumps package.json + creates a git tag
-git push --follow-tags            # tag push triggers the publish pipeline
-```
-
-For the initial `1.0.0` release only, `package.json` on `main` already carries
-the version to release. Tag it directly (`git tag v1.0.0 && git push
---follow-tags`) rather than running `npm version`, which would bump past it.
+Releases are cut in two steps:
+
+1. A release PR bumps `package.json`/`package-lock.json` (and
+   `src/schema-version.ts` if the schema moved) and merges to `main`.
+2. A maintainer tags that merge commit; the tag push triggers the publish
+   pipeline:
+
+   ```sh
+   git tag v$(node -p "require('./package.json').version") <merge-sha>
+   git push origin v<version>
+   ```
+
+Do not run `npm version` on `main`: `package.json` already carries the version
+being released, and `npm version` would bump past it.

Acceptance criteria.

• grep -n "npm version <major" docs/versioning.md returns nothing.
• After merge and tagging, git describe --tags --exact-match <merge-sha> prints v2.0.0.
• The publish run uploads 2.0.0.

4. versioning.md still defines MAJOR as "backwards-incompatible"

Problem. src/schema-version.ts was amended, but docs/versioning.md was not:

• Line 11 still says MAJOR is "a backwards-incompatible change … Consumers may need to update queries or config".
• Line 203 still says the schema's "MAJOR [moves] on one that can break a client".
• Line 205 says the package and schema versions "move independently". For the MAJOR, that now contradicts the new "share one MAJOR" section.

A reader who sees 2.0.0 or schemaVersion: "2.0" will conclude something broke.

Repro.

grep -n -A1 "backwards-incompatible change to the public contract" docs/versioning.md
grep -n "can break a client\.\|move independently" docs/versioning.md

Solution.

 - **MAJOR** — a backwards-incompatible change to the public contract (see
-  "Breaking changes" below). Consumers may need to update queries or config.
+  "Breaking changes" below), or an alignment major shared with the client SDKs
+  (see "One major across the server and the SDKs"). Release notes say which;
+  an alignment major needs no consumer action.

-  change, its MAJOR on one that can break a client.
+  change, its MAJOR on one that can break a client or on an alignment major
+  shared with the SDKs.

-The two move independently, and that is deliberate.
+Their MINOR and PATCH move independently, and that is deliberate; the MAJOR is
+shared (see "One major across the server and the SDKs").

Acceptance criteria.

• grep -n -A3 "backwards-incompatible change to the public contract" docs/versioning.md shows the "alignment major" wording.
• The wording agrees with the doc comment in src/schema-version.ts.
• The 2.0.0 release notes say "alignment major — no breaking change against 1.0".

[dkijania]

Fixed in d233bff. Thanks for the detailed review.

• 2: "Migrating from npm 0.0.6" is now "Upgrading to 2.0.0", with your two lists. It includes arm64, the ENABLED_QUERIES items, and [T] → [T!] in the schema list. The runbook now says you can roll back to any image from 1.0.0 or later. I checked each item against git diff v1.0.0..HEAD: the two ZKAPP_COMMAND_* defaults are 1000 and 5000, and the v1.0.0 KNOWN_QUERIES did not include verificationKeyUpdates.
• 3: "Releasing" now has two steps: a release PR bumps package.json, then a maintainer tags the merge commit. Do not run npm version on main.
• 4: MAJOR now also covers an alignment major. The schema MAJOR line and the "move independently" paragraph now say that only MINOR and PATCH are independent.

All your acceptance greps return nothing, except the amended MAJOR bullet. The PR description now explains why this is 2.0.0 and includes draft release notes that link to the upgrade section.

I did not reformat the table in docs/runbook.md: it already fails Prettier on main (#212), and that would add unrelated changes to this PR.

[SanabriaRusso]

Re-review at d233bff: issues 2 and 4 are resolved. Issue 3 is fixed in docs/versioning.md, but README.md still carries the old release steps.

What I verified

• Issue 2 (upgrade notes). "Upgrading to 2.0.0" has both lists. I checked "From 1.0.0" against git diff v1.0.0..d233bff -- src/config.ts src/envionment.d.ts Dockerfile package.json. It covers Node 24, amd64/arm64, Apache-2.0, ENABLE_ZKAPP_COMMANDS_QUERY, both ZKAPP_COMMAND_* limits (1000 and 5000), the new ENABLED_QUERIES names and [T] → [T!]. Nothing is missing. docs/runbook.md now says to roll back to any image from 1.0.0 or later.
• Issue 4 (MAJOR wording). The MAJOR bullet, the schema MAJOR line and the "move independently" paragraph all describe the alignment major now. They agree with "One major across the server and the SDKs".
• Issue 3 (release steps), in docs/versioning.md. The two-step flow is correct. In a scratch clone at d233bff, node -p "require('./package.json').version" prints 2.0.0, so the documented tag command produces v2.0.0.
• Release notes. The draft in the PR description links to #upgrading-to-200 and says "alignment major".
• CI. All checks are green at d233bff.

1. README.md still says to run npm version on main, which would tag v3.0.0

Description. The "Releasing" section at README.md:106-114 was not part of this PR's changes and still says:

Normal releases after `1.0.0` are cut with:

npm version <major|minor|patch>
git push --follow-tags

For the initial `1.0.0` tag and current npm trusted-publishing caveat, see …

This now contradicts docs/versioning.md ("Do not run npm version on main"). The README is the landing page, so a maintainer will most likely find it first. package.json is already 2.0.0, so following the README after merge bumps to 3.0.0 and creates v3.0.0 locally.

git push --follow-tags is not atomic. If branch protection rejects the push to main, the tag ref can still go through. build.yaml then runs on v* and publishes the npm package from package.json and the images from the tag name. It does not check that the tagged commit is on main. The "initial 1.0.0 tag" pointer is also stale.

This one is my miss as well. My acceptance grep for issue 3 covered only docs/versioning.md.

Reproduce, at d233bff:

git grep -n "npm version" -- '*.md'
# README.md:109:npm version <major|minor|patch>          <- contradicts versioning.md:141
# docs/versioning.md:141:Do not run `npm version` on `main` ...

# in a scratch clone (does not touch your checkout):
git clone -q https://github.com/o1-labs/Archive-Node-API /tmp/rel && cd /tmp/rel
git fetch -q origin pull/245/head && git checkout -q FETCH_HEAD
npm version major --no-git-tag-version      # prints v3.0.0

2. Solution

AGENTS.md says the README should link to the docs rather than repeat them. So replace the duplicated steps with a pointer:

 Tagged commits trigger CI to publish:
 
 - npm (public): [`@o1-labs/mina-archive-node-graphql`](https://www.npmjs.com/package/@o1-labs/mina-archive-node-graphql)
 - Docker (GHCR): `ghcr.io/o1-labs/archive-node-api`
 
-Normal releases after `1.0.0` are cut with:
-
-```sh
-npm version <major|minor|patch>
-git push --follow-tags
-```
-
-For the initial `1.0.0` tag and current npm trusted-publishing caveat, see
-the [versioning & schema stability policy](./docs/versioning.md#releasing).
+A release PR bumps `package.json`, then a maintainer tags its merge commit. Do
+not run `npm version` on `main`: `package.json` already carries the version
+being released. Steps and the npm trusted-publishing caveat are in the
+[versioning & schema stability policy](./docs/versioning.md#releasing).

Optional, not blocking: in docs/versioning.md step 2, node -p "require('./package.json').version" reads the working tree, not <merge-sha>. Adding "run from a checkout of <merge-sha>" (or git checkout <merge-sha> before the command) makes sure the tag and the published version can't disagree.

How to validate the change

git grep -n "npm version" -- '*.md'
# expected: only docs/versioning.md "Do not run `npm version` on `main`" lines
git grep -n "npm version <major\|initial .1.0.0. tag" -- README.md docs
# expected: no output

Then open the README on the PR branch and click the link. It must land on the "Releasing" heading of docs/versioning.md.

3. Definition of done and testing methodology

Done when:

• git grep -n "npm version <major" -- README.md docs returns nothing.
• git grep -n "npm version" -- '*.md' matches only the "Do not run npm version on main" sentence in docs/versioning.md.
• README "Releasing" links to docs/versioning.md#releasing and does not repeat the steps.
• The diff touches only README.md (plus docs/versioning.md if you take the optional note), and CI stays green.

Testing methodology. This is docs-only, so no code test applies. Do a dry run of the documented release in a scratch clone of the PR head, not a real tag:

1. git clone the repo into a scratch directory and check out the PR head.
2. Follow README → docs/versioning.md#releasing step 2 literally, with <merge-sha> = HEAD, but do not push.
3. git tag --points-at HEAD must print v2.0.0, and node -p "require('./package.json').version" must print 2.0.0.
4. Delete the scratch clone.

Once that is in, I'll approve. Everything else in this PR is ready.

[dkijania]

Fixed in 07f1786.

• README.md "Releasing" now uses your text. It links to docs/versioning.md#releasing and no longer repeats the steps or the stale "initial 1.0.0 tag" pointer.
• I also took the optional note. Step 2 in docs/versioning.md now runs git checkout <merge-sha> before git tag. The tag and the push both read package.json from that checkout, so the tag and the published version cannot disagree.

Validation

• git grep -n "npm version <major\|initial .1.0.0. tag" -- README.md docs: no output.
• git grep -n "npm version" -- '*.md': only the "Do not run npm version on main" sentences. One is in docs/versioning.md, and one is in the README text you proposed.
• Dry run in a scratch clone of the PR head, with no push: git tag --points-at HEAD prints v2.0.0, and package.json gives 2.0.0.

README.md already fails prettier --check on main (#212). This change does not add to that.

[SanabriaRusso]

Approved at 07f1786. All four issues from the earlier rounds are resolved.

What I verified

• README.md "Releasing" no longer repeats the steps. It links to docs/versioning.md#releasing, and the stale "initial 1.0.0 tag" pointer is gone.
• git grep -n "npm version" -- '*.md' now matches only the "Do not run npm version on main" sentences (README.md:107, docs/versioning.md:143-144).
• Release dry run in a scratch clone at 07f1786, without pushing. Following docs/versioning.md step 2: node -p "require('./package.json').version" prints 2.0.0, and git tag --points-at HEAD prints v2.0.0. Before this PR, the README steps gave v3.0.0.
• Step 2 now runs git checkout <merge-sha> first, so the tag and the push both read the package.json at the merge commit.
• CI is all green at 07f1786.

Before merging and tagging

• Update the branch. GitHub reports it as BEHIND: main gained #246 (d53dfbf). git merge-tree shows no conflict, and the two PRs touch different files. Use "Update branch", wait for CI to go green, then squash-merge.
• Wait to tag v2.0.0. As the description says, tag only after the npm ENEEDAUTH publish failure is fixed. Then tag the squash merge commit as in docs/versioning.md#releasing, and use the draft notes from the description for the GitHub release.