Summary
When dispatching a feature-execute wave, the agents' generated prompt files cite a JSON output shape that fails the canonical scripts/agent-output.schema.json validator at swarm collect time. The mismatch is in two places:
-
stage field — lib/templates.js's PHASE_TO_STAGE only maps health-audit-a/b/c and stage-d-audit. For other phases (including feature-execute), the template falls back to opts.phase.toUpperCase(), producing "stage": "FEATURE-EXECUTE". But agent-output.schema.json enforces stage ∈ {A, B, C, D} (the schema description: "Health-pass stage (audit outputs only). Optional in feature/amend outputs"). Validation fails: /stage must be equal to one of the allowed values.
-
Required fixes[] + files_changed[] — agent-output.schema.json's oneOf branches require fixes[] + files_changed[] for amend/feature-execute outputs. The template doesn't include these in the example JSON shape it shows agents, so agents that follow the prompt template literally produce outputs missing those fields. Validation fails: "fixes" must be an array.
Reproduction
In a fresh swarm run (any repo):
swarm dispatch <run-id> feature-execute
# inspect any wave-N/<domain>.md prompt — note "stage": "FEATURE-EXECUTE" in the example JSON, no fixes[] / files_changed[]
# run agents, collect their outputs
swarm collect <run-id> --domain=<domain>:<path>
# fails with stage validation error, then fixes[] error
Discovered while running rig-bridge's Phase 6 swarm against mcp-tool-shop-org/rig-bridge (run swarm-1777510208-621a). Wave 3 + 4 hit invalid_output blocked state; wave 5 collected after manual JSON edits (drop stage, add fixes: [], add files_changed: []).
Suggested fix
Two coordinated edits in packages/dogfood-swarm/lib/templates.js:
- Drop
"stage": "${PHASE_TO_STAGE[opts.phase] || opts.phase.toUpperCase()}", for non-audit phases (or only emit stage when the phase IS in PHASE_TO_STAGE).
- Add
"fixes": [], and "files_changed": [], to the example JSON shape when phase is feature-execute or *-amend-*.
The schema description already documents the correct shape ("audit outputs add findings[]; feature outputs add features[]; amend outputs add fixes[] + files_changed[]"). The templates just need to follow it.
Why this matters (intra-workspace downstream audit)
Per feedback_intra_workspace_downstream_audit.md family thinking — schema spec and dispatch templates drifted from each other within the same workspace. The schema is canonical; the template is the consumer; the consumer doesn't follow the spec. Future swarm runs hit this until the templates catch up.
Files:
packages/dogfood-swarm/lib/templates.js (templates with the drift)
scripts/agent-output.schema.json (canonical schema — correct as-is)
packages/dogfood-swarm/lib/state-machine.js:42 (invalid_output is terminal-blocked, so once an agent hits this, the wave can't recover without a fresh dispatch)
Workaround (not a fix)
Each new wave dispatch reuses the prior wave's correctly-edited JSON outputs. Rig-bridge's Phase 6 ate 3 wave numbers (3 → 4 → 5) before collecting cleanly.
Summary
When dispatching a
feature-executewave, the agents' generated prompt files cite a JSON output shape that fails the canonicalscripts/agent-output.schema.jsonvalidator atswarm collecttime. The mismatch is in two places:stagefield —lib/templates.js'sPHASE_TO_STAGEonly mapshealth-audit-a/b/candstage-d-audit. For other phases (includingfeature-execute), the template falls back toopts.phase.toUpperCase(), producing"stage": "FEATURE-EXECUTE". Butagent-output.schema.jsonenforcesstage ∈ {A, B, C, D}(the schema description: "Health-pass stage (audit outputs only). Optional in feature/amend outputs"). Validation fails:/stage must be equal to one of the allowed values.Required
fixes[]+files_changed[]—agent-output.schema.json'soneOfbranches requirefixes[]+files_changed[]for amend/feature-execute outputs. The template doesn't include these in the example JSON shape it shows agents, so agents that follow the prompt template literally produce outputs missing those fields. Validation fails:"fixes" must be an array.Reproduction
In a fresh swarm run (any repo):
Discovered while running rig-bridge's Phase 6 swarm against
mcp-tool-shop-org/rig-bridge(runswarm-1777510208-621a). Wave 3 + 4 hitinvalid_outputblocked state; wave 5 collected after manual JSON edits (dropstage, addfixes: [], addfiles_changed: []).Suggested fix
Two coordinated edits in
packages/dogfood-swarm/lib/templates.js:"stage": "${PHASE_TO_STAGE[opts.phase] || opts.phase.toUpperCase()}",for non-audit phases (or only emitstagewhen the phase IS inPHASE_TO_STAGE)."fixes": [],and"files_changed": [],to the example JSON shape when phase isfeature-executeor*-amend-*.The schema description already documents the correct shape ("audit outputs add findings[]; feature outputs add features[]; amend outputs add fixes[] + files_changed[]"). The templates just need to follow it.
Why this matters (intra-workspace downstream audit)
Per
feedback_intra_workspace_downstream_audit.mdfamily thinking — schema spec and dispatch templates drifted from each other within the same workspace. The schema is canonical; the template is the consumer; the consumer doesn't follow the spec. Future swarm runs hit this until the templates catch up.Files:
packages/dogfood-swarm/lib/templates.js(templates with the drift)scripts/agent-output.schema.json(canonical schema — correct as-is)packages/dogfood-swarm/lib/state-machine.js:42(invalid_outputis terminal-blocked, so once an agent hits this, the wave can't recover without a fresh dispatch)Workaround (not a fix)
Each new wave dispatch reuses the prior wave's correctly-edited JSON outputs. Rig-bridge's Phase 6 ate 3 wave numbers (3 → 4 → 5) before collecting cleanly.