Parallel dispatch

When several independent tasks are ready and you have more than one agent, session, or worker available, you can implement them at the same time. The dependency graph tells you which tasks are safe to run together, and the task row keeps the parallel workers from stepping on each other.

Dependency edges define what is safe to parallelize

A task is ready when every one of its depends_on targets is done. Run piyaz_analyze type='ready' to list them. Two tasks that both appear in ready cannot block each other by definition, so they are candidates for parallel work. See Task graph for how ready, blocked, and critical path are computed.

Readiness is necessary but not sufficient. Two ready tasks that both edit the same file are not actually independent: they will produce merge conflicts. Before dispatching, check for file overlap. If you find it, either serialize the two tasks or split the shared change into a third task that lands first.

Rank the remaining candidates by critical-path proximity (piyaz_analyze type='critical_path'). If you have three agents and six ready tasks, send the agents to the three critical-path tasks first; those determine the project's minimum duration.

Claim before work, one branch per task

Each agent claims its task before touching code by setting status='in_progress'. The claim is what prevents two agents from grabbing the same task: anyone reading the project sees the task is being worked. Each agent then works on its own feature branch, one branch per task, named for the task ref. Separate tasks, separate branches, separate workers; the isolation is real because nothing is shared at the task level.

Execution records keep agents from colliding

The graph carries each agent's context so the workers do not have to coordinate by hand:

• When an agent fetches piyaz_context depth='agent' for its task, it gets the execution records of upstream tasks: the files, the functions, the decisions already shipped. It builds on that work instead of re-deriving or contradicting it.
• When a task lands, its execution record propagates down its depends_on edges. A later agent picking up a dependent task starts already knowing what the parallel run produced.

Finalize and propagate

Each dispatched agent marks its task in_review with the full Completion Protocol payload and opens a PR if the work changed code, then returns a one-sentence summary. When the agents return, review their execution records and PRs, flip approved tasks in_review → done, and run propagation on each finalized task so downstream context reflects what shipped.