Defame1297
a8beff7d2c
Both runners spawned one process at a time and let it finish before starting the next, so wall time scaled with file count even though each file's own work (bats: mostly repeated apm/git subprocess startup; the vale-heavy shell scripts: repeated vale binary startup) rarely used a full core. run-bats.sh now backgrounds one `bats` invocation per file, bounded by core count, buffering each file's TAP output so concurrent streams can't interleave, then flushes in stable sorted order once every job finishes. run-tests.sh does the same for test-*.sh in fixed-size batches (plain `wait`, not `wait -n`, to stay on the bash-3.2-safe path test-vale-wrap.sh already enforces for this file) -- verified beforehand that every test-*.sh keeps its fixtures under its own mktemp dir rather than mutating the live repo tree, so running them concurrently is safe. Confirmed correct on both the pass and fail paths (a deliberately failing bats test and a scratch TEST_DIR with pass/fail/skip-77 scripts) before measuring: full bats suite 26-30s -> 7.5s, tests/run-tests.sh 68s -> ~45-50s, full pre-push gate 2m40s -> 1m12s. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X7GvKuJfy2WrdBmUttV4DT