[max-sixty]

After the picker paints its rows, the collect thread ran two steps one after the other before the ref snapshot could start. The task pool opens only once that snapshot finishes, so every row's results waited on both steps:

• prime_worktree_path_caches, which canonicalizes and reads .git for each worktree: 5–7ms warm, 20–82ms loaded or cold on leaf (~130 worktrees).
• The comments fetch's ci_platform() call, whose first use forks git remote get-url: 20–48ms. It runs only when a row's cached CI status is still fresh (within 30–60s of a wt list).

The seeding now runs as a spawn in the post-skeleton rayon::scope, alongside the ref snapshot. The fsmonitor probes are nested under it because each probe reads the git dir the seeding fills in. The comments fetch now resolves the forge inside its pool job, through the same spawn_comments_fetch path the --prs rows use, so on_skeleton and on_update start no processes. That removes the last production caller of fill_external; tests call fill directly.

In a trace with a fresh CI cache, main spends 93→168ms on these two steps before the snapshot starts. On this branch the snapshot starts at the skeleton handoff. The expected saving is ~10ms on an idle machine and up to ~130ms under load. An end-to-end timing wasn't possible: the load average was 55–164 during the runs, and time to pool start varied 430–660ms on both builds, mostly from the snapshot's own for-each-ref scans.

The pipeline diagram in src/commands/list/collect/mod.rs is updated to show where both steps now run.

This was written by Claude Code on behalf of max-sixty

🤖 Generated with Claude Code

[worktrunk-bot]

codecov/patch fails because of the three lines at collect/mod.rs:1762-1764: the s.spawn(|_| repo.start_fsmonitor_daemon_at(&wt.path)) loop. That loop was only moved inside the seed spawn, and it was already uncovered on main. fsmonitor_worktrees is empty on every platform except macOS, and coverage runs on Linux. None of the PR's new logic is missed: prs.rs, preview_orchestrator.rs, and progressive_handler.rs are at 100% patch coverage.

Adding a test can't close this gap, so there's nothing to change in the code. Per AGENTS.md, merging with a failing codecov/patch needs your explicit sign-off, so I'm withdrawing my approval until you decide. My review of the code itself found no issues.

codecov/patch failing (moved macOS-only lines); needs maintainer sign-off per AGENTS.md