Context
Observed while compiling a workflow set where one agentic workflow dispatches another (prd-decomposer -> repo-assist) during the March 8, 2026 autonomy hardening pass. The first gh aw compile pass failed, the second pass succeeded with no source changes.
Still reproducible on local gh-aw main at b2d8af754 (v0.53.4).
Problem
validateDispatchWorkflow() validates referenced workflows against files already present on disk. If the referenced workflow exists only as .md and is being compiled in the same batch, validation still fails with "must be compiled first".
This makes same-batch dispatcher dependencies compile-order dependent and can force a second pass when the dispatcher is processed before its target.
Location
pkg/workflow/dispatch_workflow_validation.go:61-108
pkg/workflow/safe_outputs_config_generation.go:121-137
Reproduction
- Create
b.md with a valid workflow_dispatch trigger
- Create
a.md with:
safe-outputs:
dispatch-workflow:
workflows:
- b
- Ensure
b.lock.yml does not already exist
- Run
gh aw compile in a directory where a.md is discovered before b.md
Expected: both workflows compile in one pass
Actual: a.md fails validation because b.lock.yml is missing, even though b.md is part of the same compile batch
Expected behavior
The compiler should resolve same-batch workflow dependencies and accept referenced markdown workflows that are about to emit .lock.yml in the current compile invocation.
Proposed fix
Two possible approaches:
Option A — batch-aware validation: Pass the compile set into validateDispatchWorkflow() so it can recognize same-batch .md targets as valid:
- build a map of markdown workflows that will emit
.lock.yml
- use that map in validation and
workflow_files population
- only require a pre-existing lock file for workflows that are not part of the current batch
Option B — topological compile ordering: Sort workflows by dispatch dependencies before compiling, so referenced targets are always emitted before their dispatchers:
- build a dependency graph from
dispatch-workflow.workflows references
- compile in topological order (targets before dispatchers)
- simpler than making validation batch-aware, but requires cycle detection
Environment
- Observed in production bootstrap tooling: v0.52.1 workflow set
- Still present on: local
main at b2d8af754 (v0.53.4)
Context
Observed while compiling a workflow set where one agentic workflow dispatches another (
prd-decomposer->repo-assist) during the March 8, 2026 autonomy hardening pass. The firstgh aw compilepass failed, the second pass succeeded with no source changes.Still reproducible on local
gh-awmainatb2d8af754(v0.53.4).Problem
validateDispatchWorkflow()validates referenced workflows against files already present on disk. If the referenced workflow exists only as.mdand is being compiled in the same batch, validation still fails with "must be compiled first".This makes same-batch dispatcher dependencies compile-order dependent and can force a second pass when the dispatcher is processed before its target.
Location
pkg/workflow/dispatch_workflow_validation.go:61-108pkg/workflow/safe_outputs_config_generation.go:121-137Reproduction
b.mdwith a validworkflow_dispatchtriggera.mdwith:b.lock.ymldoes not already existgh aw compilein a directory wherea.mdis discovered beforeb.mdExpected: both workflows compile in one pass
Actual:
a.mdfails validation becauseb.lock.ymlis missing, even thoughb.mdis part of the same compile batchExpected behavior
The compiler should resolve same-batch workflow dependencies and accept referenced markdown workflows that are about to emit
.lock.ymlin the current compile invocation.Proposed fix
Two possible approaches:
Option A — batch-aware validation: Pass the compile set into
validateDispatchWorkflow()so it can recognize same-batch.mdtargets as valid:.lock.ymlworkflow_filespopulationOption B — topological compile ordering: Sort workflows by dispatch dependencies before compiling, so referenced targets are always emitted before their dispatchers:
dispatch-workflow.workflowsreferencesEnvironment
mainatb2d8af754(v0.53.4)