ci: the windows e2e step stops starving its own reporter - #766

What

cli / Windows has been failing with every test passing:

Error: [vitest-worker]: Timeout calling "onTaskUpdate"
 Test Files  39 passed (39)
      Tests  279 passed (279)
     Errors  1 error
##[error]Process completed with exit code 1.

A red check that names no failing test is worse than a red check: it teaches everyone reading it that red means nothing.

Measured

All green, exit 1, every time. The re-run rules out a one-off; three plain merges to next rule out any one branch. Two other Windows failures in the same window were a different, real fault (a comment that names a source file names one that exists), already fixed.

Cause

Vitest transforms modules on its own main thread while every worker calls back into it (onTaskUpdate after each test), and that call has a fixed 60 s timeout — DEFAULT_TIMEOUT = 6e4 in the bundled birpc, exposed by no configuration key. On this runner (slow filesystem, an e2e test that spawns node dist/cli.js inside every worker) the default pool of one fork per CPU-but-one queued that main thread past 60 s. The e2e suite has grown all week, which is why one occurrence on 2026-09-02 became four in an evening.

Change

--max-workers=2 on that one step. Halving the pool halves the transform requests competing for the thread that must answer them. The Linux jobs keep the default — they have never produced this, and slowing them would buy nothing.

The workflow never ran on its own changes

Found while opening this PR: cli CI filters on cli/**, kanban/**, plugins/aidd-telemetry/** and scripts/__tests__/**. A commit touching only .github/workflows/cli-ci.yml matches none of them, so the first push of this very fix ran three workflows and not the one it changes — and merging it would have run nothing either, since push filters the same way. A change to how the suite runs would have landed unverified.

The workflow now lists itself. It is the one path whose change alters every job in the file.

A sixth occurrence, on a branch that touches no CI file

While this PR waited, #767 - a change to two domain predicates and nothing else - failed cli / Windows the same way on 18e31bb8: [vitest-worker]: Timeout calling "onTaskUpdate", 39 files, 280 tests, 0 failures, exit 1. Six occurrences now, across four different branches and three plain merges to next. Nothing about the failure is branch-specific, which is what a pool-size fix has to be true of to be the right fix.

The committed comment says "five runs" - it was written before this one and stays true as a subset. It is not amended here, because amending it would replace the commit whose Windows run is the evidence this PR is waiting on.

What would prove it wrong

Nothing local: the failure needs that runner. The proof is the runs. If the message returns with the smaller pool, the next step is sharding the step in two, not a larger --max-workers — written into the plan so the next person does not re-derive it from an empty log.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VWNxk63AGKkqE8HRqHLjGp