Subtasks: how a plan becomes units of work

The idea

Large changes are easier to build and check in pieces. Each piece is a scoped instruction an implementer can complete and commit by itself. The parent holds the approved approach, the branch and the pull request.

Where they come from

After you approve the approach, a read-only role called the task creator splits it. Every workspace now uses consolidated decomposition, where the cap is 8. A split that exceeds it is rejected rather than cut short, so nothing approved is silently left out.

By default, implementation starts right after the split. A workspace can turn that off: the parent then parks with a Ready to implement badge, you review the list, and you start the run yourself.

Lifecycle

Each unit moves from pending to in progress, then to done or failed. If one breaks, the parent stops too and its worktree is kept so you can inspect what happened. You can retry the failed piece once the cause is fixed.

Two narrow exceptions avoid needless failures. An empty result from the implementer triggers a single re-run. On a re-run where the recorded commit is already on the branch, an empty result is correct, and the existing commit is kept.

Rework

When the final build check fails on code, DevFlow adds a unit whose title starts with Rework, at most 2 times. The model analytics use these titles to measure how often each implementer model needed rework.

Failures caused by the environment, such as a missing toolchain, never start a rework. The run ends with a message naming what to fix instead.