Context
Item #4 from the CI flakiness sweep in #181's family of issues. In one `unit (windows)` CI run under heavy load, these tests failed by hitting exactly their configured time limits (10s/60s/61s):
- `test/project/instance-bootstrap.test.ts`: "InstanceStore.provide runs InstanceBootstrap before effect"
- `test/project/instance-bootstrap.test.ts`: "CLI bootstrap runs InstanceBootstrap before callback"
- `test/session/prompt.test.ts`: "loop waits while shell runs and starts after shell exits"
- `test/session/prompt.test.ts`: "shell completion resumes queued loop callers"
- `test/skill/discovery.test.ts`: "Discovery.pull > refreshes a remote skill when its version changes"
What I checked
None of these 5 tests declare a custom per-test timeout — they all run under the suite's default (60s, from the `--timeout 60000` CLI flag in `package.json`'s `test` script). That's different from the subprocess-timeout flakes fixed in #162/PR #191, which had tight custom bounds (25s/30s/5s) that were the actual bug.
I did not reproduce this locally (a single CI run under heavy load isn't something I can force-reproduce on a dev machine), and per the investigation methodology for this sweep, I'm not comfortable bumping the global default or adding ad-hoc per-test timeouts without evidence that these specific tests are systematically slow — that risks masking a real regression instead of fixing a flake (explicitly out of scope: "não aumente timeouts genericamente 'pra nunca mais falhar'").
Suggested next step
Don't fix yet — watch for recurrence. If any of these 5 tests fail again on a future Windows CI run (via `gh run list` / job logs), that's enough of a pattern to justify either: (a) a targeted per-test timeout bump with measured headroom like #191, if it's consistently these tests, or (b) a deeper look at whether something systemic (e.g. InstanceBootstrap/tmpdir/git setup cost) is genuinely growing slower under CI load. A single occurrence isn't enough signal to act on safely.
Context
Item #4 from the CI flakiness sweep in #181's family of issues. In one `unit (windows)` CI run under heavy load, these tests failed by hitting exactly their configured time limits (10s/60s/61s):
What I checked
None of these 5 tests declare a custom per-test timeout — they all run under the suite's default (60s, from the `--timeout 60000` CLI flag in `package.json`'s `test` script). That's different from the subprocess-timeout flakes fixed in #162/PR #191, which had tight custom bounds (25s/30s/5s) that were the actual bug.
I did not reproduce this locally (a single CI run under heavy load isn't something I can force-reproduce on a dev machine), and per the investigation methodology for this sweep, I'm not comfortable bumping the global default or adding ad-hoc per-test timeouts without evidence that these specific tests are systematically slow — that risks masking a real regression instead of fixing a flake (explicitly out of scope: "não aumente timeouts genericamente 'pra nunca mais falhar'").
Suggested next step
Don't fix yet — watch for recurrence. If any of these 5 tests fail again on a future Windows CI run (via `gh run list` / job logs), that's enough of a pattern to justify either: (a) a targeted per-test timeout bump with measured headroom like #191, if it's consistently these tests, or (b) a deeper look at whether something systemic (e.g.
InstanceBootstrap/tmpdir/git setup cost) is genuinely growing slower under CI load. A single occurrence isn't enough signal to act on safely.