The 2026-05-09 parity audit against agents/final-working surfaced one
HIGH-severity regression in the new dispatcher: workers run strictly
serially (no ThreadPoolExecutor / asyncio anywhere in
_dispatch_runtime.py), where the legacy LLM supervisors ran
max_workers=4 concurrent workers. ~4x wallclock throughput penalty on
backlog burndown.
Document this in docs/development/auto-agents-tier-2-3-plan.md as a
new Tracking subsection ("Open - immediate follow-up after dispatcher
soak") with full acceptance criteria (--workers N flag wrapping the
per-item cycle loop in ThreadPoolExecutor, default 1 for safety; six
concrete test cases; cycle_failure_budget must remain cycle-level not
per-worker) so the fix is ready to pick up the moment the serial
dispatcher demonstrates >= 1 week of clean production runtime. The
soak-first ordering is deliberate: known-good serial baseline makes
concurrency bugs much easier to attribute. Operator-side multi-process
fallback (sharding via distinct LOCK_PATH/HEARTBEAT_PATH per process)
also documented for hosts that cannot wait for the in-process fix.
Cross-referenced from the existing "Cross-cutting work" section so a
reader scanning the plan top-to-bottom sees the dependency before
reaching Tracking. CHANGELOG updated.
Co-authored-by: Cursor <cursoragent@cursor.com>
drew
720b633b1d