Concurrency

Flow-Next exposes parallel candidates through the task dependency graph. /flow-next:plan reports those candidates as execution waves; /flow-next:work decides at runtime whether a ready subset can run safely in parallel.

Safe parallelism

• Different specs on different branches
• Independent tasks from the same execution wave
• Isolated mutable workspaces for concurrent writers
• Atomic claims to avoid duplicate ownership
• A conductor-owned join and integration step

Worker isolation

/flow-next:work dispatches worker subagents with fresh context per task. Each worker re-anchors against the spec, task, and git state before editing. In a parallel wave, workers implement, test, commit, and return task-unique handovers without marking tasks done or running plan-sync. The conductor joins the whole wave, integrates it, then runs the existing per-task review, completion, and tracker gates before deferred plan-sync runs.

Coordination rule

If two tasks touch the same high-churn module, share mutable resources, or cannot get isolated workspaces with a safe integration path, prefer serial execution or split the boundary first. A successful task claim is an ownership lock, not a filesystem or Git lock.

Solo developer

Solo concurrency is mostly about not losing context:

/flow-next:work fn-1
/flow-next:impl-review fn-1
/flow-next:work fn-2

Keep one spec in active implementation unless the second spec is truly isolated. If you switch, re-anchor before editing: read the spec, ready tasks, branch diff, and current review receipts.

Team execution

Teams can run multiple workers when the graph supports it:

flowchart LR
  Spec["Reviewed spec"] --> API["Worker 1: API"]
  Spec --> UI["Worker 2: UI"]
  Spec --> Docs["Worker 3: docs"]
  API --> Review["Impl review"]
  UI --> Review
  Docs --> Review

The plan makes candidate waves visible; the host agent makes the runtime choice. It evaluates dependencies, declared files, shared resources, available worker capacity, workspace isolation, and integration risk before selecting a concurrent subset. If the safe subset has one task, it serializes and says why.

Worktree pattern

Use a worktree per independent task cluster when multiple agents need to edit simultaneously:

Worktree	Scope
fn-12-api	Server contract, tests
fn-12-ui	Client integration using agreed contract
fn-12-docs	Docs and examples

Join all workers before integrating. Merge back through the same spec branch, complete the normal per-task gates, then run /flow-next:spec-completion-review after integration. The completion review is where cross-task drift is caught.

Signals to stop parallelizing

• Two workers repeatedly touch the same files.
• Review findings mention conflicting assumptions.
• A task needs a product answer that is not in the spec.
• Tests only pass in one worktree.
• The PR body cannot explain acceptance coverage cleanly.

When these show up, serialize the risky part and improve the spec before restarting.