🐛 Fix parallel task groups finishing without commits

docs/implementation.md

@@ -20,6 +20,8 @@ Three execution modes control how much human oversight the AI receives during im
 
 All task groups are pre-planned in parallel (one planner subagent per group produces `plans/group-N.md`), the adversarial-thinker challenges the plan batch, and an execution schedule of parallel **waves** is derived — groups share a wave only when they have no dependency on each other and disjoint file sets. You approve the batch and schedule, then execution runs with no human intervention. The main conversation acts as an **orchestrator**: each group is executed by a fresh executor subagent with a clean context; the orchestrator re-runs the group's tests itself, dispatches the implementation-reviewer + test-verifier pair in parallel, drives a bounded fix cycle on blocking findings (max 2 rounds, then it stops and asks you), and commits — one atomic commit per group.
 
+Committing is a gate, not a formality: a group is not complete until its commit exists, and the next wave is not dispatched while the current wave's work is uncommitted. Each wave starts from a clean working tree so every dirty path afterwards is attributable to a group in that wave; in a parallel wave the orchestrator stages each group's paths explicitly from the manifest its executor reported, never the whole tree, so concurrent groups still land as separate atomic commits.
+
 ```
         plan G1..G4 (parallel) → adversarial challenge → approve batch + waves
 Wave 1  G1 ⇒ executor → verify pair → commit

docs/workflow.md

@@ -33,7 +33,7 @@ Interactive Q&A session to gather requirements, then formalizes into a structure
 
 ### Step 2: Scope (`/lead-dev-os:step2-scope-tasks`)
 
-Breaks the spec into task groups with explicit context directives. Groups follow an explicit strategy recorded in `tasks.md`: **vertical slices** (preferred — each group a thin end-to-end increment that's demoable on its own and parallelizable during implementation) or **layers** (Database → API → Frontend, when the data model is the hard part). Each task group declares which files from `agents-context/` to load before executing, and reads as a complete user story — a plain-language goal and "done when" definition that a non-technical stakeholder can understand and verify. Produces `tasks.md` with atomic, implementable work items, including an **Execution Waves** map of which groups can safely run in parallel during implementation (no mutual dependencies, disjoint file sets).
+Breaks the spec into task groups with explicit context directives. Groups follow an explicit strategy recorded in `tasks.md`: **vertical slices** (preferred — each group a thin end-to-end increment that's demoable on its own and parallelizable during implementation) or **layers** (Database → API → Frontend, when the data model is the hard part). Each task group declares which files from `agents-context/` to load before executing, and reads as a complete user story — a plain-language goal and "done when" definition that a non-technical stakeholder can understand and verify. Produces `tasks.md` with atomic, implementable work items, including an **Execution Waves** map of which groups can safely run in parallel during implementation (no mutual dependencies, disjoint file sets). Disjointness is judged across the test surface as well as the source surface — shared test suites are the usual reason a schedule that looks parallel turns out not to be — and a file-ownership rule names the single owning group for anything two groups would otherwise both edit.
 
 ### Step 3: Implement (`/lead-dev-os:step3-implement-tasks`)
 

lead-dev-os/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lead-dev-os",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "Spec & context-driven framework for Claude Code development. Structured skills for product planning, spec writing, task scoping, and context-aware implementation.",
   "author": {
     "name": "CaptainMe-AI",

lead-dev-os/skills/step2-scope-tasks/SKILL.md

@@ -42,6 +42,13 @@ This skill does not write code or implementation plans — it produces `tasks.md
      feature flags, cross-cutting concerns)
    - Contention hot spots: files that several parts of the feature will
      all need to touch (these force sequential work)
+   - Shared test surface: pre-existing test files that assert
+     project-wide or cross-surface invariants — site-wide sweeps,
+     snapshot files, shared fixtures and test-utils — naming each one
+     and what it asserts. Say which of them this feature's changes will
+     invalidate. These are the most common cause of false parallelism:
+     every group writes its own new tests, but they all end up repairing
+     assertions in the same few shared suites.
    Do not propose a design — just report what exists.
    ```
 
@@ -60,6 +67,14 @@ This skill does not write code or implementation plans — it produces `tasks.md
 
 Whichever strategy you choose, keep each group's `Dependencies:` list minimal and honest — over-declared dependencies serialize execution for no reason. Use the research reports' contention hot spots when carving groups: if two candidate slices would both rewrite the same few files, either merge them or declare the dependency, rather than pretending they're parallel.
 
