fix(startup): scale the idle-silence timeout for CI, matching the absolute-max ceiling

[kriszyp]

Summary

DEFAULT_STARTUP_TIMEOUT_MS (the idle/no-output watchdog window runHarperCommand uses to decide a boot has hung) was a flat 60s regardless of environment, while DEFAULT_STARTUP_MAX_MS (the absolute ceiling) already scales 120s → 300s under CI (IS_CI check). Applies the same 2.5x ratio to the idle window: 60s → 150s under CI.

Purpose

Closes the "and/or a higher CI-aware default" ask from #8, and the underlying cause of HarperFast/harper#1827 (recurring HarperStartupError: Harper produced no startup output for 60000ms across unrelated PRs).

Timeline that led here:

• startHarper readiness deadline and teardown loopback recycle cause intermittent failures under sharded CI #8 / Integration test harness: startup-deadline and teardown/loopback-recycle races (tracks integration-testing#8) harper#1139 flagged the old fixed-wall-clock startup deadline as "the flake lever" and proposed either readiness polling or a higher CI-aware default.
• fix: idle-based startup readiness and port-safe teardown recycle #9 replaced the fixed deadline with the current idle-window + absolute-max design — but only made the absolute-max ceiling CI-aware, not the idle window.
• HarperFast/harper@b676af8a4 then dropped harper's own HARPER_INTEGRATION_TEST_STARTUP_TIMEOUT_MS env overrides (120s Linux / 180s Windows), trusting the new idle-based design to handle contended CI runners without them.
• That trust wasn't quite earned: the idle window itself stayed at the un-scaled 60s default, so a healthy-but-contended boot (e.g. several Harper instances booting concurrently within one sharded test process — this repo's own run.ts defaults to floor(availableParallelism()/2)+1 concurrent processes) can still go quiet for >60s between debug-log lines without being hung, tripping the idle timer well under the deliberately-larger absolute ceiling. Hence "no startup output for 60000ms" showing up verbatim in the flake.

Where to look

• src/harperLifecycle.ts: the DEFAULT_STARTUP_TIMEOUT_MS default and its JSDoc, plus the StartHarperOptions.startupTimeoutMs JSDoc (caught by Codex review — was still documenting the old flat 60s).
• README.md: default value docs updated to match.

No behavior change for non-CI runs; CI runs get 2.5x more idle headroom, consistent with the existing max-ceiling ratio. Not adding new test coverage for the IS_CI branch here — the sibling DEFAULT_STARTUP_MAX_MS CI branch has no coverage either and is already tracked as a follow-up in #10; happy to fold this new branch into that same issue instead of inventing a one-off pattern for it now.

🤖 Generated by Claude (Sonnet 5), reviewed via codex exec review --uncommitted (one non-blocking JSDoc nit found and fixed).

[gemini-code-assist]

Code Review

This pull request increases the default startup timeout (DEFAULT_STARTUP_TIMEOUT_MS) from 60 seconds to 150 seconds when running in a CI environment to prevent false-positive hang detections on contended runners. The documentation in README.md and the JSDoc comments in src/harperLifecycle.ts have been updated accordingly. There are no review comments, and I have no additional feedback to provide.

[heskew]

Test-infra only; idle-silence timeout scales 2.5× for CI (60→150s) consistently with the absolute-max ceiling (120→300s), and idle never exceeds max. Docs aligned. LGTM.

_{🤖 Reviewed via cross-model pipeline; approved by @heskew.}

[github-actions]

🎉 This PR is included in version 0.6.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