fix(test): sandbox the home directory on every platform, add CI (v1.52.2)

[siddharth-bhansali]

INT-4396

Problem

Every test file sandboxed process.env.HOME. That is a no-op on Windows: os.homedir() follows $HOME on POSIX but reads USERPROFILE on win32 and ignores HOME entirely.

process.env.HOME = 'C:/tmp/fake-home'
os.homedir()  // → C:\Users\<you>   ← unchanged

So on Windows the suite read and wrote the developer's real ~/.one:

• analytics.test.ts appended 255 fabricated rollup events (distinct_id: "user-0" … "user-49") to the live telemetry send-queue. That queue is a retry queue — drainQueue() fires on the next one command, so those would have shipped to production PostHog.
• action-details.test.ts wrote into the real knowledge cache.
• config.test.ts read through to the real ~/.one/config.json, so ~29 assertions failed against whatever config happened to be installed. Notably resolveConfig "returns null scope when no config exists anywhere" failed with 'global'.

No workflow ran the suite on push or PR, so none of this was ever visible in CI.

Changes

lib/home.ts — one home resolver. homeDir() replaces all 20 os.homedir() call sites and is overridable via ONE_HOME identically on every platform. Also a genuine feature for containers and multi-tenant shells; documented in the README.

Three module-load bindings made lazy. update.ts (ONE_DIR/CACHE_PATH/LOCK_PATH), schedule-registry.ts (REGISTRY_DIR/REGISTRY_FILE), and embedded-postgres (DEFAULTS.dataDir) each captured the home directory at import time, which defeats any override no matter how early it is set. config.ts:9 already carried a comment warning about exactly this, from a 2026-04-21 incident where the suite clobbered a real config.json; these three sites had not been converted.

test-support/home.ts — isolation you cannot get half-right. withTempHome() / setHomeTo() set ONE_HOME, HOME and USERPROFILE. assertHomeIsSandboxed() throws rather than silently falling back to the real home — the failure mode that kept this invisible. All 9 test files that sandboxed HOME now use it.

getProjectRoot no longer walks above $HOME. It skipped home as a project root but kept climbing, so a .git, package.json, or .one in C:\Users / /home / / would be adopted as the project root for every marker-less directory under home. This is a real bug independent of tests — and it is also what let the sandbox escape on Windows, where os.tmpdir() lives inside the real home (%LOCALAPPDATA%\Temp).

scripts/run-tests.mjs replaces the glob. tsx --test \"src/**/*.test.ts\" relies on runner-side glob expansion that only landed in Node 21. On Node 18 and 20 — both inside our declared engines.node: >=18 — the pattern is passed through literally, matches nothing, and the runner exits 0 having run zero tests. A contributor on Node 20 sees a green run that asserted nothing. The new runner discovers files itself, works the same across sh/cmd/PowerShell, and fails loudly on an empty discovery.

.github/workflows/ci.yml. Typecheck + tests on Node 18/20/22 across ubuntu and windows, plus a build job so tsup/dts failures surface on a PR rather than on a release tag. Windows coverage is the point: this entire class of bug was invisible everywhere else.

Verification

• Full suite: ~29 failures → 0. 405 tests, 392 pass, 13 skipped (suites that skip when the optional native deps are absent — better-sqlite3 will not build on Node 24).
• npx tsc --noEmit passes.
• The real ~/.one is byte-for-byte unchanged across three consecutive full runs — 63 files, zero added, modified, or removed, verified by snapshotting LastWriteTimeUtc + Length before and after.
• The withTempHome test caught a genuine flaw in my own guard during development (assertHomeIsSandboxed compared against os.homedir(), which the sandbox had already moved via USERPROFILE); it now compares against the real home captured at module load.

Notes for review

• Node 18 in the matrix is untested locally — I can't run it here. It is included to honour the declared engines.node: >=18. If it fails on first run, the honest fix is raising engines rather than dropping the job, since we currently promise 18 and don't verify it.
• package-lock.json version fields hand-edited rather than regenerated: npm install on Node 24 drops the pg optional dependency from the lockfile. That dirty lockfile was already in the working tree when I started and I reverted it — worth a look at whoever's local Node.
• Version 1.52.1 → 1.52.2. Collides with fix(sync): never destroy a healthy database on a driver fault (v1.52.3) #179's bump; whichever merges later needs a rebase.
• Cleanup still outstanding from the same root cause: 45 test-fixture events remain in the real ~/.one/.analytics-queue.jsonl on my machine (I removed 255; a backup is at .analytics-queue.jsonl.bak). Anyone who ran npm test on Windows should check theirs before the next one command drains it.

🤖 Generated with Claude Code

[linear]

INT-4396