+**Carve against the test surface, not just the source surface.** Slices usually are disjoint in source and still collide in tests, because each one invalidates assertions in the same project-wide suite. A wave declared parallel on source files alone gets serialized later by `/lead-dev-os:step3-implement-tasks`, which validates disjointness against the real plans — so the contention has to be resolved here, while the groups are still being carved. New tests never contend (each group writes its own new test file); contention comes entirely from **repairing stale assertions in pre-existing shared suites**. For each shared suite the research reports flagged, pick a resolution in this order:
+
+1. **Split the suite** along the boundaries the groups already have (per-surface files), so each group owns a file outright. Best outcome — do this whenever the suite's sections separate cleanly. Make the split its own subtask in the earliest group that touches it.
+2. **Give the suite a single owner group.** Every assertion repair in that file belongs to the owner; any other group that needs one declares a dependency on the owner and lands in a later wave.
+3. **Serialize the contending groups** into different waves. Honest, but the most expensive — use it when neither of the above fits.
+
+Record the outcome as a **file-ownership rule** in the Overview: which groups exclusively own which shared source files, shared test suites, fixtures, and test-utils. Groups then treat files they don't own as read-only. Files under `agents-context/` are exempt — they never contend, because parallel executors don't write them at all (`/lead-dev-os:step3-implement-tasks` applies each group's proposed context edits itself at commit time).
+
 Each task group uses **hierarchical numbered subtasks**. The parent task (N.0) is the group's completion goal. Subtasks (N.1, N.2, ...) are the steps to achieve it.
 
 For each task group (except the final Testing group), follow a **test-first approach**:
@@ -145,12 +160,12 @@ If a relevant concept or standard file does NOT yet exist, the directive should
 - Groups must have explicit **dependency ordering**
 - Context directives reference **general guidance, not code** — concept files describe approaches, conventions, and decision rationale, never code snippets
 - The **final group is always "Test Review & Gap Analysis"** — reviews previous tests, fills critical gaps (up to 10 additional tests), runs feature-specific tests, then runs the full test suite ONCE as a final backstop (fix new failures, report pre-existing ones)
-- Include an **Execution Order** section at the end listing the recommended implementation sequence, with an **Execution Waves** subsection: waves of groups that can run in parallel during `/lead-dev-os:step3-implement-tasks`. Groups share a wave only when they have no dependency on each other (direct or transitive) AND their expected file sets are disjoint (per the research reports and contention hot spots). When every group depends on the previous one (e.g. layers), say so — one group per wave is an honest answer
-- Include an **Overview** section at the top with total task count
+- Include an **Execution Order** section at the end listing the recommended implementation sequence, with an **Execution Waves** subsection: waves of groups that can run in parallel during `/lead-dev-os:step3-implement-tasks`. Groups share a wave only when they have no dependency on each other (direct or transitive) AND their expected file sets are disjoint (per the research reports and contention hot spots). **File sets include test files** — new test files, pre-existing shared suites the group will repair, fixtures, and test-utils — not just source files; a wave justified on source files alone is the standard way a parallel schedule collapses at execution time. Files under `agents-context/` don't count toward disjointness. State the per-wave justification in terms of both surfaces, and cite the file-ownership rule for any shared file involved. When every group depends on the previous one (e.g. layers), say so — one group per wave is an honest answer
+- Include an **Overview** section at the top with total task count, the grouping strategy and its rationale, and — when any shared source file, test suite, fixture, or test-util is touched by more than one group — a **file-ownership rule** naming the single owning group for each
 
 ### Phase 4: Self-check, Review & Save
 
-Before presenting the result, verify `tasks.md` against the Rules for Task Groups above — every group has description, User Story, Done-when block, context directives, honest Dependencies, test-first subtasks, and Acceptance Criteria; the final group is Test Review & Gap Analysis; Overview records the grouping strategy; Execution Order includes the Execution Waves subsection. Fix any gap before showing the file.
+Before presenting the result, verify `tasks.md` against the Rules for Task Groups above — every group has description, User Story, Done-when block, context directives, honest Dependencies, test-first subtasks, and Acceptance Criteria; the final group is Test Review & Gap Analysis; Overview records the grouping strategy; Execution Order includes the Execution Waves subsection, and every wave holding 2+ groups is justified across both the source and the test surface. Fix any gap before showing the file.
 
 Display the following message to the user:
 

lead-dev-os/skills/step2-scope-tasks/template.md

@@ -10,6 +10,8 @@ Grouping strategy: [Vertical slices | Layers] — [one-line rationale]
 
 [brief summary of the task]
 
+**File-ownership rule (keeps waves parallel-safe):** [Include only when a shared file is touched by more than one group. Name the single owning group for each shared source file, test suite, fixture, and test-util — e.g. "`lib/shared-cta.ts` and `components/Nav.tsx` belong to Group 1 only. The site-wide `invariants.test.ts` suite belongs to Group 4 only; other groups that need an assertion changed there depend on Group 4 rather than editing it." Groups treat files they don't own as read-only. Omit this block entirely when nothing is shared.]
+
 ## Context Management
 
 ### Before Starting Each Task Group
@@ -216,10 +218,11 @@ Recommended implementation sequence:
 
 ### Execution Waves
 
-Groups in the same wave have no mutual dependencies and disjoint expected file sets — `/lead-dev-os:step3-implement-tasks` may run them in parallel after validating against the actual plans:
+Groups in the same wave have no mutual dependencies and disjoint expected file sets — `/lead-dev-os:step3-implement-tasks` may run them in parallel after validating against the actual plans. File sets cover the test surface as well as the source surface: new test files, pre-existing shared suites the group will repair, fixtures, and test-utils. Files under `agents-context/` are exempt — parallel executors never write them.
 
 - Wave 1: Task Group 1
-- Wave 2: Task Group 2, Task Group 3 — [why they're independent, e.g. "no shared files: Group 2 touches API only, Group 3 touches UI only"]
+- Wave 2: Task Group 2, Task Group 3 — [why they're independent on BOTH surfaces, e.g. "source: Group 2 touches API only, Group 3 touches UI only. Tests: each owns its own new suite; neither repairs a shared suite — `[shared-suite]` is owned by Group N per the file-ownership rule"]
 - Wave 3: Task Group 4 (Test Review & Gap Analysis — always last, always alone)
 
 [If groups form a strict chain (e.g. layers strategy), list one group per wave and say so.]
+[If a shared test suite forced two otherwise-independent groups into different waves, name the suite and say why it wasn't split or assigned an owner.]

lead-dev-os/skills/step3-implement-tasks/SKILL.md

@@ -32,7 +32,8 @@ Shared procedures used by more than one step:
 
 ## Hard rules (all modes, all steps)
 
-- **Executor subagents never commit** — the orchestrator commits after verifying each group's work. When groups ran in parallel, stage each group's files separately so each group still gets its own atomic commit.
+- **A task group is not complete until it is committed.** In orchestrated execution the orchestrator commits each group the moment it passes verification — never batched at the end of a wave or the end of the run, and never handed back to the user to do. An uncommitted tree at the end of an A-mode run is a failed run.
+- **Executor subagents never commit or stage** — the orchestrator commits after verifying each group's work. When groups ran in parallel, stage each group's files explicitly (never `git add -A`, `git add .`, or `git commit -a`) so each group still gets its own atomic commit, and never dispatch the next wave while the current wave's work is uncommitted.
 - **Never delete tests, weaken assertions, skip migrations, or use `--no-verify`** to get to green — in your own work or by accepting it from a subagent. Surface the failure instead.
 - **Bounded retries everywhere.** Test-failure fixes: 2 attempts. Verification fix cycles: 2 rounds. After the limit, stop and report — the user would rather debug a stuck group with you than inherit silently disabled tests.
 - **Check off tasks in `tasks.md` as each completes**, not in a batch at the end. This protects progress if the session is interrupted. Exception: executors running in a parallel wave never write `tasks.md` (or `agents-context/`) — they report completions via `plans/group-N-updates.md` and the orchestrator checks the boxes at commit time, so concurrent groups can't clobber each other's bookkeeping.

lead-dev-os/skills/step3-implement-tasks/steps/execute-direct.md

@@ -55,7 +55,7 @@ Atomic-commit policy:
 
 - **Default: one commit per task group.** The commit message describes what the group shipped (not how) and references the spec folder name.
 - **Optional sub-commits:** if a group has natural sub-units (e.g. a "primitives" sub-task that lands cleanly on its own, then "integration" on top), commit each sub-unit separately. Use judgment — if you can't summarize a sub-commit in one clean line, it isn't ready as its own commit.
-- **Don't sweep up unrelated changes.** If the user has uncommitted edits in files outside this group's scope, ask before staging anything.
+- **Don't sweep up unrelated changes.** Stage this group's paths, not the whole tree. If the user has pre-existing uncommitted edits in files outside this group's scope, ask what to do with them — but that question never postpones this group's commit: stage the group's own paths and commit them regardless.
 
 In **L** mode you may skip the auto-commit and let the user commit manually after the review gate.