Cannot create a flat plan from an empty task list

createFlatPlan is the fallback used when the full planner is unavailable or its output could not be used. It builds a single wave containing every task, and it refuses to run on an empty list.

Why empty is an error and not an empty plan

Returning a valid plan with zero tasks would be the accommodating choice and it is the wrong one. Downstream, an empty plan is indistinguishable from a plan that finished — waves complete, metrics settle, the item is marked done, and no work was ever performed.

The failure is silent and it looks like success on every dashboard.

Almost every empty collection reaching this function is the residue of an earlier failure: a parse that produced nothing, a spec that yielded no tasks, an upstream call that returned an error the caller swallowed. Refusing here surfaces that failure at its origin.

The sibling error

Cannot create flat plan from empty descriptions list is the same guard on the other entry point, which builds a plan from plain descriptions rather than parsed tasks. Same reasoning, same refusal.

How to fix it

Look upstream, not here. The question is why the task list is empty, and the answer is almost never "there was genuinely nothing to do" — that case does not usually reach a planner at all.

Check whether the spec parsed, whether the model returned anything, and whether an error earlier in the chain was logged and then discarded.

Why the fallback exists at all

The flat plan is what runs when the real planner cannot. It puts everything in a single wave and declares it all parallel, which is deliberately naive — it makes no claim about dependencies because it has no basis for one.

That is safe only when a human reviews it. A flat plan dispatched unreviewed will run tasks concurrently that should have been ordered, and the guard here does not protect against that. It protects against the narrower case of producing a plan from nothing at all.