[lilyshen0722]

process.env.PG_HOST = undefined stores the string 'undefined', which is truthy. In unit suites that satisfied every if (process.env.PG_HOST) guard in the backend and made config/db-pg.ts:75 build a real Pool for host 'undefined', so connectPG()'s not-configured branch (:106-108) was unreachable. Same for MONGO_URI.

Change. Delete the keys instead of assigning undefined, with the comment saying why.

Scope, searched rather than assumed. PG_HOST is also a feature flag: server.ts:68/:363, controllers/podController.ts:22/:426/:627, controllers/authController.ts:121, routes/agentsRuntime.ts:3103 all took the configured branch in every unit suite and now take the not-configured one — the shape a unit suite is supposed to see. Every test file that reads PG_HOST also sets it, and testUtils.js builds its Pool only under useRealServices().

MONGO_URI adds no new failure mode: server.ts:297 calls connectDB() unconditionally and config/db.ts:11-13 already answers a connect failure with console.error + process.exit(1), which is what the string URL 'undefined' produced.

Witness — __tests__/unit/config/setupEnvAbsence.test.js. Both assertions were red before the change and green after:

1. neither var is the literal string 'undefined' (the defect's signature);
2. no Pool is built for host 'undefined', read off the pool's own options.host rather than pool === null, so a developer with a real PG_HOST in the environment still passes. Assertion 2 also confirms the consequence at the level the defect actually has it, not only the env-var level.

The two dependent populations this exposes

Suites that depended on the defect. __tests__/unit/config/init-pg-db.test.js:17 reached for a REAL pool, which existed only because of the bogus host; once the harness stopped lying, both tests died on Cannot set properties of null (setting 'connect'). The unit under test is initializeDatabase and its pool is a dependency, so it now stubs config/db-pg and keeps the same two assertions. That file also gets the import/no-unresolved, import/extensions disable its siblings carry (lint 4 errors → 0).

Three files set PG_HOST = process.env.PG_HOST || 'localhost-test' (unit/config/db-pg.test.js:8, unit/routes/health.db.test.js:26, unit/routes/health.ready.test.js:20). That fallback has never fired, because the string was truthy; it does now. Both values are truthy, so no arm flips, and all three are green.

Runtime code that read the bogus host as configured. Five sites branch on a null pool without naming PG_HOST, and each is a degrade path: controllers/pgStatusController.ts:10 → {available:false}, models/ToolCall.ts:104 → throw tool broker requires PostgreSQL, services/activityService.ts:364 → unranked podIds, services/attachmentAccess.ts:205 → [], services/systemExchangeTriggers.ts:123 → null. Today they get a Pool, the query fails, and the catch degrades; after this change they return early. The result is the same and the arm is different, so a green suite cannot tell the two apart — stated here because it is the one place this change moves behaviour without moving an outcome. Found by a scan of the 28 modules importing db-pg for !pool / pool && / pool ? / pool?., which shares no term with the PG_HOST grep.

Dead code this makes removable

• agentIdentityService.ts — syncUserToPostgreSQL's pgHost === 'undefined' clause (feat(v2): align Settings with artboard #1546) was there to compensate for exactly this harness. !process.env.PG_HOST covers the unconfigured case on its own; the clause and its stale comment go.
• backend/jest.setup.js is orphaned. Verified, not assumed: jest.config.js:35 lists __tests__/setup.js as the only setupFilesAfterEnv entry, package.json has no jest key, no script passes --config, and a repo-wide grep finds the file named only in tsconfig.build.json's exclude — so the file and that exclude line both go. tsconfig.json:23 stays; it records a landing-time count, which is history rather than configuration.

Docs, same PR

backend/TESTING.md now says process.env is per test FILE (mechanism: jest-environment-node's detached createProcessObject copy per file), plus the corollary that a child process needs env passed explicitly. docs/development/review-checklist.md rule 31 had called the TMPDIR mechanism unexplained; it is that same per-file copy, so the rule keeps its conclusion and loses only the rider — reason rewritten, rule not deleted.

Suite

427 of 433 suites, 4001 tests, 0 failures (6 suites / 24 tests skipped). Two intermittent things, disclosed rather than buried, neither caused by this change:

• __tests__/unit/server.test.js "returns available:false when PG init throws" failed once under full-suite load, passes 3/3 in isolation, and passed in two other full runs with this same change set. It is a race: the fallback /api/pg/status mount happens inside the connectPG().then(...) chain while the test awaits a single setImmediate, so under load the request can arrive before the mount. I have deliberately not touched it — I cannot demonstrate a fix for a flake I cannot reproduce in isolation.
• __tests__/unit/models/AgentMemory.test.ts "enforces unique (agentName, instanceId)" — one of the three known flaky members.