Skip to content

🐛 Fix parallel task groups finishing without commits - #6

Open
velles wants to merge 2 commits into
mainfrom
fix/step3-parallel-commit-gate
Open

🐛 Fix parallel task groups finishing without commits#6
velles wants to merge 2 commits into
mainfrom
fix/step3-parallel-commit-gate

Conversation

@velles

@velles velles commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

✨ What's New

  • 💾 Task groups that run in parallel now actually get committed — previously a run could implement everything correctly, report success, and leave all the work sitting uncommitted
  • 🔒 A group is no longer considered done until its commit exists, and the next batch of work won't start while the previous one is uncommitted
  • 🧾 A finished run refuses to call itself delivered while any work is still uncommitted
  • ⚡ Parallel execution stops collapsing into sequential execution — shared test suites are now accounted for when planning what can run at the same time, instead of being discovered too late
  • 🧭 Work that two groups would otherwise both edit gets an explicit single owner, decided during planning rather than improvised during execution
  • 🩹 Two groups updating the same context file no longer risk one silently discarding the other's changes
  • 📣 Any decision to run groups sequentially now has to say which file forced it and why

🧪 Test Plan

  • Run an autonomous implementation on a spec with several independent task groups and confirm each group lands its own separate commit
  • Confirm the working tree is clean between batches of parallel work, and at the end of the run
  • Confirm a run cannot report completion while changes remain uncommitted
  • Scope a spec where several groups touch the same shared test suite, and confirm the plan names a single owner instead of quietly running everything one at a time
  • Confirm groups sharing only a context file are still scheduled to run at the same time
  • Run the repository test suites and confirm all pass

🤖 Generated with Claude Code

velles and others added 2 commits August 19, 2026 12:03
@velles @claude
step3-implement-tasks: make the per-group commit a gate, not a footnote
53d3918 
In a parallel wave the orchestrator never committed. Two instructions
cancelled each other out: commit each group after verifying it, but ask
before staging when uncommitted changes exist outside the group's scope
— which in a parallel wave is every sibling group still in flight. With
no way to attribute the mixed working tree to a group either, deferring
was always the safe reading, so runs finished with the work uncommitted
and still reported success.

- State the commit invariant up front in orchestrated execution: a group
  is incomplete until its commit exists, commits are never batched, and
  no wave is dispatched while the previous one is uncommitted.
- Require a clean baseline before each wave, so every dirty path
  afterwards is attributable. This is the only place the don't-sweep-up
  rule is asked, and carried-over dirt is recorded once as a run
  baseline instead of re-prompting each wave.
- Give staging an explicit procedure per wave shape, with a staged-set
  check before commit and a commit receipt in the group report.
- Make executors report an exhaustive changed-file manifest, written
  into group-N-updates.md in parallel waves — plans go stale, and a path
  the plan never listed was silently going uncommitted.
- Close each wave on a clean tree; unclaimed paths are amended into the
  owning commit or surfaced, never rolled into the next group's commit.
- Finalize now refuses to call a run delivered with work still in the
  tree.

Ten assertions in test_skill_content.sh pin the gate.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@velles @claude
step2-scope-tasks: schedule waves across the test surface, not just s…
5907658 
…ource

Parallel waves were collapsing at execution time. step2 declared groups
disjoint on source files, then step3 validated against the real plans and
found the test layer wasn't disjoint at all — every group had repaired
assertions in the same few project-wide suites — and serialized them. A
five-group wave became three sequential ones.

step2 now scopes the surface that actually contends:

- Research subagents report the shared test surface — cross-cutting
  suites, snapshots, fixtures, test-utils — and which of them the
  feature's changes will invalidate.
- Groups are carved against that surface. New tests never contend; stale
  assertion repairs in pre-existing shared suites do. Resolve by
  splitting the suite, giving it a single owner, or serializing — in
  that order.
- The resolution is recorded as a file-ownership rule in the Overview,
  covering shared test suites and fixtures rather than source files
  alone, and waves are justified across both surfaces.

step3 stops manufacturing collisions of its own:

- Wave disjointness no longer counts tasks.md or agents-context/. Parallel
  executors never write them — the orchestrator applies each group's
  updates at commit time — so serializing over a shared concept file
  costs real parallelism to avoid a conflict that cannot occur.
- Proposed edits to existing context files must be anchored rather than
  whole-file, so two groups' updates to one concept file compose instead
  of the second discarding the first. This is what made the exemption
  safe.
- Every serialization now names the file, the groups, and the reason;
  unexplained ones read as dependencies and get copied into the next spec.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@velles