parallel-coordinationlisted

# Parallel coordination Running workers at the same time is only safe when their write sets do not collide. Parallelism buys wall-clock time, but it costs coordination, so use it for genuinely independent streams and serialize everything else. Each worker is a native subagent in its own call, never sees another's changes, and cannot merge. The primary stays the single point of coordination and does the assembling. ## When to use - The plan has more than one worker that should run at once. - The developer asks to run work in parallel ("in parallel", "at the same time", "have two agents look at it"). - Deciding whether two work streams are independent enough to overlap. ## When not to use - The streams share files, a branch, shared resources (a port, a browser session), or an ordering dependency: they are not independent, so run them serially — one worker at a time, letting the first return before starting the next — or give one stream sole ownership of the shared area. - There is only one stream: plain `delegate-task` is simpler, and a parallel wrapper adds coordination without saving time. ## Inputs - The plan (`plan-work`): the streams, their roles, and their intended independence. - Each stream's project root (`multi-project-context`). - `max_concurrent` and `max_iterations` from the loaded `team-mate.toml` (task-level flags override the single loaded file). - A ledger task per stream (`task-ledger`). - The resolved harness (`tm harness`): whether it s