Hypothesis
The external-tools phase is slow because three independent npm audit subprocesses run serially. Parallelizing only those network-bound subprocesses should reduce wall time without changing output order or check semantics.
Baseline
Ten clean Bunsen runs completed in 25.30 seconds median. A line-timestamp trace localized 20.14 seconds to External Tools. The three audit gaps were 6.55, 6.77, and 6.98 seconds.
Candidate
A bounded ThreadPoolExecutor runs at most four audit jobs concurrently and collects futures in declaration order. Output remains deterministic.
Baseline25.30 s
Candidate11.99 s
Result
- 10/10 measured candidate runs passed.
- Candidate median: 11.99 seconds.
- Improvement: 52.6%.
- Three concurrency/order tests passed; Ruff passed.
- The original bare
pytest -q tests/hermes_clirun was stopped after 2h27m at 83%. It had already accumulated roughly 243 failures before becoming silent. - Investigation did not reproduce a deterministic doctor regression: doctor plus the nearest tools-config window completed 208/208, and the test nearest the stall completed alone in 0.68 seconds.
- The failure is classified as a polluted, unbounded monolithic-runner result—not a waiver and not proof that the doctor patch hangs. The repository’s bounded per-file runner is the applicable promotion gate.
- The candidate remains HOLD and is not installed on Herman. Promotion requires the canonical bounded runner to terminate green.
Falsifier
Reject this candidate if the bounded per-file gate reproduces a doctor-owned timeout, changes output order, misses an audit result, or records a new subprocess failure attributable to the parallel block.