Context
On 2026-06-23 an ad-hoc bun -e 'register(...)' probe accidentally wrote 4u/4net/8tok into the production hub DB (~/.commhub/commhub.db) because COMMHUB_DB defaulted to the prod path when unset. See commhub thread / robustness-maintenance Round 10 self-report.
What's already shipped (Round 10, commit 57b5ec6)
server/src/db-adapter.ts createAdapter() now throws when NODE_ENV === "test" AND COMMHUB_DB is unset. Plus server/package.json has "test": "COMMHUB_DB=/tmp/test-commhub-$$.db bun test src/".
This closes the bun test vector (the historical recurrence path — bun test sets NODE_ENV=test automatically).
What's still open
bun -e does NOT set NODE_ENV. An ad-hoc bun -e 'import { register } from "./src/auth.js"; register(...)' STILL silently hits prod by default — the exact vector of the 2026-06-23 incident.
Proposed fix (single roll-up)
Flip the default. createAdapter() ONLY allows the ~/.commhub/commhub.db path when an explicit COMMHUB_SERVER=1 (or equivalent) env var is set — i.e. only the actual bun run src/index.ts / bun --watch run src/index.ts boot path opts into the prod default.
bin/commhub.ts and package.json "start" + "dev" scripts get COMMHUB_SERVER=1 prepended (or set inside bin/commhub.ts BEFORE the adapter import).
- Any other entry point (bun -e, bun test, ad-hoc scripts) without
COMMHUB_SERVER=1 AND without COMMHUB_DB=<path> set → throw with the same friendly message R10 introduced.
- Existing
npm run test already sets COMMHUB_DB, unaffected.
- Production server runs unchanged in behavior (the start/dev scripts get the flag).
Why this is on the backlog, not done today
- Touches the hub boot path (every production node hits this) — needs careful walkthrough by 通信龙 + Vincent review.
- Today's R10 fix closes the highest-frequency vector (
bun test); the remaining ad-hoc vector is held by operator discipline + this issue as the doc trail.
- Single-标 careful implementation when picked up.
Acceptance criteria
Refs
Context
On 2026-06-23 an ad-hoc
bun -e 'register(...)'probe accidentally wrote 4u/4net/8tok into the production hub DB (~/.commhub/commhub.db) becauseCOMMHUB_DBdefaulted to the prod path when unset. See commhub thread / robustness-maintenance Round 10 self-report.What's already shipped (Round 10, commit
57b5ec6)server/src/db-adapter.ts createAdapter()now throws whenNODE_ENV === "test"ANDCOMMHUB_DBis unset. Plusserver/package.jsonhas"test": "COMMHUB_DB=/tmp/test-commhub-$$.db bun test src/".This closes the
bun testvector (the historical recurrence path —bun testsetsNODE_ENV=testautomatically).What's still open
bun -edoes NOT setNODE_ENV. An ad-hocbun -e 'import { register } from "./src/auth.js"; register(...)'STILL silently hits prod by default — the exact vector of the 2026-06-23 incident.Proposed fix (single roll-up)
Flip the default.
createAdapter()ONLY allows the~/.commhub/commhub.dbpath when an explicitCOMMHUB_SERVER=1(or equivalent) env var is set — i.e. only the actualbun run src/index.ts/bun --watch run src/index.tsboot path opts into the prod default.bin/commhub.tsandpackage.json"start"+"dev"scripts getCOMMHUB_SERVER=1prepended (or set insidebin/commhub.tsBEFORE the adapter import).COMMHUB_SERVER=1AND withoutCOMMHUB_DB=<path>set → throw with the same friendly message R10 introduced.npm run testalready setsCOMMHUB_DB, unaffected.Why this is on the backlog, not done today
bun test); the remaining ad-hoc vector is held by operator discipline + this issue as the doc trail.Acceptance criteria
bun -e 'import("./src/db-adapter.js").then(m => m.createAdapter())'(no COMMHUB_DB, no COMMHUB_SERVER) → throwsbun run src/index.ts(production boot) → adapter loads, prod path used, identical behavior to todaynpm run test→ adapter loads to /tmp path, all tests pass (131/0)bun test src/(without COMMHUB_DB) → throws (already covered by R10)Refs