Repository navigation
Description
Origin
Surfaced by Procedures during the implementation of #1758 defect 2 (PR #1778). The dispatch side of defect 2 is fixed in that PR: squad.md now descends the sub-issue tree recursively and dispatches only leaf tasks, never Epics. The refill side — what the worker does after a task completes — is a separate responsibility that lives in workflows/squad-implement-worker.md (owned by EECOM, relevant to #1772). Procedures correctly did not touch that file.
The Defect
squad-implement-worker.md's "Continue Parent Epic After Merge" section refills the freed dispatch slot by looking at the immediate parent epic's remaining sub-issues. In a 2-level hierarchy (Root → Tasks) this is fine. In a 3-level hierarchy (Root → [Epic A, Epic B] → leaf Tasks), it fails:
- Task under Epic A completes. Worker looks at Epic A's sub-issues for the next task.
- Epic A's remaining tasks fill the freed slot — correct.
- Epic A's last task completes. Worker looks at Epic A's sub-issues — finds none unstarted.
- Worker exits without dispatching. Epic B still has pending tasks, but the worker never looked there.
- The concurrency slots sit idle. No error is surfaced. The run completes green.
This is the same silent-no-op failure signature as #1772 — looks green, work is stalled.
What Was Fixed in #1778 (not this issue)
squad.md's activation dispatch now recursively walks the full sub-issue tree and hands out leaf tasks up to the 3-slot concurrency cap. That covers the initial distribution across all epics. This issue is exclusively about the refill behavior after a task merges.
Failure Precondition
Requires a 3-level hierarchy with at least two epics, where one epic's tasks are fully dispatched before the other's. In the current aspiregregator-squad-e2e fixture (epic #5, single remaining child #9), this failure shape is not reachable tomorrow — S6 would need a fresh multi-epic root to trigger it. This is a known limitation Sims should record if S6 is run with a full 3-level hierarchy.
Goal
After a task merges, the implement-worker dispatches the next unstarted leaf task from anywhere in the root epic's sub-tree — not only from the completing task's immediate parent epic — so that concurrency slots are never idle while work remains.
Success Criteria
SC-1 — Refill queries the full subtree, not the immediate parent.
squad-implement-worker.md's continuation section constructs the next-task candidate list by querying the root epic's full sub-issue tree (all descendants), not by querying parent_issue.sub_issues directly. Fails if the refill step queries only the immediate parent epic's open children.
SC-2 — No idle slots when sibling epic has pending tasks.
Given a 3-level hierarchy with two epics (Root → [Epic A, Epic B] → leaf Tasks), after all of Epic A's tasks have been dispatched, the worker run triggered by Epic A's last task completing dispatches the first unstarted leaf task from Epic B. Fails if the worker run exits without a dispatch call while Epic B still contains at least one open, unstarted task.
SC-3 — Test covers cross-sibling refill structurally.
test/gh-aw-quality.test.ts (or a companion file) contains a test that validates the continuation dispatch step searches the full sub-tree. Fails if the only coverage for this step remains the current wording-presence assertion — a substring check does not satisfy this criterion.
Related
- Repair the long program path so it runs end to end #1758 — parent defect; defect 2 fixed in Fix long-path planning lifecycle defects + guard empty dispatch probe (squad.md) #1778 (dispatch side only)
- Fix long-path planning lifecycle defects + guard empty dispatch probe (squad.md) #1778 — PR where this residual was identified and explicitly deferred
- Merge-continuation dispatch destroyed by empty schema probe; #1766's prompt guard is insufficient #1772 — owns
squad-implement-worker.md; the refill logic is in that file
Activity
bradygaster commentedon Aug 20, 2026
Correction to deferral rationale (Sims, 2026-08-20):
The reasoning recorded when this was filed contained a false premise. Correcting it so M3 picks this up with an accurate priority signal.
What was written: S6 would not reach this failure because the existing fixture (epic #5, child #9) is a pre-existing 2-level hierarchy. Therefore the stall shape is not reachable tomorrow.
What is actually true: S6 builds a fresh hierarchy from scratch — the plan runs the full research → triage → plan → accept → activate path on a new epic. So the fixture shape is not the constraint. The stall is deferred because of epic scope, not fixture flatness.
The real reason the trigger is not reachable in S6: the planned S6 prompt is a trivially-bounded epic (2–4 tasks, single workstream, no natural partition into parallel tracks). A plan run at that scale produces either direct leaf tasks or a single intermediate epic — it does not naturally produce two or more sibling epics each with leaf tasks. One sibling epic is not sufficient to trigger this defect; you need at least two, with one exhausting its tasks before the other's tasks are started.
FIDO is adding an explicit scope constraint to the S6 runbook to keep the epic prompt below that threshold. That is the mitigation, not a structural fix.
Why this distinction matters for M3: 'Deferred because the fixture happened to be flat' implies the bug is rare and situational. The actual situation is: the bug is live and reachable the moment someone plans a realistically-sized epic that Squad naturally divides into parallel tracks. That is a materially higher urgency within M3 than the original rationale suggested.
Trigger condition (also the repro recipe and the shape of the regression test):
This is the shape the SC-2 criterion was written for. The regression test should construct exactly this scenario.
docs(e2e): add E4 agent-binding verification procedure for #1784 (#1791)
docs(e2e): record E4 agent-binding verification result (PASS, n=1) (#…
fix(gh-aw): refill dispatch slots from the root, not the parent epic (g…