feat(ship): run independent decompose-and-implement sub-tasks concurrently - #651
Merged
Merged
Conversation
…ently decompose-and-implement-loop.workflow.mjs always ran a High-risk+Large unit's sub-tasks strictly sequentially, one coding agent at a time on the same branch, even when a sub-task's dependsOn declared it had nothing to do with another. On a large plan (observed: #630 phase 7, 7 sub-tasks) that means real wall-clock time even when several sub-tasks are genuinely independent. Group sub-tasks into dependency-ordered waves from their existing dependsOn graph. A wave of one sub-task runs exactly as before, directly on the unit branch. A wave of more than one runs those sub-tasks concurrently, each in its own isolation:"worktree" on its own wip/<unit>-<id> branch, since none of them can see another's edits until merged. After a concurrent wave, one integration agent merges every branch into the unit branch in that wave's order and gates the merged result before the next wave starts; a merge conflict there means the sub-tasks' declared file scopes were not actually disjoint and is treated as a real planning defect (error status), never forced through. dependsOn is the only signal driving this — the decomposition prompt now tells Fable to favor adding a dependsOn edge whenever it isn't fully confident two sub-tasks are safe to run at the same time, so a plan with sparse dependency information still comes out mostly or fully sequential, matching today's behavior, and only a genuinely independent plan gets real concurrency. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LwFPT465eDJqYcRa8HGNLz
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
decompose-and-implement-loop.workflow.mjsalways ran a High-risk+Large unit'ssub-tasks strictly sequentially — one coding agent at a time on the same branch —
even when a sub-task's own
dependsOndeclared it had nothing to do with another.On a large plan (#630 phase 7, 7 sub-tasks) that costs real wall-clock time (~107
minutes) even when several sub-tasks are genuinely independent.
What changed
dependsOngraph (a plain topological pass, no new field). A wave of onesub-task runs exactly as before, directly on the unit branch. A wave of more
than one runs those sub-tasks concurrently, each in its own
isolation: "worktree"on its ownwip/<unit>-<id>branch, since none of themcan see another's edits until merged.
unit branch in that wave's order (
git merge --no-ff) and gates the mergedresult before the next wave starts. A merge conflict there means the sub-tasks'
declared file scopes were not actually disjoint — treated as a real planning
defect (
errorstatus), never forced through.dependsOnedgewhenever it isn't fully confident two sub-tasks are safe to run at the same
time —
dependsOnis the only signal driving concurrency, so a plan withsparse dependency information still comes out mostly or fully sequential
(today's behavior unchanged), and only a genuinely independent plan gets real
concurrency. This matches the skill's existing "when in doubt, serialize"
principle for wave-planning at the unit level, applied one level down to
sub-tasks.
SKILL.mdstep 2.3 updated to describe the new wave/integrate mechanics.Verification
No dedicated test harness exists for
.workflow.mjsscripts elsewhere in thisskill (none of the other reference scripts have one either) — verified by careful
review of the control flow, in particular:
phase('Implement')is re-asserted at the top of every wave iteration so aprior wave's
phase('Integrate')label doesn't leak into the next wave'ssolo-sub-task agent call.
PARALLEL_TASK_SCHEMA/INTEGRATE_SCHEMAadditions are additive; thesingle-sub-task-per-wave path (today's common case) is otherwise byte-for-byte
the original prompt/logic, so existing behavior for a fully-sequential plan is
unchanged.
Full repository gate green (
check:types/check:arch/check:schemas/check:examples/npm test/npm run build) — this change touches onlyskills/**, outside the coverage-gatedsrc/**tree.Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01LwFPT465eDJqYcRa8HGNLz