perf(runner): Parallelize hunk analysis

[gricha]

Move hunk analysis onto one shared FIFO work queue.

Warden previously applied concurrency at the file boundary while processing hunks within each file serially. A large multi-hunk file could therefore leave most configured capacity idle.

Hunks are now independent queue items under one global concurrency limit across files, skills, SDK runs, CLI runs, and GitHub Actions. Reports remain deterministically ordered even when hunks finish out of order.

Queued rate-limit delays respect aborts, and file progress begins when work actually starts. Fatal hunk errors now cancel in-flight siblings and prevent queued hunks from making additional provider calls. Public concurrency documentation has been updated accordingly.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
warden-prod	Ready	Preview	Aug 24, 2026 6:40pm

[sentry-junior]

Looks good to me. The shared FIFO queue is a clean replacement for the file-level semaphore, and the tests lock in the important bits: cross-file/skill concurrency, deterministic report order when hunks finish out of order, abort-aware rate-limit delays, and file progress starting when work actually begins.

[sentry-junior]

Looks good to me. Moving concurrency to a shared hunk-level FIFO queue is the right fix for multi-hunk files starving capacity, and the tests cover the important contracts: cross-skill/file limits, deterministic report order when hunks finish out of order, abort-aware rate-limit delays, and file progress starting when work actually begins. Docs and call sites stay consistent with the new unit of work.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 87fae02. Configure here.}

[sentry-warden]

Base config runner concurrency incorrectly overrides repo config

schedule.ts computes runnerConcurrency with ??, which picks the base config value before the merged config. When a base config defines [runner].concurrency, repo-level overrides are ignored even though mergeRunnerConfig already resolves them correctly into layered.config. Bug is at schedule.ts:137-140; nearest changed line in the hunk is the concurrency: 2 assertion that exercises the setting.

Evidence

• mergeRunnerConfig in config/loader.ts merges runner configs with overlay (repo) priority via { ...base, ...overlay }.
• loadLayeredWardenConfig returns the merged result in layered.config, so layered.config.runner?.concurrency already holds the correct effective value.
• schedule.ts:137-140 computes runnerConcurrency = baseConfig?.runner?.concurrency ?? repoConfig?.runner?.concurrency ?? config.runner?.concurrency.
• If the base config sets runner.concurrency = 5 and the repo config sets runner.concurrency = 2, the merged config correctly yields 2, but runnerConcurrency evaluates to 5 because ?? stops at the first non-nullish value.
• This causes the schedule workflow to use the base concurrency limit instead of the repo override, violating the documented layering semantics.

_{Identified by Warden · code-review · 33R-MJS}