[Bug] Root workspace admits Node runtimes below the SQLite compatibility floor

[VeraPyuyi]

Affected area

Build / packaging

Installation method

Built from source

Lody version or commit

d924231b95e91c8c25e073292d5f01b5a8549b97 (current main on 2026-08-28)

Operating system

Cross-platform; reproduced with Node.js 22.13.1 and Node-API 9

Agent or runtime

Node.js 22.x/23.x, pnpm workspace installation, and the better-sqlite3 binding built for Node-API 10

What happened?

The root workspace declares Node.js >=22.0.0, while both SQLite-owning packages require at least Node 22.14.0. A root install can therefore admit Node 22.0-22.13. The simple lower-bound range also admits Node 23.0-23.5, where Node-API 10 is not yet available. In those runtimes the native SQLite binding can fail before Lody can provide a useful diagnostic.

The pinned pnpm 10.20.0 also does not reliably turn the root devEngines.runtime.onFail: error setting into a hard installation failure, so the manifest warning is not a sufficient guard by itself.

What did you expect?

The root workspace and SQLite-owning packages should express the same Node-API 10 compatibility boundary, and dependency installation should stop with a clear error before loading the native binding on unsupported runtimes.

How can we reproduce it?

1. Use Node.js 22.13.1, which reports process.versions.napi as 9.
2. Run the root workspace installation with the repository-pinned pnpm.
3. Observe that the current root >=22.0.0 declaration admits the runtime even though the CLI packages require 22.14+ and the SQLite binding requires Node-API 10.
4. Attempt to load the SQLite-backed CLI path and observe that failure occurs at the native runtime boundary instead of during installation with an actionable message.

How often does it happen?

Every time

Relevant log output

Node.js 22.13.1: process.versions.napi = 9
Root package.json: engines.node = ">=22.0.0"
apps/cli and packages/turn-diff-store: engines.node = ">=22.14.0"

Additional context

An implementation already exists in #72. That PR was opened on 2026-08-27, before the contribution-intake policy in #91 merged on 2026-08-28. I am not treating this issue as retroactive approval. I am asking a Lody maintainer to explicitly confirm whether this approach is acceptable: use the exact Node-API 10 semver boundary (>=22.14.0 <23 || >=23.6.0) consistently, add a package-manager-independent preinstall guard based on process.versions.napi, retain the existing pnpm 10.20.0 pin, and cover the manifest/runtime contract with focused tests. PR #60 has since merged an initial "22.14 or later" quickstart prerequisite; because that wording includes unsupported Node 23.0-23.5, the prepared follow-up also narrows the English, Chinese, and tracked compatibility text to 22.14-22.x or 23.6+ (Node-API 10+). I will not push the prepared follow-up until explicit maintainer agreement is recorded. If a maintainer prefers a narrower manifest-only fix or does not want the change, I will adjust or close the PR.

Before submitting

• I searched the existing issues and did not find a duplicate.
• This report concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• This is not a security vulnerability; security reports follow the repository's security policy.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.
• If I plan to submit a pull request, I will wait for a Lody maintainer to explicitly agree on the scope and approach before implementation.

[VeraPyuyi]

This issue documents the scope for the existing PR #72, which predates the current intake policy. The reviewed follow-up enforces the actual Node-API 10 boundary across manifests, installation, diagnostics, and quickstart docs, with focused regression coverage. Could a maintainer please confirm whether this scope and approach are acceptable before I update the PR branch?