Generated plan has validation errors

The refinement service validates the plan it just generated and throws with the collected messages when validation fails.

if (!validation.valid) {
  throw new Error(
    `Generated plan has validation errors: ${validation.errors.map(e => e.message).join('; ')}`
  );
}

Validating your own output

It would be reasonable to assume a plan produced by the planner is well-formed. It is not a safe assumption, and this check is the reason the assumption is never made.

A model asked for a dependency graph can produce a cycle, reference a task that does not exist, or assign the same file to two tasks in one wave. Every one of those parses as valid structure and is invalid as a plan — which is exactly the distinction validation exists to enforce, and it applies regardless of who wrote the plan.

The errors are joined, not truncated

All validation messages are concatenated rather than reporting the first. A plan with three problems should surface three, because fixing one and re-running to discover the next is the slow path — and each re-run costs a model call.

What it catches

Cycles in the dependency graph, tasks referencing unknown dependencies, file ownership conflicts within a wave, and empty or degenerate structures.

How to fix it

Read the joined messages — they name the specific tasks. A cycle is the most common, and it has its own page because it is also the most common way a hand-written plan fails.

If refinement produces invalid plans repeatedly for one spec, the spec is usually the problem: an ambiguous dependency described in prose gives the planner room to infer an edge that closes a loop.