Repository navigation
Description
Summary
The merge-continuation hop now fires correctly, but the dispatch payload is destroyed by a schema-discovery probe. #1766's prompt-level WRITE-ONCE guard is not sufficient — the fixture was running the fixed worker and the agent probed anyway.
This is the same failure class as #1765, but in workflows/squad-implement-worker.md's ## Continue Parent Epic After Merge path rather than the router.
Evidence
Live run in bradygaster/aspiregregator-squad-e2e, 2026-08-20:
- PR Add @copilot coding agent as a Squad member type #13 (implementing child Please Don't Lock
squadinto using GitHub #8) merged. - Worker run 32394811753 →
success. It posted the correct visible next-step comment on the PR, so finding B's fix is working. - Worker's
agent/safeoutputs.jsonlcontains two entries, in this order:
{"type":"dispatch_workflow"}
{"type":"dispatch_workflow","inputs":{"command":"implement","issue_number":"5"},"workflow_name":"squad"}dispatch_workflowis configuredmax: 1. The collector keeps the first item, so the empty probe won and the real payload was discarded.- Dispatched Squad run 32395290857 →
success, but its own safe output was:
This workflow run was triggered via
workflow_dispatch, but the requiredcommandinput (github.event.inputs.command) was empty or not provided. […] there is no command to execute, so this run cannot proceed.
- Net effect: epic feat: Issue Assignment & Auto-Triage for Squad Members #5 got no new dispatch, child I don't see a tool called task in github copilot #9 was never picked up, and no comment was posted on the epic — the run looked green from the outside. This is the silent-no-op signature that has been unexplained across multiple sessions.
The fixture was NOT stale
Confirmed against bradygaster/aspiregregator-squad-e2e's installed .github/workflows/squad-implement-worker.md:
- Contains
probe or discover✅ - Contains the
FIRST … winslanguage ✅
So the worker carried #1766's fix and the probe happened regardless. Prompt instructions alone do not prevent this. The fix must be structural.
Why this matters
This is the exact hop that stalled the original epic. The earlier e2e proved the implement-dispatch hop (/squad implement → worker) is probe-free. It did not prove the merge-continuation hop, which is what this run finally exercised — and it fails.
Suggested direction (needs investigation, not prescriptive)
The root hazard is that a malformed item consumes the single max: 1 slot. Candidate approaches, in rough order of preference:
- Raise
maxfordispatch_workflowon the worker so a probe cannot destroy the real payload. Needs verification of what gh-aw does with a second dispatch and with a malformed/empty one — if empty entries are rejected at validation rather than dispatched, this is safe and cheap. - Assert the contract in CI — extend
test/gh-aw-quality.test.tsso the worker's continuation dispatch spec is pinned structurally, not just by prompt phrasing. - Post-dispatch verification — have the worker confirm its dispatch landed and fall back to
add_commenton the epic if not, so a swallowed dispatch can never present as green.
Do not simply strengthen the prompt wording again. That was #1766 and it did not hold.
Acceptance
- A merged child PR in
bradygaster/aspiregregator-squad-e2eresults in the epic receiving a dispatch that carriescommandandissue_numberintact. agent/safeoutputs.jsonlfor the worker run contains no emptydispatch_workflowentry, or the empty entry provably does not suppress the real one.- A regression test covers the contract so this cannot silently return.
- A run that fails to dispatch must not report success without a visible explanation.
Related
- dispatch_workflow schema probe swallows the real payload, stalling epic continuation #1765 / Prevent dispatch_workflow schema probes #1766 — same failure class in the router; the prompt-only fix that proved insufficient here.
- Re-run the live e2e to prove the epic-continuation hop #1767 — the e2e re-run that surfaced this.
Goal and Success Criteria
Added 2026-08-20 during wave:1 triage. Criteria must be checkable from run artifacts without re-running.
Goal: When a child PR merges in the E2E fixture, the Squad epic always receives a dispatch_workflow call carrying command=implement and issue_number=<epic> as inputs — never an empty no-op that presents as green.
SC-1 — Structural guard on dispatch slot (no max: 1 without payload validation).
squad-implement-worker.md's Continue Parent Epic section has max: 1 removed or replaced by a structural guard that rejects an empty payload before consuming the slot. Fails if max: 1 remains at line 204 with no compensating structural check.
SC-2 — Compile-time test pins the dispatch contract (not wording).
test/gh-aw-quality.test.ts asserts the worker's continuation dispatch step has command and issue_number as required inputs, parsed structurally (not substring). Fails if the only coverage for this step is the existing lines 1069-1081 (wording presence only).
SC-3 — E2E artifact shows no empty dispatch entry winning the slot.
In a post-fix run, agent/safeoutputs.jsonl for the worker run contains no {"type":"dispatch_workflow"} entry that precedes the real payload entry, OR the real payload is the sole surviving entry. Fails if an empty dispatch entry appears first in the file and the dispatched Squad run receives no command input.
SC-4 — A failed dispatch is never silent.
If the worker run dispatches Squad and Squad receives an empty command, the worker posts a visible comment on the epic before exiting. Fails if a no-op Squad run exits green with no comment on the parent epic.
Activity
bradygaster commentedon Aug 20, 2026
Flight sequencing note — revised graph anchor, 2026-08-20.
Wave: 1, highest-value correctness fix.
Depends on: nothing open in this stream. #1766 is merged, and #1767 proved the implement-dispatch hop is clean before surfacing this merge-continuation defect.
Blocks:
bots:/trigger semantics while the current merge-continuation path is known red.Safe to run in parallel with: #1770, #1760, #1761, #1762, #1768, #1756, #1759, and #1748 after #1762. It touches
workflows/squad-implement-worker.md, not the mainworkflows/squad.mdprompt blocks. Avoid overlapping with any other change to the worker safe-output/continuation section.Why / evidence:
workflows/squad-implement-worker.mdcurrently allows only onedispatch-workflowitem at lines 202-205. The continuation prompt tries to forbid probes at lines 226-233, and tests only pin that prompt wording attest/gh-aw-quality.test.tslines 1069-1081. The latest #1767 outcome showed the fixture had that wording but still emitted an empty{"type":"dispatch_workflow"}before the real payload;max: 1kept the probe. That makes this a structural defect, not another prompt-polish task.Revised wave table
aspiregregator-squad-e2eis now the honest fixture.workflows/squad.mdhunks: research lines 577-609 vs plan lines 611-637 and implementation lines 832-863.bots:decision. #1772 does not provebots:is wrong, it removes the known payload-loss defect before trigger semantics are changed.Current hard edges
Removed/kept-out edges: #1767 does not depend on #1768 and is now closed; #1768 blocks nothing. #1770 blocks nothing. #1760 blocks no numbered issue here. #1763 is deferred because the workflow-dispatch activation path is still hazardous; #1772 strengthens that deferral by showing the baseline is currently red, but it does not change the hazard's cause from workflow-dispatch/trigger semantics to bot slash comments.
bradygaster commentedon Aug 20, 2026
Prior decision record — relevant guardrail, now merged
While draining
.squad/decisions/inboxI found an unmerged Booster decision record that bears directly on this issue. It is being merged into.squad/decisions.mdin #1773 so it survives a fresh clone. Summarizing here because it proposes the structural direction this issue needs.It documents an earlier, different failure against the same single-slot dispatch budget. In run
32316227601the agent called the genericdispatch_workflowsafe-job with top-level keys:{"command":"implement","issue_number":"5"}while the compiled schema expected
workflow_nameplus a nestedinputsobject. Result: the call was accepted and Squad was dispatched with no inputs. Contributing cause — the compiled prompt's safe-output tool summary advertised the genericdispatch_workflow, so the prompt and the visible schema disagreed.That specific shape error was fixed. This issue is a distinct failure mode — a well-formed payload preceded by an empty probe that consumes the single slot. Same budget, same silent-success outcome, different cause. Worth keeping distinct so a fix for one is not mistaken for a fix for both.
The decision's guardrail clause is the part worth carrying forward:
Two things follow for this issue:
scripts/check-workflow-input-interpolation.mjsalready exists from fix(workflows): interpolate dispatch inputs so merge continuation resolves the epic #1741. Extending that class of gate is more consistent with how this repo has handled the problem than adding another prompt assertion.workflows/squad.mdmust not defaultworkflow_dispatch.inputs.commandtocast, because that masks a missing input instead of surfacing it. That is the same principle as this issue's acceptance criterion that a run which fails to dispatch must not report success without a visible explanation. Whatever fix lands here should not reintroduce a masking default.Note the existing test at
test/gh-aw-quality.test.ts:1069-1081asserts only that the continuation prompt contains the anti-probe wording. The live run confirmed that wording was present and the probe happened anyway, so that test cannot detect this class of defect.github-actions commentedon Aug 20, 2026
📋 Assigned to EECOM (Core Dev)
Issue: #1772 — Merge-continuation dispatch destroyed by empty schema probe; #1766's prompt guard is insufficient
EECOM will pick this up in the next Copilot session.
Fix long-path planning lifecycle defects + guard empty dispatch probe…
fix(dispatch): raise max to 2 and add schema static gate (github#1772) (
fix(gh-aw): refill dispatch slots from the root, not the parent epic (#…