Task Graphs

/flow-next:plan decomposes a spec into task files under .flow/tasks/. Each task is sized for one work iteration and may declare dependencies.

flowchart TB
  S["fn-1 add oauth"]
  S --> T1["fn-1.1 create schema"]
  T1 --> T2["fn-1.2 implement auth routes"]
  T1 --> T3["fn-1.3 add UI states"]
  T2 --> T4["fn-1.4 document setup"]
  T3 --> T4

Tasks carry acceptance mapping:

satisfies: [R1, R3]
requires: [fn-1-add-oauth.1]

The graph gives agents a deterministic execution order and gives reviewers traceability from requirement to evidence.

What makes a good task

• It satisfies a small, named set of R-IDs.
• It has explicit dependencies.
• It can be reviewed from one diff chunk or one module cluster.
• It lists expected evidence.
• It does not hide product decisions inside implementation instructions.

Planning output

After /flow-next:plan, reviewers should be able to answer:

Question	Source
What can start now?	Ready tasks with no unmet dependencies
What is blocked?	requires edges
Which acceptance criteria are uncovered?	Task satisfies mapping
Which tasks can run in parallel?	Independent branches of the graph
Which files are high-risk?	Plan notes and review findings

Parallel execution model

flowchart LR
  Root["Shared spec"] --> A["Worker A: API task"]
  Root --> B["Worker B: UI task"]
  Root --> C["Worker C: docs task"]
  A --> Join["Completion review"]
  B --> Join
  C --> Join

Parallel work is safe when tasks have clear file and contract boundaries. If two tasks need the same unstable module, model the ordering in the graph instead of hoping merge conflict resolution will discover the design.