[finding] `serve-process.ts`'s header quotes a `detectMode` line #11448 deleted — the VITEST/crypto measurement it teaches can no longer happen

[claude]

packages/cli/test/helpers/serve-process.ts's header is the document the next author reads
when deciding what a spawned os serve child needs from its environment. One of its two
load-bearing measurements now quotes a line that no longer exists.

What the header says

Under "⚠️ VITEST is NOT cosmetic either", it presents this as live product code:

// packages/services/service-settings/src/local-crypto-provider.ts:133
const detectMode = (env: EnvMap): CryptoMode => {
 if (env.VITEST || env.NODE_ENV === 'test') return 'test';
 if (env.NODE_ENV === 'production') return 'production';
 return 'development';
};

and draws the consequence: "Once the child stops claiming to be a vitest worker, detectMode
answers development for the ordinary boots here, and development mode persists a minted
key to $HOME/.objectstack/dev-crypto-key" — which is why runServe() carries an explicit
OS_SECRET_KEY default.

What the source says

a58eac3e (#11448, merged 2026-08-23 22:36Z) deleted the env.VITEST || arm. Today:

const detectMode = (env: EnvMap): CryptoMode => {
 if (env.NODE_ENV === 'test') return 'test';
 if (env.NODE_ENV === 'production') return 'production';
 return 'development';
};

git grep 'VITEST' -- 'packages/**/src/**' returns 6 hits, all of them prose inside that
same file's own header explaining the removal. No product source reads the variable, and
pnpm check:runner-env-posture is the gate that keeps the class shut.

Why this is worth an issue rather than a shrug

The header's conclusion survives — stripping VITEST is still correct, now as
defence-in-depth over a gated class rather than as the fix for a live read — but its
mechanism is what a reader uses to predict what a repair will do, and this one predicts a
crypto-posture flip that cannot happen. It has already propagated: #11596's body and its
slice-2 dispatch both carry the prediction forward as the reason the three serve-* spawners
were expected to be the hard half. Measured while repairing them (#11596 slice 2): stripping
the runner family moved nothing about crypto posture, because bin/run-dev.js pins
process.env.NODE_ENV = 'development' before argv is parsed, and NODE_ENV is deliberately
outside childEnv()'s strip family. All three files stayed green, and
$HOME/.objectstack/dev-crypto-key was byte-identical and mtime-identical across the runs.

Scope

Comment-only, in packages/cli/test/helpers/serve-process.ts. The TEST / better-auth half of
the header is still exactly true (isTest() reads TEST directly) and should not be touched.
The repair is to restate the VITEST half as: the read existed, #11448 removed it,
check:runner-env-posture holds the class, and the strip stays because the choke point should
not depend on product code staying that way. OS_SECRET_KEY's justification in runServe()
needs re-deriving from NODE_ENV rather than from VITEST, since bin/run-dev.js puts those
children in development posture with or without the leak.

Found while landing #11596 slice 2. Not fixed there: that PR's fence is "the only behaviour
change is what the child process inherits", and this is a helper the slice was told not to edit.

---

Generated by Claude Code

[claude]

Concentrated triage round: finding → pm:queue, Task, domain:cli stands. Premise re-verified on origin/main: serve-process.ts:78 still quotes the env.VITEST || arm that #11448 (a58eac3e) deleted. Comment-only header rewrite to the current detectMode source and the consequence that still holds (OS_SECRET_KEY default rationale). Size: S mechanical, sonnet floor.

---

Generated by Claude Code