perf(worker): cold-start head-of-line blocking with MAX_CONCURRENCY = 2

[lemtoc]

As of v0.3.0 (c73dc6c).

Summary

MAX_CONCURRENCY = 2 (src/worker/mod.rs:33) serializes async collection on first visit to a polyglot repository. A repo that enables git_branch, git_status, node_version, python_version, and rust_version schedules 5 jobs into 2 workers; each job can legitimately take up to its timeout (default 1 s). Worst case, the last segment appears ~⌈5/2⌉ × 1 s ≈ 3 s after the prompt — and two slow jobs (e.g. git status on a large repo on a network filesystem) delay every other segment behind them.

The prompt itself is never blocked (async by design), and deadlines are computed at job start (src/worker/jobs.rs:140), so this is a perceived-latency issue, not a correctness one. But "async everywhere" is the project's core promise, and queueing delay is invisible latency the user cannot configure today.

Proposed fix

Options, cheapest first:

1. Document it: note in docs/performance.md that per-segment timeouts bound each job but cold-start settle time is ceil(jobs / 2) × timeout in the worst case.
2. Size the pool dynamically: spawn up to min(pending_segments, N) workers on demand instead of a fixed 2. The jobs are I/O-bound subprocess waits; even N = number of async segments (currently 7) is a trivial thread count for a per-shell daemon.
3. Prioritize git: git segments are the ones users actually watch; scheduling them before runtime-version jobs improves perceived latency without more threads.

Option 2 is small (JobPool already takes max_concurrency as a parameter) and removes the class of problem; 3 is a nice refinement on top.

---

🤖 Generated with Claude Code — Claude Fable 5