Graph plan does not record a step's on: [...] filter, so graph show draws conditional edges as unconditional #537

Summary

nodus graph show (#534) draws every dependency edge as an unconditional arrow,
because the plan object it renders does not record a step's with { on: [...] }
dependency-outcome filter.

So this workflow:

workflow deploy {
    step build { return "ok" }
    step notify after build with { on: ["failed"] } { return "alerted" }
}

renders identically to one where notify runs on success. The diagram says
"notify depends on build", which is true, and implies "build then notify", which
is not.

The renderer deliberately does not guess — an unconditional arrow for a
conditional edge is a lie a diagram tells convincingly, and it is worse than no
diagram because it is persuasive. That decision is recorded in
src/nodus/orchestration/graph_render.py's module docstring and in
docs/runtime/TASK_GRAPHS.md § "What an edge means". This issue is about
removing the reason for it.

Where the information is lost

plan_graph() / _step_plan_from_graph() return:

{"workflow": ..., "graph_id": ..., "nodes": [...], "edges": [[a, b], ...],
 "levels": [...], "parallel_groups": [...], "tasks": {...}}

edges is a list of [source, target] pairs. The accepted-outcome set lives on
the task, is validated against JOIN_ON_STATES in
orchestration/workflow_lowering.py, and is not carried into the plan.

Fix direction

Carry the filter on the edge. The shape that keeps existing consumers working is
an additional key rather than a change to edges:

"edge_conditions": {"build->notify": ["failed"]}

or edges as 3-tuples behind a separate key. edges is public-ish — the CLI, the
tests, and anything reading plan_workflow() output consume it — so changing its
element arity is the more disruptive option and needs a CHANGELOG entry either
way.

Then graph_render can label the edge (build -->|failed| notify in Mermaid,
[label="failed"] in DOT) and the docstring caveat comes out.

Worth deciding at the same time: whether the default on set (the implicit
"completed") is rendered. Labelling every edge completed would be noise;
labelling only the non-default ones means the absence of a label carries meaning,
which needs saying in the docs.

Related

• TASK_STATUSES is seven values; JOIN_ON_STATES is the three a dependency can
  reach mid-run (completed, failed, skipped). Only the latter can appear on
  an edge, which bounds the label vocabulary usefully.
• cli: make the command surface data, and add graph show / doctor / completion #534 added the renderer and the caveat.

Affected versions

nodus graph show landed on main after v5.1.0. The underlying gap — the plan
not recording on: — predates it and affects any consumer of plan_workflow()
output, not just the renderer.