chore(deps): update all non-major dependencies

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@commitlint/cli (source)	21.2.1 → 21.2.2
@commitlint/config-conventional (source)	21.2.0 → 21.2.2
harper (source)	5.2.1 → 5.2.2

---

Release Notes

conventional-changelog/commitlint (@​commitlint/cli)

v21.2.2

Compare Source

Note: Version bump only for package @​commitlint/cli

conventional-changelog/commitlint (@​commitlint/config-conventional)

v21.2.2

Compare Source

Note: Version bump only for package @​commitlint/config-conventional

harperfast/harper (harper)

v5.2.2

Compare Source

Vector search (HNSW) — correctness and scaling fixes

Removed two terms from vector search that scaled linearly with corpus size (#​2069), along with a series of follow-on fixes: graph-size is now resolved from node IDs instead of RocksDB's key estimate (previously wrong under certain deletion patterns), and the limit-derived ef ceiling is now bounded correctly so an explicit ef stays authoritative and limit-widening no longer re-resolves graph size per query. Filtered vector queries with a selective filter now return distances correctly (#​2133).

SQL engine — TOP / LIMIT / OFFSET

SELECT TOP n and fractional LIMIT/OFFSET are now honored correctly; TOP PERCENT and out-of-range LIMIT/OFFSET values are properly deferred to the legacy query path instead of being mishandled (#​2124).

Config reload and override inheritance

Config reloads could diverge from the live config tree: reload comparisons were key-order-sensitive and non-total, setProperty overrides could leak or fail to propagate to worker threads, and an HDB_ROOT install-time property could be silently dropped by canonical keying. The live config tree is now uniquely identifiable, reload comparisons are total and key-order-insensitive, and overrides propagate correctly across the main/worker boundary.

Deployment payload ingest — durability under load

Deploy payload ingest could race with deployment-progress flushes and run with an insufficient transaction budget. Ingest writes now run in their own isolated transaction with a dedicated, sticky timeout budget, and deployment recorder writes are serialized against progress updates.

Data integrity: bodyless records and migration verification

Audit entries no longer advertise a record body that was never actually captured (a source-applied put with no content is now correctly skipped rather than reconstructed). Database migration's verification pass no longer leaks a rawDbi handle when a partial open fails.

Also in this release

Dependency bump (argon2 → 0.45.1, #​2132); test coverage, documentation, and formatting chores.

Full Changelog: HarperFast/harper@v5.2.1...v5.2.2

---

Configuration

📅 Schedule: (in timezone America/New_York)

• Branch creation
  • "before 9am on Monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[dawsontoth]

The bumps are fine — the lockfile is regenerated wrong

All four red checks are the same failure: npm ci dies before any test or build step runs. This is the --package-lock-only landmine, not a problem with any dependency in this PR.

What's wrong

This branch touches only package-lock.json (package.json is untouched), and it drops 249 lockfile entries — the entire react-native subtree that hangs off harper → alasql:

node_modules/harper/node_modules/alasql  --[optionalDependencies]-->  react-native-fs

main has 6 node_modules/react-native* entries; this branch has 0. So npm ci refuses the tree:

npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and package-lock.json are in sync.
npm error Missing: react-native-fs@2.20.0 from lock file
npm error Missing: react-native@0.84.1 from lock file
npm error Missing: react@19.2.8 from lock file
... (~138 more from the same subtree)

The trigger is the harper 5.2.1 → 5.2.2 bump in this PR. Renovate regenerates the lockfile with --package-lock-only, which resolves harper's subtree without installing it, so alasql's optional react-native-fs dependency is dropped.

Why Node 22 is green and 24/26 are red

All three matrix legs run the identical npm ci, so the split is purely the bundled npm version. Confirmed by running the same broken lockfile under both:

Node	npm	npm ci
22.20.0	10.9.3	exit 0 — tolerates the pruned optional subtree
24.19.0	11.17.0	exit 1 — EUSAGE

So the Node 22 pass is not evidence the lockfile is sound; npm 10 is just lenient here. Worth knowing, because if this repo ever drops to a Node-22-only matrix, this class of breakage goes silent.

The intended changes are all fine

Filtering out the erroneous deletions, this PR means to bump 17 packages, all routine:

package	change
@commitlint/*	21.2.0/21.2.1 → 21.2.2
harper	5.2.1 → 5.2.2
es-toolkit	1.49.0 → 1.50.0
fast-uri	3.1.0 → 3.1.5
@conventional-changelog/template	1.2.1 → 1.3.0
argon2 (under harper)	0.44.0 → 0.45.1
node-addon-api (under harper)	8.6.0 → 8.9.1

I verified these are good by regenerating the lockfile properly and running everything:

npm install          # restores the 6 react-native entries
npm ci               # exit 0
npm run format:check # exit 0
npm run build        # exit 0
npm run test         # exit 0

So there is nothing to fix in the dependency set — only in how the lockfile was produced.

The fix

Regenerate this lockfile with a full install rather than --package-lock-only. In renovate.json:

"postUpdateOptions": ["npmDedupe"],
"skipInstalls": false

skipInstalls: false is the operative setting — it forces a real npm install, which walks optional dependencies and keeps the react-native-fs subtree.

HarperFast/agent#149 is failing right now for the identical reason (also an npm repo bumping harper to 5.2.2), so this is worth fixing at the Renovate-config level in both repos rather than per-PR. studio bumps harper too and is unaffected only because pnpm resolves optional dependencies differently.

Requesting changes so this doesn't land a lockfile that npm ci rejects. Not pushing to the branch, so Renovate keeps its normal rebase loop.

_{🤖 Verified locally by Claude Opus 5 via scheduled Renovate triage}

[dawsontoth]

Correction: skipInstalls: false is already set here — my suggested fix was wrong

Following up on my own comment above. The diagnosis of the symptom holds (the lockfile is missing the harper → alasql → react-native-fs optional subtree, and npm ci rejects it), but the remedy I gave was already in place, so please don't act on it as written.

renovate.json on this branch and on the base already contains:

"skipInstalls": false

It was added in c5b68bb (ci(renovate): do a full install when updating lockfiles) back on 2026-08-13, precisely to stop this. So skipInstalls: false is necessary but not sufficient — Renovate produced a pruned lockfile anyway.

I also can't reproduce the pruning locally with npm, which means my attribution of it to --package-lock-only was a guess I should not have stated as the cause. Starting from the base lockfile (subtree present, harper at 5.2.1) and re-resolving harper to 5.2.2 every way I could:

how	react-native entries after
npm update harper --package-lock-only (npm 11.17.0)	6 — kept
npm update harper full install (npm 11.17.0)	6 — kept
npm update harper --package-lock-only (npm 10.9.3)	6 — kept
npm install --omit=optional --package-lock-only	6 — kept
npm install --omit=optional full	6 — kept

All exit 0, all preserve the subtree, and the npm-10-generated lockfile is even accepted by npm ci under npm 11. So plain npm does not prune this on its own, under either major, in either mode.

What is still solid

Everything I measured directly stands:

• The branch lockfile is missing the subtree that the base has, and npm ci fails with EUSAGE under npm 11 (Node 24/26) while npm 10 (Node 22) accepts it — which is the whole of the matrix split.
• A full npm install on the branch restores the subtree, after which npm ci, lint, format, build, and the test suite all pass. The dependency bumps themselves are fine.

What changes about the ask

The immediate unblock is unchanged: commit a full-install regeneration of the lockfile (same remedy that fixed agent#141 / vite#37 on 08-13). What I got wrong is implying a config change would prevent a recurrence — that config is already there and didn't.

So the real follow-up is a genuine root-cause hunt on the Renovate side, not another config toggle. Worth checking:

• which npm version Renovate's runner actually uses, and whether its lockfile write path differs from the CLI equivalents above
• whether the optional subtree fails to fetch/build in Renovate's container (react-native-fs and the argon2 / node-addon-api bumps in this same PR are native), leaving it recorded as absent
• Renovate's repository cache — a stale cached tree from before the 08-13 regen would explain the subtree being dropped again on every re-resolve, and would explain why I can't reproduce it from the committed base

I'd start with Renovate's debug log for this branch's lockfile step; that names the command and npm version and would settle it quickly.

Requesting-changes state is unchanged — the branch still can't be installed with npm ci. Apologies for the misdirection on the fix.

_{🤖 Verified locally by Claude Opus 5 via scheduled Renovate triage}