✨ Add verification agents and parallel task execution

docs/implementation.md

@@ -8,22 +8,24 @@ nav_order: 4
 
 The implementation phase executes task groups produced by `/lead-dev-os:step2-scope-tasks`. Each task group contains context directives (which files from `agents-context/` to load) and atomic tasks derived from the spec. Templates and examples are co-located with each skill for reference.
 
-Three execution modes control how much human oversight the AI receives during implementation.
+The main conversation acts as the orchestrator of a small agent team: **planner** subagents (pre-plan groups in parallel), **executor** subagents (implement one group each in a fresh context), and three verification agents — an **implementation-reviewer** and a **test-verifier** that check every group before it's committed, and an **adversarial-thinker** that challenges the plans before code is written and attacks the finished feature before delivery.
+
+Three execution modes control how much human oversight the AI receives during implementation. The verification agents run in every mode; the modes differ in who acts on their findings — the orchestrator (bounded fix cycles) or the lead (at review gates).
 
 ![Implementation modes diagram]({{ site.baseurl }}/assets/images/implementation-diagram.png)
 
 ---
 
 ## Mode A: Autonomous
 
-All task groups are pre-planned in parallel (one planner subagent per group produces `plans/group-N.md`), you approve the batch, 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, and the orchestrator verifies the group's tests itself, reviews the diff, and commits — one atomic commit per group. Independent groups (no dependency between them, disjoint file operations) may execute in parallel.
+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.
 
 ```
-        plan G1..G4 (parallel) → approve batch
-G1 ⇒ executor → verify → commit
-G2 ⇒ executor → verify → commit     (G2 ∥ G3 if independent)
-G3 ⇒ executor → verify → commit
-G4 ⇒ executor → verify → commit → DONE
+        plan G1..G4 (parallel) → adversarial challenge → approve batch + waves
+Wave 1  G1 ⇒ executor → verify pair → commit
+Wave 2  G2 ⇒ executor → verify pair → commit ─┐
+        G3 ⇒ executor → verify pair → commit ─┘  (G2 ∥ G3 — same wave)
+Wave 3  G4 ⇒ executor → verify pair → commit → adversarial review → DONE
 ```
 
 **Best for:** Small features, well-understood domains, no unknowns in the spec. The spec and task definitions are clear enough that the agent can ship without review.
@@ -32,7 +34,7 @@ G4 ⇒ executor → verify → commit → DONE
 
 ## Mode L: Lead-in-the-Loop
 
