Speedups

Why PA3 stays serial

The router runs experts one at a time on purpose; inside a task, coders can overlap. Two ways to run tasks in parallel were studied and not adopted.

Waves

A wave would run two, at most three, tasks with disjoint files and no shared imports, none of them touching the card, the plan, the skill, a measurement, a review-gated task or the close. Shared record shapes would be fixed at plan approval, the router would refresh nothing mid-wave, gate each task after its sibling's commit, and fall back to serial on the first collision. The task grammar already has the wait-for: key a wave would use; the router has no wave step.

Worktrees

One git worktree per expert, merged at the task boundary. Repositories can be huge, so a checkout per task multiplies disk and time; promotion, the installed copies and the single plan file all assume one tree, so the merge step would be new machinery; and conflicts would come back as merge conflicts, needing an agent of their own or a rule that the later task rebases.

Why serial

In phases 3.1 to 3.8 the plans' dependencies would have allowed three- to five-way parallelism; later phases became chains (3.9.6 was a chain of 8 tasks out of 10, 3.9.7 of 7 out of 11). Experts were busy 42 % (3.9.5) and 41 % (3.9.6) of a phase's wall-clock time; the rest was waiting on the developer and on measurement runs. A wave would save an estimated 20 to 30 % of expert-busy time in a phase shaped for it and almost nothing in a chain. The decision, on 2026-09-25, was to stay serial.