Flow validator should check step data dependency ordering

[ameet]

Description

`one --agent flow validate` checks for undefined step references (e.g., `$.steps.X` where step X doesn't exist), but does NOT check that step X executes before the step that references it.

This causes silent bugs when:

• A cache write step (`buildCacheEntry`) references a result step (`buildResult`) that comes after it in the step array
• The cache entry is written as `null` because the result hasn't been computed yet

Reproduction

{
  "steps": [
    {"id": "buildCacheEntry", "type": "code", "code": {"source": "return $.steps.buildResult.output;"}},
    {"id": "buildResult", "type": "code", "code": {"source": "return {data: 'hello'};"}}
  ]
}

`one --agent flow validate` returns `{"valid": true}` even though `buildCacheEntry` references `buildResult` which hasn't run yet.

Impact

Cache entries get written as `null` or `undefined`, causing downstream cache hits to return empty data. The bug is silent — no error, no warning. Subsequent runs read the poisoned cache and produce empty results.

Suggested Fix

During validation, build a dependency graph from step references (`$.steps.X`). Flag any step that references a step with a higher index in the steps array (i.e., a forward reference).

[raye-deng]

This is a great catch. The validator checks structural correctness (references point to existing steps) but not temporal correctness (references point to steps that have already executed). The code is structurally valid but semantically broken.

This pattern — "correct shape, wrong order" — is one of the most common classes of bugs in AI-generated workflows. The agent builds a valid step graph where every $.steps.X reference resolves to an existing step ID, but the execution semantics are wrong because step dependencies aren't modeled.

We see a very similar pattern in CI pipelines: AI agents generate GitHub Actions workflows where a step references an output from a later step. YAML validates fine, the pipeline starts fine, but the dependent step gets null and either fails silently (writes bad data) or fails loudly (crashes the pipeline). The worst case is the silent one — null gets propagated through subsequent steps and corrupts downstream state.

For this specific case, a topological sort of the step dependency graph (parse all $.steps.X references, build a DAG, verify edges only point backward) would catch it deterministically. No heuristics needed.

On our side, we validate step ordering and data flow in AI-generated CI configs as part of PR scanning. npx @opencodereview/cli scan . --sla L1 if you want to see what dependency-order validation looks like in practice.