-The agent plans and implements one task group in the main conversation (using Claude Code's native plan mode per group), then pauses and waits for the lead developer to review before continuing. This creates a feedback loop at every group boundary — and keeps the work visible, which is why L mode does not delegate to subagents.
+The agent plans and implements one task group in the main conversation (using Claude Code's native plan mode per group), then pauses and waits for the lead developer to review before continuing. This creates a feedback loop at every group boundary — and keeps the work visible, which is why L mode does not delegate execution to subagents. The verification agents still run: after each group's tests pass, the implementation-reviewer and test-verifier report into the review gate, so the lead reviews with machine-found issues already surfaced and decides what gets fixed.
 
 ```
 G1 → [REVIEW] → G2 → [REVIEW] → G3 → [REVIEW] → G4
@@ -83,8 +85,9 @@ When you run `/lead-dev-os:step3-implement-tasks`, the skill reads the `> Size:`
 
 ## After Implementation
 
-Once all task groups are complete, the skill closes with two gates before suggesting archive:
+Once all task groups are complete, the skill closes with three gates before suggesting archive:
 
+- **Adversarial delivery review** — the adversarial-thinker (a fresh, read-only agent) attacks the finished feature: concrete failure scenarios, edge cases the tests miss, regressions in adjacent behavior, acceptance criteria satisfied in letter but not intent. Confirmed in-scope defects get fixed (bounded); everything else is reported.
 - **Full-suite backstop** — the entire test suite runs once (the only full-suite run in the workflow; per-group runs stay feature-scoped for fast feedback). New failures caused by the feature get fixed; pre-existing failures get reported, not fixed.
 - **Runtime verification** — the agent exercises the feature's primary user flow in the running app where feasible, because tests passing is not the same as the feature working.
 

docs/workflow.md

@@ -33,11 +33,11 @@ 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.
+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).
 
 ### Step 3: Implement (`/lead-dev-os:step3-implement-tasks`)
 
-Context-aware execution of task groups. In autonomous modes each group runs in a fresh executor subagent while the main conversation orchestrates, verifies, and commits; independent groups can run in parallel. Execution ends with a full-test-suite backstop and a runtime check of the feature's primary flow. See [Implementation]({{ site.baseurl }}/implementation) for the three execution modes.
+Context-aware execution of task groups by an orchestrated agent team. In autonomous modes each group runs in a fresh executor subagent while the main conversation orchestrates; independent groups run in parallel waves. Every group is checked before commit by a parallel verification pair — an **implementation-reviewer** (diff vs. plan, spec, and standards) and a **test-verifier** (tests are meaningful, edge cases covered, nothing weakened) — and an **adversarial-thinker** challenges the plans up front and attacks the finished feature before delivery. Execution ends with a full-test-suite backstop and a runtime check of the feature's primary flow. See [Implementation]({{ site.baseurl }}/implementation) for the three execution modes.
 
 ### Step 4: Archive (`/lead-dev-os:step4-archive-spec`)
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lead-dev-os",
-  "version": "1.0.0",
+  "version": "1.1.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/step1-write-spec/SKILL.md

@@ -47,7 +47,7 @@ Before asking questions, silently research available project context to inform y
 
 3. **Concept-driven reusability scan** — The concept files you read describe existing patterns, conventions, and architectural decisions — and they reference source file paths. Use these to identify reusable code without blindly searching the entire codebase. Note any relevant concepts and the source paths they reference.
 
-4. **If the scan must go beyond what the README indexes** (sparse concepts, or the feature touches undocumented territory), dispatch a read-only `Explore` subagent (fall back to `general-purpose`) with a bounded prompt — "find existing patterns, components, or modules related to [feature domain]; report paths and one-line descriptions, under 300 words" — instead of scanning the codebase in this conversation. Requirements gathering should keep the main context for the user's answers, not file dumps.
+4. **If the scan must go beyond what the README indexes** (sparse concepts, or the feature touches undocumented territory), dispatch read-only `Explore` subagents (fall back to `general-purpose`) instead of scanning the codebase in this conversation — 1 for a single-domain feature, up to 3 in a single parallel batch when the feature spans areas (e.g. one for backend, one for frontend). Give each a bounded prompt: "find existing patterns, components, or modules related to [feature domain / area]; report paths and one-line descriptions, under 300 words". Requirements gathering should keep the main context for the user's answers, not file dumps.
 
 Use this context to ask smarter, more targeted questions in the next phase. Do NOT ask the user about things already documented in these files.
 

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

@@ -16,6 +16,8 @@ You are a senior engineer breaking down a spec into implementable task groups. E
 
 Every task group MUST also stand on its own as a **complete user story** — a non-technical stakeholder who understands the feature's goal should be able to read the group and know (a) what value it delivers and (b) what "done" looks like, without reading any code or technical acceptance criteria.
 
+This skill does not write code or implementation plans — it produces `tasks.md` only; execution and per-group planning belong to `/lead-dev-os:step3-implement-tasks`.
+
 ### Phase 1: Load Context
 
 1. **Find the spec folder.** Look for the most recent `lead-dev-os/specs/YYYY-MM-DD-*/` folder, or ask the user which spec to work from.
@@ -38,6 +40,8 @@ Every task group MUST also stand on its own as a **complete user story** — a n
    - Shared utilities, helpers, or components to reuse instead of rebuilding
    - Anything that will constrain the task breakdown (migrations,
      feature flags, cross-cutting concerns)
+   - Contention hot spots: files that several parts of the feature will
+     all need to touch (these force sequential work)
    Do not propose a design — just report what exists.
    ```
 
@@ -54,7 +58,7 @@ Every task group MUST also stand on its own as a **complete user story** — a n
   4. **Testing** — test review & gap analysis (always last)
 - **Layers.** Groups follow the stack: Database → API → Frontend → Testing. Choose this when the data model is the hard part, the feature lives in a single layer, or slices would all contend for the same few files. Trade-off: layer groups form a strict dependency chain — they always execute sequentially, and nothing is user-demoable until the top layer lands.
 
-Whichever strategy you choose, keep each group's `Dependencies:` list minimal and honest — over-declared dependencies serialize execution for no reason.
+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.
 
 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.
 
@@ -141,10 +145,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
+- 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
 
-### Phase 4: Review & Save
+### 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.
 
 Display the following message to the user:
 

lead-dev-os/skills/step2-scope-tasks/examples/user-profile-feature.md

@@ -242,3 +242,14 @@ Recommended implementation sequence:
 2. File Upload Layer (Task Group 2)
 3. Frontend Components (Task Group 3)
 4. Test Review & Gap Analysis (Task Group 4)
+
+### 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:
+
+- Wave 1: Task Group 1
+- Wave 2: Task Group 2 — depends on Group 1's model changes
+- Wave 3: Task Group 3 — depends on Group 2's upload endpoint (avatar UI)
+- Wave 4: Task Group 4 (Test Review & Gap Analysis — always last, always alone)
+
+The groups form a strict dependency chain, so each wave holds a single group — no parallel execution is available for this feature.

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

@@ -213,3 +213,13 @@ Recommended implementation sequence:
 2. [Group Theme] (Task Group 2)
 3. [Group Theme] (Task Group 3)
 4. Test Review & Gap Analysis (Task Group 4)
+
+### 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:
+
+- 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 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.]