test: scale Windows CI timing budgets from a shared helper

[steipete]

Why

Windows CI runners run this suite ~3–4x slower than macOS/Linux (~25s locally, ~100s on a Windows runner), and several tests were calibrated with flat millisecond budgets on fast machines. After three Windows-only flakes surfaced in one session (runtime-stdio-close, e2e-fixture-servers, runtime-inflight-close), this does a systematic pass instead of tuning one flake at a time.

What

Every hardcoded millisecond timeout / timing assertion in the suite was classified into one of three buckets and handled accordingly:

• Shared helper — new tests/helpers/timing.ts exports CI_SLOWDOWN (3× on Windows, 1× elsewhere) and budget(ms). This is for hang-catcher budgets that exist to fail fast on a hang, not to measure machine speed. The helper's doc comment says so explicitly.
• Derived from the real budget — bounds now track the source constant they police:
  • The force-exit flush deadline STDOUT_FLUSH_TIMEOUT_MS was moved from cli.ts into the leaf module cli/timeouts.ts (and re-exported), so the truncation test imports it without triggering the CLI's auto-run-on-import.
  • The daemon liveness probe DAEMON_PROBE_TIMEOUT_MS is exposed via __daemonHostInternals and the hung-daemon test derives its budget from it.
  • The e2e stopChild teardown waits and readiness guards scale via budget().
• Hang-catchers scaled — spawn-heavy per-test budgets and readiness guards across the e2e, daemon, and CLI integration suites now use budget().
• Genuine perf assertions kept fixed — serve.test.ts's 750ms close-promptness check and the in-flight close deadline stay fixed (closing an in-process HTTP server has no per-platform cost) and are documented as such.

Proof

• The two non-trivial relaxed bounds were mutation-checked: breaking the force-exit fallback and breaking the daemon probe timeout each still fails the corresponding test, so the relaxed assertions retain their teeth.
• 134 tests across the 12 affected files pass locally; typecheck, oxlint, and oxfmt are clean.
• autoreview (codex, gpt-5.6-sol, high) clean; TruffleHog clean.

The formatting churn in the diff (e.g. daemon.integration.test.ts) is oxfmt's mandated multiline it(name, fn, timeout) form whenever a trailing timeout arg is present — same reflow the earlier f0bd0d8 commit accepted.

Follow-up

Only a Windows CI run confirms the 3× factor is right. If it still flakes there, bump CI_SLOWDOWN rather than individual budgets.

🤖 Generated with Claude Code

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: test: scale Windows CI timing budgets from a shared helper This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 385f6c12a2

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Add a matching Vitest timeout for the scaled child wait

On Windows, budget(10_000) gives this execFile up to 30s, but the only it that calls runCli in this file still relies on the suite-wide Vitest timeout of 10s. In the slow or hung CLI case, Vitest aborts the test before this scaled child timeout can fire, so the added Windows headroom is ineffective and can leave the spawned CLI running until execFile kills it later; add a matching budget(...) timeout to that test or keep the child timeout within 10s.

Useful? React with 👍 / 👎.