Filed by the os-dev seat working objectui#9013, which edited the sibling gate. ⛔ Filed bare — no assignee, no labels, ⛔ not claimed; routing and grading are triage's. ⛔ Nothing about spawned-build-vitest-env-8598.test.ts was changed on that card's branch.
The shape
The two gates are the same construction — derive a population of child-process call sites by AST, then judge each one's env: — and they disagree on what counts as a spawner. Both lines, printed:
scripts/__tests__/spawned-build-vitest-env-8598.test.ts:66:const SPAWNERS = new Set(['spawnSync', 'spawn', 'execFileSync', 'execFile', 'execSync', 'exec']);
scripts/__tests__/spawned-vitest-child-env-8616.test.ts:79:const SPAWNERS = new Set(['spawnSync', 'spawn', 'execFileSync', 'execFile', 'execSync', 'exec', 'fork']);
⇒ child_process.fork is a spawner to objectui#8616's gate and is not one to objectui#8598's. Neither file's header states a reason for the difference, so it reads as drift rather than a decision — but ⚠️ it could equally be a deliberate call nobody wrote down, which is a thing triage can settle and this seat cannot.
The direction matters: omitting an entry from a population set is a false GREEN, not a false red. A build started with fork('…', ['build'], { env }) would never enter objectui#8598's population, so the gate that exists to stop VITEST reaching a spawned build would report clean about a call site it never looked at.
Measured, on origin/main = 1f4e02995a
⚠️ Latent, not live. The test tree contains zero fork( call sites today, so nothing is leaking through this:
target — /(^|[^.\w])fork\(/ across packages, apps, scripts, examples (*.test.ts, *.spec.ts, *.tsx),
comment lines excluded: 0 matches
control — the same command, same run, /(^|[^.\w])spawnSync\(/:
35 matches, e.g. packages/cli/src/__tests__/cli-bin.test.ts:77
The control is what makes the zero a reading rather than a broken command.
⛔ What this is not
- ⛔ Not a claim that objectui#8616's inclusion of
fork is the correct side. The two sets should agree, or one of them should say why not; which way to converge is a judgement about what these gates are for.
- ⛔ Not a leak. No measurement here shows anything escaping either gate.
- ⛔ Not in scope for objectui#9013, whose fence is explicitly "only the per-spawn membership test is at issue" in the objectui#8616 gate.
Filed by the
os-devseat working objectui#9013, which edited the sibling gate. ⛔ Filed bare — no assignee, no labels, ⛔ not claimed; routing and grading are triage's. ⛔ Nothing aboutspawned-build-vitest-env-8598.test.tswas changed on that card's branch.The shape
The two gates are the same construction — derive a population of child-process call sites by AST, then judge each one's
env:— and they disagree on what counts as a spawner. Both lines, printed:⇒⚠️ it could equally be a deliberate call nobody wrote down, which is a thing triage can settle and this seat cannot.
child_process.forkis a spawner to objectui#8616's gate and is not one to objectui#8598's. Neither file's header states a reason for the difference, so it reads as drift rather than a decision — butThe direction matters: omitting an entry from a population set is a false GREEN, not a false red. A build started with
fork('…', ['build'], { env })would never enter objectui#8598's population, so the gate that exists to stopVITESTreaching a spawned build would report clean about a call site it never looked at.Measured, on
origin/main=1f4e02995afork(call sites today, so nothing is leaking through this:The control is what makes the zero a reading rather than a broken command.
⛔ What this is not
forkis the correct side. The two sets should agree, or one of them should say why not; which way to converge is a judgement about what these gates are for.