Task graphs

Waiting for human means Labor0 is waiting for an active decision or response, a plan review, action on an open pull request, or active follow-up work.

Needs attention can mean a linked pull request was closed without merging. Review it on GitHub before deciding how to continue the task.

Read dependencies, parallel work, waiting states, and follow-up actions in a project graph.

Before you begin

Open a project with a task request. A graph is easiest to read when the requested outcome and the repository boundary are already clear.

Example graph

Suppose the request is “Add a focus style and prove it with an accessibility test.” Labor0 may represent it as related work such as:

1. Inspect the existing search control.
2. Update the focus style after inspection is ready.
3. Run the focused test after the implementation change.
4. Prepare review evidence after the check finishes.

The exact split is generated from the request. The important part is direction: a child that depends on an unfinished parent is expected to wait.

Procedure

1. Open Graph from the project navigation.
2. Start with the highest-level task and read its status before opening children.
3. Follow edges from prerequisites to dependent work. Waiting on graph means the dependency path is not ready; it is not by itself an execution failure.
4. Use the overview grouping: In Progress, Waiting for Human, Blocked by other tasks, and Done.
5. Open a node to inspect its details, plan, session, quality result, or next action.
6. When several nodes fail, repair the earliest failed prerequisite before retrying dependent nodes.

Status reference

Expected result

Every visible node has a status, and selecting it provides enough context to find its parent, children, task activity, or session. Parallel nodes may advance independently; dependent nodes should remain waiting until their prerequisites complete.

Permission guidance

Viewers can inspect graph progress; changing task state or approving work requires the project permission shown by the app.

Optional automatic approval

Graph-change auto-approval is off by default for every project. A project operator can change the default under Project settings > Plan mode > Graph-change auto-approval, and each prompt can choose Project default, Enabled, or Disabled. This is separate from coding-plan auto-approval: it controls whether a final, validated Graph update is committed, not whether a coding session's Plan Mode plan is approved.

Labor0 resolves the effective setting when it accepts a prompt. Prompts with the same resolved setting may be batched together, and that ON/OFF snapshot does not change if the Project default is edited later. When enabled, Labor0 commits the planner's proposed tasks and dependencies through the ordinary Graph validation path and starts newly ready work without waiting for a review notification.

If an automatic commit encounters a temporary availability problem, the preview shows Automatic approval retrying and review actions remain unavailable while Labor0 retries safely. If it still cannot finish, the preview shows Automatic approval couldn’t finish. Review the graph changes to continue. No planned change is discarded: inspect the pending preview, then use the ordinary Approve, Request changes, or Discard action. There is no separate manual retry action.

If the graph looks stale

Symptom: a node does not reflect the latest task state. Likely cause: the view has not refreshed or the task is waiting on another node. Safe recovery: refresh the project view, open the node and its newest activity, then use the app's reconcile action only if it is offered. Do not remove or retry a node merely because a valid dependency is still running.