chore(release): bump version set to 10.0.10

[Jurij89]

Summary

Release-prep bump for 10.0.10, per RELEASE_PROCESS.md §3. Moves the root package and all 20 packages/* workspaces to 10.0.10 in lockstep, adds the CHANGELOG.md entry, declares the new Node runtime floor, and repairs §6c/§10.

Last gate before the comprehensive devnet run (§4) and the signed tag (§5). All 10.0.10 code landed via #1983; the only product-code change here is engines metadata.

Changes

• Version set → 10.0.10 (21 package.json files: root + 20 workspaces, including the two private ones so the publish graph stays aligned). Internal deps use workspace:*, so a partial bump would ship a skewed dependency graph.
• CHANGELOG.md: new ## [10.0.10] section. The existing [Unreleased] SWM 4 MiB bullet moves in verbatim, leaving [Unreleased] empty.
• engines.node on @origintrail-official/dkg and @origintrail-official/dkg-agent (see below).
• RELEASE_PROCESS.md §6c and §10: single-sourced release notes; upgrade guidance scaled to the migration.

Version-only for the bump itself: pnpm-lock.yaml is untouched, so pnpm install --frozen-lockfile stays valid.

Node runtime floor

10.0.10 makes node:sqlite a hard startup dependency — prepareRfc64PersistenceV1() is awaited in DKGAgent.start() outside the surrounding try/catch, and the daemon always passes a dataDir.

Declared range, on both publishable packages that need it:

>=22.13.0 <23.0.0 || >=23.4.0

node:sqlite ships from Node 22.5.0 but stays behind --experimental-sqlite until 22.13.0 / 23.4.0 (Node version history), and the daemon builds its command from process.execArgv (daemon-entrypoint.ts:52-58) and never passes the flag. So 22.5–22.12 and 23.0–23.3 install cleanly and then fail to boot — which is why a bare >=22.5.0 or >=22.13.0 would both have been wrong.

packages/agent is the only package referencing node:sqlite in src (node-ui uses the native better-sqlite3 dep), so cli + agent is the complete set.

engines is declarative only, and the ### Known issues entry says so. Verified both ways: pnpm WARN Unsupported engine + exit 0, npm EBADENGINE + exit 0; both hard-fail only under engine-strict, which this repo does not set.

Enforcement is deferred to 10.0.11 — #1985, by maintainer decision. The gap that matters: blue-green auto-update gates activation on existsSync of build output (auto-update.ts:1407-1418 / :578-598) and never proves the slot boots, so an unsupported runtime can activate and then restart-loop with a message the operator never sees (dkg start detaches with stdio: ignore). #1985 covers a capability probe, wiring at dkg start / daemon / both swapSlot sites, a node-runtime doctor check in UPDATE_PREFLIGHT_CHECKS, and a release-metadata guard against drift.

§6c / §10 change — why

§10 required a standalone docs/UPGRADE_<PRIOR>_TO_<NEW>.md cross-linked from docs/RELEASE.md. That link had been dangling since #1123 moved the file, so §10 was literally unsatisfiable — it just never fired, because no release since has been builder-impacting (10.0.8 was fixes-only; 10.0.9's sole ### Changed entry was an internal store-boundary refactor). No release in the 10.0.x line has ever shipped an upgrade guide; the only ones that exist are rc.11/rc.12/rc.13.

1. Scales the artifact to the migration. Small migrations (this release: 4 discrete changes) → an ### Upgrading from <PRIOR> matrix inside the CHANGELOG section. Standalone files are reserved for mass renames and ABI/economic changes.
2. Gives long-form notes a real home: docs/release-notes/<version>.md, one file per release — shipped notes are immutable, per-release files stay linkable, and they don't conflict on every release.
3. Drops the citation of docs/archive/internal/RELEASE.md, which is the superseded DKG V9 runbook (101 lines, replaced by this 248-line document). §10 now states that archived V9-era material is history only.
4. Single-sources the release notes. §6c now owns Release note generation and states the CHANGELOG section is copied verbatim with only fixed metadata added; §10 defines only when guidance is required and where it is written.

Also records the actual publishing rule: GitBook builds navigation from docs/SUMMARY.md, so a docs/ file absent from SUMMARY.md is not published. docs/release-notes/ stays unlisted, matching docs/reports/, docs/rfcs/ and docs/adr/ (verified: 0 SUMMARY.md references each).

Reviewer notes

• ### Upgrading from 10.0.9 is a new CHANGELOG convention — no prior section has one. Intentional per the §10 rewrite.
• No standalone release-notes file for 10.0.10 — the four builder-visible changes fit the CHANGELOG matrix, which is the documented default.
• No contract deployment needed — git diff --name-only v10.0.9..origin/main -- '*.sol' 'packages/evm-module/abi/*' 'packages/evm-module/deployments/*' is empty.
• CHANGELOG length: ~8k characters / 20 bullets, roughly double a typical section (3.1–4.1k, 11–15 bullets). Proportionate to 497 commits vs the 18–108 of recent releases. All 43 PR citations from the full audited draft are preserved — verified by set difference, zero dropped and zero invented.

Test Plan

• pnpm release:verify-versions --version 10.0.10 → passes, 21/21
• pnpm-lock.yaml untouched
• Both engines-bearing manifests parse; declared range satisfied by the .nvmrc baseline (node -v = v22.22.0)
• Every package importing node:sqlite declares the range (agent is the only one)
• No stray hardcoded 10.0.9 in product source
• No dangling path references left in §10
• CI green
• Comprehensive devnet gate on the resulting main commit (§4) — next gate, after merge

Related

• All 10.0.10 code landed via release: promote testnet-canary to main for 10.0.10 #1983 (testnet-canary → main promotion, 497 commits)
• Runtime-floor enforcement deferred to Enforce the node:sqlite runtime floor at startup and before slot activation #1985

🤖 Generated with Claude Code

[otReviewAgent]

🔴 Bug: 10.0.10 can still install on Node runtimes that cannot run it

What's wrong
This release turns node:sqlite into a startup requirement for normal nodes, but the package metadata being bumped to 10.0.10 does not advertise or enforce that requirement. Existing operators on Node 20 or early Node 22 can receive the update through npm/auto-update and only discover the incompatibility when the daemon is already trying to boot, causing avoidable downtime.

Example
On Node v20.19.0, node -e "import('node:sqlite')" fails with ERR_UNKNOWN_BUILTIN_MODULE. Because the 10.0.10 CLI package has no engine constraint, npm can still install or auto-update to it, and the daemon then fails at start with the documented requires Node runtime support for node:sqlite path instead of being blocked before promotion.

Suggested direction
Declare and enforce the new minimum Node runtime in the package/runtime promotion path, not only in the changelog, so incompatible nodes fail before installation or slot activation.

For Agents
Look at the publishable package manifests, especially packages/cli/package.json and packages/agent/package.json. Preserve the 10.0.10 release version, but add a runtime gate such as engines.node >=22.5.0 and, if auto-update can ignore engine warnings, a preflight before switching the active slot. Prove that Node 20 or Node 22.0-22.4 cannot be promoted/started as a compatible 10.0.10 runtime, while a supported Node 22.5+ runtime still installs and starts.

[otReviewAgent]

🟡 Issue: Declare the Node runtime invariant at the package that owns sqlite

What's wrong
The new engine constraint is attached only to the CLI package, while the code that actually owns the node:sqlite dependency lives in the agent package. That makes the runtime floor a scattered release convention instead of a clear package boundary, and future maintainers have to keep prose, CLI metadata, and agent internals aligned manually.

Example
A downstream consumer installs @origintrail-official/dkg-agent@10.0.10 directly on Node 22.12 and uses the RFC-64 inventory/finalization persistence path. The agent package metadata gives no EBADENGINE warning, but the runtime loader later throws requires Node runtime support for node:sqlite.

Suggested direction
Add the same engines.node contract to @origintrail-official/dkg-agent, or centralize/enforce this metadata so the CLI is not the only place that remembers an agent-owned runtime requirement.

Confidence note
If @origintrail-official/dkg-agent is intentionally unsupported as a standalone runtime package for RFC-64/finalization persistence, this is less severe. Its public package metadata and exports make that boundary unclear from the diff.

For Agents
Look at the package that owns the sqlite-backed persistence (packages/agent) and the release metadata checks. Preserve the same Node range, but make the runtime invariant explicit at the canonical package boundary, or add a metadata check that every package importing/loading node:sqlite declares the same floor.

[Jurij89]

Fixed in part, deferred in part — tracked in #1985.

Done in this PR: engines.node is now declared as >=22.13.0 <23.0.0 || >=23.4.0 on both @origintrail-official/dkg (packages/cli) and @origintrail-official/dkg-agent (packages/agent). The agent package is the one that owns the node:sqlite code, and it is the complete set — packages/agent is the only package referencing node:sqlite in src; node-ui uses the native better-sqlite3 dep and is unaffected.

Correction to the suggested range: >=22.5.0 would not have fixed this. node:sqlite ships from 22.5.0 but stays behind --experimental-sqlite until 22.13.0 (and 23.4.0 on the 23.x line), and the daemon builds its command from process.execArgv and never passes that flag. A bare >=22.13.0 would also wrongly admit 23.0–23.3. Your 🟡 on CHANGELOG.md:15 had the right number; the two findings are resolved together at 22.13.

Deferred to 10.0.11 (#1985), by maintainer decision: enforcement. engines is advisory — verified both ways: pnpm WARN Unsupported engine + exit 0, npm EBADENGINE + exit 0; both hard-fail only under engine-strict. The larger gap is that blue-green auto-update gates activation on existsSync of build output (auto-update.ts:1407-1418 / :578-598) and never proves the slot boots, so an unsupported runtime can activate and then restart-loop. #1985 covers a capability probe (process.getBuiltinModule('node:sqlite'), which also handles --without-sqlite builds and correctly passes 22.10 + flag), wiring at dkg start, the daemon, both swapSlot sites, a node-runtime doctor check in UPDATE_PREFLIGHT_CHECKS, and your 🟡 asking for a release-metadata guard against drift.

10.0.10 therefore ships the declaration plus an explicit ### Known issues entry stating that engines does not block and that auto-update can activate an unbootable slot.

[otReviewAgent]

🟡 Issue: Node minimum in the upgrade table is too low for unflagged node:sqlite startup

What's wrong
The new release notes make the RFC-64 catalog active by default and tell operators that Node 22.5+ is sufficient, but versions before Node 22.13 still require --experimental-sqlite. Since the production loader just imports node:sqlite, operators following this guidance can get a startup failure on a version the upgrade table appears to allow.

Example
An operator on Node 22.10 follows the 10.0.10 upgrade table, upgrades without adding --experimental-sqlite, and starts a node with a data directory. The RFC-64 SQLite loader calls import('node:sqlite'), which fails before networking, even though the release notes said Node 22.5+ was enough.

Suggested direction
Change the documented minimum to a Node line where node:sqlite is available without flags, or include the required runtime flag for earlier 22.x/23.x versions.

For Agents
Update the 10.0.10 upgrade guidance in CHANGELOG.md to distinguish availability from unflagged availability: require Node >=22.13.0 or Node >=24 for normal startup, or explicitly document --experimental-sqlite for Node 22.5-22.12 and affected 23.x releases. Consider adding matching engines.node metadata to the published package manifests so install/runtime expectations align. A smoke test should prove the documented minimum can start the RFC-64 SQLite loader without extra flags.

[Jurij89]

Confirmed and fixed — thank you, this was the load-bearing catch. The 22.5 figure was wrong in three places (theme paragraph, upgrade table, Known issues) and would have sent operators onto a runtime that installs and then fails to boot.

Verified against Node's own version-history table: node:sqlite added v22.5.0, "no longer behind --experimental-sqlite but still experimental" at v23.4.0 / v22.13.0. The daemon builds its command from process.execArgv (daemon-entrypoint.ts:52-58) and never adds the flag, so 22.5–22.12 is exactly the broken window you describe.

Documented floor is now >=22.13.0, or >=23.4.0 on the 23.x line — also excluding 23.0–23.3, which a bare >=22.13.0 would have wrongly admitted. Same range declared in engines.node on both publishable runtime packages, per your suggestion and the 🔴s.

[otReviewAgent]

🟡 Issue: Release-note guidance now has two competing publication models

What's wrong
The new paragraph is trying to reduce release-note sprawl, but it introduces a hidden conflict with the existing GitHub Release step. That makes the release runbook less maintainable because the source of truth for upgrade guidance is now split between an inline CHANGELOG convention and a separate notes-file assembly step.

Example
A maintainer following line 228 could put the upgrade matrix in CHANGELOG.md and expect the GitHub Release to be a verbatim copy, while a maintainer following §6c could assemble a curated notes.md that omits or reshuffles that same matrix while adding channel and compare-link content.

Suggested direction
Collapse this into one canonical procedure. Either update §6c to explicitly say the matching CHANGELOG section is copied verbatim with fixed metadata appended/prepended, or move the inline/standalone matrix rules into §6c and let §10 only define when a standalone guide is required.

For Agents
Edit RELEASE_PROCESS.md around §6c and §10. Preserve the inline-vs-standalone upgrade-guide policy, but make one section own GitHub Release note generation and have the other reference it. Docs-only; no tests needed beyond rereading the runbook for a single coherent flow.

[otReviewAgent]

🟡 Issue: Make GitHub Release note generation mechanically single-source

What's wrong
The new runbook tries to establish the changelog as the source of truth, but the assembly steps immediately add an exception that edits the copied body. That preserves the exact kind of manual, position-sensitive release-note drift the change is trying to eliminate.

Example
For the new 10.0.10 entry, the release author would copy the section body from CHANGELOG.md, then manually splice the npm line between the theme paragraph and ### Upgrading from 10.0.9. The final GitHub Release body is no longer the changelog body verbatim, and placement becomes ambiguous for any release whose first body element is not a simple theme paragraph.

Suggested direction
Avoid a manual splice inside the copied changelog body. Keep the changelog section truly verbatim and place fixed metadata before or after it, or move the npm/channel line into the changelog itself before tagging.

For Agents
Update RELEASE_PROCESS.md §6c and §10 so release-note assembly has one deterministic transform. Preserve current content, but either put npm/channel metadata in the changelog before copying, append all fixed metadata outside the copied body, or introduce a small script/template that extracts the changelog section and adds metadata in one predictable place.

[Jurij89]

Fixed — this was my inconsistency, introduced in the previous commit.

§6c now explicitly owns GitHub Release note generation: it states the matching CHANGELOG section is copied verbatim (including its ### Upgrading from <PRIOR> matrix), with only fixed metadata added around it — title line, npm + channel line, compare link — and that if the notes need to say something the CHANGELOG does not, the CHANGELOG gets fixed first so the two cannot drift.

§10 no longer describes release-note assembly at all. It now defines only when upgrade guidance is required and where it is written, and defers to §6c for how it reaches the Release.

[otReviewAgent]

🔴 Bug: Standalone agent package lacks the new Node runtime contract

What's wrong
The release declares the new node:sqlite runtime requirement only on the CLI package. The public @origintrail-official/dkg-agent package is also being released as 10.0.10 and contains the agent startup paths that open RFC-64 inventory and finalization recovery stores through node:sqlite. Direct agent consumers can install this release on unsupported Node versions with no package-manager warning and only discover the incompatibility as a startup failure.

Example
On Node 22.12, npm install @origintrail-official/dkg-agent@10.0.10 would not warn about an unsupported runtime. A direct consumer that creates an agent with dataDir and calls start() then reaches prepareRfc64PersistenceV1() and fails with requires Node runtime support for node:sqlite before networking starts. The expected behavior is that the unsupported runtime is declared on the package that exposes and starts that code.

Suggested direction
Propagate the engines.node requirement to the public package that owns the SQLite-backed agent runtime, not only to the CLI wrapper.

Confidence note
This assumes @origintrail-official/dkg-agent is still intended to be a standalone public package, which is consistent with its public package name, publish config, root exports, and allowlisted RFC-64 subpath exports.

For Agents
Add the same supported Node range to packages/agent/package.json and any other public package that directly exposes startup/runtime APIs requiring node:sqlite. Preserve the CLI engine range, and add/update a release metadata check proving all publishable runtime packages that can open RFC-64/finalization SQLite declare the contract.

[Jurij89]

Fixed in part, deferred in part — tracked in #1985.

Done in this PR: engines.node is now declared as >=22.13.0 <23.0.0 || >=23.4.0 on both @origintrail-official/dkg (packages/cli) and @origintrail-official/dkg-agent (packages/agent). The agent package is the one that owns the node:sqlite code, and it is the complete set — packages/agent is the only package referencing node:sqlite in src; node-ui uses the native better-sqlite3 dep and is unaffected.

Correction to the suggested range: >=22.5.0 would not have fixed this. node:sqlite ships from 22.5.0 but stays behind --experimental-sqlite until 22.13.0 (and 23.4.0 on the 23.x line), and the daemon builds its command from process.execArgv and never passes that flag. A bare >=22.13.0 would also wrongly admit 23.0–23.3. Your 🟡 on CHANGELOG.md:15 had the right number; the two findings are resolved together at 22.13.

Deferred to 10.0.11 (#1985), by maintainer decision: enforcement. engines is advisory — verified both ways: pnpm WARN Unsupported engine + exit 0, npm EBADENGINE + exit 0; both hard-fail only under engine-strict. The larger gap is that blue-green auto-update gates activation on existsSync of build output (auto-update.ts:1407-1418 / :578-598) and never proves the slot boots, so an unsupported runtime can activate and then restart-loop. #1985 covers a capability probe (process.getBuiltinModule('node:sqlite'), which also handles --without-sqlite builds and correctly passes 22.10 + flag), wiring at dkg start, the daemon, both swapSlot sites, a node-runtime doctor check in UPDATE_PREFLIGHT_CHECKS, and your 🟡 asking for a release-metadata guard against drift.

10.0.10 therefore ships the declaration plus an explicit ### Known issues entry stating that engines does not block and that auto-update can activate an unbootable slot.

[otReviewAgent]

Review Agent completed this review and found no issues.