Infer dependencies only from fields the runtime renders

[jeremymanning]

Addresses critical finding 1 from review: dependency inference scans fields that never render.

Reproduced verbatim

- id: a
  name: "{{ b.result }}"
- id: b
  name: "{{ a.result }}"

Dependency cycle detected: a -> b -> a

Task names are copied verbatim. Nothing substitutes into them. Two inert strings produced a hard compile error.

Cause — mine, in #466

The canonical graph used a blocklist: scan every step key except id, dependencies and the control-flow keys. I wrote the accompanying comment — "everything else the step carries that may hold a template" — without checking what the runtime actually renders.

Because that graph now drives scheduling and execution levels as well as cycle detection, a spurious edge does more than warn: it serialises independent work, invents cycles, and misreports which dependencies were inferred.

The allowlist, derived from the runtime

core/step_fields.py. Every entry cites the code that renders it:

field	evidence
parameters	ControlSystem._render_task_templates deep-renders it (control_system.py:363)
action	same function, when it is a string (:367)
location	kept as location_template, resolved when the output is recorded — which is why real examples write location: "./reports/{{ inputs.topic | slugify }}.md"

Nested steps are recursed into and attributed to the enclosing step, since a child is not scheduled independently of its parent. Control-flow keys are renderable too, but are inferred separately so their edges keep the more precise control_flow origin.

The inert set is named explicitly rather than left implied by absence, so a future reader sees the reasoning instead of inferring it from a gap.

Both directions are pinned

Each has already happened in this repo:

• scanning too much → false cycles (this bug)
• scanning too little → Pipeline validates, then cannot run: inferred dependencies are computed and discarded #465, where a step ran before the value it needed existed, having passed validation

The catalogue guards the first. examples/supported/ — which actually execute — guard the second.

Verification

• Mutation: reverting to the blocklist fails 7 of 14 new tests, including the CLI-level reproduction (the unit tests call build_dependency_graph directly; the CLI goes through ControlFlowCompiler, and One graph decides what runs before what #466 shipped with a mutation only one of those caught)
• Blocking suite: 882 passed, 13 skipped
• Lint: clean
• Catalogue: all 52 listed examples still validate — no edge dropped

Not in this PR

The surviving warning on the repro says {{ b.result }} in name: "will be resolved at runtime" — precisely what will not happen. The template validator has the same too-broad field notion, and should consume this same declaration. Next, alongside the loop-binding contracts.

🤖 Generated with Claude Code