workflows: the planner must admit it cannot route, and a for node inverts the envelope rule

[jklaassenjc]

Two of five findings from a self-directed test pass. A third is deliberately not here, and why is the most useful part of this PR.

1. The planner silently defaulted a data-driven switch — the one worth acting on

pickBranch called evalBool and, on error, discarded it and fell through to the default branch.

A when reading a prior step's response body cannot be evaluated without one — which is what all four corrected templates do. So the plan confidently named the default branch, and compare_run then reported every run that branched otherwise as ran-but-planned-skip.

That is the verdict the tool's own how_to_read calls "the direction worth acting on", and unresolved stayed 0 while it happened.

The proof it was not evaluating at all: the plan was identical across two runs with opposite data, agreeing with the second by accident.

The if-guard path had always reported this honestly, so there was a correct reference implementation sitting next to the defect. Now:

• an unevaluable when leaves that switch's targets unresolved, not skipped
• the switch reports cannot route: with the expression and the evaluation error
• a switch the planner can evaluate still routes
• a default is still chosen when every when evaluated and none matched — that is a decision, not an inability to decide

The last two are pinned, because a fix that blinded the planner to all switches would be worse than the bug.

2. A for node inverts the envelope rule

Established by running both outcomes:

outcome	node_output	iteration_count
loop completed	null	7
loop failed	populated	1

Every other node type means "it ran" by carrying node_output. for was not known to State() at all, so a completed loop fell through to unknown — safe, but useless — while the rule as written would read a loop that iterated seven times as a step that never ran. On a fleet-wide sweep that is the difference between "we processed everyone" and "we processed nobody".

An empty loop is now skipped rather than ran, since reporting a run would hide an empty extract.

3. Not shipped: the branch-target lint, because the rule is wrong

The report proposed linting a branch target with no then, on the rule "once a switch routes, a branch target without an explicit then ends the run".

Building it surfaced the problem immediately: the warning fired on jc's own corrected deprovisioning template, where getManagerDetails is a branch target with no then and has two email tasks after it.

Rather than exempt the case that motivated the rule, I ran it. A workflow whose switch routes to a branch target with no then, followed by another task:

[ok] route              (Switch evaluated.)
[ok] branchTarget       GET /api/systemusers → 200
[ok] afterBranchTarget  GET /api/systemusers → 200

Fall-through happens. The corrected template is fine, and the lint would have fired on correct documents — which is how a check gets switched off.

Something did stop that pass's done task from running, and diagnosing it needs their DSL. But it is not the stated rule, and shipping a lint built on it would have made every converging workflow noisy.

Verification

Both shipped fixes mutation-verified. go test ./... green. Tenant left clean — the probe workflow was created, run, and deleted.

Refs KLA-485

🤖 Generated with Claude Code