fix(mcp-conformance-fixture): set hookTimeout to match testTimeout

[willgriffin]

{"schema":"hv-agent-run:v1","runtime":"claude","session":"8a94e288-0358-403f-a3a6-8e81a80e6c5d","issue":"2240","head_sha":"8451eac142f993640ee0e4d512596b1cd141e40d","policy_revision":"1.0.0","status":"complete"}

Summary

packages/mcp-conformance-fixture had testTimeout: 240_000 but no hookTimeout, so its
beforeAll ran against vitest's 10 s default. That is backwards for this suite — the
expensive work is entirely in the hook:

	work
beforeAll	generate the MCP server, spawn tsx on the generated TypeScript (stdio transport), complete a protocol handshake with listTools assertions, then spawn the HTTP adapter as a second process
each it	one fetch POST to the already-running adapter

So the cheap half held the 240 s budget and the heavy half held none.

Impact

This is nondeterministic and it failed PRs that have nothing to do with MCP:

• feat(fields): add FieldPolicy model, layered resolver, and batch resolve action #2230 (feat(fields)) was admitted to the merge queue and then ejected by this in
  test-packages (2/3) — which is why it silently reverted to CLEAN with no visible cause.
• fix(core,scanner): make build output reproducible #2231 (fix(core,scanner)) went red on Validate Changes / Affected Build, Typecheck, and Tests
  with the identical failure.

Both showed:

❯ src/generated-server-conformance.test.ts (2 tests | 2 skipped) 10067ms
Error: Hook timed out in 10000ms.
  ❯ src/generated-server-conformance.test.ts:27:1

67 ms over the line, both tests skipped — the failure carried no signal about the code
under test. Because the merge queue runs mode: full while the PR lane runs mode: affected,
a PR could sit at CLEAN and still be ejected on queue entry.

Why match testTimeout rather than pick 30 s

The repo's usual value is hookTimeout: 30000 (with 60_000 in bundle-gate), but those
hooks do not spawn two tsx processes. Matching the value this package already declares for
the same workload avoids inventing a third number, and the hook runs once per suite so there
is no cost to the headroom. It only relaxes a limit — it cannot mask a failure, since an
actually-hung spawn still fails, just later.

Validation

• pnpm --filter @happyvertical/smrt-mcp-conformance-fixture test — 2 passed, 3.32 s total
  on an idle machine, confirming the hook is normally fast and the 10 s default was marginal
  only under CI contention rather than covering a real hang
• npx turbo build --filter=@happyvertical/smrt-mcp-conformance-fixture... — 6/6 successful
• biome check — the path is ignored by the repo's Biome config, so no diagnostics apply
• Single-file test-config change; no runtime or source code is touched

Related: #2220 is the same class (permission tests marginal against their timeout, failing the
merge queue nondeterministically).

Closes #2240

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[Copilot]

Pull request overview

Updates the @happyvertical/smrt-mcp-conformance-fixture Vitest configuration to prevent nondeterministic CI failures caused by a long-running beforeAll hook timing out under Vitest’s default hook timeout.

Changes:

• Adds hookTimeout: 240_000 to match the already-configured testTimeout: 240_000.
• Documents why the suite’s timeout budget needs to apply to hooks (the heavy work is in beforeAll).

[willgriffin]

Closing as a duplicate of #2239 — same root cause, same fix, filed ~6 minutes apart by two sessions that hit the ejection independently.

Timeline: I filed #2238 at 20:28Z and opened #2239 at 20:35Z; #2240 was filed at 20:37Z and this PR at 20:41Z. Keeping #2239 because it is a strict superset — the same hookTimeout: 240_000 with an equivalent explanatory comment, plus prevention in .claude/rules/testing.md and TESTING_STANDARD.md, which matters because this is not the first occurrence (smrt-svelte's teardown hook, #1426).

No criticism of the work here — your inline comment is good, and you actually ran the fixture suite locally (2 passed, 3.32s), which is more validation evidence than my PR carries. Nothing is lost by consolidating; the fix is identical. Reopen if you disagree.