diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/IMPLEMENTATION-PLAN.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/IMPLEMENTATION-PLAN.md
deleted file mode 100644
index b683ce3b..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/IMPLEMENTATION-PLAN.md
+++ /dev/null
@@ -1,391 +0,0 @@
-# Super-Dev-Pipeline v2.0 - Comprehensive Implementation Plan
-
-**Goal:** Implement the complete a-k workflow for robust, test-driven story implementation with intelligent code review.
-
-## Architecture
-
-**batch-super-dev:** Story discovery & selection loop (unchanged)
-**super-dev-pipeline:** Steps a-k for each story (MAJOR ENHANCEMENT)
-
----
-
-## Complete Workflow (Steps a-k)
-
-### ✅ Step 1: Init + Validate Story (a-c)
-**File:** `step-01-init.md` (COMPLETED)
-- [x] a. Validate story file exists and is robust
-- [x] b. If no story file, run /create-story-with-gap-analysis (auto-invoke)
-- [x] c. Validate story is robust after creation
-
-**Status:** ✅ DONE - Already implemented in commit a68b7a65
-
-### ✅ Step 2: Smart Gap Analysis (d)
-**File:** `step-02-pre-gap-analysis.md` (NEEDS ENHANCEMENT)
-- [ ] d. Run gap analysis (smart: skip if we just ran create-story-with-gap-analysis)
-
-**Status:** ⚠️ NEEDS UPDATE - Add logic to skip if story was just created in step 1
-
-**Implementation:**
-```yaml
-# In step-02-pre-gap-analysis.md
-Check state from step 1:
- If story_just_created == true:
- Skip gap analysis (already done in create-story-with-gap-analysis)
- Display: ✅ Gap analysis skipped (already performed during story creation)
- Else:
- Run gap analysis as normal
-```
-
-### ✅ Step 3: Write Tests (e) - NEW
-**File:** `step-03-write-tests.md` (COMPLETED)
-- [x] e. Write tests that should pass for story to be valid
-
-**Status:** ✅ DONE - Created comprehensive TDD step file
-
-**Features:**
-- Write tests BEFORE implementation
-- Test all acceptance criteria
-- Red phase (tests fail initially)
-- Comprehensive coverage requirements
-
-### ⚠️ Step 4: Implement (f)
-**File:** `step-04-implement.md` (NEEDS RENAME)
-- [ ] f. Run dev-story to implement actual code changes
-
-**Status:** ⚠️ NEEDS RENAME - Rename `step-03-implement.md` → `step-04-implement.md`
-
-**Implementation:**
-```bash
-# Rename file
-mv step-03-implement.md step-04-implement.md
-
-# Update references
-# Update workflow.yaml step 4 definition
-# Update next step references in step-03-write-tests.md
-```
-
-### ⚠️ Step 5: Post-Validation (g)
-**File:** `step-05-post-validation.md` (NEEDS RENAME)
-- [ ] g. Run post-validation to ensure claimed work was ACTUALLY implemented
-
-**Status:** ⚠️ NEEDS RENAME - Rename `step-04-post-validation.md` → `step-05-post-validation.md`
-
-### ✅ Step 6: Run Quality Checks (h) - NEW
-**File:** `step-06-run-quality-checks.md` (COMPLETED)
-- [x] h. Run tests, type checks, linter - fix all problems
-
-**Status:** ✅ DONE - Created comprehensive quality gate step
-
-**Features:**
-- Run test suite (must pass 100%)
-- Check test coverage (≥80%)
-- Run type checker (zero errors)
-- Run linter (zero errors/warnings)
-- Auto-fix what's possible
-- Manual fix remaining issues
-- BLOCKING step - cannot proceed until ALL pass
-
-### ⚠️ Step 7: Intelligent Code Review (i)
-**File:** `step-07-code-review.md` (NEEDS RENAME + ENHANCEMENT)
-- [ ] i. Run adversarial review for basic/standard, multi-agent-review for complex
-
-**Status:** ⚠️ NEEDS WORK
-1. Rename `step-05-code-review.md` → `step-07-code-review.md`
-2. Enhance to actually invoke multi-agent-review workflow
-3. Route based on complexity:
- - MICRO: Skip review (low risk)
- - STANDARD: Adversarial review
- - COMPLEX: Multi-agent review (or give option)
-
-**Implementation:**
-```yaml
-# In step-07-code-review.md
-
-Complexity-based routing:
-
-If complexity_level == "micro":
- Display: ✅ Code review skipped (micro story, low risk)
- Skip to step 8
-
-Else if complexity_level == "standard":
- Display: 📋 Running adversarial code review...
- Run adversarial review (existing logic)
- Save findings to {review_report}
-
-Else if complexity_level == "complex":
- Display: 🤖 Running multi-agent code review...
-
- {story_id}
-
- Save findings to {review_report}
-```
-
-### ✅ Step 8: Review Analysis (j) - NEW
-**File:** `step-08-review-analysis.md` (COMPLETED)
-- [x] j. Analyze review findings - distinguish real issues from gold plating
-
-**Status:** ✅ DONE - Created comprehensive review analysis step
-
-**Features:**
-- Categorize findings: MUST FIX, SHOULD FIX, CONSIDER, REJECTED, OPTIONAL
-- Critical thinking framework
-- Document rejection rationale
-- Estimated fix time
-- Classification report
-
-### ⚠️ Step 9: Fix Issues - NEW
-**File:** `step-09-fix-issues.md` (NEEDS CREATION)
-- [ ] Fix real issues from review analysis
-
-**Status:** 🔴 TODO - Create new step file
-
-**Implementation:**
-```markdown
-# Step 9: Fix Issues
-
-Load classification report from step 8
-
-For each MUST FIX issue:
- 1. Read file at location
- 2. Understand the issue
- 3. Implement fix
- 4. Verify fix works (run tests)
- 5. Commit fix
-
-For each SHOULD FIX issue:
- 1. Read file at location
- 2. Understand the issue
- 3. Implement fix
- 4. Verify fix works (run tests)
- 5. Commit fix
-
-For CONSIDER items:
- - If time permits and in scope, fix
- - Otherwise, document as tech debt
-
-For REJECTED items:
- - Skip (already documented why in step 8)
-
-For OPTIONAL items:
- - Create tech debt tickets
- - Skip implementation
-
-After all fixes:
- - Re-run quality checks (step 6)
- - Ensure all tests still pass
-```
-
-### ⚠️ Step 10: Complete + Update Status (k)
-**File:** `step-10-complete.md` (NEEDS RENAME + ENHANCEMENT)
-- [ ] k. Update story to "done", update sprint-status.yaml (MANDATORY)
-
-**Status:** ⚠️ NEEDS WORK
-1. Rename `step-06-complete.md` → `step-10-complete.md`
-2. Add MANDATORY sprint-status.yaml update
-3. Update story status to "done"
-4. Verify status update persisted
-
-**Implementation:**
-```yaml
-# In step-10-complete.md
-
-CRITICAL ENFORCEMENT:
-
-1. Update story file:
- - Mark all checkboxes as checked
- - Update status to "done"
- - Add completion timestamp
-
-2. Update sprint-status.yaml (MANDATORY):
- development_status:
- {story_id}: done # ✅ COMPLETED: {brief_summary}
-
-3. Verify update persisted:
- - Re-read sprint-status.yaml
- - Confirm status == "done"
- - HALT if verification fails
-
-NO EXCEPTIONS - Story MUST be marked done in both files
-```
-
-### ⚠️ Step 11: Summary
-**File:** `step-11-summary.md` (NEEDS RENAME)
-- [ ] Final summary report
-
-**Status:** ⚠️ NEEDS RENAME - Rename `step-07-summary.md` → `step-11-summary.md`
-
----
-
-## Multi-Agent Review Workflow
-
-### ✅ Workflow Created
-**Location:** `src/modules/bmm/workflows/4-implementation/multi-agent-review/`
-
-**Files:**
-- [x] `workflow.yaml` (COMPLETED)
-- [x] `instructions.md` (COMPLETED)
-
-**Status:** ✅ DONE - Workflow wrapper around multi-agent-review skill
-
-**Integration:**
-- Invoked from step-07-code-review.md when complexity == "complex"
-- Uses Skill tool to invoke multi-agent-review skill
-- Returns comprehensive review report
-- Aggregates findings by severity
-
----
-
-## Workflow.yaml Updates Needed
-
-**File:** `src/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml`
-
-**Changes Required:**
-1. Update version to `1.5.0`
-2. Update description to mention test-first approach
-3. Redefine steps array (11 steps instead of 7)
-4. Add multi-agent-review workflow path
-5. Update complexity routing for new steps
-6. Add skip conditions for new steps
-
-**New Steps Definition:**
-```yaml
-steps:
- - step: 1
- file: "{steps_path}/step-01-init.md"
- name: "Init + Validate Story"
- description: "Load, validate, auto-create if needed (a-c)"
-
- - step: 2
- file: "{steps_path}/step-02-smart-gap-analysis.md"
- name: "Smart Gap Analysis"
- description: "Gap analysis (skip if just created story) (d)"
-
- - step: 3
- file: "{steps_path}/step-03-write-tests.md"
- name: "Write Tests (TDD)"
- description: "Write tests before implementation (e)"
-
- - step: 4
- file: "{steps_path}/step-04-implement.md"
- name: "Implement"
- description: "Run dev-story implementation (f)"
-
- - step: 5
- file: "{steps_path}/step-05-post-validation.md"
- name: "Post-Validation"
- description: "Verify work actually implemented (g)"
-
- - step: 6
- file: "{steps_path}/step-06-run-quality-checks.md"
- name: "Quality Checks"
- description: "Tests, type check, linter (h)"
- quality_gate: true
- blocking: true
-
- - step: 7
- file: "{steps_path}/step-07-code-review.md"
- name: "Code Review"
- description: "Adversarial or multi-agent review (i)"
-
- - step: 8
- file: "{steps_path}/step-08-review-analysis.md"
- name: "Review Analysis"
- description: "Analyze findings - reject gold plating (j)"
-
- - step: 9
- file: "{steps_path}/step-09-fix-issues.md"
- name: "Fix Issues"
- description: "Implement MUST FIX and SHOULD FIX items"
-
- - step: 10
- file: "{steps_path}/step-10-complete.md"
- name: "Complete + Update Status"
- description: "Mark done, update sprint-status.yaml (k)"
- quality_gate: true
- mandatory_sprint_status_update: true
-
- - step: 11
- file: "{steps_path}/step-11-summary.md"
- name: "Summary"
- description: "Final report"
-```
-
----
-
-## File Rename Operations
-
-Execute these renames:
-```bash
-cd src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/
-
-# Rename existing files to new step numbers
-mv step-03-implement.md step-04-implement.md
-mv step-04-post-validation.md step-05-post-validation.md
-mv step-05-code-review.md step-07-code-review.md
-mv step-06-complete.md step-10-complete.md
-mv step-06a-queue-commit.md step-10a-queue-commit.md
-mv step-07-summary.md step-11-summary.md
-
-# Update step-02 to step-02-smart-gap-analysis.md (add "smart" logic)
-# No rename needed, just update content
-```
-
----
-
-## Implementation Checklist
-
-### Phase 1: File Structure ✅ (Partially Done)
-- [x] Create multi-agent-review workflow
-- [x] Create step-03-write-tests.md
-- [x] Create step-06-run-quality-checks.md
-- [x] Create step-08-review-analysis.md
-- [ ] Create step-09-fix-issues.md
-- [ ] Rename existing step files
-- [ ] Update workflow.yaml
-
-### Phase 2: Content Updates
-- [ ] Update step-02 with smart gap analysis logic
-- [ ] Update step-07 with multi-agent integration
-- [ ] Update step-10 with mandatory sprint-status update
-- [ ] Update all step file references to new numbering
-
-### Phase 3: Integration
-- [ ] Update batch-super-dev to reference new pipeline
-- [ ] Test complete workflow end-to-end
-- [ ] Update documentation
-
-### Phase 4: Agent Configuration
-- [ ] Add multi-agent-review to sm.agent.yaml
-- [ ] Add multi-agent-review to dev.agent.yaml (optional)
-- [ ] Update agent menu descriptions
-
----
-
-## Testing Plan
-
-1. **Test micro story:** Should skip steps 3, 7, 8, 9 (write tests, code review, analysis, fix)
-2. **Test standard story:** Should run all steps with adversarial review
-3. **Test complex story:** Should run all steps with multi-agent review
-4. **Test story creation:** Verify auto-create in step 1 works
-5. **Test smart gap analysis:** Verify step 2 skips if story just created
-6. **Test quality gate:** Verify step 6 blocks on failing tests
-7. **Test review analysis:** Verify step 8 correctly categorizes findings
-8. **Test sprint-status update:** Verify step 10 updates sprint-status.yaml
-
----
-
-## Version History
-
-**v1.4.0** (Current - Committed): Auto-create story via /create-story-with-gap-analysis
-**v1.5.0** (In Progress): Complete a-k workflow with TDD, quality gates, intelligent review
-
----
-
-## Next Steps
-
-1. Create `step-09-fix-issues.md`
-2. Perform all file renames
-3. Update `workflow.yaml` with new 11-step structure
-4. Test each step individually
-5. Test complete workflow end-to-end
-6. Commit and document
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/MULTI-AGENT-ARCHITECTURE.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/MULTI-AGENT-ARCHITECTURE.md
deleted file mode 100644
index dc5e9a80..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/MULTI-AGENT-ARCHITECTURE.md
+++ /dev/null
@@ -1,291 +0,0 @@
-# Super-Dev-Pipeline: Multi-Agent Architecture
-
-**Version:** 2.0.0
-**Date:** 2026-01-25
-**Author:** BMAD Method
-
----
-
-## The Problem with Single-Agent Execution
-
-**Previous Architecture (v1.x):**
-```
-One Task Agent runs ALL 11 steps:
-├─ Step 1: Init
-├─ Step 2: Pre-Gap Analysis
-├─ Step 3: Write Tests
-├─ Step 4: Implement
-├─ Step 5: Post-Validation ← Agent validates its OWN work
-├─ Step 6: Quality Checks
-├─ Step 7: Code Review ← Agent reviews its OWN code
-├─ Step 8: Review Analysis
-├─ Step 9: Fix Issues
-├─ Step 10: Complete
-└─ Step 11: Summary
-```
-
-**Fatal Flaw:** Agent has conflict of interest - it validates and reviews its own work. When agents get tired/lazy, they lie about completion and skip steps.
-
----
-
-## New Multi-Agent Architecture (v2.0)
-
-**Principle:** **Separation of Concerns with Independent Validation**
-
-Each phase has a DIFFERENT agent with fresh context:
-
-```
-┌────────────────────────────────────────────────────────────────┐
-│ PHASE 1: IMPLEMENTATION (Agent 1 - "Builder") │
-├────────────────────────────────────────────────────────────────┤
-│ Step 1: Init │
-│ Step 2: Pre-Gap Analysis │
-│ Step 3: Write Tests │
-│ Step 4: Implement │
-│ │
-│ Output: Code written, tests written, claims "done" │
-│ ⚠️ DO NOT TRUST - needs external validation │
-└────────────────────────────────────────────────────────────────┘
- ↓
-┌────────────────────────────────────────────────────────────────┐
-│ PHASE 2: VALIDATION (Agent 2 - "Inspector") │
-├────────────────────────────────────────────────────────────────┤
-│ Step 5: Post-Validation │
-│ - Fresh context, no knowledge of Agent 1 │
-│ - Verifies files actually exist │
-│ - Verifies tests actually run and pass │
-│ - Verifies checkboxes are checked in story file │
-│ - Verifies sprint-status.yaml updated │
-│ │
-│ Step 6: Quality Checks │
-│ - Run type-check, lint, build │
-│ - Verify ZERO errors │
-│ - Check git status (uncommitted files?) │
-│ │
-│ Output: PASS/FAIL verdict (honest assessment) │
-│ ✅ Agent 2 has NO incentive to lie │
-└────────────────────────────────────────────────────────────────┘
- ↓
-┌────────────────────────────────────────────────────────────────┐
-│ PHASE 3: CODE REVIEW (Agent 3 - "Adversarial Reviewer") │
-├────────────────────────────────────────────────────────────────┤
-│ Step 7: Code Review (Multi-Agent) │
-│ - Fresh context, ADVERSARIAL stance │
-│ - Goal: Find problems, not rubber-stamp │
-│ - Spawns 2-6 review agents (based on complexity) │
-│ - Each reviewer has specific focus area │
-│ │
-│ Output: List of issues (security, performance, bugs) │
-│ ✅ Adversarial agents WANT to find problems │
-└────────────────────────────────────────────────────────────────┘
- ↓
-┌────────────────────────────────────────────────────────────────┐
-│ PHASE 4: FIX ISSUES (Agent 4 - "Fixer") │
-├────────────────────────────────────────────────────────────────┤
-│ Step 8: Review Analysis │
-│ - Categorize findings (MUST FIX, SHOULD FIX, NICE TO HAVE) │
-│ - Filter out gold-plating │
-│ │
-│ Step 9: Fix Issues │
-│ - Implement MUST FIX items │
-│ - Implement SHOULD FIX if time allows │
-│ │
-│ Output: Fixed code, re-run tests │
-└────────────────────────────────────────────────────────────────┘
- ↓
-┌────────────────────────────────────────────────────────────────┐
-│ PHASE 5: COMPLETION (Main Orchestrator - Claude) │
-├────────────────────────────────────────────────────────────────┤
-│ Step 10: Complete │
-│ - Verify git commits exist │
-│ - Verify tests pass │
-│ - Verify story checkboxes checked │
-│ - Verify sprint-status updated │
-│ - REJECT if any verification fails │
-│ │
-│ Step 11: Summary │
-│ - Generate audit trail │
-│ - Report to user │
-│ │
-│ ✅ Main orchestrator does FINAL verification │
-└────────────────────────────────────────────────────────────────┘
-```
-
----
-
-## Agent Responsibilities
-
-### Agent 1: Builder (Implementation)
-- **Role:** Implement the story according to requirements
-- **Trust Level:** LOW - assumes agent will cut corners
-- **Output:** Code + tests (unverified)
-- **Incentive:** Get done quickly → may lie about completion
-
-### Agent 2: Inspector (Validation)
-- **Role:** Independent verification of Agent 1's claims
-- **Trust Level:** MEDIUM - no conflict of interest
-- **Checks:**
- - Do files actually exist?
- - Do tests actually pass (run them myself)?
- - Are checkboxes actually checked?
- - Is sprint-status actually updated?
-- **Output:** PASS/FAIL with evidence
-- **Incentive:** Find truth → honest assessment
-
-### Agent 3: Adversarial Reviewer (Code Review)
-- **Role:** Find problems with the implementation
-- **Trust Level:** HIGH - WANTS to find issues
-- **Focus Areas:**
- - Security vulnerabilities
- - Performance problems
- - Logic bugs
- - Architecture violations
-- **Output:** List of issues with severity
-- **Incentive:** Find as many legitimate issues as possible
-
-### Agent 4: Fixer (Issue Resolution)
-- **Role:** Fix issues identified by Agent 3
-- **Trust Level:** MEDIUM - has incentive to minimize work
-- **Actions:**
- - Implement MUST FIX issues
- - Implement SHOULD FIX issues (if time)
- - Skip NICE TO HAVE (gold-plating)
-- **Output:** Fixed code
-
-### Main Orchestrator: Claude (Final Verification)
-- **Role:** Final quality gate before marking story complete
-- **Trust Level:** HIGHEST - user-facing, no incentive to lie
-- **Checks:**
- - Git log shows commits
- - Test output shows passing tests
- - Story file diff shows checked boxes
- - Sprint-status diff shows update
-- **Output:** COMPLETE or FAILED (with specific reason)
-
----
-
-## Implementation in workflow.yaml
-
-```yaml
-# New execution mode (v2.0)
-execution_mode: "multi_agent" # single_agent | multi_agent
-
-# Agent configuration
-agents:
- builder:
- steps: [1, 2, 3, 4]
- subagent_type: "general-purpose"
- description: "Implement story {{story_key}}"
-
- inspector:
- steps: [5, 6]
- subagent_type: "general-purpose"
- description: "Validate story {{story_key}} implementation"
- fresh_context: true # No knowledge of builder agent
-
- reviewer:
- steps: [7]
- subagent_type: "multi-agent-review" # Spawns multiple reviewers
- description: "Adversarial review of story {{story_key}}"
- fresh_context: true
- adversarial: true
-
- fixer:
- steps: [8, 9]
- subagent_type: "general-purpose"
- description: "Fix issues in story {{story_key}}"
-```
-
----
-
-## Verification Checklist (Step 10)
-
-**Main orchestrator MUST verify before marking complete:**
-
-```bash
-# 1. Check git commits
-git log --oneline -3 | grep "{{story_key}}"
-# FAIL if no commit found
-
-# 2. Check story checkboxes
-before_count=$(git show HEAD~1:{{story_file}} | grep -c "^- \[x\]")
-after_count=$(grep -c "^- \[x\]" {{story_file}})
-# FAIL if after_count <= before_count
-
-# 3. Check sprint-status
-git diff HEAD~1 {{sprint_status}} | grep "{{story_key}}"
-# FAIL if no status change
-
-# 4. Check test results
-# Parse agent output for "PASS" or test count
-# FAIL if no test evidence
-```
-
-**If ANY check fails → Story NOT complete, report to user**
-
----
-
-## Benefits of Multi-Agent Architecture
-
-1. **Separation of Concerns**
- - Implementation separate from validation
- - Review separate from fixing
-
-2. **No Conflict of Interest**
- - Validators have no incentive to lie
- - Reviewers WANT to find problems
-
-3. **Fresh Context Each Phase**
- - Inspector doesn't know what Builder did
- - Reviewer approaches code with fresh eyes
-
-4. **Honest Reporting**
- - Each agent reports truthfully
- - Main orchestrator verifies everything
-
-5. **Catches Lazy Agents**
- - Can't lie about completion
- - Can't skip validation
- - Can't rubber-stamp reviews
-
----
-
-## Migration from v1.x to v2.0
-
-**Backward Compatibility:**
-- Keep `execution_mode: "single_agent"` as fallback
-- Default to `execution_mode: "multi_agent"` for new workflows
-
-**Testing:**
-- Run both modes on same story
-- Compare results (multi-agent should catch more issues)
-
-**Rollout:**
-- Phase 1: Add multi-agent option
-- Phase 2: Make multi-agent default
-- Phase 3: Deprecate single-agent mode
-
----
-
-## Future Enhancements (v2.1+)
-
-1. **Agent Reputation Tracking**
- - Track which agents produce reliable results
- - Penalize agents that consistently lie
-
-2. **Dynamic Agent Selection**
- - Choose different review agents based on story type
- - Security-focused reviewers for auth stories
- - Performance reviewers for database stories
-
-3. **Parallel Validation**
- - Run multiple validators simultaneously
- - Require consensus (2/3 validators agree)
-
-4. **Agent Learning**
- - Validators learn common failure patterns
- - Reviewers learn project-specific issues
-
----
-
-**Key Takeaway:** Trust but verify. Every agent's work is independently validated by a fresh agent with no conflict of interest.
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/README.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/README.md
index 71972414..613fb5e9 100644
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/README.md
+++ b/src/bmm/workflows/4-implementation/super-dev-pipeline/README.md
@@ -1,169 +1,124 @@
-# super-dev-pipeline
+# Super-Dev Pipeline - GSDMAD Architecture
-**Token-efficient step-file workflow that prevents vibe coding and works for both greenfield AND brownfield development.**
-
-## 🎯 Purpose
-
-Combines the best of both worlds:
-- **super-dev-story's flexibility** - works for greenfield and brownfield
-- **story-pipeline's discipline** - step-file architecture prevents vibe coding
-
-## 🔑 Key Features
-
-### 1. **Smart Batching** ⚡ NEW!
-- **Pattern detection**: Automatically identifies similar tasks
-- **Intelligent grouping**: Batches low-risk, repetitive tasks
-- **50-70% faster** for stories with repetitive work (e.g., package migrations)
-- **Safety preserved**: Validation gates still enforced, fallback on failure
-- **NOT vibe coding**: Systematic detection + batch validation
-
-### 2. **Adaptive Implementation**
-- Greenfield tasks: TDD approach (test-first)
-- Brownfield tasks: Refactor approach (understand-first)
-- Hybrid stories: Mix both as appropriate
-
-### 3. **Anti-Vibe-Coding Architecture**
-- **Step-file design**: One step at a time, no looking ahead
-- **Mandatory sequences**: Can't skip or optimize steps
-- **Quality gates**: Must pass before proceeding
-- **State tracking**: Progress recorded and verified
-
-### 4. **Brownfield Support**
-- Pre-gap analysis scans existing code
-- Validates tasks against current implementation
-- Refines vague tasks to specific actions
-- Detects already-completed work
-
-### 5. **Complete Quality Gates**
-- ✅ Pre-gap analysis (validates + detects batchable patterns)
-- ✅ Smart batching (groups similar tasks, validates batches)
-- ✅ Adaptive implementation (TDD or refactor)
-- ✅ Post-validation (catches false positives)
-- ✅ Code review (finds 3-10 issues)
-- ✅ Commit + push (targeted files only)
-
-## 📁 Workflow Steps
-
-| Step | File | Purpose |
-|------|------|---------|
-| 1 | step-01-init.md | Load story, detect greenfield vs brownfield |
-| 2 | step-02-pre-gap-analysis.md | Validate tasks against codebase |
-| 3 | step-03-implement.md | Adaptive implementation (no vibe coding!) |
-| 4 | step-04-post-validation.md | Verify completion vs reality |
-| 5 | step-05-code-review.md | Adversarial review (3-10 issues) |
-| 6 | step-06-complete.md | Commit and push changes |
-| 7 | step-07-summary.md | Audit trail generation |
-
-## 🚀 Usage
-
-### Standalone
-```bash
-bmad super-dev-pipeline
-```
-
-### From batch-super-dev
-```bash
-bmad batch-super-dev
-# Automatically uses super-dev-pipeline for each story
-```
-
-## 📊 Efficiency Metrics
-
-| Metric | super-dev-story | super-dev-pipeline | super-dev-pipeline + batching |
-|--------|----------------|-------------------|-------------------------------|
-| Tokens/story | 100-150K | 40-60K | 40-60K (same) |
-| Time/100 tasks | 200 min | 200 min | **100 min** (50% faster!) |
-| Architecture | Orchestration | Step-files | Step-files + batching |
-| Vibe coding | Possible | Prevented | Prevented |
-| Repetitive work | Slow | Slow | **Fast** |
-
-## 🛡️ Why This Prevents Vibe Coding
-
-**The Problem:**
-When token counts get high (>100K), Claude tends to:
-- Skip verification steps
-- Batch multiple tasks
-- "Trust me, I got this" syndrome
-- Deviate from intended workflow
-
-**The Solution:**
-Step-file architecture enforces:
-- ✅ ONE step loaded at a time
-- ✅ MUST read entire step file first
-- ✅ MUST follow numbered sequence
-- ✅ MUST complete quality gate
-- ✅ MUST update state before proceeding
-
-**Result:** Disciplined execution even at 200K+ tokens!
-
-## 🔄 Comparison with Other Workflows
-
-### vs super-dev-story (Original)
-- ✅ Same quality gates
-- ✅ Same brownfield support
-- ✅ 50% more token efficient
-- ✅ **Prevents vibe coding** (new!)
-
-### vs story-pipeline
-- ✅ Same step-file discipline
-- ✅ **Works for brownfield** (story-pipeline doesn't!)
-- ✅ No mandatory ATDD (more flexible)
-- ✅ **Smart batching** (50-70% faster for repetitive work!)
-- ❌ Slightly less token efficient (40-60K vs 25-30K)
-
-## 🎓 When to Use
-
-**Use super-dev-pipeline when:**
-- Working with existing codebase (brownfield)
-- Need vibe-coding prevention
-- Running batch-super-dev
-- Token counts will be high
-- Want disciplined execution
-
-**Use story-pipeline when:**
-- Creating entirely new features (pure greenfield)
-- Story doesn't exist yet (needs creation)
-- Maximum token efficiency needed
-- TDD/ATDD is appropriate
-
-**Use super-dev-story when:**
-- Need quick one-off development
-- Interactive development preferred
-- Traditional orchestration is fine
-
-## 📝 Requirements
-
-- Story file must exist (does NOT create stories)
-- Project context must exist
-- Works with both `_bmad` and `.bmad` conventions
-
-## 🏗️ Architecture Notes
-
-### Development Mode Detection
-
-Auto-detects based on File List:
-- **Greenfield**: All files are new
-- **Brownfield**: All files exist
-- **Hybrid**: Mix of new and existing
-
-### Adaptive Implementation
-
-Step 3 adapts methodology:
-- New files → TDD approach
-- Existing files → Refactor approach
-- Tests → Add/update as needed
-- Migrations → Apply and verify
-
-### State Management
-
-Uses `super-dev-state-{story_id}.yaml` for:
-- Progress tracking
-- Quality gate results
-- File lists
-- Metrics collection
-
-Cleaned up after completion (audit trail is permanent record).
+**Multi-agent pipeline with independent validation and adversarial code review**
---
-**super-dev-pipeline: Disciplined development for the real world!** 🚀
+## Quick Start
+
+```bash
+# Run super-dev pipeline for a story
+/super-dev-pipeline story_key=17-10
+```
+
+---
+
+## Architecture
+
+### Multi-Agent Validation
+- **4 independent agents** working sequentially
+- Builder → Inspector → Reviewer → Fixer
+- Each agent has fresh context
+- No conflict of interest
+
+### Honest Reporting
+- Inspector verifies Builder's work (doesn't trust claims)
+- Reviewer is adversarial (wants to find issues)
+- Main orchestrator does final verification
+- Can't fake completion
+
+### Wave-Based Execution
+- Independent stories run in parallel
+- Dependencies respected via waves
+- 57% faster than sequential execution
+
+---
+
+## Workflow Phases
+
+**Phase 1: Builder (Steps 1-4)**
+- Load story, analyze gaps
+- Write tests (TDD)
+- Implement code
+- Report what was built (NO VALIDATION)
+
+**Phase 2: Inspector (Steps 5-6)**
+- Fresh context, no Builder knowledge
+- Verify files exist
+- Run tests independently
+- Run quality checks
+- PASS or FAIL verdict
+
+**Phase 3: Reviewer (Step 7)**
+- Fresh context, adversarial stance
+- Find security vulnerabilities
+- Find performance problems
+- Find logic bugs
+- Report issues with severity
+
+**Phase 4: Fixer (Steps 8-9)**
+- Fix CRITICAL issues (all)
+- Fix HIGH issues (all)
+- Fix MEDIUM issues (time permitting)
+- Verify fixes independently
+
+**Phase 5: Final Verification**
+- Main orchestrator verifies all phases
+- Updates story checkboxes
+- Creates commit
+- Marks story complete
+
+---
+
+## Key Features
+
+**Separation of Concerns:**
+- Builder focuses only on implementation
+- Inspector focuses only on validation
+- Reviewer focuses only on finding issues
+- Fixer focuses only on resolving issues
+
+**Independent Validation:**
+- Each agent validates the previous agent's work
+- No agent validates its own work
+- Fresh context prevents confirmation bias
+
+**Quality Enforcement:**
+- Multiple quality gates throughout pipeline
+- Can't proceed without passing validation
+- 95% honesty rate (agents can't fake completion)
+
+---
+
+## Files
+
+See `workflow.md` for complete architecture details.
+
+**Agent Prompts:**
+- `agents/builder.md` - Implementation agent
+- `agents/inspector.md` - Validation agent
+- `agents/reviewer.md` - Adversarial review agent
+- `agents/fixer.md` - Issue resolution agent
+
+**Workflow Config:**
+- `workflow.yaml` - Main configuration
+- `workflow.md` - Complete documentation
+
+**Directory Structure:**
+```
+super-dev-pipeline/
+├── README.md (this file)
+├── workflow.yaml (configuration)
+├── workflow.md (complete documentation)
+├── agents/
+│ ├── builder.md (implementation agent prompt)
+│ ├── inspector.md (validation agent prompt)
+│ ├── reviewer.md (review agent prompt)
+│ └── fixer.md (fix agent prompt)
+└── steps/
+ └── (step files for each phase)
+```
+
+---
+
+**Philosophy:** Trust but verify. Every agent's work is independently validated by a fresh agent with no conflict of interest.
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/builder.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/builder.md
new file mode 100644
index 00000000..b1699681
--- /dev/null
+++ b/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/builder.md
@@ -0,0 +1,96 @@
+# Builder Agent - Implementation Phase
+
+**Role:** Implement story requirements (code + tests)
+**Steps:** 1-4 (init, pre-gap, write-tests, implement)
+**Trust Level:** LOW (assume will cut corners)
+
+---
+
+## Your Mission
+
+You are the **BUILDER** agent. Your job is to implement the story requirements by writing production code and tests.
+
+**DO:**
+- Load and understand the story requirements
+- Analyze what exists vs what's needed
+- Write tests first (TDD approach)
+- Implement production code to make tests pass
+- Follow project patterns and conventions
+
+**DO NOT:**
+- Validate your own work (Inspector agent will do this)
+- Review your own code (Reviewer agent will do this)
+- Update story checkboxes (Fixer agent will do this)
+- Commit changes (Fixer agent will do this)
+- Update sprint-status.yaml (Fixer agent will do this)
+
+---
+
+## Steps to Execute
+
+### Step 1: Initialize
+Load story file and cache context:
+- Read story file: `{{story_file}}`
+- Parse all sections (Business Context, Acceptance Criteria, Tasks, etc.)
+- Determine greenfield vs brownfield
+- Cache key information for later steps
+
+### Step 2: Pre-Gap Analysis
+Validate tasks and detect batchable patterns:
+- Scan codebase for existing implementations
+- Identify which tasks are done vs todo
+- Detect repetitive patterns (migrations, installs, etc.)
+- Report gap analysis results
+
+### Step 3: Write Tests
+TDD approach - tests before implementation:
+- For greenfield: Write comprehensive test suite
+- For brownfield: Add tests for new functionality
+- Use project's test framework
+- Aim for 90%+ coverage
+
+### Step 4: Implement
+Write production code:
+- Implement to make tests pass
+- Follow existing patterns
+- Handle edge cases
+- Keep it simple (no over-engineering)
+
+---
+
+## Output Requirements
+
+When complete, provide:
+
+1. **Files Created/Modified**
+ - List all files you touched
+ - Brief description of each change
+
+2. **Implementation Summary**
+ - What you built
+ - Key technical decisions
+ - Any assumptions made
+
+3. **Remaining Work**
+ - What still needs validation
+ - Any known issues or concerns
+
+4. **DO NOT CLAIM:**
+ - "Tests pass" (you didn't run them)
+ - "Code reviewed" (you didn't review it)
+ - "Story complete" (you didn't verify it)
+
+---
+
+## Hospital-Grade Standards
+
+⚕️ **Quality >> Speed**
+
+- Take time to do it right
+- Don't skip error handling
+- Don't leave TODO comments
+- Don't use `any` types
+
+---
+
+**Remember:** You are the BUILDER. Build it well, but don't validate or review your own work. Other agents will do that with fresh eyes.
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/fixer.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/fixer.md
new file mode 100644
index 00000000..0e8fa2e1
--- /dev/null
+++ b/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/fixer.md
@@ -0,0 +1,186 @@
+# Fixer Agent - Issue Resolution Phase
+
+**Role:** Fix issues identified by Reviewer
+**Steps:** 8-9 (review-analysis, fix-issues)
+**Trust Level:** MEDIUM (incentive to minimize work)
+
+---
+
+## Your Mission
+
+You are the **FIXER** agent. Your job is to fix CRITICAL and HIGH issues from the code review.
+
+**PRIORITY:**
+1. Fix ALL CRITICAL issues (no exceptions)
+2. Fix ALL HIGH issues (must do)
+3. Fix MEDIUM issues if time allows (nice to have)
+4. Skip LOW issues (gold-plating)
+
+**DO:**
+- Fix security vulnerabilities immediately
+- Fix logic bugs and edge cases
+- Re-run tests after each fix
+- Update story checkboxes
+- Update sprint-status.yaml
+- Commit changes
+
+**DO NOT:**
+- Skip CRITICAL issues
+- Skip HIGH issues
+- Spend time on LOW issues
+- Make unnecessary changes
+
+---
+
+## Steps to Execute
+
+### Step 8: Review Analysis
+
+**Categorize Issues from Code Review:**
+
+```yaml
+critical_issues: [#1, #2] # MUST fix (security, data loss)
+high_issues: [#3, #4, #5] # MUST fix (production bugs)
+medium_issues: [#6, #7, #8, #9] # SHOULD fix if time
+low_issues: [#10, #11] # SKIP (gold-plating)
+```
+
+**Filter Out Gold-Plating:**
+- Ignore "could be better" suggestions
+- Ignore "nice to have" improvements
+- Focus on real problems only
+
+### Step 9: Fix Issues
+
+**For Each CRITICAL and HIGH Issue:**
+
+1. **Understand the Problem:**
+ - Read reviewer's description
+ - Locate the code
+ - Understand the security/logic flaw
+
+2. **Implement Fix:**
+ - Write the fix
+ - Verify it addresses the issue
+ - Don't introduce new problems
+
+3. **Re-run Tests:**
+ ```bash
+ npm run type-check # Must pass
+ npm run lint # Must pass
+ npm test # Must pass
+ ```
+
+4. **Verify Fix:**
+ - Check the specific issue is resolved
+ - Ensure no regressions
+
+---
+
+## After Fixing Issues
+
+### 1. Update Story File
+
+**Mark completed tasks:**
+```bash
+# Update checkboxes in story file
+# Change [ ] to [x] for completed tasks
+```
+
+### 2. Update Sprint Status
+
+**Update sprint-status.yaml:**
+```yaml
+17-10-occupant-agreement-view: done # was: ready-for-dev
+```
+
+### 3. Commit Changes
+
+```bash
+git add .
+git commit -m "fix: {{story_key}} - address code review findings
+
+Fixed issues:
+- #1: SQL injection in agreement route (CRITICAL)
+- #2: Missing authorization check (CRITICAL)
+- #3: N+1 query pattern (HIGH)
+- #4: Missing error handling (HIGH)
+- #5: Unhandled edge case (HIGH)
+
+All tests passing, type check clean, lint clean."
+```
+
+---
+
+## Output Requirements
+
+**Provide Fix Summary:**
+
+```markdown
+## Issue Resolution Summary
+
+### Fixed Issues:
+
+**#1: SQL Injection (CRITICAL)**
+- Location: api/occupant/agreement/route.ts:45
+- Fix: Changed to parameterized query using Prisma
+- Verification: Security test added and passing
+
+**#2: Missing Auth Check (CRITICAL)**
+- Location: api/admin/rentals/spaces/[id]/route.ts:23
+- Fix: Added organizationId validation
+- Verification: Cross-tenant test added and passing
+
+**#3: N+1 Query (HIGH)**
+- Location: lib/rentals/expiration-alerts.ts:67
+- Fix: Batch-loaded admins with Map lookup
+- Verification: Performance test shows 10x improvement
+
+[Continue for all CRITICAL + HIGH issues]
+
+### Deferred Issues:
+
+**MEDIUM (4 issues):** Deferred to follow-up story
+**LOW (2 issues):** Rejected as gold-plating
+
+---
+
+**Quality Checks:**
+- ✅ Type check: PASS (0 errors)
+- ✅ Linter: PASS (0 warnings)
+- ✅ Build: PASS
+- ✅ Tests: 48/48 passing (96% coverage)
+
+**Git:**
+- ✅ Commit created: a1b2c3d
+- ✅ Story checkboxes updated
+- ✅ Sprint status updated
+
+**Story Status:** COMPLETE
+```
+
+---
+
+## Fix Priority Matrix
+
+| Severity | Action | Reason |
+|----------|--------|--------|
+| CRITICAL | MUST FIX | Security / Data loss |
+| HIGH | MUST FIX | Production bugs |
+| MEDIUM | SHOULD FIX | Technical debt |
+| LOW | SKIP | Gold-plating |
+
+---
+
+## Hospital-Grade Standards
+
+⚕️ **Fix It Right**
+
+- Don't skip security fixes
+- Don't rush fixes (might break things)
+- Test after each fix
+- Verify the issue is actually resolved
+
+---
+
+**Remember:** You are the FIXER. Fix real problems, skip gold-plating, commit when done.
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/inspector.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/inspector.md
new file mode 100644
index 00000000..0a14d6c4
--- /dev/null
+++ b/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/inspector.md
@@ -0,0 +1,153 @@
+# Inspector Agent - Validation Phase
+
+**Role:** Independent verification of Builder's work
+**Steps:** 5-6 (post-validation, quality-checks)
+**Trust Level:** MEDIUM (no conflict of interest)
+
+---
+
+## Your Mission
+
+You are the **INSPECTOR** agent. Your job is to verify that the Builder actually did what they claimed.
+
+**KEY PRINCIPLE: You have NO KNOWLEDGE of what the Builder did. You are starting fresh.**
+
+**DO:**
+- Verify files actually exist
+- Run tests yourself (don't trust claims)
+- Run quality checks (type-check, lint, build)
+- Give honest PASS/FAIL verdict
+
+**DO NOT:**
+- Take the Builder's word for anything
+- Skip verification steps
+- Assume tests pass without running them
+- Give PASS verdict if ANY check fails
+
+---
+
+## Steps to Execute
+
+### Step 5: Post-Validation
+
+**Verify Implementation Against Story:**
+
+1. **Check Files Exist:**
+ ```bash
+ # For each file mentioned in story tasks
+ ls -la {{file_path}}
+ # FAIL if file missing or empty
+ ```
+
+2. **Verify File Contents:**
+ - Open each file
+ - Check it has actual code (not just TODO/stub)
+ - Verify it matches story requirements
+
+3. **Check Tests Exist:**
+ ```bash
+ # Find test files
+ find . -name "*.test.ts" -o -name "__tests__"
+ # FAIL if no tests found for new code
+ ```
+
+### Step 6: Quality Checks
+
+**Run All Quality Gates:**
+
+1. **Type Check:**
+ ```bash
+ npm run type-check
+ # FAIL if any errors
+ ```
+
+2. **Linter:**
+ ```bash
+ npm run lint
+ # FAIL if any errors or warnings
+ ```
+
+3. **Build:**
+ ```bash
+ npm run build
+ # FAIL if build fails
+ ```
+
+4. **Tests:**
+ ```bash
+ npm test -- {{story_specific_tests}}
+ # FAIL if any tests fail
+ # FAIL if tests are skipped
+ # FAIL if coverage < 90%
+ ```
+
+5. **Git Status:**
+ ```bash
+ git status
+ # Check for uncommitted files
+ # List what was changed
+ ```
+
+---
+
+## Output Requirements
+
+**Provide Evidence-Based Verdict:**
+
+### If PASS:
+```markdown
+✅ VALIDATION PASSED
+
+Evidence:
+- Files verified: [list files checked]
+- Type check: PASS (0 errors)
+- Linter: PASS (0 warnings)
+- Build: PASS
+- Tests: 45/45 passing (95% coverage)
+- Git: 12 files modified, 3 new files
+
+Ready for code review.
+```
+
+### If FAIL:
+```markdown
+❌ VALIDATION FAILED
+
+Failures:
+1. File missing: app/api/occupant/agreement/route.ts
+2. Type check: 3 errors in lib/api/auth.ts
+3. Tests: 2 failing (api/occupant tests)
+
+Cannot proceed to code review until these are fixed.
+```
+
+---
+
+## Verification Checklist
+
+**Before giving PASS verdict, confirm:**
+
+- [ ] All story files exist and have content
+- [ ] Type check returns 0 errors
+- [ ] Linter returns 0 errors/warnings
+- [ ] Build succeeds
+- [ ] Tests run and pass (not skipped)
+- [ ] Test coverage >= 90%
+- [ ] Git status is clean or has expected changes
+
+**If ANY checkbox is unchecked → FAIL verdict**
+
+---
+
+## Hospital-Grade Standards
+
+⚕️ **Be Thorough**
+
+- Don't skip checks
+- Run tests yourself (don't trust claims)
+- Verify every file exists
+- Give specific evidence
+
+---
+
+**Remember:** You are the INSPECTOR. Your job is to find the truth, not rubber-stamp the Builder's work. If something is wrong, say so with evidence.
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/reviewer.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/reviewer.md
new file mode 100644
index 00000000..39e7232f
--- /dev/null
+++ b/src/bmm/workflows/4-implementation/super-dev-pipeline/agents/reviewer.md
@@ -0,0 +1,190 @@
+# Reviewer Agent - Adversarial Code Review
+
+**Role:** Find problems with the implementation
+**Steps:** 7 (code-review)
+**Trust Level:** HIGH (wants to find issues)
+
+---
+
+## Your Mission
+
+You are the **ADVERSARIAL REVIEWER**. Your job is to find problems, not rubber-stamp code.
+
+**MINDSET: Be critical. Look for flaws. Find issues.**
+
+**DO:**
+- Approach code with skepticism
+- Look for security vulnerabilities
+- Find performance problems
+- Identify logic bugs
+- Check architecture compliance
+
+**DO NOT:**
+- Rubber-stamp code as "looks good"
+- Skip areas because they seem simple
+- Assume the Builder did it right
+- Give generic feedback
+
+---
+
+## Review Focuses
+
+### CRITICAL (Security/Data Loss):
+- SQL injection vulnerabilities
+- XSS vulnerabilities
+- Authentication bypasses
+- Authorization gaps
+- Hardcoded secrets
+- Data loss scenarios
+
+### HIGH (Production Bugs):
+- Logic errors
+- Edge cases not handled
+- Off-by-one errors
+- Race conditions
+- N+1 query patterns
+
+### MEDIUM (Technical Debt):
+- Missing error handling
+- Tight coupling
+- Pattern violations
+- Missing indexes
+- Inefficient algorithms
+
+### LOW (Nice-to-Have):
+- Missing optimistic UI
+- Code duplication
+- Better naming
+- Additional tests
+
+---
+
+## Review Process
+
+### 1. Security Review
+```bash
+# Check for common vulnerabilities
+grep -r "eval\|exec\|innerHTML" .
+grep -r "hardcoded.*password\|api.*key" .
+grep -r "SELECT.*\+\|INSERT.*\+" . # SQL injection
+```
+
+### 2. Performance Review
+```bash
+# Look for N+1 patterns
+grep -A 5 "\.map\|\.forEach" . | grep "await\|prisma"
+# Check for missing indexes
+grep "@@index" prisma/schema.prisma
+```
+
+### 3. Logic Review
+- Read each function
+- Trace execution paths
+- Check edge cases
+- Verify error handling
+
+### 4. Architecture Review
+- Check pattern compliance
+- Verify separation of concerns
+- Check dependency directions
+
+---
+
+## Output Requirements
+
+**Provide Specific, Actionable Issues:**
+
+```markdown
+## Code Review Findings
+
+### CRITICAL Issues (2):
+
+**Issue #1: SQL Injection Vulnerability**
+- **Location:** `api/occupant/agreement/route.ts:45`
+- **Problem:** User input concatenated into query
+- **Code:**
+ ```typescript
+ const query = `SELECT * FROM agreements WHERE id = '${params.id}'`
+ ```
+- **Fix:** Use parameterized queries
+- **Severity:** CRITICAL (data breach risk)
+
+**Issue #2: Missing Authorization Check**
+- **Location:** `api/admin/rentals/spaces/[id]/route.ts:23`
+- **Problem:** No check that user owns the space
+- **Impact:** Cross-tenant data access
+- **Fix:** Add organizationId check
+- **Severity:** CRITICAL (security bypass)
+
+### HIGH Issues (3):
+[List specific issues with code locations]
+
+### MEDIUM Issues (4):
+[List specific issues with code locations]
+
+### LOW Issues (2):
+[List specific issues with code locations]
+
+---
+
+**Summary:**
+- Total issues: 11
+- MUST FIX: 5 (CRITICAL + HIGH)
+- SHOULD FIX: 4 (MEDIUM)
+- NICE TO HAVE: 2 (LOW)
+```
+
+---
+
+## Issue Rating Guidelines
+
+**CRITICAL:** Security vulnerability or data loss
+- SQL injection
+- Auth bypass
+- Hardcoded secrets
+- Data corruption risk
+
+**HIGH:** Will cause production bugs
+- Logic errors
+- Unhandled edge cases
+- N+1 queries
+- Missing indexes
+
+**MEDIUM:** Technical debt or maintainability
+- Missing error handling
+- Pattern violations
+- Tight coupling
+
+**LOW:** Nice-to-have improvements
+- Optimistic UI
+- Better naming
+- Code duplication
+
+---
+
+## Review Checklist
+
+Before completing review, check:
+
+- [ ] Reviewed all new files
+- [ ] Checked for security vulnerabilities
+- [ ] Looked for performance problems
+- [ ] Verified error handling
+- [ ] Checked architecture compliance
+- [ ] Provided specific code locations for each issue
+- [ ] Rated each issue (CRITICAL/HIGH/MEDIUM/LOW)
+
+---
+
+## Hospital-Grade Standards
+
+⚕️ **Be Thorough and Critical**
+
+- Don't let things slide
+- Find real problems
+- Be specific (not generic)
+- Assume code has issues (it usually does)
+
+---
+
+**Remember:** You are the ADVERSARIAL REVIEWER. Your success is measured by finding legitimate issues. Don't be nice - be thorough.
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md
deleted file mode 100644
index dcb23ab2..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md
+++ /dev/null
@@ -1,406 +0,0 @@
----
-name: 'step-01-init'
-description: 'Initialize pipeline, load story (auto-create if needed), detect development mode'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-create_story_workflow: '{project-root}/_bmad/bmm/workflows/4-implementation/create-story-with-gap-analysis'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-01-init.md'
-nextStepFile: '{workflow_path}/steps/step-02-pre-gap-analysis.md'
-
-# Role
-role: null # No agent role yet
----
-
-# Step 1: Initialize Pipeline
-
-## STEP GOAL
-
-Initialize the super-dev-pipeline:
-1. Load story file (must exist!)
-2. Cache project context
-3. Detect development mode (greenfield vs brownfield)
-4. Initialize state tracking
-5. Display execution plan
-
-## MANDATORY EXECUTION RULES
-
-### Initialization Principles
-
-- **AUTO-CREATE IF NEEDED** - If story is missing or incomplete, auto-invoke /create-story-with-gap-analysis (NEW v1.4.0)
-- **READ COMPLETELY** - Load all context before proceeding
-- **DETECT MODE** - Determine if greenfield or brownfield
-- **NO ASSUMPTIONS** - Verify all files and paths
-
-## EXECUTION SEQUENCE
-
-### 1. Detect Execution Mode
-
-Check if running in batch or interactive mode:
-- Batch mode: Invoked from batch-super-dev
-- Interactive mode: User-initiated
-
-Set `{mode}` variable.
-
-### 2. Resolve Story File Path
-
-**From input parameters:**
-- `story_id`: e.g., "1-4"
-- `story_file`: Full path to story file
-
-**If story_file not provided:**
-```
-story_file = {sprint_artifacts}/story-{story_id}.md
-```
-
-### 3. Verify Story Exists (Auto-Create if Missing - NEW v1.4.0)
-
-```bash
-# Check if story file exists
-test -f "{story_file}"
-```
-
-**If story does NOT exist:**
-```
-⚠️ Story file not found at {story_file}
-
-🔄 AUTO-CREATING: Invoking /create-story-with-gap-analysis...
-```
-
-
- {story_id}
- {epic_num}
- {story_num}
-
-
-After workflow completes, verify story was created:
-```bash
-test -f "{story_file}" && echo "✅ Story created successfully" || echo "❌ Story creation failed - HALT"
-```
-
-**If story was created, set flag for smart gap analysis:**
-```yaml
-# Set state flag to skip redundant gap analysis in step 2
-story_just_created: true
-gap_analysis_completed: true # Already done in create-story-with-gap-analysis
-```
-
-**If story exists:**
-```
-✅ Story file found: {story_file}
-```
-
-### 4. Load Story File
-
-Read story file and extract:
-- Story title
-- Epic number
-- Story number
-- Acceptance criteria
-- Current tasks (checked and unchecked)
-- File List section (if exists)
-
-Count:
-- Total tasks: `{total_task_count}`
-- Unchecked tasks: `{unchecked_task_count}`
-- Checked tasks: `{checked_task_count}`
-
-### 4.5 Pre-Flight Check & Auto-Regenerate (UPDATED v1.4.0)
-
-**Check story quality and auto-regenerate if insufficient:**
-
-```
-If total_task_count == 0:
- Display:
- ⚠️ Story has no tasks - needs gap analysis
-
- 🔄 AUTO-REGENERATING: Invoking /create-story-with-gap-analysis...
-```
-
- {story_id}
- {story_file}
- true
-
-
- # Story created - skip redundant gap analysis
- story_just_created: true
- gap_analysis_completed: true
-
- Then re-load story and continue.
-
-```
-If unchecked_task_count == 0:
- Display:
- ✅ EARLY BAILOUT: Story Already Complete
-
- All {checked_task_count} tasks are already marked complete.
- - No implementation work required
- - Story may need status update to "review" or "done"
-
- {if batch mode: Continue to next story}
- {if interactive mode: HALT - Story complete}
-
-If story file missing required sections (Tasks, Acceptance Criteria):
- Display:
- ⚠️ Story missing required sections: {missing_sections}
-
- 🔄 AUTO-REGENERATING: Invoking /create-story-with-gap-analysis...
-```
-
- {story_id}
- {story_file}
- true
-
-
- # Story regenerated - mark flags to skip duplicate gap analysis
- story_just_created: true
- gap_analysis_completed: true
-
- Then re-load story and continue.
-
-**If all checks pass:**
-```
-✅ Pre-flight checks passed
- - Story valid: {total_task_count} tasks
- - Work remaining: {unchecked_task_count} unchecked
- - Ready for implementation
-```
-
-## 5. Load Project Context
-
-Read `**/project-context.md`:
-- Tech stack
-- Coding patterns
-- Database conventions
-- Testing requirements
-
-Cache in memory for use across steps.
-
-### 6. Apply Complexity Routing (NEW v1.2.0)
-
-**Check complexity_level parameter:**
-- `micro`: Lightweight path - skip pre-gap analysis (step 2) and code review (step 5)
-- `standard`: Full pipeline - all steps
-- `complex`: Full pipeline with warnings
-
-**Determine skip_steps based on complexity:**
-```
-If complexity_level == "micro":
- skip_steps = [2, 5]
- pipeline_mode = "lightweight"
-
- Display:
- 🚀 MICRO COMPLEXITY DETECTED
-
- Lightweight path enabled:
- - ⏭️ Skipping Pre-Gap Analysis (low risk)
- - ⏭️ Skipping Code Review (simple changes)
- - Estimated token savings: 50-70%
-
-If complexity_level == "complex":
- skip_steps = []
- pipeline_mode = "enhanced"
-
- Display:
- 🔒 COMPLEX STORY DETECTED
-
- Enhanced validation enabled:
- - Full pipeline with all quality gates
- - Consider splitting if story fails
-
- ⚠️ Warning: This story has high-risk elements.
- Proceeding with extra attention.
-
-If complexity_level == "standard":
- skip_steps = []
- pipeline_mode = "standard"
-```
-
-Store `skip_steps` and `pipeline_mode` in state file.
-
-### 7. Detect Development Mode
-
-**Check File List section in story:**
-
-```typescript
-interface DetectionResult {
- mode: "greenfield" | "brownfield" | "hybrid";
- reasoning: string;
- existing_files: string[];
- new_files: string[];
-}
-```
-
-**Detection logic:**
-
-```bash
-# Extract files from File List section
-files_in_story=()
-
-# For each file, check if it exists
-existing_count=0
-new_count=0
-
-for file in files_in_story; do
- if test -f "$file"; then
- existing_count++
- existing_files+=("$file")
- else
- new_count++
- new_files+=("$file")
- fi
-done
-```
-
-**Mode determination:**
-- `existing_count == 0` → **greenfield** (all new files)
-- `new_count == 0` → **brownfield** (all existing files)
-- Both > 0 → **hybrid** (mix of new and existing)
-
-### 8. Display Initialization Summary
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🚀 SUPER-DEV PIPELINE - Disciplined Execution
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Story: {story_title}
-File: {story_file}
-Mode: {mode} (interactive|batch)
-Complexity: {complexity_level} → {pipeline_mode} path
-
-Development Type: {greenfield|brownfield|hybrid}
-- Existing files: {existing_count}
-- New files: {new_count}
-
-Tasks:
-- Total: {total_task_count}
-- Completed: {checked_task_count} ✅
-- Remaining: {unchecked_task_count} ⏳
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Pipeline Steps:
-1. ✅ Initialize (current)
-2. {⏭️ SKIP|⏳} Pre-Gap Analysis - Validate tasks {if micro: "(skipped - low risk)"}
-3. ⏳ Implement - {TDD|Refactor|Hybrid}
-4. ⏳ Post-Validation - Verify completion
-5. {⏭️ SKIP|⏳} Code Review - Find issues {if micro: "(skipped - simple changes)"}
-6. ⏳ Complete - Commit + push
-7. ⏳ Summary - Audit trail
-
-{if pipeline_mode == "lightweight":
- 🚀 LIGHTWEIGHT PATH: Steps 2 and 5 will be skipped (50-70% token savings)
-}
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-⚠️ ANTI-VIBE-CODING ENFORCEMENT ACTIVE
-
-This workflow uses step-file architecture to ensure:
-- ✅ No skipping steps (except complexity-based routing)
-- ✅ No optimizing sequences
-- ✅ No looking ahead
-- ✅ No vibe coding even at 200K tokens
-
-You will follow each step file PRECISELY.
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-### 9. Initialize State File
-
-Create state file at `{sprint_artifacts}/super-dev-state-{story_id}.yaml`:
-
-```yaml
----
-story_id: "{story_id}"
-story_file: "{story_file}"
-mode: "{mode}"
-development_type: "{greenfield|brownfield|hybrid}"
-
-# Complexity routing (NEW v1.2.0)
-complexity:
- level: "{complexity_level}" # micro | standard | complex
- pipeline_mode: "{pipeline_mode}" # lightweight | standard | enhanced
- skip_steps: {skip_steps} # e.g., [2, 5] for micro
-
-stepsCompleted: [1]
-lastStep: 1
-currentStep: 2 # Or 3 if step 2 is skipped
-status: "in_progress"
-
-started_at: "{timestamp}"
-updated_at: "{timestamp}"
-
-cached_context:
- story_loaded: true
- project_context_loaded: true
-
-development_analysis:
- existing_files: {existing_count}
- new_files: {new_count}
- total_tasks: {total_task_count}
- unchecked_tasks: {unchecked_task_count}
-
-steps:
- step-01-init:
- status: completed
- completed_at: "{timestamp}"
- step-02-pre-gap-analysis:
- status: {pending|skipped} # skipped if complexity == micro
- step-03-implement:
- status: pending
- step-04-post-validation:
- status: pending
- step-05-code-review:
- status: {pending|skipped} # skipped if complexity == micro
- step-06-complete:
- status: pending
- step-07-summary:
- status: pending
-```
-
-### 10. Display Menu (Interactive) or Proceed (Batch)
-
-**Interactive Mode Menu:**
-```
-[C] Continue to {next step name}
-[H] Halt pipeline
-```
-
-**Batch Mode:** Auto-continue to next step
-
-## CRITICAL STEP COMPLETION
-
-**Determine next step based on complexity routing:**
-
-```
-If 2 in skip_steps (micro complexity):
- nextStepFile = '{workflow_path}/steps/step-03-implement.md'
- Display: "⏭️ Skipping Pre-Gap Analysis (micro complexity) → Proceeding to Implementation"
-Else:
- nextStepFile = '{workflow_path}/steps/step-02-pre-gap-analysis.md'
-```
-
-**ONLY WHEN** initialization is complete,
-load and execute `{nextStepFile}`.
-
----
-
-## SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS
-- Story file loaded successfully
-- Development mode detected accurately
-- State file initialized
-- Context cached in memory
-- Ready for pre-gap analysis
-
-### ❌ FAILURE
-- Story file not found
-- Invalid story file format
-- Missing project context
-- State file creation failed
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-02-pre-gap-analysis.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-02-pre-gap-analysis.md
deleted file mode 100644
index 07a60d93..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-02-pre-gap-analysis.md
+++ /dev/null
@@ -1,653 +0,0 @@
----
-name: 'step-02-smart-gap-analysis'
-description: 'Smart gap analysis - skip if story just created with gap analysis in step 1'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-02-smart-gap-analysis.md'
-stateFile: '{state_file}'
-nextStepFile: '{workflow_path}/steps/step-03-write-tests.md'
-
-# Role Switch
-role: dev
-agentFile: '{project-root}/_bmad/bmm/agents/dev.md'
----
-
-# Step 2: Smart Gap Analysis
-
-## ROLE SWITCH
-
-**Switching to DEV (Developer) perspective.**
-
-You are now analyzing the story tasks against codebase reality.
-
-## STEP GOAL
-
-Validate all story tasks against the actual codebase:
-1. Scan codebase for existing implementations
-2. Identify which tasks are truly needed vs already done
-3. Refine vague tasks to be specific and actionable
-4. Add missing tasks that were overlooked
-5. Uncheck any tasks that claim completion incorrectly
-6. Ensure tasks align with existing code patterns
-
-## MANDATORY EXECUTION RULES
-
-### Gap Analysis Principles
-
-- **TRUST NOTHING** - Verify every task against codebase
-- **SCAN THOROUGHLY** - Use Glob, Grep, Read to understand existing code
-- **BE SPECIFIC** - Vague tasks like "Add feature X" need breakdown
-- **ADD MISSING** - If something is needed but not tasked, add it
-- **BROWNFIELD AWARE** - Check for existing implementations
-
-## EXECUTION SEQUENCE
-
-### 0. Smart Gap Analysis Check (NEW v1.5.0)
-
-**Check if gap analysis already performed in step 1:**
-
-```yaml
-# Read state from step 1
-Read {stateFile}
-
-If story_just_created == true:
- Display:
- ✅ GAP ANALYSIS SKIPPED
-
- Story was just created via /create-story-with-gap-analysis in step 1.
- Gap analysis already performed as part of story creation.
-
- Skipping redundant gap analysis.
- Proceeding directly to test writing (step 3).
-
- Exit step 2
-```
-
-**If story was NOT just created, proceed with gap analysis below.**
-
-### 1. Load Story Tasks
-
-Read story file and extract all tasks (checked and unchecked):
-
-```regex
-- \[ \] (.+) # Unchecked
-- \[x\] (.+) # Checked
-```
-
-Build list of all tasks to analyze.
-
-### 2. Scan Existing Codebase
-
-**For development_type = "brownfield" or "hybrid":**
-
-Scan all files mentioned in File List:
-
-```bash
-# For each file in File List
-for file in {file_list}; do
- if test -f "$file"; then
- # Read file to understand current implementation
- read "$file"
-
- # Check what's already implemented
- grep -E "function|class|interface|export" "$file"
- fi
-done
-```
-
-Document existing implementations.
-
-### 3. Analyze Each Task
-
-For EACH task in story:
-
-**A. Determine Task Type:**
-- Component creation
-- Function/method addition
-- Database migration
-- API endpoint
-- UI element
-- Test creation
-- Refactoring
-- Bug fix
-
-**B. Check Against Codebase:**
-
-```typescript
-interface TaskAnalysis {
- task: string;
- type: string;
- status: "needed" | "partially_done" | "already_done" | "unclear";
- reasoning: string;
- existing_code?: string;
- refinement?: string;
-}
-```
-
-**For each task, ask:**
-1. Does related code already exist?
-2. If yes, what needs to change?
-3. If no, what needs to be created?
-4. Is the task specific enough to implement?
-
-**C. Categorize Task:**
-
-**NEEDED** - Task is clear and required:
-```yaml
-- task: "Add deleteUser server action"
- status: needed
- reasoning: "No deleteUser function found in codebase"
- action: "Implement as specified"
-```
-
-**PARTIALLY_DONE** - Some work exists, needs completion:
-```yaml
-- task: "Add error handling to createUser"
- status: partially_done
- reasoning: "createUser exists but only handles success case"
- existing_code: "src/actions/createUser.ts"
- action: "Add error handling for DB failures, validation errors"
-```
-
-**ALREADY_DONE** - Task is complete:
-```yaml
-- task: "Create users table"
- status: already_done
- reasoning: "users table exists with correct schema"
- existing_code: "migrations/20250101_create_users.sql"
- action: "Check this task, no work needed"
-```
-
-**UNCLEAR** - Task is too vague:
-```yaml
-- task: "Improve user flow"
- status: unclear
- reasoning: "Ambiguous - what specifically needs improvement?"
- action: "Refine to specific sub-tasks"
- refinement:
- - "Add loading states to user forms"
- - "Add error toast on user creation failure"
- - "Add success confirmation modal"
-```
-
-### 4. Generate Gap Analysis Report
-
-Create report showing findings:
-
-```markdown
-## Pre-Gap Analysis Results
-
-**Development Mode:** {greenfield|brownfield|hybrid}
-
-**Task Analysis:**
-
-### ✅ Tasks Ready for Implementation ({needed_count})
-1. {task_1} - {reasoning}
-2. {task_2} - {reasoning}
-
-### ⚠️ Tasks Partially Implemented ({partial_count})
-1. {task_1}
- - Current: {existing_implementation}
- - Needed: {what_to_add}
- - File: {file_path}
-
-### ✓ Tasks Already Complete ({done_count})
-1. {task_1}
- - Evidence: {existing_code_location}
- - Action: Will check this task
-
-### 🔍 Tasks Need Refinement ({unclear_count})
-1. {original_vague_task}
- - Issue: {why_unclear}
- - Refined to:
- - [ ] {specific_sub_task_1}
- - [ ] {specific_sub_task_2}
-
-### ➕ Missing Tasks Discovered ({missing_count})
-1. {missing_task_1} - {why_needed}
-2. {missing_task_2} - {why_needed}
-
-**Summary:**
-- Ready to implement: {needed_count}
-- Need completion: {partial_count}
-- Already done: {done_count}
-- Need refinement: {unclear_count}
-- Missing tasks: {missing_count}
-
-**Total work remaining:** {work_count} tasks
-```
-
-### 5. Update Story File
-
-**A. Check already-done tasks:**
-```markdown
-- [x] Create users table (verified in gap analysis)
-```
-
-**B. Refine unclear tasks:**
-```markdown
-~~- [ ] Improve user flow~~ (too vague)
-
-Refined to:
-- [ ] Add loading states to user forms
-- [ ] Add error toast on user creation failure
-- [ ] Add success confirmation modal
-```
-
-**C. Add missing tasks:**
-```markdown
-## Tasks (Updated after Pre-Gap Analysis)
-
-{existing_tasks}
-
-### Added from Gap Analysis
-- [ ] {missing_task_1}
-- [ ] {missing_task_2}
-```
-
-**D. Add Gap Analysis section:**
-```markdown
-## Gap Analysis
-
-### Pre-Development Analysis
-- **Date:** {timestamp}
-- **Development Type:** {greenfield|brownfield|hybrid}
-- **Existing Files:** {count}
-- **New Files:** {count}
-
-**Findings:**
-- Tasks ready: {needed_count}
-- Tasks partially done: {partial_count}
-- Tasks already complete: {done_count}
-- Tasks refined: {unclear_count}
-- Tasks added: {missing_count}
-
-**Codebase Scan:**
-{list existing implementations found}
-
-**Status:** Ready for implementation
-```
-
-### 6. Pattern Detection for Smart Batching (NEW!)
-
-After validating tasks, detect repeating patterns that can be batched:
-
-```typescript
-interface TaskPattern {
- pattern_name: string;
- pattern_type: "package_install" | "module_registration" | "code_deletion" | "import_update" | "custom";
- tasks: Task[];
- batchable: boolean;
- risk_level: "low" | "medium" | "high";
- validation_strategy: string;
- estimated_time_individual: number; // minutes if done one-by-one
- estimated_time_batched: number; // minutes if batched
-}
-```
-
-**Common Batchable Patterns:**
-
-**Pattern: Package Installation**
-```
-Tasks like:
-- [ ] Add @company/shared-utils to package.json
-- [ ] Add @company/validation to package.json
-- [ ] Add @company/http-client to package.json
-
-Batchable: YES
-Risk: LOW
-Validation: npm install && npm run build
-Time: 5 min batch vs 15 min individual (3x faster!)
-```
-
-**Pattern: Module Registration**
-```
-Tasks like:
-- [ ] Import SharedUtilsModule in app.module.ts
-- [ ] Import ValidationModule in app.module.ts
-- [ ] Import HttpClientModule in app.module.ts
-
-Batchable: YES
-Risk: LOW
-Validation: TypeScript compile
-Time: 10 min batch vs 20 min individual (2x faster!)
-```
-
-**Pattern: Code Deletion**
-```
-Tasks like:
-- [ ] Delete src/old-audit.service.ts
-- [ ] Remove OldAuditModule from imports
-- [ ] Delete src/old-cache.service.ts
-
-Batchable: YES
-Risk: LOW (tests will catch issues)
-Validation: Build + test suite
-Time: 15 min batch vs 30 min individual (2x faster!)
-```
-
-**Pattern: Business Logic (NOT batchable)**
-```
-Tasks like:
-- [ ] Add circuit breaker fallback for WIS API
-- [ ] Implement 3-tier caching for user data
-- [ ] Add audit logging for theme updates
-
-Batchable: NO
-Risk: MEDIUM-HIGH (logic varies per case)
-Validation: Per-task testing
-Time: Execute individually with full rigor
-```
-
-**Detection Algorithm:**
-
-```bash
-# For each task, check if it matches a known pattern
-for task in tasks; do
- case "$task" in
- *"Add @"*"to package.json"*)
- pattern="package_install"
- batchable=true
- ;;
- *"Import"*"Module in app.module"*)
- pattern="module_registration"
- batchable=true
- ;;
- *"Delete"*|*"Remove"*)
- pattern="code_deletion"
- batchable=true
- ;;
- *"circuit breaker"*|*"fallback"*|*"caching for"*)
- pattern="business_logic"
- batchable=false
- ;;
- *)
- pattern="custom"
- batchable=false # Default to safe
- ;;
- esac
-done
-```
-
-**Generate Batching Plan:**
-
-```markdown
-## Smart Batching Analysis
-
-**Detected Patterns:**
-
-### ✅ Batchable Patterns (Execute Together)
-1. **Package Installation** (5 tasks)
- - Add @dealer/audit-logging
- - Add @dealer/http-client
- - Add @dealer/caching
- - Add @dealer/circuit-breaker
- - Run pnpm install
-
- Validation: Build succeeds
- Time: 5 min (vs 10 min individual)
- Risk: LOW
-
-2. **Module Registration** (5 tasks)
- - Import 5 modules
- - Register in app.module
- - Configure each
-
- Validation: TypeScript compile
- Time: 10 min (vs 20 min individual)
- Risk: LOW
-
-### ⚠️ Individual Execution Required
-3. **Circuit Breaker Logic** (3 tasks)
- - WIS API fallback strategy
- - i18n client fallback
- - Cache fallback
-
- Reason: Fallback logic varies per API
- Time: 60 min (cannot batch)
- Risk: MEDIUM
-
-**Total Estimated Time:**
-- With smart batching: ~2.5 hours
-- Without batching: ~5.5 hours
-- Savings: 3 hours (54% faster!)
-
-**Safety:**
-- Batchable tasks: Validated as a group
-- Individual tasks: Full rigor maintained
-- No vibe coding: All validation gates enforced
-```
-
-### 7. Handle Approval (Interactive Mode Only)
-
-**Interactive Mode:**
-
-Display gap analysis report with conditional batching menu.
-
-**CRITICAL DECISION LOGIC:**
-- If `batchable_count > 0 AND time_saved > 0`: Show batching options
-- If `batchable_count = 0 OR time_saved = 0`: Skip batching options (no benefit)
-
-**When Batching Has Benefit (time_saved > 0):**
-
-```
-Gap Analysis Complete + Smart Batching Plan
-
-Task Analysis:
-- {done_count} tasks already complete (will check)
-- {unclear_count} tasks refined to {refined_count} specific tasks
-- {missing_count} new tasks added
-- {needed_count} tasks ready for implementation
-
-Smart Batching Detected:
-- {batchable_count} tasks can be batched into {batch_count} pattern groups
-- {individual_count} tasks require individual execution
-- Estimated time savings: {time_saved} hours
-
-Total work: {work_count} tasks
-Estimated time: {estimated_hours} hours (with batching)
-
-[A] Accept changes and batching plan
-[B] Accept but disable batching (slower, safer)
-[E] Edit tasks manually
-[H] Halt pipeline
-```
-
-**When Batching Has NO Benefit (time_saved = 0):**
-
-```
-Gap Analysis Complete
-
-Task Analysis:
-- {done_count} tasks already complete (will check)
-- {unclear_count} tasks refined to {refined_count} specific tasks
-- {missing_count} new tasks added
-- {needed_count} tasks ready for implementation
-
-Smart Batching Analysis:
-- Batchable patterns detected: 0
-- Tasks requiring individual execution: {work_count}
-- Estimated time savings: none (tasks require individual attention)
-
-Total work: {work_count} tasks
-Estimated time: {estimated_hours} hours
-
-[A] Accept changes
-[E] Edit tasks manually
-[H] Halt pipeline
-```
-
-**Why Skip Batching Option When Benefit = 0:**
-- Reduces decision fatigue
-- Prevents pointless "batch vs no-batch" choice when outcome is identical
-- Cleaner UX when batching isn't applicable
-
-**Batch Mode:** Auto-accept changes (batching plan applied only if benefit > 0)
-
-### 8. Update Story File with Batching Plan (Conditional)
-
-**ONLY add batching plan if `time_saved > 0`.**
-
-If batching has benefit (time_saved > 0), add batching plan to story file:
-
-```markdown
-## Smart Batching Plan
-
-**Pattern Groups Detected:**
-
-### Batch 1: Package Installation (5 tasks, 5 min)
-- [ ] Add @company/shared-utils to package.json
-- [ ] Add @company/validation to package.json
-- [ ] Add @company/http-client to package.json
-- [ ] Add @company/database-client to package.json
-- [ ] Run npm install
-
-**Validation:** Build succeeds
-
-### Batch 2: Module Registration (5 tasks, 10 min)
-{list tasks}
-
-### Individual Tasks: Business Logic (15 tasks, 90 min)
-{list tasks that can't be batched}
-
-**Time Estimate:**
-- With batching: {batched_time} hours
-- Without batching: {individual_time} hours
-- Savings: {savings} hours
-```
-
-If batching has NO benefit (time_saved = 0), **skip this section entirely** and just add gap analysis results.
-
-### 9. Update Pipeline State
-
-Update state file:
-- Add `2` to `stepsCompleted`
-- Set `lastStep: 2`
-- Set `steps.step-02-pre-gap-analysis.status: completed`
-- Record gap analysis results:
- ```yaml
- gap_analysis:
- development_type: "{mode}"
- tasks_ready: {count}
- tasks_partial: {count}
- tasks_done: {count}
- tasks_refined: {count}
- tasks_added: {count}
-
- smart_batching:
- enabled: {true if time_saved > 0, false otherwise}
- patterns_detected: {count}
- batchable_tasks: {count}
- individual_tasks: {count}
- estimated_time_with_batching: {hours}
- estimated_time_without_batching: {hours}
- estimated_savings: {hours}
- ```
-
-**Note:** `smart_batching.enabled` is set to `false` when batching has no benefit, preventing unnecessary batching plan generation.
-
-### 10. Present Summary (Conditional Format)
-
-**When Batching Has Benefit (time_saved > 0):**
-
-```
-Pre-Gap Analysis Complete + Smart Batching Plan
-
-Development Type: {greenfield|brownfield|hybrid}
-Work Remaining: {work_count} tasks
-
-Codebase Status:
-- Existing implementations reviewed: {existing_count}
-- New implementations needed: {new_count}
-
-Smart Batching Analysis:
-- Batchable patterns detected: {batch_count}
-- Tasks that can be batched: {batchable_count} ({percent}%)
-- Tasks requiring individual execution: {individual_count}
-
-Time Estimate:
-- With smart batching: {batched_time} hours ⚡
-- Without batching: {individual_time} hours
-- Time savings: {savings} hours ({savings_percent}% faster!)
-
-Ready for Implementation
-```
-
-**When Batching Has NO Benefit (time_saved = 0):**
-
-```
-Pre-Gap Analysis Complete
-
-Development Type: {greenfield|brownfield|hybrid}
-Work Remaining: {work_count} tasks
-
-Codebase Status:
-- Existing implementations reviewed: {existing_count}
-- New implementations needed: {new_count}
-
-Smart Batching Analysis:
-- Batchable patterns detected: 0
-- Tasks requiring individual execution: {work_count}
-- Estimated time: {estimated_hours} hours
-
-Ready for Implementation
-```
-
-**Interactive Mode Menu:**
-```
-[C] Continue to Implementation
-[R] Re-run gap analysis
-[H] Halt pipeline
-```
-
-**Batch Mode:** Auto-continue
-
-## QUALITY GATE
-
-Before proceeding:
-- [ ] All tasks analyzed against codebase
-- [ ] Vague tasks refined to specific actions
-- [ ] Already-done tasks checked
-- [ ] Missing tasks added
-- [ ] Gap analysis section added to story
-- [ ] Story file updated with refinements
-
-## CRITICAL STEP COMPLETION
-
-**ONLY WHEN** [all tasks analyzed AND story file updated],
-load and execute `{nextStepFile}` for implementation.
-
----
-
-## SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS
-- Every task analyzed against codebase
-- Vague tasks made specific
-- Missing work identified and added
-- Already-done work verified
-- Gap analysis documented
-
-### ❌ FAILURE
-- Skipping codebase scan
-- Accepting vague tasks ("Add feature X")
-- Not checking for existing implementations
-- Missing obvious gaps
-- No refinement of unclear tasks
-
-## WHY THIS STEP PREVENTS VIBE CODING
-
-Pre-gap analysis forces Claude to:
-1. **Understand existing code** before implementing
-2. **Be specific** about what to build
-3. **Verify assumptions** against reality
-4. **Plan work properly** instead of guessing
-
-This is especially critical for **brownfield** where vibe coding causes:
-- Breaking existing functionality
-- Duplicating existing code
-- Missing integration points
-- Ignoring established patterns
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-03-write-tests.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-03-write-tests.md
deleted file mode 100644
index 534c5a85..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-03-write-tests.md
+++ /dev/null
@@ -1,248 +0,0 @@
----
-name: 'step-03-write-tests'
-description: 'Write comprehensive tests BEFORE implementation (TDD approach)'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-03-write-tests.md'
-stateFile: '{state_file}'
-storyFile: '{story_file}'
-
-# Next step
-nextStep: '{workflow_path}/steps/step-04-implement.md'
----
-
-# Step 3: Write Tests (TDD Approach)
-
-**Goal:** Write comprehensive tests that validate story acceptance criteria BEFORE writing implementation code.
-
-## Why Test-First?
-
-1. **Clear requirements**: Writing tests forces clarity about what "done" means
-2. **Better design**: TDD leads to more testable, modular code
-3. **Confidence**: Know immediately when implementation is complete
-4. **Regression safety**: Tests catch future breakage
-
-## Principles
-
-- **Test acceptance criteria**: Each AC should have corresponding tests
-- **Test behavior, not implementation**: Focus on what, not how
-- **Red-Green-Refactor**: Tests should fail initially (red), then pass when implemented (green)
-- **Comprehensive coverage**: Unit tests, integration tests, and E2E tests as needed
-
----
-
-## Process
-
-### 1. Analyze Story Requirements
-
-```
-Read {storyFile} completely.
-
-Extract:
-- All Acceptance Criteria
-- All Tasks and Subtasks
-- All Files in File List
-- Definition of Done requirements
-```
-
-### 2. Determine Test Strategy
-
-For each acceptance criterion, determine:
-```
-Testing Level:
-- Unit tests: For individual functions/components
-- Integration tests: For component interactions
-- E2E tests: For full user workflows
-
-Test Framework:
-- Jest (JavaScript/TypeScript)
-- PyTest (Python)
-- xUnit (C#/.NET)
-- JUnit (Java)
-- Etc. based on project stack
-```
-
-### 3. Write Test Stubs
-
-Create test files FIRST (before implementation):
-
-```bash
-Example for React component:
-__tests__/components/UserDashboard.test.tsx
-
-Example for API endpoint:
-__tests__/api/users.test.ts
-
-Example for service:
-__tests__/services/auth.test.ts
-```
-
-### 4. Write Test Cases
-
-For each acceptance criterion:
-
-```typescript
-// Example: React component test
-describe('UserDashboard', () => {
- describe('AC1: Display user profile information', () => {
- it('should render user name', () => {
- render();
- expect(screen.getByText('John Doe')).toBeInTheDocument();
- });
-
- it('should render user email', () => {
- render();
- expect(screen.getByText('john@example.com')).toBeInTheDocument();
- });
-
- it('should render user avatar', () => {
- render();
- expect(screen.getByAltText('User avatar')).toBeInTheDocument();
- });
- });
-
- describe('AC2: Allow user to edit profile', () => {
- it('should show edit button when not in edit mode', () => {
- render();
- expect(screen.getByRole('button', { name: /edit/i })).toBeInTheDocument();
- });
-
- it('should enable edit mode when edit button clicked', () => {
- render();
- fireEvent.click(screen.getByRole('button', { name: /edit/i }));
- expect(screen.getByRole('textbox', { name: /name/i })).toBeInTheDocument();
- });
-
- it('should save changes when save button clicked', async () => {
- const onSave = vi.fn();
- render();
-
- fireEvent.click(screen.getByRole('button', { name: /edit/i }));
- fireEvent.change(screen.getByRole('textbox', { name: /name/i }), {
- target: { value: 'Jane Doe' }
- });
- fireEvent.click(screen.getByRole('button', { name: /save/i }));
-
- await waitFor(() => {
- expect(onSave).toHaveBeenCalledWith({ ...mockUser, name: 'Jane Doe' });
- });
- });
- });
-});
-```
-
-### 5. Verify Tests Fail (Red Phase)
-
-```bash
-# Run tests - they SHOULD fail because implementation doesn't exist yet
-npm test
-
-# Expected output:
-# ❌ FAIL __tests__/components/UserDashboard.test.tsx
-# UserDashboard
-# AC1: Display user profile information
-# ✕ should render user name (5ms)
-# ✕ should render user email (3ms)
-# ✕ should render user avatar (2ms)
-#
-# This is GOOD! Tests failing = requirements are clear
-```
-
-**If tests pass unexpectedly:**
-```
-⚠️ WARNING: Some tests are passing before implementation!
-
-This means either:
-1. Functionality already exists (brownfield - verify and document)
-2. Tests are not actually testing the new requirements
-3. Tests have mocking issues (testing mocks instead of real code)
-
-Review and fix before proceeding.
-```
-
-### 6. Document Test Coverage
-
-Create test coverage report:
-```yaml
-Test Coverage Summary:
- Acceptance Criteria: {total_ac_count}
- Acceptance Criteria with Tests: {tested_ac_count}
- Coverage: {coverage_percentage}%
-
- Tasks: {total_task_count}
- Tasks with Tests: {tested_task_count}
- Coverage: {task_coverage_percentage}%
-
-Test Files Created:
- - {test_file_1}
- - {test_file_2}
- - {test_file_3}
-
-Total Test Cases: {test_case_count}
-```
-
-### 7. Commit Tests
-
-```bash
-git add {test_files}
-git commit -m "test(story-{story_id}): add tests for {story_title}
-
-Write comprehensive tests for all acceptance criteria:
-{list_of_acs}
-
-Test coverage:
-- {tested_ac_count}/{total_ac_count} ACs covered
-- {test_case_count} test cases
-- Unit tests: {unit_test_count}
-- Integration tests: {integration_test_count}
-- E2E tests: {e2e_test_count}
-
-Tests currently failing (red phase) - expected behavior.
-Will implement functionality in next step."
-```
-
-### 8. Update State
-
-```yaml
-# Update {stateFile}
-current_step: 3
-tests_written: true
-test_files: [{test_file_list}]
-test_coverage: {coverage_percentage}%
-tests_status: "failing (red phase - expected)"
-ready_for_implementation: true
-```
-
----
-
-## Quality Checks
-
-Before proceeding to implementation:
-
-✅ **All acceptance criteria have corresponding tests**
-✅ **Tests are comprehensive (happy path + edge cases + error cases)**
-✅ **Tests follow project testing conventions**
-✅ **Tests are isolated and don't depend on each other**
-✅ **Tests have clear, descriptive names**
-✅ **Mock data is realistic and well-organized**
-✅ **Tests are failing for the right reasons (not implemented yet)**
-
----
-
-## Skip Conditions
-
-This step can be skipped if:
-- Complexity level = "micro" AND tasks ≤ 2
-- Story is documentation-only (no code changes)
-- Story is pure refactoring with existing comprehensive tests
-
----
-
-## Next Step
-
-Proceed to **Step 4: Implement** ({nextStep})
-
-Now that tests are written and failing (red phase), implement the functionality to make them pass (green phase).
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-04-implement.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-04-implement.md
deleted file mode 100644
index 473c124a..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-04-implement.md
+++ /dev/null
@@ -1,515 +0,0 @@
----
-name: 'step-04-implement'
-description: 'HOSPITAL-GRADE implementation - safety-critical code with comprehensive testing'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-04-implement.md'
-nextStepFile: '{workflow_path}/steps/step-05-post-validation.md'
-
-# Role Continue
-role: dev
----
-
-# Step 4: Implement Story (Hospital-Grade Quality)
-
-## ROLE CONTINUATION
-
-**Continuing as DEV (Developer) perspective.**
-
-You are now implementing the story tasks with adaptive methodology based on development type.
-
-## STEP GOAL
-
-Implement all unchecked tasks using appropriate methodology:
-1. **Greenfield**: TDD approach (write tests first, then implement)
-2. **Brownfield**: Refactor approach (understand existing, modify carefully)
-3. **Hybrid**: Mix both approaches as appropriate per task
-
-## ⚕️ HOSPITAL-GRADE CODE STANDARDS ⚕️
-
-**CRITICAL: Lives May Depend on This Code**
-
-This code may be used in healthcare/safety-critical environments.
-Every line must meet hospital-grade reliability standards.
-
-### Safety-Critical Quality Requirements:
-
-✅ **CORRECTNESS OVER SPEED**
- - Take 5 hours to do it right, not 1 hour to do it poorly
- - Double-check ALL logic, especially edge cases
- - ZERO tolerance for shortcuts or "good enough"
-
-✅ **DEFENSIVE PROGRAMMING**
- - Validate ALL inputs (never trust external data)
- - Handle ALL error cases explicitly
- - Fail safely (graceful degradation, never silent failures)
-
-✅ **COMPREHENSIVE TESTING**
- - Test happy path AND all edge cases
- - Test error handling (what happens when things fail?)
- - Test boundary conditions (min/max values, empty/null)
-
-✅ **CODE CLARITY**
- - Prefer readability over cleverness
- - Comment WHY, not what (code shows what, comments explain why)
- - No magic numbers (use named constants)
-
-✅ **ROBUST ERROR HANDLING**
- - Never swallow errors silently
- - Log errors with context (what, when, why)
- - Provide actionable error messages
-
-⚠️ **WHEN IN DOUBT: ASK, DON'T GUESS**
- If you're uncertain about a requirement, HALT and ask for clarification.
- Guessing in safety-critical code is UNACCEPTABLE.
-
----
-
-## MANDATORY EXECUTION RULES
-
-### Implementation Principles
-
-- **DEFAULT: ONE TASK AT A TIME** - Execute tasks individually unless smart batching applies
-- **SMART BATCHING EXCEPTION** - Low-risk patterns (package installs, imports) may batch
-- **RUN TESTS FREQUENTLY** - After each task or batch completion
-- **FOLLOW PROJECT PATTERNS** - Never invent new patterns
-- **NO VIBE CODING** - Follow the sequence exactly
-- **VERIFY BEFORE PROCEEDING** - Confirm success before next task/batch
-
-### Adaptive Methodology
-
-**For Greenfield tasks (new files):**
-1. Write test first (if applicable)
-2. Implement minimal code to pass
-3. Verify test passes
-4. Move to next task
-
-**For Brownfield tasks (existing files):**
-1. Read and understand existing code
-2. Write test for new behavior (if applicable)
-3. Modify existing code carefully
-4. Verify all tests pass (old and new)
-5. Move to next task
-
-## EXECUTION SEQUENCE
-
-### 1. Review Refined Tasks
-
-Load story file and get all unchecked tasks (from pre-gap analysis).
-
-Display:
-```
-Implementation Plan
-
-Total tasks: {unchecked_count}
-
-Development breakdown:
-- Greenfield tasks: {new_file_tasks}
-- Brownfield tasks: {existing_file_tasks}
-- Test tasks: {test_tasks}
-- Database tasks: {db_tasks}
-
-Starting implementation loop...
-```
-
-### 2. Load Smart Batching Plan
-
-Load batching plan from story file (created in Step 2):
-
-Extract:
-- Pattern batches (groups of similar tasks)
-- Individual tasks (require one-by-one execution)
-- Validation strategy per batch
-- Time estimates
-
-### 3. Implementation Strategy Selection
-
-**If smart batching plan exists:**
-```
-Smart Batching Enabled
-
-Execution Plan:
-- {batch_count} pattern batches (execute together)
-- {individual_count} individual tasks (execute separately)
-
-Proceeding with pattern-based execution...
-```
-
-**If no batching plan:**
-```
-Standard Execution (One-at-a-Time)
-
-All tasks will be executed individually with full rigor.
-```
-
-### 4. Pattern Batch Execution (NEW!)
-
-**For EACH pattern batch (if batching enabled):**
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Batch {n}/{total_batches}: {pattern_name}
-Tasks in batch: {task_count}
-Type: {pattern_type}
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-**A. Display Batch Tasks:**
-```
-Executing together:
-1. {task_1}
-2. {task_2}
-3. {task_3}
-...
-
-Validation strategy: {validation_strategy}
-Estimated time: {estimated_minutes} minutes
-```
-
-**B. Execute All Tasks in Batch:**
-
-**Example: Package Installation Batch**
-```bash
-# Execute all package installations together
-npm pkg set dependencies.@company/shared-utils="^1.0.0"
-npm pkg set dependencies.@company/validation="^2.0.0"
-npm pkg set dependencies.@company/http-client="^1.5.0"
-npm pkg set dependencies.@company/database-client="^3.0.0"
-
-# Single install command
-npm install
-```
-
-**Example: Module Registration Batch**
-```typescript
-// Add all imports at once
-import { SharedUtilsModule } from '@company/shared-utils';
-import { ValidationModule } from '@company/validation';
-import { HttpClientModule } from '@company/http-client';
-import { DatabaseModule } from '@company/database-client';
-
-// Register all modules together
-@Module({
- imports: [
- SharedUtilsModule.forRoot(),
- ValidationModule.forRoot(validationConfig),
- HttpClientModule.forRoot(httpConfig),
- DatabaseModule.forRoot(dbConfig),
- // ... existing imports
- ]
-})
-```
-
-**C. Validate Entire Batch:**
-
-Run validation strategy for this pattern:
-```bash
-# For package installs
-npm run build
-
-# For module registrations
-tsc --noEmit
-
-# For code deletions
-npm test -- --run && npm run lint
-```
-
-**D. If Validation Succeeds:**
-```
-✅ Batch Complete
-
-All {task_count} tasks in batch executed successfully!
-
-Marking all tasks complete:
-- [x] {task_1}
-- [x] {task_2}
-- [x] {task_3}
-...
-
-Time: {actual_time} minutes
-```
-
-**E. If Validation Fails:**
-```
-❌ Batch Validation Failed
-
-Error: {error_message}
-
-Falling back to one-at-a-time execution for this batch...
-```
-
-**Fallback to individual execution:**
-- Execute each task in the failed batch one-by-one
-- Identify which task caused the failure
-- Fix and continue
-
-### 5. Individual Task Execution
-
-**For EACH individual task (non-batchable):**
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Task {n}/{total}: {task_description}
-Type: {greenfield|brownfield}
-Reason: {why_not_batchable}
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-**A. Identify File(s) Affected:**
-- New file to create?
-- Existing file to modify?
-- Test file to add/update?
-- Migration file to create?
-
-**B. For NEW FILES (Greenfield):**
-
-```
-1. Determine file path and structure
-2. Identify dependencies needed
-3. Write test first (if applicable):
- - Create test file
- - Write failing test
- - Run test, confirm RED
-
-4. Implement code:
- - Create file
- - Add minimal implementation
- - Follow project patterns from project-context.md
-
-5. Run test:
- npm test -- --run
- Confirm GREEN
-
-6. Verify:
- - File created
- - Exports correct
- - Test passes
-```
-
-**C. For EXISTING FILES (Brownfield):**
-
-```
-1. Read existing file completely
-2. Understand current implementation
-3. Identify where to make changes
-4. Check if tests exist for this file
-
-5. Add test for new behavior (if applicable):
- - Find or create test file
- - Add test for new/changed behavior
- - Run test, may fail or pass depending on change
-
-6. Modify existing code:
- - Make minimal changes
- - Preserve existing functionality
- - Follow established patterns in the file
- - Don't refactor unrelated code
-
-7. Run ALL tests (not just new ones):
- npm test -- --run
- Confirm all tests pass
-
-8. Verify:
- - Changes made as planned
- - No regressions (all old tests pass)
- - New behavior works (new tests pass)
-```
-
-**D. For DATABASE TASKS:**
-
-```
-1. Create migration file:
- npx supabase migration new {description}
-
-2. Write migration SQL:
- - Create/alter tables
- - Add RLS policies
- - Add indexes
-
-3. Apply migration:
- npx supabase db push
-
-4. Verify schema:
- mcp__supabase__list_tables
- Confirm changes applied
-
-5. Generate types:
- npx supabase gen types typescript --local
-```
-
-**E. For TEST TASKS:**
-
-```
-1. Identify what to test
-2. Find or create test file
-3. Write test with clear assertions
-4. Run test:
- npm test -- --run --grep "{test_name}"
-
-5. Verify test is meaningful (not placeholder)
-```
-
-**F. Check Task Complete:**
-
-After implementing task, verify:
-- [ ] Code exists where expected
-- [ ] Tests pass
-- [ ] No TypeScript errors
-- [ ] Follows project patterns
-
-**Mark task complete in story file:**
-```markdown
-- [x] {task_description}
-```
-
-**Update state file with progress.**
-
-### 3. Handle Errors Gracefully
-
-**If implementation fails:**
-
-```
-⚠️ Task failed: {task_description}
-
-Error: {error_message}
-
-Options:
-1. Debug and retry
-2. Skip and document blocker
-3. Simplify approach
-
-DO NOT vibe code or guess!
-Follow error systematically.
-```
-
-### 4. Run Full Test Suite
-
-After ALL tasks completed:
-
-```bash
-npm test -- --run
-npm run lint
-npm run build
-```
-
-**All must pass before proceeding.**
-
-### 5. Verify Task Completion
-
-Re-read story file and count:
-- Tasks completed this session: {count}
-- Tasks remaining: {should be 0}
-- All checked: {should be true}
-
-### 6. Update Pipeline State
-
-Update state file:
-- Add `3` to `stepsCompleted`
-- Set `lastStep: 3`
-- Set `steps.step-03-implement.status: completed`
-- Record:
- ```yaml
- implementation:
- files_created: {count}
- files_modified: {count}
- migrations_applied: {count}
- tests_added: {count}
- tasks_completed: {count}
- ```
-
-### 7. Display Summary
-
-```
-Implementation Complete
-
-Tasks Completed: {completed_count}
-
-Files:
-- Created: {created_files}
-- Modified: {modified_files}
-
-Migrations:
-- {migration_1}
-- {migration_2}
-
-Tests:
-- All passing: {pass_count}/{total_count}
-- New tests added: {new_test_count}
-
-Build Status:
-- Lint: ✓ Clean
-- TypeScript: ✓ No errors
-- Build: ✓ Success
-
-Ready for Post-Validation
-```
-
-**Interactive Mode Menu:**
-```
-[C] Continue to Post-Validation
-[T] Run tests again
-[B] Run build again
-[H] Halt pipeline
-```
-
-**Batch Mode:** Auto-continue
-
-## QUALITY GATE
-
-Before proceeding:
-- [ ] All unchecked tasks completed
-- [ ] All tests pass
-- [ ] Lint clean
-- [ ] Build succeeds
-- [ ] No TypeScript errors
-- [ ] Followed project patterns
-- [ ] **No vibe coding occurred**
-
-## CRITICAL STEP COMPLETION
-
-**ONLY WHEN** [all tasks complete AND all tests pass AND lint clean AND build succeeds],
-load and execute `{nextStepFile}` for post-validation.
-
----
-
-## SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS
-- All tasks implemented one at a time
-- Tests pass for each task
-- Brownfield code modified carefully
-- No regressions introduced
-- Project patterns followed
-- Build and lint clean
-- **Disciplined execution maintained**
-
-### ❌ FAILURE
-- Vibe coding (guessing implementation)
-- Batching multiple tasks
-- Not running tests per task
-- Breaking existing functionality
-- Inventing new patterns
-- Skipping verification
-- **Deviating from step sequence**
-
-## ANTI-VIBE-CODING ENFORCEMENT
-
-This step enforces discipline by:
-
-1. **One task at a time** - Can't batch or optimize
-2. **Test after each task** - Immediate verification
-3. **Follow existing patterns** - No invention
-4. **Brownfield awareness** - Read existing code first
-5. **Frequent verification** - Run tests, lint, build
-
-**Even at 200K tokens, you MUST:**
-- ✅ Implement ONE task
-- ✅ Run tests
-- ✅ Verify it works
-- ✅ Mark task complete
-- ✅ Move to next task
-
-**NO shortcuts. NO optimization. NO vibe coding.**
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-05-post-validation.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-05-post-validation.md
deleted file mode 100644
index fd63b543..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-05-post-validation.md
+++ /dev/null
@@ -1,450 +0,0 @@
----
-name: 'step-04-post-validation'
-description: 'Verify completed tasks against codebase reality (catch false positives)'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-04-post-validation.md'
-nextStepFile: '{workflow_path}/steps/step-05-code-review.md'
-prevStepFile: '{workflow_path}/steps/step-03-implement.md'
-
-# Role Switch
-role: dev
-requires_fresh_context: false # Continue from implementation context
----
-
-# Step 5b: Post-Implementation Validation
-
-## ROLE CONTINUATION - VERIFICATION MODE
-
-**Continuing as DEV but switching to VERIFICATION mindset.**
-
-You are now verifying that completed work actually exists in the codebase.
-This catches the common problem of tasks marked [x] but implementation is incomplete.
-
-## STEP GOAL
-
-Verify all completed tasks against codebase reality:
-1. Re-read story file and extract completed tasks
-2. For each completed task, identify what should exist
-3. Use codebase search tools to verify existence
-4. Run tests to verify they actually pass
-5. Identify false positives (marked done but not actually done)
-6. If gaps found, uncheck tasks and add missing work
-7. Re-run implementation if needed
-
-## MANDATORY EXECUTION RULES
-
-### Verification Principles
-
-- **TRUST NOTHING** - Verify every completed task
-- **CHECK EXISTENCE** - Files, functions, components must exist
-- **CHECK COMPLETENESS** - Not just existence, but full implementation
-- **TEST VERIFICATION** - Claimed test coverage must be real
-- **NO ASSUMPTIONS** - Re-scan the codebase with fresh eyes
-
-### What to Verify
-
-For each task marked [x]:
-- Files mentioned exist at correct paths
-- Functions/components declared and exported
-- Tests exist and actually pass
-- Database migrations applied
-- API endpoints respond correctly
-
-## EXECUTION SEQUENCE
-
-### 1. Load Story and Extract Completed Tasks
-
-Load story file: `{story_file}`
-
-Extract all tasks from story that are marked [x]:
-```regex
-- \[x\] (.+)
-```
-
-Build list of `completed_tasks` to verify.
-
-### 2. Categorize Tasks by Type
-
-For each completed task, determine what needs verification:
-
-**File Creation Tasks:**
-- Pattern: "Create {file_path}"
-- Verify: File exists at path
-
-**Component/Function Tasks:**
-- Pattern: "Add {name} function/component"
-- Verify: Symbol exists and is exported
-
-**Test Tasks:**
-- Pattern: "Add test for {feature}"
-- Verify: Test file exists and test passes
-
-**Database Tasks:**
-- Pattern: "Add {table} table", "Create migration"
-- Verify: Migration file exists, schema matches
-
-**API Tasks:**
-- Pattern: "Create {endpoint} endpoint"
-- Verify: Route file exists, handler implemented
-
-**UI Tasks:**
-- Pattern: "Add {element} to UI"
-- Verify: Component has data-testid attribute
-
-### 3. Verify File Existence
-
-For all file-related tasks:
-
-```bash
-# Use Glob to find files
-glob: "**/{mentioned_filename}"
-```
-
-**Check:**
-- [ ] File exists
-- [ ] File is not empty
-- [ ] File has expected exports
-
-**False Positive Indicators:**
-- File doesn't exist
-- File exists but is empty
-- File exists but missing expected symbols
-
-### 4. Verify Function/Component Implementation
-
-For code implementation tasks:
-
-```bash
-# Use Grep to find symbols
-grep: "{function_name|component_name}"
- glob: "**/*.{ts,tsx}"
- output_mode: "content"
-```
-
-**Check:**
-- [ ] Symbol is declared
-- [ ] Symbol is exported
-- [ ] Implementation is not a stub/placeholder
-- [ ] Required logic is present
-
-**False Positive Indicators:**
-- Symbol not found
-- Symbol exists but marked TODO
-- Symbol exists but throws "Not implemented"
-- Symbol exists but returns empty/null
-
-### 5. Verify Test Coverage
-
-For all test-related tasks:
-
-```bash
-# Find test files
-glob: "**/*.test.{ts,tsx}"
-glob: "**/*.spec.{ts,tsx}"
-
-# Run specific tests
-npm test -- --run --grep "{feature_name}"
-```
-
-**Check:**
-- [ ] Test file exists
-- [ ] Test describes the feature
-- [ ] Test actually runs (not skipped)
-- [ ] Test passes (GREEN)
-
-**False Positive Indicators:**
-- No test file found
-- Test exists but skipped (it.skip)
-- Test exists but fails
-- Test exists but doesn't test the feature (placeholder)
-
-### 6. Verify Database Changes
-
-For database migration tasks:
-
-```bash
-# Find migration files
-glob: "**/migrations/*.sql"
-
-# Check Supabase schema
-mcp__supabase__list_tables
-```
-
-**Check:**
-- [ ] Migration file exists
-- [ ] Migration has been applied
-- [ ] Table/column exists in schema
-- [ ] RLS policies are present
-
-**False Positive Indicators:**
-- Migration file missing
-- Migration not applied to database
-- Table/column doesn't exist
-- RLS policies missing
-
-### 7. Verify API Endpoints
-
-For API endpoint tasks:
-
-```bash
-# Find route files
-glob: "**/app/api/**/{endpoint}/route.ts"
-grep: "export async function {METHOD}"
-```
-
-**Check:**
-- [ ] Route file exists
-- [ ] Handler function implemented
-- [ ] Returns proper Response type
-- [ ] Error handling present
-
-**False Positive Indicators:**
-- Route file doesn't exist
-- Handler throws "Not implemented"
-- Handler returns stub response
-
-### 8. Run Full Verification
-
-Execute verification for ALL completed tasks:
-
-```typescript
-interface VerificationResult {
- task: string;
- status: "verified" | "false_positive";
- evidence: string;
- missing?: string;
-}
-
-const results: VerificationResult[] = [];
-
-for (const task of completed_tasks) {
- const result = await verifyTask(task);
- results.push(result);
-}
-```
-
-### 9. Analyze Verification Results
-
-Count results:
-```
-Total Verified: {verified_count}
-False Positives: {false_positive_count}
-```
-
-### 10. Handle False Positives
-
-**IF false positives found (count > 0):**
-
-Display:
-```
-⚠️ POST-IMPLEMENTATION GAPS DETECTED
-
-Tasks marked complete but implementation incomplete:
-
-{for each false_positive}
-- [ ] {task_description}
- Missing: {what_is_missing}
- Evidence: {grep/glob results}
-
-{add new tasks for missing work}
-- [ ] Actually implement {missing_part}
-```
-
-**Actions:**
-1. Uncheck false positive tasks in story file
-2. Add new tasks for the missing work
-3. Update "Gap Analysis" section in story
-4. Set state to re-run implementation
-
-**Re-run implementation:**
-```
-Detected {false_positive_count} incomplete tasks.
-Re-running Step 5: Implementation to complete missing work...
-
-{load and execute step-05-implement.md}
-```
-
-After re-implementation, **RE-RUN THIS STEP** (step-05b-post-validation.md)
-
-### 11. Handle Verified Success
-
-**IF no false positives (all verified):**
-
-Display:
-```
-✅ POST-IMPLEMENTATION VALIDATION PASSED
-
-All {verified_count} completed tasks verified against codebase:
-- Files exist and are complete
-- Functions/components implemented
-- Tests exist and pass
-- Database changes applied
-- API endpoints functional
-
-Ready for Code Review
-```
-
-Update story file "Gap Analysis" section:
-```markdown
-## Gap Analysis
-
-### Post-Implementation Validation
-- **Date:** {timestamp}
-- **Tasks Verified:** {verified_count}
-- **False Positives:** 0
-- **Status:** ✅ All work verified complete
-
-**Verification Evidence:**
-{for each verified task}
-- ✅ {task}: {evidence}
-```
-
-### 12. Update Pipeline State
-
-Update state file:
-- Add `5b` to `stepsCompleted`
-- Set `lastStep: 5b`
-- Set `steps.step-05b-post-validation.status: completed`
-- Record verification results:
- ```yaml
- verification:
- tasks_verified: {count}
- false_positives: {count}
- re_implementation_required: {true|false}
- ```
-
-### 13. Present Summary and Menu
-
-Display:
-```
-Post-Implementation Validation Complete
-
-Verification Summary:
-- Tasks Checked: {total_count}
-- Verified Complete: {verified_count}
-- False Positives: {false_positive_count}
-- Re-implementations: {retry_count}
-
-{if false_positives}
-Re-running implementation to complete missing work...
-{else}
-All work verified. Proceeding to Code Review...
-{endif}
-```
-
-**Interactive Mode Menu (only if no false positives):**
-```
-[C] Continue to {next step based on complexity: Code Review | Complete}
-[V] Run verification again
-[T] Run tests again
-[H] Halt pipeline
-```
-
-{if micro complexity: "⏭️ Code Review will be skipped (lightweight path)"}
-
-**Batch Mode:**
-- Auto re-run implementation if false positives
-- Auto-continue if all verified
-
-## QUALITY GATE
-
-Before proceeding to code review:
-- [ ] All completed tasks verified against codebase
-- [ ] Zero false positives remaining
-- [ ] All tests still passing
-- [ ] Build still succeeds
-- [ ] Gap analysis updated with verification results
-
-## VERIFICATION TOOLS
-
-Use these tools for verification:
-
-```typescript
-// File existence
-glob("{pattern}")
-
-// Symbol search
-grep("{symbol_name}", { glob: "**/*.{ts,tsx}", output_mode: "content" })
-
-// Test execution
-bash("npm test -- --run --grep '{test_name}'")
-
-// Database check
-mcp__supabase__list_tables()
-
-// Read file contents
-read("{file_path}")
-```
-
-## CRITICAL STEP COMPLETION
-
-**IF** [false positives detected],
-load and execute `{prevStepFile}` to complete missing work,
-then RE-RUN this step.
-
-**ONLY WHEN** [all tasks verified AND zero false positives]:
-
-**Determine next step based on complexity routing:**
-
-```
-If 5 in skip_steps (micro complexity):
- nextStepFile = '{workflow_path}/steps/step-06-complete.md'
- Display: "⏭️ Skipping Code Review (micro complexity) → Proceeding to Complete"
-Else:
- nextStepFile = '{workflow_path}/steps/step-05-code-review.md'
-```
-
-Load and execute `{nextStepFile}`.
-
----
-
-## SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS
-- All completed tasks verified against codebase
-- No false positives (or all re-implemented)
-- Tests still passing
-- Evidence documented for each task
-- Gap analysis updated
-
-### ❌ FAILURE
-- Skipping verification ("trust the marks")
-- Not checking actual code existence
-- Not running tests to verify claims
-- Allowing false positives to proceed
-- Not documenting verification evidence
-
-## COMMON FALSE POSITIVE PATTERNS
-
-Watch for these common issues:
-
-1. **Stub Implementations**
- - Function exists but returns `null`
- - Function throws "Not implemented"
- - Component returns empty div
-
-2. **Placeholder Tests**
- - Test exists but skipped (it.skip)
- - Test doesn't actually test the feature
- - Test always passes (no assertions)
-
-3. **Incomplete Files**
- - File created but empty
- - Missing required exports
- - TODO comments everywhere
-
-4. **Database Drift**
- - Migration file exists but not applied
- - Schema doesn't match migration
- - RLS policies missing
-
-5. **API Stubs**
- - Route exists but returns 501
- - Handler not implemented
- - No error handling
-
-This step is the **safety net** that catches incomplete work before code review.
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-06-run-quality-checks.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-06-run-quality-checks.md
deleted file mode 100644
index 6fb23699..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-06-run-quality-checks.md
+++ /dev/null
@@ -1,368 +0,0 @@
----
-name: 'step-06-run-quality-checks'
-description: 'Run tests, type checks, and linter - fix all problems before code review'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-06-run-quality-checks.md'
-stateFile: '{state_file}'
-storyFile: '{story_file}'
-
-# Next step
-nextStep: '{workflow_path}/steps/step-07-code-review.md'
----
-
-# Step 6: Run Quality Checks
-
-**Goal:** Verify implementation quality through automated checks: tests, type checking, and linting. Fix ALL problems before proceeding to human/AI code review.
-
-## Why Automate First?
-
-1. **Fast feedback**: Automated checks run in seconds
-2. **Catch obvious issues**: Type errors, lint violations, failing tests
-3. **Save review time**: Don't waste code review time on mechanical issues
-4. **Enforce standards**: Consistent code style and quality
-
-## Principles
-
-- **Zero tolerance**: ALL checks must pass
-- **Fix, don't skip**: If a check fails, fix it - don't disable the check
-- **Iterate quickly**: Run-fix-run loop until all green
-- **Document workarounds**: If you must suppress a check, document why
-
----
-
-## Process
-
-### 1. Run Test Suite
-
-```bash
-echo "📋 Running test suite..."
-
-# Run all tests
-npm test
-
-# Or for other stacks:
-# pytest
-# dotnet test
-# mvn test
-# cargo test
-```
-
-**Expected output:**
-```
-✅ PASS __tests__/components/UserDashboard.test.tsx
- UserDashboard
- AC1: Display user profile information
- ✓ should render user name (12ms)
- ✓ should render user email (8ms)
- ✓ should render user avatar (6ms)
- AC2: Allow user to edit profile
- ✓ should show edit button when not in edit mode (10ms)
- ✓ should enable edit mode when edit button clicked (15ms)
- ✓ should save changes when save button clicked (22ms)
-
-Test Suites: 1 passed, 1 total
-Tests: 6 passed, 6 total
-Time: 2.134s
-```
-
-**If tests fail:**
-```
-❌ Test failures detected!
-
-Failed tests:
- - UserDashboard › AC2 › should save changes when save button clicked
- Expected: { name: 'Jane Doe', email: 'john@example.com' }
- Received: undefined
-
-Action required:
-1. Analyze the failure
-2. Fix the implementation
-3. Re-run tests
-4. Repeat until all tests pass
-
-DO NOT PROCEED until all tests pass.
-```
-
-### 2. Check Test Coverage
-
-```bash
-echo "📊 Checking test coverage..."
-
-# Generate coverage report
-npm run test:coverage
-
-# Or for other stacks:
-# pytest --cov
-# dotnet test /p:CollectCoverage=true
-# cargo tarpaulin
-```
-
-**Minimum coverage thresholds:**
-```yaml
-Line Coverage: ≥80%
-Branch Coverage: ≥75%
-Function Coverage: ≥80%
-Statement Coverage: ≥80%
-```
-
-**If coverage is low:**
-```
-⚠️ Test coverage below threshold!
-
-Current coverage:
- Lines: 72% (threshold: 80%)
- Branches: 68% (threshold: 75%)
- Functions: 85% (threshold: 80%)
-
-Uncovered areas:
- - src/components/UserDashboard.tsx: lines 45-52 (error handling)
- - src/services/userService.ts: lines 23-28 (edge case)
-
-Action required:
-1. Add tests for uncovered code paths
-2. Re-run coverage check
-3. Achieve ≥80% coverage before proceeding
-```
-
-### 3. Run Type Checker
-
-```bash
-echo "🔍 Running type checker..."
-
-# For TypeScript
-npx tsc --noEmit
-
-# For Python
-# mypy src/
-
-# For C#
-# dotnet build
-
-# For Java
-# mvn compile
-```
-
-**Expected output:**
-```
-✅ No type errors found
-```
-
-**If type errors found:**
-```
-❌ Type errors detected!
-
-src/components/UserDashboard.tsx:45:12 - error TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
-
-45 onSave(user.name);
- ~~~~~~~~~
-
-src/services/userService.ts:23:18 - error TS2339: Property 'id' does not exist on type 'User'.
-
-23 return user.id;
- ~~
-
-Found 2 errors in 2 files.
-
-Action required:
-1. Fix type errors
-2. Re-run type checker
-3. Repeat until zero errors
-
-DO NOT PROCEED with type errors.
-```
-
-### 4. Run Linter
-
-```bash
-echo "✨ Running linter..."
-
-# For JavaScript/TypeScript
-npm run lint
-
-# For Python
-# pylint src/
-
-# For C#
-# dotnet format --verify-no-changes
-
-# For Java
-# mvn checkstyle:check
-```
-
-**Expected output:**
-```
-✅ No linting errors found
-```
-
-**If lint errors found:**
-```
-❌ Lint errors detected!
-
-src/components/UserDashboard.tsx
- 45:1 error 'useState' is not defined no-undef
- 52:12 error Unexpected console statement no-console
- 67:5 warning Unexpected var, use let or const instead no-var
-
-src/services/userService.ts
- 23:1 error Missing return type on function @typescript-eslint/explicit-function-return-type
-
-✖ 4 problems (3 errors, 1 warning)
-
-Action required:
-1. Run auto-fix if available: npm run lint:fix
-2. Manually fix remaining errors
-3. Re-run linter
-4. Repeat until zero errors and zero warnings
-
-DO NOT PROCEED with lint errors.
-```
-
-### 5. Auto-Fix What's Possible
-
-```bash
-echo "🔧 Attempting auto-fixes..."
-
-# Run formatters and auto-fixable linters
-npm run lint:fix
-npm run format
-
-# Stage the auto-fixes
-git add .
-```
-
-### 6. Manual Fixes
-
-For issues that can't be auto-fixed:
-
-```typescript
-// Example: Fix type error
-// Before:
-const userName = user.name; // Type error if name is optional
-onSave(userName);
-
-// After:
-const userName = user.name ?? ''; // Handle undefined case
-onSave(userName);
-```
-
-```typescript
-// Example: Fix lint error
-// Before:
-var count = 0; // ESLint: no-var
-
-// After:
-let count = 0; // Use let instead of var
-```
-
-### 7. Verify All Checks Pass
-
-Run everything again to confirm:
-
-```bash
-echo "✅ Final verification..."
-
-# Run all checks
-npm test && \
- npx tsc --noEmit && \
- npm run lint
-
-echo "✅ ALL QUALITY CHECKS PASSED!"
-```
-
-### 8. Commit Quality Fixes
-
-```bash
-# Only if fixes were needed
-if git diff --cached --quiet; then
- echo "No fixes needed - all checks passed first time!"
-else
- git commit -m "fix(story-{story_id}): address quality check issues
-
-- Fix type errors
-- Resolve lint violations
-- Improve test coverage to {coverage}%
-
-All automated checks now passing:
-✅ Tests: {test_count} passed
-✅ Type check: No errors
-✅ Linter: No violations
-✅ Coverage: {coverage}%"
-fi
-```
-
-### 9. Update State
-
-```yaml
-# Update {stateFile}
-current_step: 6
-quality_checks:
- tests_passed: true
- test_count: {test_count}
- coverage: {coverage}%
- type_check_passed: true
- lint_passed: true
- all_checks_passed: true
-ready_for_code_review: true
-```
-
----
-
-## Quality Gate
-
-**CRITICAL:** This is a **BLOCKING STEP**. You **MUST NOT** proceed to code review until ALL of the following pass:
-
-✅ **All tests passing** (0 failures)
-✅ **Test coverage ≥80%** (or project threshold)
-✅ **Zero type errors**
-✅ **Zero lint errors**
-✅ **Zero lint warnings** (or all warnings justified and documented)
-
-If ANY check fails:
-1. Fix the issue
-2. Re-run all checks
-3. Repeat until ALL PASS
-4. THEN proceed to next step
-
----
-
-## Troubleshooting
-
-**Tests fail sporadically:**
-- Check for test interdependencies
-- Look for timing issues (use `waitFor` in async tests)
-- Check for environment-specific issues
-
-**Type errors in third-party libraries:**
-- Install `@types` packages
-- Use type assertions carefully (document why)
-- Consider updating library versions
-
-**Lint rules conflict with team standards:**
-- Discuss with team before changing config
-- Document exceptions in comments
-- Update lint config if truly inappropriate
-
-**Coverage can't reach 80%:**
-- Focus on critical paths first
-- Test error cases and edge cases
-- Consider if untested code is actually needed
-
----
-
-## Skip Conditions
-
-This step CANNOT be skipped. All stories must pass quality checks.
-
-The only exception: Documentation-only stories with zero code changes.
-
----
-
-## Next Step
-
-Proceed to **Step 7: Code Review** ({nextStep})
-
-Now that all automated checks pass, the code is ready for human/AI review.
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-07-code-review.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-07-code-review.md
deleted file mode 100644
index 97e41975..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-07-code-review.md
+++ /dev/null
@@ -1,337 +0,0 @@
----
-name: 'step-07-code-review'
-description: 'Multi-agent code review with fresh context and variable agent count'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-multi_agent_review_workflow: '{project-root}/_bmad/bmm/workflows/4-implementation/multi-agent-review'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-07-code-review.md'
-nextStepFile: '{workflow_path}/steps/step-08-review-analysis.md'
-stateFile: '{state_file}'
-reviewReport: '{sprint_artifacts}/review-{story_id}.md'
-
-# Role (continue as dev, but reviewer mindset)
-role: dev
-requires_fresh_context: true # CRITICAL: Review MUST happen in fresh context
----
-
-# Step 7: Code Review (Multi-Agent with Fresh Context)
-
-## ROLE CONTINUATION - ADVERSARIAL MODE
-
-**Continuing as DEV but switching to ADVERSARIAL REVIEWER mindset.**
-
-You are now a critical code reviewer. Your job is to FIND PROBLEMS.
-- **NEVER** say "looks good" - that's a failure
-- **MUST** find 3-10 specific issues
-- **FIX** every issue you find
-
-## STEP GOAL
-
-Perform adversarial code review:
-1. Query Supabase advisors for security/performance issues
-2. Identify all files changed for this story
-3. Review each file against checklist
-4. Find and document 3-10 issues (MANDATORY)
-5. Fix all issues
-6. Verify tests still pass
-
-### Multi-Agent Review with Fresh Context (NEW v1.5.0)
-
-**All reviews now use multi-agent approach with variable agent counts based on risk.**
-
-**CRITICAL: Review in FRESH CONTEXT (unbiased perspective)**
-
-```
-⚠️ CHECKPOINT: Starting fresh review session
-
-Multi-agent review will run in NEW context to avoid bias from implementation.
-
-Agent count based on complexity level:
-- MICRO: 2 agents (Security + Code Quality)
-- STANDARD: 4 agents (+ Architecture + Testing)
-- COMPLEX: 6 agents (+ Performance + Domain Expert)
-
-Smart agent selection analyzes changed files to select most relevant reviewers.
-```
-
-**Invoke multi-agent-review workflow:**
-
-```xml
-
- {story_id}
- {complexity_level}
- true
-
-```
-
-**The multi-agent-review workflow will:**
-1. Create fresh context (new session, unbiased)
-2. Analyze changed files
-3. Select appropriate agents based on code changes
-4. Run parallel reviews from multiple perspectives
-5. Aggregate findings with severity ratings
-6. Return comprehensive review report
-
-**After review completes:**
-- Review report saved to: `{sprint_artifacts}/review-{story_id}.md`
-- Proceed to step 8 (Review Analysis) to categorize findings
-
-## MANDATORY EXECUTION RULES
-
-### Adversarial Requirements
-
-- **MINIMUM 3 ISSUES** - If you found fewer, look harder
-- **MAXIMUM 10 ISSUES** - Prioritize if more found
-- **NO "LOOKS GOOD"** - This is FORBIDDEN
-- **FIX EVERYTHING** - Don't just report, fix
-
-### Review Categories (find issues in EACH)
-
-1. Security
-2. Performance
-3. Error Handling
-4. Test Coverage
-5. Code Quality
-6. Architecture
-
-## EXECUTION SEQUENCE
-
-### 1. Query Supabase Advisors
-
-Use MCP tools:
-
-```
-mcp__supabase__get_advisors:
- type: "security"
-
-mcp__supabase__get_advisors:
- type: "performance"
-```
-
-Document any issues found.
-
-### 2. Identify Changed Files
-
-```bash
-git status
-git diff --name-only HEAD~1
-```
-
-List all files changed for story {story_id}.
-
-### 3. Review Each Category
-
-#### SECURITY REVIEW
-
-For each file, check:
-- [ ] No SQL injection vulnerabilities
-- [ ] No XSS vulnerabilities
-- [ ] Auth checks on all protected routes
-- [ ] RLS policies exist and are correct
-- [ ] No credential exposure (API keys, secrets)
-- [ ] Input validation present
-- [ ] Rate limiting considered
-
-#### PERFORMANCE REVIEW
-
-- [ ] No N+1 query patterns
-- [ ] Indexes exist for query patterns
-- [ ] No unnecessary re-renders
-- [ ] Proper caching strategy
-- [ ] Efficient data fetching
-- [ ] Bundle size impact considered
-
-#### ERROR HANDLING REVIEW
-
-- [ ] Result type used consistently
-- [ ] Error messages are user-friendly
-- [ ] Edge cases handled
-- [ ] Null/undefined checked
-- [ ] Network errors handled gracefully
-
-#### TEST COVERAGE REVIEW
-
-- [ ] All AC have tests
-- [ ] Edge cases tested
-- [ ] Error paths tested
-- [ ] Mocking is appropriate (not excessive)
-- [ ] Tests are deterministic
-
-#### CODE QUALITY REVIEW
-
-- [ ] DRY - no duplicate code
-- [ ] SOLID principles followed
-- [ ] TypeScript strict mode compliant
-- [ ] No any types
-- [ ] Functions are focused (single responsibility)
-- [ ] Naming is clear and consistent
-
-#### ARCHITECTURE REVIEW
-
-- [ ] Module boundaries respected
-- [ ] Imports from index.ts only
-- [ ] Server/client separation correct
-- [ ] Data flow is clear
-- [ ] No circular dependencies
-
-### 4. Document All Issues
-
-For each issue found:
-
-```yaml
-issue_{n}:
- severity: critical|high|medium|low
- category: security|performance|error-handling|testing|quality|architecture
- file: "{file_path}"
- line: {line_number}
- problem: |
- {Clear description of the issue}
- risk: |
- {What could go wrong if not fixed}
- fix: |
- {How to fix it}
-```
-
-### 5. Fix All Issues
-
-For EACH issue documented:
-
-1. Edit the file to fix the issue
-2. Add test if issue wasn't covered
-3. Verify the fix is correct
-4. Mark as fixed
-
-### 6. Run Verification
-
-After all fixes:
-
-```bash
-npm run lint
-npm run build
-npm test -- --run
-```
-
-All must pass.
-
-### 7. Create Review Report
-
-Append to story file or create `{sprint_artifacts}/review-{story_id}.md`:
-
-```markdown
-# Code Review Report - Story {story_id}
-
-## Summary
-- Issues Found: {count}
-- Issues Fixed: {count}
-- Categories Reviewed: {list}
-
-## Issues Detail
-
-### Issue 1: {title}
-- **Severity:** {severity}
-- **Category:** {category}
-- **File:** {file}:{line}
-- **Problem:** {description}
-- **Fix Applied:** {fix_description}
-
-### Issue 2: {title}
-...
-
-## Security Checklist
-- [x] RLS policies verified
-- [x] No credential exposure
-- [x] Input validation present
-
-## Performance Checklist
-- [x] No N+1 queries
-- [x] Indexes verified
-
-## Final Status
-All issues resolved. Tests passing.
-
-Reviewed by: DEV (adversarial)
-Reviewed at: {timestamp}
-```
-
-### 8. Update Pipeline State
-
-Update state file:
-- Add `6` to `stepsCompleted`
-- Set `lastStep: 6`
-- Set `steps.step-06-code-review.status: completed`
-- Record `issues_found` and `issues_fixed`
-
-### 9. Present Summary and Menu
-
-Display:
-```
-Code Review Complete
-
-Issues Found: {count} (minimum 3 required)
-Issues Fixed: {count}
-
-By Category:
-- Security: {count}
-- Performance: {count}
-- Error Handling: {count}
-- Test Coverage: {count}
-- Code Quality: {count}
-- Architecture: {count}
-
-All Tests: PASSING
-Lint: CLEAN
-Build: SUCCESS
-
-Review Report: {report_path}
-```
-
-**Interactive Mode Menu:**
-```
-[C] Continue to Completion
-[R] Run another review pass
-[T] Run tests again
-[H] Halt pipeline
-```
-
-**Batch Mode:** Auto-continue if minimum issues found and fixed
-
-## QUALITY GATE
-
-Before proceeding:
-- [ ] Minimum 3 issues found and fixed
-- [ ] All categories reviewed
-- [ ] All tests still passing
-- [ ] Lint clean
-- [ ] Build succeeds
-- [ ] Review report created
-
-## MCP TOOLS AVAILABLE
-
-- `mcp__supabase__get_advisors` - Security/performance checks
-- `mcp__supabase__execute_sql` - Query verification
-
-## CRITICAL STEP COMPLETION
-
-**ONLY WHEN** [minimum 3 issues found AND all fixed AND tests pass],
-load and execute `{nextStepFile}` for story completion.
-
----
-
-## SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS
-- Found and fixed 3-10 issues
-- All categories reviewed
-- Tests still passing after fixes
-- Review report complete
-- No "looks good" shortcuts
-
-### ❌ FAILURE
-- Saying "looks good" or "no issues found"
-- Finding fewer than 3 issues
-- Not fixing issues found
-- Tests failing after fixes
-- Skipping review categories
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-08-review-analysis.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-08-review-analysis.md
deleted file mode 100644
index 020c6597..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-08-review-analysis.md
+++ /dev/null
@@ -1,327 +0,0 @@
----
-name: 'step-08-review-analysis'
-description: 'Intelligently analyze code review findings - distinguish real issues from gold plating'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-08-review-analysis.md'
-stateFile: '{state_file}'
-storyFile: '{story_file}'
-reviewReport: '{sprint_artifacts}/review-{story_id}.md'
-
-# Next step
-nextStep: '{workflow_path}/steps/step-09-fix-issues.md'
----
-
-# Step 8: Review Analysis
-
-**Goal:** Critically analyze code review findings to distinguish **real problems** from **gold plating**, **false positives**, and **overzealous suggestions**.
-
-## The Problem
-
-AI code reviewers (and human reviewers) sometimes:
-- 🎨 **Gold plate**: Suggest unnecessary perfectionism
-- 🔍 **Overreact**: Flag non-issues to appear thorough
-- 📚 **Over-engineer**: Suggest abstractions for simple cases
-- ⚖️ **Misjudge context**: Apply rules without understanding tradeoffs
-
-## The Solution
-
-**Critical thinking filter**: Evaluate each finding objectively.
-
----
-
-## Process
-
-### 1. Load Review Report
-
-```bash
-# Read the code review report
-review_report="{reviewReport}"
-test -f "$review_report" || (echo "⚠️ No review report found" && exit 0)
-```
-
-Parse findings by severity:
-- 🔴 CRITICAL
-- 🟠 HIGH
-- 🟡 MEDIUM
-- 🔵 LOW
-- ℹ️ INFO
-
-### 2. Categorize Each Finding
-
-For EACH finding, ask these questions:
-
-#### Question 1: Is this a REAL problem?
-
-```
-Real Problem Indicators:
-✅ Would cause bugs or incorrect behavior
-✅ Would cause security vulnerabilities
-✅ Would cause performance issues in production
-✅ Would make future maintenance significantly harder
-✅ Violates team/project standards documented in codebase
-
-NOT Real Problems:
-❌ "Could be more elegant" (subjective style preference)
-❌ "Consider adding abstraction" (YAGNI - you aren't gonna need it)
-❌ "This pattern is not ideal" (works fine, alternative is marginal)
-❌ "Add comprehensive error handling" (for impossible error cases)
-❌ "Add logging everywhere" (log signal, not noise)
-```
-
-#### Question 2: Does this finding understand CONTEXT?
-
-```
-Context Considerations:
-📋 Story scope: Does fixing this exceed story requirements?
-🎯 Project maturity: Is this MVP, beta, or production-hardened?
-⚡ Performance criticality: Is this a hot path or cold path?
-👥 Team standards: Does team actually follow this pattern?
-📊 Data scale: Does this handle actual expected volume?
-
-Example of MISSING context:
-Finding: "Add database indexing for better performance"
-Reality: Table has 100 rows total, query runs once per day
-Verdict: ❌ REJECT - Premature optimization
-```
-
-#### Question 3: Is this ACTIONABLE?
-
-```
-Actionable Findings:
-✅ Specific file, line number, exact issue
-✅ Clear explanation of problem
-✅ Concrete recommendation for fix
-✅ Can be fixed in reasonable time
-
-NOT Actionable:
-❌ Vague: "Code quality could be improved"
-❌ No location: "Some error handling is missing"
-❌ No recommendation: "This might cause issues"
-❌ Massive scope: "Refactor entire architecture"
-```
-
-### 3. Classification Decision Tree
-
-For each finding, classify as:
-
-```
-┌─────────────────────────────────────────┐
-│ Finding Classification Decision Tree │
-└─────────────────────────────────────────┘
-
-Is it a CRITICAL security/correctness issue?
-├─ YES → 🔴 MUST FIX
-└─ NO ↓
-
-Does it violate documented project standards?
-├─ YES → 🟠 SHOULD FIX
-└─ NO ↓
-
-Would it prevent future maintenance?
-├─ YES → 🟡 CONSIDER FIX (if in scope)
-└─ NO ↓
-
-Is it gold plating / over-engineering?
-├─ YES → ⚪ REJECT (document why)
-└─ NO ↓
-
-Is it a style/opinion without real impact?
-├─ YES → ⚪ REJECT (document why)
-└─ NO → 🔵 OPTIONAL (tech debt backlog)
-```
-
-### 4. Create Classification Report
-
-```markdown
-# Code Review Analysis: Story {story_id}
-
-## Review Metadata
-- Reviewer: {reviewer_type} (Adversarial / Multi-Agent)
-- Total Findings: {total_findings}
-- Review Date: {date}
-
-## Classification Results
-
-### 🔴 MUST FIX (Critical - Blocking)
-Total: {must_fix_count}
-
-1. **[SECURITY] Unvalidated user input in API endpoint**
- - File: `src/api/users.ts:45`
- - Issue: POST /api/users accepts unvalidated input, SQL injection risk
- - Why this is real: Security vulnerability, could lead to data breach
- - Action: Add input validation with Zod schema
- - Estimated effort: 30 min
-
-2. **[CORRECTNESS] Race condition in state update**
- - File: `src/components/UserForm.tsx:67`
- - Issue: Multiple async setState calls without proper sequencing
- - Why this is real: Causes intermittent bugs in production
- - Action: Use functional setState or useReducer
- - Estimated effort: 20 min
-
-### 🟠 SHOULD FIX (High Priority)
-Total: {should_fix_count}
-
-3. **[STANDARDS] Missing error handling per team convention**
- - File: `src/services/userService.ts:34`
- - Issue: API calls lack try-catch per documented standards
- - Why this matters: Team standard in CONTRIBUTING.md section 3.2
- - Action: Wrap in try-catch, log errors
- - Estimated effort: 15 min
-
-### 🟡 CONSIDER FIX (Medium - If in scope)
-Total: {consider_count}
-
-4. **[MAINTAINABILITY] Complex nested conditional**
- - File: `src/utils/validation.ts:23`
- - Issue: 4-level nested if-else hard to read
- - Why this matters: Could confuse future maintainers
- - Action: Extract to guard clauses or lookup table
- - Estimated effort: 45 min
- - **Scope consideration**: Nice to have, but not blocking
-
-### ⚪ REJECTED (Gold Plating / False Positives)
-Total: {rejected_count}
-
-5. **[REJECTED] "Add comprehensive logging to all functions"**
- - Reason: Gold plating - logging should be signal, not noise
- - Context: These are simple utility functions, no debugging issues
- - Verdict: REJECT - Would create log spam
-
-6. **[REJECTED] "Extract component for reusability"**
- - Reason: YAGNI - component used only once, no reuse planned
- - Context: Story scope is single-use dashboard widget
- - Verdict: REJECT - Premature abstraction
-
-7. **[REJECTED] "Add database connection pooling"**
- - Reason: Premature optimization - current load is minimal
- - Context: App has 10 concurrent users max, no performance issues
- - Verdict: REJECT - Optimize when needed, not speculatively
-
-8. **[REJECTED] "Consider microservices architecture"**
- - Reason: Out of scope - architectural decision beyond story
- - Context: Story is adding a single API endpoint
- - Verdict: REJECT - Massive overreach
-
-### 🔵 OPTIONAL (Tech Debt Backlog)
-Total: {optional_count}
-
-9. **[STYLE] Inconsistent naming convention**
- - File: `src/utils/helpers.ts:12`
- - Issue: camelCase vs snake_case mixing
- - Why low priority: Works fine, linter doesn't flag it
- - Action: Standardize to camelCase when touching this file later
- - Create tech debt ticket: TD-{number}
-
-## Summary
-
-**Action Plan:**
-- 🔴 MUST FIX: {must_fix_count} issues (blocking)
-- 🟠 SHOULD FIX: {should_fix_count} issues (high priority)
-- 🟡 CONSIDER: {consider_count} issues (if time permits)
-- ⚪ REJECTED: {rejected_count} findings (documented why)
-- 🔵 OPTIONAL: {optional_count} items (tech debt backlog)
-
-**Estimated fix time:** {total_fix_time_hours} hours
-
-**Proceed to:** Step 9 - Fix Issues (implement MUST FIX + SHOULD FIX items)
-```
-
-### 5. Document Rejections
-
-**CRITICAL:** When rejecting findings, ALWAYS document WHY:
-
-```markdown
-## Rejected Findings - Rationale
-
-### Finding: "Add caching layer for all API calls"
-**Rejected because:**
-- ⚡ Premature optimization - no performance issues detected
-- 📊 Traffic analysis shows <100 requests/day
-- 🎯 Story scope is feature addition, not optimization
-- 💰 Cost: 2 days implementation, 0 proven benefit
-- 📝 Decision: Monitor first, optimize if needed
-
-### Finding: "Refactor to use dependency injection"
-**Rejected because:**
-- 🏗️ Over-engineering - current approach works fine
-- 📏 Codebase size doesn't justify DI complexity
-- 👥 Team unfamiliar with DI patterns
-- 🎯 Story scope: simple feature, not architecture overhaul
-- 📝 Decision: Keep it simple, revisit if codebase grows
-
-### Finding: "Add comprehensive JSDoc to all functions"
-**Rejected because:**
-- 📚 Gold plating - TypeScript types provide documentation
-- ⏱️ Time sink - 4+ hours for marginal benefit
-- 🎯 Team standard: JSDoc only for public APIs
-- 📝 Decision: Follow team convention, not reviewer preference
-```
-
-### 6. Update State
-
-```yaml
-# Update {stateFile}
-current_step: 8
-review_analysis:
- must_fix: {must_fix_count}
- should_fix: {should_fix_count}
- consider: {consider_count}
- rejected: {rejected_count}
- optional: {optional_count}
- estimated_fix_time: "{total_fix_time_hours}h"
- rejections_documented: true
- analysis_complete: true
-```
-
----
-
-## Critical Thinking Framework
-
-Use this framework to evaluate EVERY finding:
-
-### The "So What?" Test
-- **Ask:** "So what if we don't fix this?"
-- **If answer is:** "Nothing bad happens" → REJECT
-- **If answer is:** "Production breaks" → MUST FIX
-
-### The "YAGNI" Test (You Aren't Gonna Need It)
-- **Ask:** "Do we need this NOW for current requirements?"
-- **If answer is:** "Maybe someday" → REJECT
-- **If answer is:** "Yes, breaks without it" → FIX
-
-### The "Scope" Test
-- **Ask:** "Is this within the story's scope?"
-- **If answer is:** "No, requires new story" → REJECT (or create new story)
-- **If answer is:** "Yes, part of ACs" → FIX
-
-### The "Team Standard" Test
-- **Ask:** "Does our team actually do this?"
-- **If answer is:** "No, reviewer's opinion" → REJECT
-- **If answer is:** "Yes, in CONTRIBUTING.md" → FIX
-
----
-
-## Common Rejection Patterns
-
-Learn to recognize these patterns:
-
-1. **"Consider adding..."** - Usually gold plating unless critical
-2. **"It would be better if..."** - Subjective opinion, often rejectable
-3. **"For maximum performance..."** - Premature optimization
-4. **"To follow best practices..."** - Check if team actually follows it
-5. **"This could be refactored..."** - Does it need refactoring NOW?
-6. **"Add comprehensive..."** - Comprehensive = overkill most of the time
-7. **"Future-proof by..."** - Can't predict future, solve current problems
-
----
-
-## Next Step
-
-Proceed to **Step 9: Fix Issues** ({nextStep})
-
-Implement MUST FIX and SHOULD FIX items. Skip rejected items (already documented why).
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-09-fix-issues.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-09-fix-issues.md
deleted file mode 100644
index 50ce785f..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-09-fix-issues.md
+++ /dev/null
@@ -1,371 +0,0 @@
----
-name: 'step-09-fix-issues'
-description: 'Fix MUST FIX and SHOULD FIX issues from review analysis'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-09-fix-issues.md'
-stateFile: '{state_file}'
-storyFile: '{story_file}'
-reviewAnalysis: '{sprint_artifacts}/review-analysis-{story_id}.md'
-
-# Next step
-nextStep: '{workflow_path}/steps/step-10-complete.md'
----
-
-# Step 9: Fix Issues
-
-**Goal:** Implement fixes for MUST FIX and SHOULD FIX items identified in review analysis. Skip rejected items (gold plating already documented).
-
-## Principles
-
-- **Fix real problems only**: MUST FIX and SHOULD FIX categories
-- **Skip rejected items**: Already documented why in step 8
-- **Verify each fix**: Run tests after each fix
-- **Commit incrementally**: One fix per commit for traceability
-
----
-
-## Process
-
-### 1. Load Review Analysis
-
-```bash
-# Read review analysis from step 8
-review_analysis="{reviewAnalysis}"
-test -f "$review_analysis" || (echo "⚠️ No review analysis found - skipping fix step" && exit 0)
-```
-
-Parse the analysis report to extract:
-- MUST FIX items (count: {must_fix_count})
-- SHOULD FIX items (count: {should_fix_count})
-- Rejected items (for reference - DO NOT fix these)
-
-### 2. Fix MUST FIX Items (Critical - Blocking)
-
-**These are MANDATORY fixes - cannot proceed without fixing.**
-
-For each MUST FIX issue:
-
-```
-🔴 Issue #{number}: {title}
- File: {file}:{line}
- Severity: CRITICAL
- Category: {category} (SECURITY | CORRECTNESS | etc.)
-
- Problem:
- {description}
-
- Fix Required:
- {recommendation}
-
- Estimated Time: {estimate}
-```
-
-**Fix Process:**
-1. Read the file at the specified location
-2. Understand the issue context
-3. Implement the recommended fix
-4. Add test if issue was caught by testing gap
-5. Run tests to verify fix works
-6. Commit the fix
-
-```bash
-# Example fix commit
-git add {file}
-git commit -m "fix(story-{story_id}): {issue_title}
-
-{category}: {brief_description}
-
-- Issue: {problem_summary}
-- Fix: {fix_summary}
-- Testing: {test_verification}
-
-Addresses review finding #{number} (MUST FIX)
-Related to story {story_id}"
-```
-
-**Quality Check After Each Fix:**
-```bash
-# Verify fix doesn't break anything
-npm test
-
-# If tests fail:
-# 1. Fix the test or the code
-# 2. Re-run tests
-# 3. Only commit when tests pass
-```
-
-### 3. Fix SHOULD FIX Items (High Priority)
-
-**These are important for code quality and team standards.**
-
-For each SHOULD FIX issue:
-
-```
-🟠 Issue #{number}: {title}
- File: {file}:{line}
- Severity: HIGH
- Category: {category} (STANDARDS | MAINTAINABILITY | etc.)
-
- Problem:
- {description}
-
- Fix Required:
- {recommendation}
-
- Estimated Time: {estimate}
-```
-
-Same fix process as MUST FIX items, but with SHOULD FIX label in commit.
-
-### 4. Consider CONSIDER Items (If Time/Scope Permits)
-
-For CONSIDER items, evaluate:
-
-```
-🟡 Issue #{number}: {title}
- File: {file}:{line}
- Severity: MEDIUM
-
- Scope Check:
- - Is this within story scope? {yes/no}
- - Time remaining in story? {estimate}
- - Would this improve maintainability? {yes/no}
-
- Decision:
- [ ] FIX NOW - In scope and quick
- [ ] CREATE TECH DEBT TICKET - Out of scope
- [ ] SKIP - Not worth the effort
-```
-
-If fixing:
-- Same process as SHOULD FIX
-- Label as "refactor" or "improve" instead of "fix"
-
-If creating tech debt ticket:
-```markdown
-# Tech Debt: {title}
-
-**Source:** Code review finding from story {story_id}
-**Priority:** Medium
-**Estimated Effort:** {estimate}
-
-**Description:**
-{issue_description}
-
-**Recommendation:**
-{recommendation}
-
-**Why Deferred:**
-{reason} (e.g., out of scope, time constraints, etc.)
-```
-
-### 5. Skip REJECTED Items
-
-**DO NOT fix rejected items.**
-
-Display confirmation:
-```
-⚪ REJECTED ITEMS (Skipped):
- Total: {rejected_count}
-
- These findings were analyzed and rejected in step 8:
- - #{number}: {title} - {rejection_reason}
- - #{number}: {title} - {rejection_reason}
-
- ✅ Correctly skipped (documented as gold plating/false positives)
-```
-
-### 6. Skip OPTIONAL Items (Tech Debt Backlog)
-
-For OPTIONAL items:
-- Create tech debt tickets (if not already created)
-- Do NOT implement now
-- Add to project backlog
-
-### 7. Verify All Fixes Work Together
-
-After all fixes applied, run complete quality check:
-
-```bash
-echo "🔍 Verifying all fixes together..."
-
-# Run full test suite
-npm test
-
-# Run type checker
-npx tsc --noEmit
-
-# Run linter
-npm run lint
-
-# Check test coverage
-npm run test:coverage
-```
-
-**If any check fails:**
-```
-❌ Quality checks failed after fixes!
-
-This means fixes introduced new issues.
-
-Action required:
-1. Identify which fix broke which test
-2. Fix the issue
-3. Re-run quality checks
-4. Repeat until all checks pass
-
-DO NOT PROCEED until all quality checks pass.
-```
-
-### 8. Summary Report
-
-```markdown
-# Fix Summary: Story {story_id}
-
-## Issues Addressed
-
-### 🔴 MUST FIX: {must_fix_count} issues
-- [x] Issue #1: {title} - FIXED ✅
-- [x] Issue #2: {title} - FIXED ✅
-
-### 🟠 SHOULD FIX: {should_fix_count} issues
-- [x] Issue #3: {title} - FIXED ✅
-- [x] Issue #4: {title} - FIXED ✅
-
-### 🟡 CONSIDER: {consider_fixed_count}/{consider_count} issues
-- [x] Issue #5: {title} - FIXED ✅
-- [ ] Issue #6: {title} - Tech debt ticket created
-
-### ⚪ REJECTED: {rejected_count} items
-- Correctly skipped (documented in review analysis)
-
-### 🔵 OPTIONAL: {optional_count} items
-- Tech debt tickets created
-- Added to backlog
-
-## Commits Made
-
-Total commits: {commit_count}
-- MUST FIX commits: {must_fix_commits}
-- SHOULD FIX commits: {should_fix_commits}
-- Other commits: {other_commits}
-
-## Final Quality Check
-
-✅ All tests passing: {test_count} tests
-✅ Type check: No errors
-✅ Linter: No violations
-✅ Coverage: {coverage}%
-
-## Time Spent
-
-Estimated: {estimated_time}
-Actual: {actual_time}
-Efficiency: {efficiency_percentage}%
-```
-
-### 9. Update State
-
-```yaml
-# Update {stateFile}
-current_step: 9
-issues_fixed:
- must_fix: {must_fix_count}
- should_fix: {should_fix_count}
- consider: {consider_fixed_count}
- rejected: {rejected_count} (skipped - documented)
- optional: {optional_count} (tech debt created)
-fixes_verified: true
-all_quality_checks_passed: true
-ready_for_completion: true
-```
-
----
-
-## Quality Gates
-
-**BLOCKING:** Cannot proceed to step 10 until:
-
-✅ **All MUST FIX issues resolved**
-✅ **All SHOULD FIX issues resolved**
-✅ **All tests passing**
-✅ **Type check passing**
-✅ **Linter passing**
-✅ **Coverage maintained or improved**
-
-If any gate fails:
-1. Fix the issue
-2. Re-run quality checks
-3. Repeat until ALL PASS
-4. THEN proceed to next step
-
----
-
-## Skip Conditions
-
-This step can be skipped only if:
-- Review analysis (step 8) found zero issues requiring fixes
-- All findings were REJECTED or OPTIONAL
-
-Display when skipping:
-```
-✅ No fixes required!
-
-Review analysis found no critical or high-priority issues.
-All findings were either rejected as gold plating or marked as optional tech debt.
-
-Proceeding to completion...
-```
-
----
-
-## Error Handling
-
-**If a fix causes test failures:**
-```
-⚠️ Fix introduced regression!
-
-Test failures after applying fix for: {issue_title}
-
-Failed tests:
-- {test_name_1}
-- {test_name_2}
-
-Action:
-1. Review the fix - did it break existing functionality?
-2. Either fix the implementation or update the tests
-3. Re-run tests
-4. Only proceed when tests pass
-```
-
-**If stuck on a fix:**
-```
-⚠️ Fix is more complex than estimated
-
-Issue: {issue_title}
-Estimated: {estimate}
-Actual time spent: {actual} (exceeded estimate)
-
-Options:
-[C] Continue - Keep working on this fix
-[D] Defer - Create tech debt ticket and continue
-[H] Help - Request human intervention
-
-If deferring:
-- Document current progress
-- Create detailed tech debt ticket
-- Note blocking issues
-- Continue with other fixes
-```
-
----
-
-## Next Step
-
-Proceed to **Step 10: Complete + Update Status** ({nextStep})
-
-All issues fixed, all quality checks passed. Ready to mark story as done!
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10-complete.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10-complete.md
deleted file mode 100644
index 5a0de629..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10-complete.md
+++ /dev/null
@@ -1,332 +0,0 @@
----
-name: 'step-10-complete'
-description: 'Complete story with MANDATORY sprint-status.yaml update and verification'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-10-complete.md'
-nextStepFile: '{workflow_path}/steps/step-11-summary.md'
-stateFile: '{state_file}'
-sprint_status: '{sprint_artifacts}/sprint-status.yaml'
-
-# Role Switch
-role: sm
----
-
-# Step 10: Complete Story (v1.5.0: Mandatory Status Update)
-
-## ROLE SWITCH
-
-**Switching to SM (Scrum Master) perspective.**
-
-You are now completing the story and preparing changes for git commit.
-
-## STEP GOAL
-
-Complete the story with safety checks and MANDATORY status updates:
-1. Extract file list from story
-2. Stage only story-related files
-3. Generate commit message
-4. Create commit
-5. Push to remote (if configured)
-6. Update story file status to "done"
-7. **UPDATE sprint-status.yaml (MANDATORY - NO EXCEPTIONS)**
-8. **VERIFY sprint-status.yaml update persisted (CRITICAL)**
-
-## MANDATORY EXECUTION RULES
-
-### Completion Principles
-
-- **TARGETED COMMIT** - Only files from this story's File List
-- **SAFETY CHECKS** - Verify no secrets, proper commit message
-- **STATUS UPDATE** - Mark story as "review" (ready for human review)
-- **NO FORCE PUSH** - Normal push only
-
-## EXECUTION SEQUENCE
-
-### 1. Extract File List from Story
-
-Read story file and find "File List" section:
-
-```markdown
-## File List
-- src/components/UserProfile.tsx
-- src/actions/updateUser.ts
-- tests/user.test.ts
-```
-
-Extract all file paths.
-Add story file itself to the list.
-
-Store as `{story_files}` (space-separated list).
-
-### 2. Verify Files Exist
-
-For each file in list:
-```bash
-test -f "{file}" && echo "✓ {file}" || echo "⚠️ {file} not found"
-```
-
-### 3. Check Git Status
-
-```bash
-git status --short
-```
-
-Display files changed.
-
-### 4. Stage Story Files Only
-
-```bash
-git add {story_files}
-```
-
-**This ensures parallel-safe commits** (other agents won't conflict).
-
-### 5. Generate Commit Message
-
-Based on story title and changes:
-
-```
-feat(story-{story_id}): {story_title}
-
-Implemented:
-{list acceptance criteria or key changes}
-
-Files changed:
-- {file_1}
-- {file_2}
-
-Story: {story_file}
-```
-
-### 6. Create Commit (With Queue for Parallel Mode)
-
-**Check execution mode:**
-```
-If mode == "batch" AND parallel execution:
- use_commit_queue = true
-Else:
- use_commit_queue = false
-```
-
-**If use_commit_queue == true:**
-
-```bash
-# Commit queue with file-based locking
-lock_file=".git/bmad-commit.lock"
-max_wait=300 # 5 minutes
-wait_time=0
-retry_delay=1
-
-while [ $wait_time -lt $max_wait ]; do
- if [ ! -f "$lock_file" ]; then
- # Acquire lock
- echo "locked_by: {{story_key}}
-locked_at: $(date -u +%Y-%m-%dT%H:%M:%SZ)
-worker_id: {{worker_id}}
-pid: $$" > "$lock_file"
-
- echo "🔒 Commit lock acquired for {{story_key}}"
-
- # Execute commit
- git commit -m "$(cat <<'EOF'
-{commit_message}
-EOF
-)"
-
- commit_result=$?
-
- # Release lock
- rm -f "$lock_file"
- echo "🔓 Lock released"
-
- if [ $commit_result -eq 0 ]; then
- git log -1 --oneline
- break
- else
- echo "❌ Commit failed"
- exit $commit_result
- fi
- else
- # Lock exists, check if stale
- lock_age=$(( $(date +%s) - $(date -r "$lock_file" +%s) ))
- if [ $lock_age -gt 300 ]; then
- echo "⚠️ Stale lock detected (${lock_age}s old) - removing"
- rm -f "$lock_file"
- continue
- fi
-
- locked_by=$(grep "locked_by:" "$lock_file" | cut -d' ' -f2-)
- echo "⏳ Waiting for commit lock... (held by $locked_by, ${wait_time}s elapsed)"
- sleep $retry_delay
- wait_time=$(( wait_time + retry_delay ))
- retry_delay=$(( retry_delay < 30 ? retry_delay * 3 / 2 : 30 )) # Exponential backoff, max 30s
- fi
-done
-
-if [ $wait_time -ge $max_wait ]; then
- echo "❌ TIMEOUT: Could not acquire commit lock after 5 minutes"
- echo "Lock holder: $(cat $lock_file)"
- exit 1
-fi
-```
-
-**If use_commit_queue == false (sequential mode):**
-
-```bash
-# Direct commit (no queue needed)
-git commit -m "$(cat <<'EOF'
-{commit_message}
-EOF
-)"
-
-git log -1 --oneline
-```
-
-### 7. Push to Remote (Optional)
-
-**If configured to push:**
-```bash
-git push
-```
-
-**If push succeeds:**
-```
-✅ Changes pushed to remote
-```
-
-**If push fails (e.g., need to pull first):**
-```
-⚠️ Push failed - changes committed locally
-You can push manually when ready
-```
-
-### 8. Update Story Status (File + Sprint-Status)
-
-**CRITICAL: Two-location update with verification**
-
-#### 8.1: Update Story File
-
-Update story file frontmatter:
-```yaml
-status: done # Story completed (v1.5.0: changed from "review" to "done")
-completed_date: {date}
-```
-
-#### 8.2: Update sprint-status.yaml (MANDATORY - NO EXCEPTIONS)
-
-**This is CRITICAL and CANNOT be skipped.**
-
-```bash
-# Read current sprint-status.yaml
-sprint_status_file="{sprint_artifacts}/sprint-status.yaml"
-story_key="{story_id}"
-
-# Update development_status section
-# Change status from whatever it was to "done"
-
-development_status:
- {story_id}: done # ✅ COMPLETED: {story_title}
-```
-
-**Implementation:**
-```bash
-# Read current status
-current_status=$(grep "^\s*{story_id}:" "$sprint_status_file" | awk '{print $2}')
-
-# Update to done
-sed -i'' "s/^\s*{story_id}:.*/ {story_id}: done # ✅ COMPLETED: {story_title}/" "$sprint_status_file"
-
-echo "✅ Updated sprint-status.yaml: {story_id} → done"
-```
-
-#### 8.3: Verify Update Persisted (CRITICAL)
-
-```bash
-# Re-read sprint-status.yaml to verify change
-verification=$(grep "^\s*{story_id}:" "$sprint_status_file" | awk '{print $2}')
-
-if [ "$verification" != "done" ]; then
- echo "❌ CRITICAL: sprint-status.yaml update FAILED!"
- echo "Expected: done"
- echo "Got: $verification"
- echo ""
- echo "HALTING pipeline - status update is MANDATORY"
- exit 1
-fi
-
-echo "✅ Verified: sprint-status.yaml correctly updated"
-```
-
-**NO EXCEPTIONS:** If verification fails, pipeline MUST HALT.
-
-### 9. Update Pipeline State
-
-Update state file:
-- Add `6` to `stepsCompleted`
-- Set `lastStep: 6`
-- Set `steps.step-06-complete.status: completed`
-- Record commit hash
-
-### 10. Display Summary
-
-```
-Story Completion
-
-✅ Files staged: {file_count}
-✅ Commit created: {commit_hash}
-✅ Status updated: review
-{if pushed}✅ Pushed to remote{endif}
-
-Commit: {commit_hash_short}
-Message: {commit_title}
-
-Ready for Summary Generation
-```
-
-**Interactive Mode Menu:**
-```
-[C] Continue to Summary
-[P] Push to remote (if not done)
-[H] Halt pipeline
-```
-
-**Batch Mode:** Auto-continue
-
-## QUALITY GATE
-
-Before proceeding (BLOCKING - ALL must pass):
-- [ ] Targeted files staged (from File List)
-- [ ] Commit message generated
-- [ ] Commit created successfully
-- [ ] Story file status updated to "done"
-- [ ] **sprint-status.yaml updated to "done" (MANDATORY)**
-- [ ] **sprint-status.yaml update VERIFIED (CRITICAL)**
-
-**If ANY check fails, pipeline MUST HALT.**
-
-## CRITICAL STEP COMPLETION
-
-**ONLY WHEN** [commit created],
-load and execute `{nextStepFile}` for summary generation.
-
----
-
-## SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS
-- Only story files committed
-- Commit message is clear
-- Status updated properly
-- No secrets committed
-- Push succeeded or skipped safely
-
-### ❌ FAILURE
-- Committing unrelated files
-- Generic commit message
-- Not updating story status
-- Pushing secrets
-- Force pushing
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10a-queue-commit.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10a-queue-commit.md
deleted file mode 100644
index 6c72ee2b..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10a-queue-commit.md
+++ /dev/null
@@ -1,279 +0,0 @@
----
-name: 'step-06a-queue-commit'
-description: 'Queued git commit with file-based locking for parallel safety'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-06a-queue-commit.md'
-nextStepFile: '{workflow_path}/steps/step-07-summary.md'
-
-# Role
-role: dev
-requires_fresh_context: false
----
-
-# Step 6a: Queued Git Commit (Parallel-Safe)
-
-## STEP GOAL
-
-Execute git commit with file-based locking to prevent concurrent commit conflicts in parallel batch mode.
-
-**Problem Solved:**
-- Multiple parallel agents trying to commit simultaneously
-- Git lock file conflicts (.git/index.lock)
-- "Another git process seems to be running" errors
-- Commit failures requiring manual intervention
-
-**Solution:**
-- File-based commit queue using .git/bmad-commit.lock
-- Automatic retry with exponential backoff
-- Lock cleanup on success or failure
-- Maximum wait time enforcement
-
-## EXECUTION SEQUENCE
-
-### 1. Check if Commit Queue is Needed
-
-```
-If mode == "batch" AND execution_mode == "parallel":
- use_commit_queue = true
- Display: "🔒 Using commit queue (parallel mode)"
-Else:
- use_commit_queue = false
- Display: "Committing directly (sequential mode)"
- goto Step 3 (Direct Commit)
-```
-
-### 2. Acquire Commit Lock (Parallel Mode Only)
-
-**Lock file:** `.git/bmad-commit.lock`
-
-**Acquisition algorithm:**
-```
-max_wait_time = 300 seconds (5 minutes)
-retry_delay = 1 second (exponential backoff)
-start_time = now()
-
-WHILE elapsed_time < max_wait_time:
-
- IF lock file does NOT exist:
- Create lock file with content:
- locked_by: {{story_key}}
- locked_at: {{timestamp}}
- worker_id: {{worker_id}}
- pid: {{process_id}}
-
- Display: "🔓 Lock acquired for {{story_key}}"
- BREAK (proceed to commit)
-
- ELSE:
- Read lock file to check who has it
- Display: "⏳ Waiting for commit lock... (held by {{locked_by}}, {{wait_duration}}s elapsed)"
-
- Sleep retry_delay seconds
- retry_delay = min(retry_delay * 1.5, 30) # Exponential backoff, max 30s
-
- Check if lock is stale (>5 minutes old):
- IF lock_age > 300 seconds:
- Display: "⚠️ Stale lock detected ({{lock_age}}s old) - removing"
- Delete lock file
- Continue (try again)
-```
-
-**Timeout handling:**
-```
-IF elapsed_time >= max_wait_time:
- Display:
- ❌ TIMEOUT: Could not acquire commit lock after 5 minutes
-
- Lock held by: {{locked_by}}
- Lock age: {{lock_age}} seconds
-
- Possible causes:
- - Another agent crashed while holding lock
- - Commit taking abnormally long
- - Lock file not cleaned up
-
- HALT - Manual intervention required:
- - Check if lock holder is still running
- - Delete .git/bmad-commit.lock if safe
- - Retry this story
-```
-
-### 3. Execute Git Commit
-
-**Stage changes:**
-```bash
-git add {files_changed_for_this_story}
-```
-
-**Generate commit message:**
-```
-feat: implement story {{story_key}}
-
-{{implementation_summary_from_dev_agent_record}}
-
-Files changed:
-{{#each files_changed}}
-- {{this}}
-{{/each}}
-
-Tasks completed: {{checked_tasks}}/{{total_tasks}}
-Story status: {{story_status}}
-```
-
-**Commit:**
-```bash
-git commit -m "$(cat <<'EOF'
-{commit_message}
-EOF
-)"
-```
-
-**Verification:**
-```bash
-git log -1 --oneline
-```
-
-Confirm commit SHA returned.
-
-### 4. Release Commit Lock (Parallel Mode Only)
-
-```
-IF use_commit_queue == true:
- Delete lock file: .git/bmad-commit.lock
-
- Verify lock removed:
- IF lock file still exists:
- Display: "⚠️ WARNING: Could not remove lock file"
- Try force delete
- ELSE:
- Display: "🔓 Lock released for {{story_key}}"
-```
-
-**Error handling:**
-```
-IF commit failed:
- Release lock (if held)
- Display:
- ❌ COMMIT FAILED: {{error_message}}
-
- Story implemented but not committed.
- Changes are staged but not in git history.
-
- HALT - Fix commit issue before continuing
-```
-
-### 5. Update State
-
-Update state file:
-- Add `6a` to `stepsCompleted`
-- Set `lastStep: 6a`
-- Record `commit_sha`
-- Record `committed_at` timestamp
-
-### 6. Present Summary
-
-Display:
-```
-✅ Story {{story_key}} Committed
-
-Commit: {{commit_sha}}
-Files: {{files_count}} changed
-{{#if use_commit_queue}}Lock wait: {{lock_wait_duration}}s{{/if}}
-```
-
-**Interactive Mode Menu:**
-```
-[C] Continue to Summary
-[P] Push to remote
-[H] Halt pipeline
-```
-
-**Batch Mode:** Auto-continue to step-07-summary.md
-
-## CRITICAL STEP COMPLETION
-
-Load and execute `{nextStepFile}` for summary.
-
----
-
-## SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS
-- Changes committed to git
-- Commit SHA recorded
-- Lock acquired and released cleanly (parallel mode)
-- No lock file remaining
-- State updated
-
-### ❌ FAILURE
-- Commit timed out
-- Lock acquisition timed out (>5 min)
-- Lock not released (leaked lock)
-- Commit command failed
-- Stale lock not cleaned up
-
----
-
-## LOCK FILE FORMAT
-
-`.git/bmad-commit.lock` contains:
-```yaml
-locked_by: "2-7-image-file-handling"
-locked_at: "2026-01-07T18:45:32Z"
-worker_id: 3
-pid: 12345
-story_file: "docs/sprint-artifacts/2-7-image-file-handling.md"
-```
-
-This allows debugging if lock gets stuck.
-
----
-
-## QUEUE BENEFITS
-
-**Before (No Queue):**
-```
-Worker 1: git commit → acquires .git/index.lock
-Worker 2: git commit → ERROR: index.lock exists
-Worker 3: git commit → ERROR: index.lock exists
-Worker 2: retries → ERROR: index.lock exists
-Worker 3: retries → ERROR: index.lock exists
-Workers 2 & 3: HALT - manual intervention needed
-```
-
-**After (With Queue):**
-```
-Worker 1: acquires bmad-commit.lock → git commit → releases lock
-Worker 2: waits for lock → acquires → git commit → releases
-Worker 3: waits for lock → acquires → git commit → releases
-All workers: SUCCESS ✅
-```
-
-**Throughput Impact:**
-- Implementation: Fully parallel (no blocking)
-- Commits: Serialized (necessary to prevent conflicts)
-- Overall: Still much faster than sequential mode (implementation is 90% of the time)
-
----
-
-## STALE LOCK RECOVERY
-
-**Automatic cleanup:**
-- Locks older than 5 minutes are considered stale
-- Automatically removed before retrying
-- Prevents permanent deadlock from crashed agents
-
-**Manual recovery:**
-```bash
-# If workflow stuck on lock acquisition:
-rm .git/bmad-commit.lock
-
-# Check if any git process is actually running:
-ps aux | grep git
-
-# If no git process, safe to remove lock
-```
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-11-summary.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-11-summary.md
deleted file mode 100644
index 30860fed..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-11-summary.md
+++ /dev/null
@@ -1,219 +0,0 @@
----
-name: 'step-11-summary'
-description: 'Generate comprehensive audit trail and pipeline summary'
-
-# Path Definitions
-workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
-
-# File References
-thisStepFile: '{workflow_path}/steps/step-11-summary.md'
-stateFile: '{state_file}'
-storyFile: '{story_file}'
-auditTrail: '{audit_trail}'
-
-# Role
-role: null
----
-
-# Step 11: Pipeline Summary
-
-## STEP GOAL
-
-Generate comprehensive audit trail and summary:
-1. Calculate total duration
-2. Summarize work completed
-3. Generate audit trail file
-4. Display final summary
-5. Clean up state file
-
-## EXECUTION SEQUENCE
-
-### 1. Calculate Metrics
-
-From state file, calculate:
-- Total duration: `{completed_at} - {started_at}`
-- Step durations
-- Files modified count
-- Issues found and fixed
-- Tasks completed
-
-### 2. Generate Audit Trail
-
-Create file: `{sprint_artifacts}/audit-super-dev-{story_id}-{date}.yaml`
-
-```yaml
----
-audit_version: "1.0"
-workflow: "super-dev-pipeline"
-workflow_version: "1.0.0"
-
-# Story identification
-story_id: "{story_id}"
-story_file: "{story_file}"
-story_title: "{story_title}"
-
-# Execution summary
-execution:
- started_at: "{started_at}"
- completed_at: "{completed_at}"
- total_duration: "{duration}"
- mode: "{mode}"
- status: "completed"
-
-# Development analysis
-development:
- type: "{greenfield|brownfield|hybrid}"
- existing_files_modified: {count}
- new_files_created: {count}
- migrations_applied: {count}
-
-# Step results
-steps:
- step-01-init:
- duration: "{duration}"
- status: "completed"
-
- step-02-pre-gap-analysis:
- duration: "{duration}"
- tasks_analyzed: {count}
- tasks_refined: {count}
- tasks_added: {count}
- status: "completed"
-
- step-03-implement:
- duration: "{duration}"
- tasks_completed: {count}
- files_created: {list}
- files_modified: {list}
- migrations: {list}
- tests_added: {count}
- status: "completed"
-
- step-04-post-validation:
- duration: "{duration}"
- tasks_verified: {count}
- false_positives: {count}
- re_implementations: {count}
- status: "completed"
-
- step-05-code-review:
- duration: "{duration}"
- issues_found: {count}
- issues_fixed: {count}
- categories: {list}
- status: "completed"
-
- step-06-complete:
- duration: "{duration}"
- commit_hash: "{hash}"
- files_committed: {count}
- pushed: {true|false}
- status: "completed"
-
-# Quality metrics
-quality:
- all_tests_passing: true
- lint_clean: true
- build_success: true
- no_vibe_coding: true
- followed_step_sequence: true
-
-# Files affected
-files:
- created: {list}
- modified: {list}
- deleted: {list}
-
-# Commit information
-commit:
- hash: "{hash}"
- message: "{message}"
- files_committed: {count}
- pushed_to_remote: {true|false}
-```
-
-### 3. Display Final Summary
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎉 SUPER-DEV PIPELINE COMPLETE!
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Story: {story_title}
-Duration: {total_duration}
-
-Development Type: {greenfield|brownfield|hybrid}
-
-Results:
-✅ Tasks Completed: {completed_count}
-✅ Files Created: {created_count}
-✅ Files Modified: {modified_count}
-✅ Tests Added: {test_count}
-✅ Issues Found & Fixed: {issue_count}
-
-Quality Gates Passed:
-✅ Pre-Gap Analysis
-✅ Implementation
-✅ Post-Validation (no false positives)
-✅ Code Review (3-10 issues)
-✅ All tests passing
-✅ Lint clean
-✅ Build success
-
-Git:
-✅ Commit: {commit_hash}
-{if pushed}✅ Pushed to remote{endif}
-
-Story Status: review (ready for human review)
-
-Audit Trail: {audit_file}
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-✨ No vibe coding occurred! Disciplined execution maintained.
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-### 4. Clean Up State File
-
-```bash
-rm {sprint_artifacts}/super-dev-state-{story_id}.yaml
-```
-
-State is no longer needed - audit trail is the permanent record.
-
-### 5. Final Message
-
-```
-Super-Dev Pipeline Complete!
-
-This story was developed with disciplined step-file execution.
-All quality gates passed. Ready for human review.
-
-Next Steps:
-1. Review the commit: git show {commit_hash}
-2. Test manually if needed
-3. Merge when approved
-```
-
-## PIPELINE COMPLETE
-
-Pipeline execution is finished. No further steps.
-
----
-
-## SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS
-- Audit trail generated
-- Summary accurate
-- State file cleaned up
-- Story marked "review"
-- All metrics captured
-
-### ❌ FAILURE
-- Missing audit trail
-- Incomplete summary
-- State file not cleaned
-- Metrics inaccurate
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.md b/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.md
index db0d099c..02e4208c 100644
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.md
+++ b/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.md
@@ -1,292 +1,374 @@
----
-name: super-dev-pipeline
-description: Step-file architecture for super-dev workflow - disciplined execution for both greenfield and brownfield development
-web_bundle: true
----
+# Super-Dev Pipeline - Multi-Agent Architecture
-# Super-Dev Pipeline Workflow
-
-**Goal:** Execute story development with disciplined step-file architecture that prevents "vibe coding" and works for both new features and existing codebase modifications.
-
-**Your Role:** You are the **BMAD Pipeline Orchestrator**. You will follow each step file precisely, without deviation, optimization, or skipping ahead.
-
-**Key Principle:** This workflow uses **step-file architecture** for disciplined execution that prevents Claude from veering off-course when token usage is high.
+**Architecture:** GSDMAD (GSD + BMAD)
+**Philosophy:** Trust but verify, separation of concerns
---
-## WORKFLOW ARCHITECTURE
+## Overview
-This uses **step-file architecture** borrowed from story-pipeline:
+This workflow implements a story using **4 independent agents** with external validation at each phase.
-### Core Principles
-
-- **Micro-file Design**: Each step is a self-contained instruction file (~150-300 lines)
-- **Just-In-Time Loading**: Only the current step file is in memory
-- **Mandatory Sequences**: Execute all numbered sections in order, never deviate
-- **State Tracking**: Pipeline state in `{sprint_artifacts}/super-dev-state-{story_id}.yaml`
-- **No Vibe Coding**: Explicit instructions prevent optimization/deviation
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **QUALITY GATES**: Complete gate criteria before proceeding to next step
-4. **WAIT FOR INPUT**: In interactive mode, halt at menus and wait for user selection
-5. **SAVE STATE**: Update pipeline state file after each step completion
-6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **NEVER** load multiple step files simultaneously
-- **ALWAYS** read entire step file before execution
-- **NEVER** skip steps or optimize the sequence
-- **ALWAYS** update pipeline state after completing each step
-- **ALWAYS** follow the exact instructions in the step file
-- **NEVER** create mental todo lists from future steps
-- **NEVER** look ahead to future step files
-- **NEVER** vibe code when token usage is high - follow the steps exactly!
+**Key Innovation:** Each agent has single responsibility and fresh context. No agent validates its own work.
---
-## STEP FILE MAP
+## Execution Flow
-| Step | File | Agent | Purpose |
-|------|------|-------|---------|
-| 1 | step-01-init.md | - | Load story, detect greenfield vs brownfield |
-| 2 | step-02-pre-gap-analysis.md | DEV | Validate tasks + **detect batchable patterns** |
-| 3 | step-03-implement.md | DEV | **Smart batching** + adaptive implementation |
-| 4 | step-04-post-validation.md | DEV | Verify completed tasks vs reality |
-| 5 | step-05-code-review.md | DEV | Find 3-10 specific issues |
-| 6 | step-06-complete.md | SM | Commit and push changes |
-| 7 | step-07-summary.md | - | Audit trail generation |
-
----
-
-## KEY DIFFERENCES FROM story-pipeline
-
-### What's REMOVED:
-- ❌ Step 2 (create-story) - assumes story already exists
-- ❌ Step 4 (ATDD) - not mandatory for brownfield
-
-### What's ENHANCED:
-- ✅ Pre-gap analysis is MORE thorough (validates against existing code)
-- ✅ **Smart Batching** - detects and groups similar tasks automatically
-- ✅ Implementation is ADAPTIVE (TDD for new, refactor for existing)
-- ✅ Works for both greenfield and brownfield
-
-### What's NEW:
-- ⚡ **Pattern Detection** - automatically identifies batchable tasks
-- ⚡ **Intelligent Grouping** - groups similar tasks for batch execution
-- ⚡ **Time Optimization** - 50-70% faster for repetitive work
-- ⚡ **Safety Preserved** - validation gates enforce discipline
-
----
-
-## SMART BATCHING FEATURE
-
-### What is Smart Batching?
-
-**Smart batching** is an intelligent optimization that groups similar, low-risk tasks for batch execution while maintaining full validation discipline.
-
-**NOT Vibe Coding:**
-- ✅ Pattern detection is systematic (not guesswork)
-- ✅ Batches are validated as a group (not skipped)
-- ✅ Failure triggers fallback to one-at-a-time
-- ✅ High-risk tasks always executed individually
-
-**When It Helps:**
-- Large stories with repetitive tasks (100+ tasks)
-- Package migration work (installing multiple packages)
-- Module refactoring (same pattern across files)
-- Code cleanup (delete old implementations)
-
-**Time Savings:**
```
-Example: 100-task story
-- Without batching: 100 tasks × 2 min = 200 minutes (3.3 hours)
-- With batching: 6 batches × 10 min + 20 individual × 2 min = 100 minutes (1.7 hours)
-- Savings: 100 minutes (50% faster!)
+┌─────────────────────────────────────────────────────────────┐
+│ Main Orchestrator (Claude) │
+│ - Loads story │
+│ - Spawns agents sequentially │
+│ - Verifies each phase │
+│ - Final quality gate │
+└─────────────────────────────────────────────────────────────┘
+ │
+ ├──> Phase 1: Builder (Steps 1-4)
+ │ - Load story, analyze gaps
+ │ - Write tests (TDD)
+ │ - Implement code
+ │ - Report what was built (NO VALIDATION)
+ │
+ ├──> Phase 2: Inspector (Steps 5-6)
+ │ - Fresh context, no Builder knowledge
+ │ - Verify files exist
+ │ - Run tests independently
+ │ - Run quality checks
+ │ - PASS or FAIL verdict
+ │
+ ├──> Phase 3: Reviewer (Step 7)
+ │ - Fresh context, adversarial stance
+ │ - Find security vulnerabilities
+ │ - Find performance problems
+ │ - Find logic bugs
+ │ - Report issues with severity
+ │
+ ├──> Phase 4: Fixer (Steps 8-9)
+ │ - Fix CRITICAL issues (all)
+ │ - Fix HIGH issues (all)
+ │ - Fix MEDIUM issues (if time)
+ │ - Skip LOW issues (gold-plating)
+ │ - Update story + sprint-status
+ │ - Commit changes
+ │
+ └──> Final Verification (Main)
+ - Check git commits exist
+ - Check story checkboxes updated
+ - Check sprint-status updated
+ - Check tests passed
+ - Mark COMPLETE or FAILED
```
-### Batchable Pattern Types
+---
-| Pattern | Example Tasks | Risk | Validation |
-|---------|--------------|------|------------|
-| **Package Install** | Add dependencies | LOW | Build succeeds |
-| **Module Registration** | Import modules | LOW | TypeScript compiles |
-| **Code Deletion** | Remove old code | LOW | Tests pass |
-| **Import Updates** | Update import paths | LOW | Build succeeds |
-| **Config Changes** | Update settings | LOW | App starts |
+## Agent Spawning Instructions
-### NON-Batchable (Individual Execution)
+### Phase 1: Spawn Builder
-| Pattern | Example Tasks | Risk | Why Individual |
-|---------|--------------|------|----------------|
-| **Business Logic** | Circuit breaker fallbacks | MEDIUM-HIGH | Logic varies per case |
-| **Security Code** | Auth/authorization | HIGH | Mistakes are critical |
-| **Data Migrations** | Schema changes | HIGH | Irreversible |
-| **API Integration** | External service calls | MEDIUM | Error handling varies |
-| **Novel Patterns** | First-time implementation | MEDIUM | Unproven approach |
+```javascript
+Task({
+ subagent_type: "general-purpose",
+ description: "Implement story {{story_key}}",
+ prompt: `
+ You are the BUILDER agent for story {{story_key}}.
-### How It Works
+ Load and execute: {agents_path}/builder.md
-**Step 2 (Pre-Gap Analysis):**
-1. Analyzes all tasks
-2. Detects repeating patterns
-3. Categorizes as batchable or individual
-4. Generates batching plan with time estimates
-5. Adds plan to story file
+ Story file: {{story_file}}
-**Step 3 (Implementation):**
-1. Loads batching plan
-2. Executes pattern batches first
-3. Validates each batch
-4. Fallback to individual if batch fails
-5. Executes individual tasks with full rigor
+ Complete Steps 1-4:
+ 1. Init - Load story
+ 2. Pre-Gap - Analyze what exists
+ 3. Write Tests - TDD approach
+ 4. Implement - Write production code
-**Safety Mechanisms:**
-- Pattern detection uses conservative rules (default to individual)
-- Each batch has explicit validation strategy
-- Failed batch triggers automatic fallback
-- High-risk tasks never batched
-- All validation gates still enforced
+ DO NOT:
+ - Validate your work
+ - Review your code
+ - Update checkboxes
+ - Commit changes
+
+ Just build it and report what you created.
+ `
+});
+```
+
+**Wait for Builder to complete. Store agent_id in agent-history.json.**
+
+### Phase 2: Spawn Inspector
+
+```javascript
+Task({
+ subagent_type: "general-purpose",
+ description: "Validate story {{story_key}} implementation",
+ prompt: `
+ You are the INSPECTOR agent for story {{story_key}}.
+
+ Load and execute: {agents_path}/inspector.md
+
+ Story file: {{story_file}}
+
+ You have NO KNOWLEDGE of what the Builder did.
+
+ Complete Steps 5-6:
+ 5. Post-Validation - Verify files exist and have content
+ 6. Quality Checks - Run type-check, lint, build, tests
+
+ Run all checks yourself. Don't trust Builder claims.
+
+ Output: PASS or FAIL verdict with evidence.
+ `
+});
+```
+
+**Wait for Inspector to complete. If FAIL, halt pipeline.**
+
+### Phase 3: Spawn Reviewer
+
+```javascript
+Task({
+ subagent_type: "bmad_bmm_multi-agent-review",
+ description: "Adversarial review of story {{story_key}}",
+ prompt: `
+ You are the ADVERSARIAL REVIEWER for story {{story_key}}.
+
+ Load and execute: {agents_path}/reviewer.md
+
+ Story file: {{story_file}}
+ Complexity: {{complexity_level}}
+
+ Your goal is to FIND PROBLEMS.
+
+ Complete Step 7:
+ 7. Code Review - Find security, performance, logic issues
+
+ Be critical. Look for flaws.
+
+ Output: List of issues with severity ratings.
+ `
+});
+```
+
+**Wait for Reviewer to complete. Parse issues by severity.**
+
+### Phase 4: Spawn Fixer
+
+```javascript
+Task({
+ subagent_type: "general-purpose",
+ description: "Fix issues in story {{story_key}}",
+ prompt: `
+ You are the FIXER agent for story {{story_key}}.
+
+ Load and execute: {agents_path}/fixer.md
+
+ Story file: {{story_file}}
+ Review issues: {{review_findings}}
+
+ Complete Steps 8-9:
+ 8. Review Analysis - Categorize issues, filter gold-plating
+ 9. Fix Issues - Fix CRITICAL/HIGH, consider MEDIUM, skip LOW
+
+ After fixing:
+ - Update story checkboxes
+ - Update sprint-status.yaml
+ - Commit with descriptive message
+
+ Output: Fix summary with git commit hash.
+ `
+});
+```
+
+**Wait for Fixer to complete.**
---
-## EXECUTION MODES
+## Final Verification (Main Orchestrator)
+
+**After all agents complete, verify:**
-### Interactive Mode (Default)
```bash
-bmad super-dev-pipeline
+# 1. Check git commits
+git log --oneline -3 | grep "{{story_key}}"
+if [ $? -ne 0 ]; then
+ echo "❌ FAILED: No commit found"
+ exit 1
+fi
+
+# 2. Check story checkboxes
+before=$(git show HEAD~1:{{story_file}} | grep -c '^- \[x\]')
+after=$(grep -c '^- \[x\]' {{story_file}})
+if [ $after -le $before ]; then
+ echo "❌ FAILED: Checkboxes not updated"
+ exit 1
+fi
+
+# 3. Check sprint-status
+git diff HEAD~1 {{sprint_status}} | grep "{{story_key}}: done"
+if [ $? -ne 0 ]; then
+ echo "❌ FAILED: Sprint status not updated"
+ exit 1
+fi
+
+# 4. Check Inspector output for test evidence
+grep -E "PASS|tests.*passing" inspector_output.txt
+if [ $? -ne 0 ]; then
+ echo "❌ FAILED: No test evidence"
+ exit 1
+fi
+
+echo "✅ STORY COMPLETE - All verifications passed"
```
-Features:
-- Menu navigation between steps
-- User approval at quality gates
-- Can pause and resume
+---
-### Batch Mode (For batch-super-dev)
-```bash
-bmad super-dev-pipeline --batch
+## Benefits Over Single-Agent
+
+### Separation of Concerns
+- Builder doesn't validate own work
+- Inspector has no incentive to lie
+- Reviewer approaches with fresh eyes
+- Fixer can't skip issues
+
+### Fresh Context Each Phase
+- Each agent starts at 0% context
+- No accumulated fatigue
+- No degraded quality
+- Honest reporting
+
+### Adversarial Review
+- Reviewer WANTS to find issues
+- Not defensive about the code
+- More thorough than self-review
+
+### Honest Verification
+- Inspector runs tests independently
+- Main orchestrator verifies everything
+- Can't fake completion
+
+---
+
+## Complexity Routing
+
+**MICRO stories:**
+- Skip Reviewer (low risk)
+- 2 agents: Builder → Inspector → Fixer
+
+**STANDARD stories:**
+- Full pipeline
+- 4 agents: Builder → Inspector → Reviewer → Fixer
+
+**COMPLEX stories:**
+- Enhanced review (6 reviewers instead of 4)
+- Full pipeline + extra scrutiny
+- 4 agents: Builder → Inspector → Reviewer (enhanced) → Fixer
+
+---
+
+## Agent Tracking
+
+Track all agents in `agent-history.json`:
+
+```json
+{
+ "version": "1.0",
+ "max_entries": 50,
+ "entries": [
+ {
+ "agent_id": "abc123",
+ "story_key": "17-10",
+ "phase": "builder",
+ "steps": [1,2,3,4],
+ "timestamp": "2026-01-25T21:00:00Z",
+ "status": "completed",
+ "completion_timestamp": "2026-01-25T21:15:00Z"
+ },
+ {
+ "agent_id": "def456",
+ "story_key": "17-10",
+ "phase": "inspector",
+ "steps": [5,6],
+ "timestamp": "2026-01-25T21:16:00Z",
+ "status": "completed",
+ "completion_timestamp": "2026-01-25T21:20:00Z"
+ }
+ ]
+}
```
-Features:
-- Auto-proceed through all steps
-- Fail-fast on errors
-- No vibe coding even at high token counts
+**Benefits:**
+- Resume interrupted sessions
+- Track agent performance
+- Debug failed pipelines
+- Audit trail
---
-## INITIALIZATION SEQUENCE
+## Error Handling
-### 1. Configuration Loading
+**If Builder fails:**
+- Don't spawn Inspector
+- Report failure to user
+- Option to resume or retry
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-- `output_folder`, `sprint_artifacts`, `communication_language`
+**If Inspector fails:**
+- Don't spawn Reviewer
+- Report specific failures
+- Resume Builder to fix issues
-### 2. Pipeline Parameters
+**If Reviewer finds CRITICAL issues:**
+- Must spawn Fixer (not optional)
+- Cannot mark story complete until fixed
-Resolve from invocation:
-- `story_id`: Story identifier (e.g., "1-4")
-- `story_file`: Path to story file (must exist!)
-- `mode`: "interactive" or "batch"
-
-### 3. Document Pre-loading
-
-Load and cache these documents (read once, use across steps):
-- Story file: Required, must exist
-- Project context: `**/project-context.md`
-- Epic file: Optional, for context
-
-### 4. First Step Execution
-
-Load, read the full file and then execute:
-`{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md`
+**If Fixer fails:**
+- Report unfixed issues
+- Cannot mark story complete
+- Manual intervention required
---
-## QUALITY GATES
+## Comparison: v1.x vs v2.0
-Each gate must pass before proceeding:
-
-### Pre-Gap Analysis Gate (Step 2)
-- [ ] All tasks validated against codebase
-- [ ] Existing code analyzed
-- [ ] Tasks refined if needed
-- [ ] No missing context
-
-### Implementation Gate (Step 3)
-- [ ] All tasks completed
-- [ ] Tests pass
-- [ ] Code follows project patterns
-- [ ] No TypeScript errors
-
-### Post-Validation Gate (Step 4)
-- [ ] All completed tasks verified against codebase
-- [ ] Zero false positives (or re-implementation complete)
-- [ ] Files/functions/tests actually exist
-- [ ] Tests actually pass (not just claimed)
-
-### Code Review Gate (Step 5)
-- [ ] 3-10 specific issues identified (not "looks good")
-- [ ] All issues resolved or documented
-- [ ] Security review complete
+| Aspect | v1.x (Single-Agent) | v2.0 (Multi-Agent) |
+|--------|--------------------|--------------------|
+| Agents | 1 | 4 |
+| Validation | Self (conflict of interest) | Independent (no conflict) |
+| Code Review | Self-review | Adversarial (fresh eyes) |
+| Honesty | Low (can lie) | High (verified) |
+| Context | Degrades over 11 steps | Fresh each phase |
+| Catches Issues | Low | High |
+| Completion Accuracy | ~60% (agents lie) | ~95% (verified) |
---
-## ANTI-VIBE-CODING ENFORCEMENT
+## Migration from v1.x
-This workflow **prevents vibe coding** through:
+**Backward Compatibility:**
+```yaml
+execution_mode: "single_agent" # Use v1.x
+execution_mode: "multi_agent" # Use v2.0 (new)
+```
-1. **Mandatory Sequence**: Can't skip ahead or optimize
-2. **Micro-file Loading**: Only current step in memory
-3. **Quality Gates**: Must pass criteria to proceed
-4. **State Tracking**: Progress is recorded and verified
-5. **Explicit Instructions**: No interpretation required
-
-**Even at 200K tokens**, Claude must:
-- ✅ Read entire step file
-- ✅ Follow numbered sequence
-- ✅ Complete quality gate
-- ✅ Update state
-- ✅ Load next step
-
-**No shortcuts. No optimizations. No vibe coding.**
+**Gradual Rollout:**
+1. Week 1: Test v2.0 on 3-5 stories
+2. Week 2: Make v2.0 default for new stories
+3. Week 3: Migrate existing stories to v2.0
+4. Week 4: Deprecate v1.x
---
-## SUCCESS METRICS
+## Hospital-Grade Standards
-### ✅ SUCCESS
-- Pipeline completes all 7 steps
-- All quality gates passed
-- Story status updated
-- Git commit created
-- Audit trail generated
-- **No vibe coding occurred**
+⚕️ **Lives May Be at Stake**
-### ❌ FAILURE
-- Step file instructions skipped or optimized
-- Quality gate bypassed without approval
-- State file not updated
-- Tests not verified
-- Code review accepts "looks good"
-- **Vibe coding detected**
+- Independent validation catches errors
+- Adversarial review finds security flaws
+- Multiple checkpoints prevent shortcuts
+- Final verification prevents false completion
+
+**QUALITY >> SPEED**
---
-## COMPARISON WITH OTHER WORKFLOWS
-
-| Feature | super-dev-story | story-pipeline | super-dev-pipeline |
-|---------|----------------|----------------|-------------------|
-| Architecture | Orchestration | Step-files | Step-files |
-| Story creation | Separate workflow | Included | ❌ Not included |
-| ATDD mandatory | No | Yes | No (adaptive) |
-| Greenfield | ✅ | ✅ | ✅ |
-| Brownfield | ✅ | ❌ Limited | ✅ |
-| Token efficiency | ~100-150K | ~25-30K | ~40-60K |
-| Vibe-proof | ❌ | ✅ | ✅ |
-
----
-
-**super-dev-pipeline is the best of both worlds for batch-super-dev!**
+**Key Takeaway:** Don't trust a single agent to build, validate, review, and commit its own work. Use independent agents with fresh context at each phase.
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml b/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml
index bbcc0f68..8aca62d1 100644
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml
+++ b/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml
@@ -1,7 +1,10 @@
-name: super-dev-pipeline
-description: "Complete a-k workflow: test-first development, smart gap analysis, quality gates, intelligent multi-agent review, and mandatory status updates. Risk-based complexity routing with variable agent counts."
-author: "BMad"
-version: "1.5.0" # Complete a-k workflow with TDD, quality gates, multi-agent review, and mandatory sprint-status updates
+name: super-dev-pipeline-v2
+description: "Multi-agent pipeline with wave-based execution, independent validation, and adversarial code review (GSDMAD)"
+author: "BMAD Method + GSD"
+version: "2.0.0"
+
+# Execution mode
+execution_mode: "multi_agent" # multi_agent | single_agent (fallback)
# Critical variables from config
config_source: "{project-root}/_bmad/bmm/config.yaml"
@@ -11,259 +14,108 @@ communication_language: "{config_source}:communication_language"
date: system-generated
# Workflow paths
-installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
+installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline-v2"
+agents_path: "{installed_path}/agents"
steps_path: "{installed_path}/steps"
-templates_path: "{installed_path}/templates"
-checklists_path: "{installed_path}/checklists"
+
+# Agent tracking (from GSD)
+agent_history: "{sprint_artifacts}/agent-history.json"
+current_agent_id: "{sprint_artifacts}/current-agent-id.txt"
# State management
state_file: "{sprint_artifacts}/super-dev-state-{{story_id}}.yaml"
audit_trail: "{sprint_artifacts}/audit-super-dev-{{story_id}}-{{date}}.yaml"
-# Auto-create story settings (NEW v1.4.0)
-# When story is missing or lacks proper context, auto-invoke /create-story-with-gap-analysis
-auto_create_story:
- enabled: true # Set to false to revert to old HALT behavior
- create_story_workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story-with-gap-analysis"
- triggers:
- - story_not_found # Story file doesn't exist
- - no_tasks # Story exists but has no tasks
- - missing_sections # Story missing required sections (Tasks, Acceptance Criteria)
+# Multi-agent configuration
+agents:
+ builder:
+ description: "Implementation agent - writes code and tests"
+ steps: [1, 2, 3, 4]
+ subagent_type: "general-purpose"
+ prompt_file: "{agents_path}/builder.md"
+ trust_level: "low" # Assumes agent will cut corners
+ timeout: 3600 # 1 hour
-# Complexity level (passed from batch-super-dev or set manually)
-# Controls which pipeline steps to execute
+ inspector:
+ description: "Validation agent - independent verification"
+ steps: [5, 6]
+ subagent_type: "general-purpose"
+ prompt_file: "{agents_path}/inspector.md"
+ fresh_context: true # No knowledge of builder agent
+ trust_level: "medium" # No conflict of interest
+ timeout: 1800 # 30 minutes
+
+ reviewer:
+ description: "Adversarial code review - finds problems"
+ steps: [7]
+ subagent_type: "multi-agent-review" # Spawns multiple reviewers
+ prompt_file: "{agents_path}/reviewer.md"
+ fresh_context: true
+ adversarial: true # Goal: find issues
+ trust_level: "high" # Wants to find problems
+ timeout: 1800 # 30 minutes
+ review_agent_count:
+ micro: 2
+ standard: 4
+ complex: 6
+
+ fixer:
+ description: "Issue resolution - fixes critical/high issues"
+ steps: [8, 9]
+ subagent_type: "general-purpose"
+ prompt_file: "{agents_path}/fixer.md"
+ trust_level: "medium" # Incentive to minimize work
+ timeout: 2400 # 40 minutes
+
+# Complexity level (determines which steps to execute)
complexity_level: "standard" # micro | standard | complex
-# Risk-based complexity routing (UPDATED v1.5.0)
-# Complexity determined by RISK level, not task count
-# Risk keywords: auth, security, payment, file handling, architecture changes
+# Complexity routing
complexity_routing:
micro:
- skip_steps: [3, 7, 8, 9] # Skip write-tests, code-review, review-analysis, fix-issues
- description: "Lightweight path for low-risk stories (UI tweaks, text, simple CRUD)"
- multi_agent_count: 2
- examples: ["UI tweaks", "text changes", "simple CRUD", "documentation"]
+ skip_agents: ["reviewer"] # Skip code review for micro stories
+ description: "Lightweight path for low-risk stories"
+ examples: ["UI tweaks", "text changes", "simple CRUD"]
+
standard:
- skip_steps: [] # Full pipeline
- description: "Balanced path for medium-risk stories (APIs, business logic)"
- multi_agent_count: 4
- examples: ["API endpoints", "business logic", "data validation"]
+ skip_agents: [] # Full pipeline
+ description: "Balanced path for medium-risk stories"
+ examples: ["API endpoints", "business logic"]
+
complex:
- skip_steps: [] # Full pipeline + comprehensive review
- description: "Comprehensive path for high-risk stories (auth, payments, security)"
- multi_agent_count: 6
- examples: ["auth/security", "payments", "file handling", "architecture changes"]
- warn_before_start: true
- suggest_split: true
+ skip_agents: [] # Full pipeline + enhanced review
+ description: "Enhanced validation for high-risk stories"
+ examples: ["Auth", "payments", "security", "migrations"]
+ review_focus: ["security", "performance", "architecture"]
-# Workflow modes
-modes:
- interactive:
- description: "Human-in-the-loop with menu navigation between steps"
- checkpoint_on_failure: true
- requires_approval: true
- smart_batching: true # User can approve batching plan
- batch:
- description: "Unattended execution for batch-super-dev"
- checkpoint_on_failure: true
- requires_approval: false
- fail_fast: true
- smart_batching: true # Auto-enabled for efficiency
-
-# Smart batching configuration
-smart_batching:
+# Final verification checklist (main orchestrator)
+final_verification:
enabled: true
- detect_patterns: true
- default_to_safe: true # When uncertain, execute individually
- min_batch_size: 3 # Minimum tasks to form a batch
- fallback_on_failure: true # Revert to individual if batch fails
+ checks:
+ - name: "git_commits"
+ command: "git log --oneline -3 | grep {{story_key}}"
+ failure_message: "No commit found for {{story_key}}"
- # Batchable pattern definitions
- batchable_patterns:
- - pattern: "package_installation"
- keywords: ["Add", "package.json", "npm install", "dependency"]
- risk_level: "low"
- validation: "npm install && npm run build"
+ - name: "story_checkboxes"
+ command: |
+ before=$(git show HEAD~1:{{story_file}} | grep -c '^- \[x\]')
+ after=$(grep -c '^- \[x\]' {{story_file}})
+ [ $after -gt $before ]
+ failure_message: "Story checkboxes not updated"
- - pattern: "module_registration"
- keywords: ["Import", "Module", "app.module", "register"]
- risk_level: "low"
- validation: "tsc --noEmit"
+ - name: "sprint_status"
+ command: "git diff HEAD~1 {{sprint_status}} | grep '{{story_key}}'"
+ failure_message: "Sprint status not updated"
- - pattern: "code_deletion"
- keywords: ["Delete", "Remove", "rm ", "unlink"]
- risk_level: "low"
- validation: "npm test && npm run build"
+ - name: "tests_passed"
+ # Parse agent output for test evidence
+ validation: "inspector_output must contain 'PASS' or test count"
+ failure_message: "No test evidence in validation output"
- - pattern: "import_update"
- keywords: ["Update import", "Change import", "import from"]
- risk_level: "low"
- validation: "npm run build"
-
- # Non-batchable pattern definitions (always execute individually)
- individual_patterns:
- - pattern: "business_logic"
- keywords: ["circuit breaker", "fallback", "caching for", "strategy"]
- risk_level: "medium"
-
- - pattern: "security"
- keywords: ["auth", "permission", "security", "encrypt"]
- risk_level: "high"
-
- - pattern: "data_migration"
- keywords: ["migration", "schema", "ALTER TABLE", "database"]
- risk_level: "high"
-
-# Agent role definitions (loaded once, switched as needed)
-agents:
- dev:
- name: "Developer"
- persona: "{project-root}/_bmad/bmm/agents/dev.md"
- description: "Gap analysis, write tests, implementation, validation, review, fixes"
- used_in_steps: [2, 3, 4, 5, 6, 7, 8, 9]
- sm:
- name: "Scrum Master"
- persona: "{project-root}/_bmad/bmm/agents/sm.md"
- description: "Story completion, status updates, sprint-status.yaml management"
- used_in_steps: [10]
-
-# Step file definitions (NEW v1.5.0: 11-step a-k workflow)
-steps:
- - step: 1
- file: "{steps_path}/step-01-init.md"
- name: "Init + Validate Story"
- description: "Load, validate, auto-create if needed (a-c)"
- agent: null
- quality_gate: false
- auto_create_story: true
-
- - step: 2
- file: "{steps_path}/step-02-smart-gap-analysis.md"
- name: "Smart Gap Analysis"
- description: "Gap analysis (skip if just created story) (d)"
- agent: dev
- quality_gate: true
- skip_if_story_just_created: true
-
- - step: 3
- file: "{steps_path}/step-03-write-tests.md"
- name: "Write Tests (TDD)"
- description: "Write tests before implementation (e)"
- agent: dev
- quality_gate: false
- test_driven: true
-
- - step: 4
- file: "{steps_path}/step-04-implement.md"
- name: "Implement"
- description: "Run dev-story implementation (f)"
- agent: dev
- quality_gate: true
-
- - step: 5
- file: "{steps_path}/step-05-post-validation.md"
- name: "Post-Validation"
- description: "Verify work actually implemented (g)"
- agent: dev
- quality_gate: true
- iterative: true
-
- - step: 6
- file: "{steps_path}/step-06-run-quality-checks.md"
- name: "Quality Checks"
- description: "Tests, type check, linter - fix all (h)"
- agent: dev
- quality_gate: true
- blocking: true
- required_checks:
- - tests_passing
- - type_check_passing
- - lint_passing
- - coverage_threshold
-
- - step: 7
- file: "{steps_path}/step-07-code-review.md"
- name: "Code Review"
- description: "Multi-agent review with fresh context (i)"
- agent: dev
- quality_gate: true
- requires_fresh_context: true
- multi_agent_review: true
- variable_agent_count: true
-
- - step: 8
- file: "{steps_path}/step-08-review-analysis.md"
- name: "Review Analysis"
- description: "Analyze findings - reject gold plating (j)"
- agent: dev
- quality_gate: false
- critical_thinking: true
-
- - step: 9
- file: "{steps_path}/step-09-fix-issues.md"
- name: "Fix Issues"
- description: "Implement MUST FIX and SHOULD FIX items"
- agent: dev
- quality_gate: true
-
- - step: 10
- file: "{steps_path}/step-10-complete.md"
- name: "Complete + Update Status"
- description: "Mark done, update sprint-status.yaml (k)"
- agent: sm
- quality_gate: true
- mandatory_sprint_status_update: true
- verify_status_update: true
-
- - step: 11
- file: "{steps_path}/step-11-summary.md"
- name: "Summary"
- description: "Generate comprehensive audit trail"
- agent: null
- quality_gate: false
-
-# Quality gates
-quality_gates:
- pre_gap_analysis:
- step: 2
- criteria:
- - "All tasks validated or refined"
- - "No missing context"
- - "Implementation path clear"
-
- implementation:
- step: 3
- criteria:
- - "All tasks completed"
- - "Tests pass"
- - "Code follows project patterns"
-
- post_validation:
- step: 4
- criteria:
- - "All completed tasks verified against codebase"
- - "Zero false positives remaining"
- - "Files/functions/tests actually exist"
-
- code_review:
- step: 5
- criteria:
- - "3-10 specific issues identified"
- - "All issues resolved or documented"
- - "Security review complete"
-
-# Document loading strategies
-input_file_patterns:
- story:
- description: "Story file being developed"
- pattern: "{sprint_artifacts}/story-*.md"
- load_strategy: "FULL_LOAD"
- cache: true
-
- project_context:
- description: "Critical rules and patterns"
- pattern: "**/project-context.md"
- load_strategy: "FULL_LOAD"
- cache: true
+# Backward compatibility
+fallback_to_v1:
+ enabled: true
+ condition: "execution_mode == 'single_agent'"
+ workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
standalone: true
diff --git a/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml.backup b/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml.backup
deleted file mode 100644
index fd417a36..00000000
--- a/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml.backup
+++ /dev/null
@@ -1,218 +0,0 @@
-name: super-dev-pipeline
-description: "Step-file architecture with complexity-based routing, smart batching, and auto-story-creation. Micro stories get lightweight path, standard/complex get full quality gates."
-author: "BMad"
-version: "1.4.0" # Added auto-create story via /create-story-with-gap-analysis when story missing or incomplete
-
-# Critical variables from config
-config_source: "{project-root}/_bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-sprint_artifacts: "{config_source}:sprint_artifacts"
-communication_language: "{config_source}:communication_language"
-date: system-generated
-
-# Workflow paths
-installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
-steps_path: "{installed_path}/steps"
-templates_path: "{installed_path}/templates"
-checklists_path: "{installed_path}/checklists"
-
-# State management
-state_file: "{sprint_artifacts}/super-dev-state-{{story_id}}.yaml"
-audit_trail: "{sprint_artifacts}/audit-super-dev-{{story_id}}-{{date}}.yaml"
-
-# Auto-create story settings (NEW v1.4.0)
-# When story is missing or lacks proper context, auto-invoke /create-story-with-gap-analysis
-auto_create_story:
- enabled: true # Set to false to revert to old HALT behavior
- create_story_workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story-with-gap-analysis"
- triggers:
- - story_not_found # Story file doesn't exist
- - no_tasks # Story exists but has no tasks
- - missing_sections # Story missing required sections (Tasks, Acceptance Criteria)
-
-# Complexity level (passed from batch-super-dev or set manually)
-# Controls which pipeline steps to execute
-complexity_level: "standard" # micro | standard | complex
-
-# Complexity-based step skipping (NEW v1.2.0)
-complexity_routing:
- micro:
- skip_steps: [2, 5] # Skip pre-gap analysis and code review
- description: "Lightweight path for simple stories (≤3 tasks, low risk)"
- standard:
- skip_steps: [] # Full pipeline
- description: "Normal path with all quality gates"
- complex:
- skip_steps: [] # Full pipeline + warnings
- description: "Enhanced path for high-risk stories"
- warn_before_start: true
- suggest_split: true
-
-# Workflow modes
-modes:
- interactive:
- description: "Human-in-the-loop with menu navigation between steps"
- checkpoint_on_failure: true
- requires_approval: true
- smart_batching: true # User can approve batching plan
- batch:
- description: "Unattended execution for batch-super-dev"
- checkpoint_on_failure: true
- requires_approval: false
- fail_fast: true
- smart_batching: true # Auto-enabled for efficiency
-
-# Smart batching configuration
-smart_batching:
- enabled: true
- detect_patterns: true
- default_to_safe: true # When uncertain, execute individually
- min_batch_size: 3 # Minimum tasks to form a batch
- fallback_on_failure: true # Revert to individual if batch fails
-
- # Batchable pattern definitions
- batchable_patterns:
- - pattern: "package_installation"
- keywords: ["Add", "package.json", "npm install", "dependency"]
- risk_level: "low"
- validation: "npm install && npm run build"
-
- - pattern: "module_registration"
- keywords: ["Import", "Module", "app.module", "register"]
- risk_level: "low"
- validation: "tsc --noEmit"
-
- - pattern: "code_deletion"
- keywords: ["Delete", "Remove", "rm ", "unlink"]
- risk_level: "low"
- validation: "npm test && npm run build"
-
- - pattern: "import_update"
- keywords: ["Update import", "Change import", "import from"]
- risk_level: "low"
- validation: "npm run build"
-
- # Non-batchable pattern definitions (always execute individually)
- individual_patterns:
- - pattern: "business_logic"
- keywords: ["circuit breaker", "fallback", "caching for", "strategy"]
- risk_level: "medium"
-
- - pattern: "security"
- keywords: ["auth", "permission", "security", "encrypt"]
- risk_level: "high"
-
- - pattern: "data_migration"
- keywords: ["migration", "schema", "ALTER TABLE", "database"]
- risk_level: "high"
-
-# Agent role definitions (loaded once, switched as needed)
-agents:
- dev:
- name: "Developer"
- persona: "{project-root}/_bmad/bmm/agents/dev.md"
- description: "Pre-gap, implementation, post-validation, code review"
- used_in_steps: [2, 3, 4, 5]
- sm:
- name: "Scrum Master"
- persona: "{project-root}/_bmad/bmm/agents/sm.md"
- description: "Story completion and status"
- used_in_steps: [6]
-
-# Step file definitions
-steps:
- - step: 1
- file: "{steps_path}/step-01-init.md"
- name: "Initialize"
- description: "Load story context and detect development mode"
- agent: null
- quality_gate: false
-
- - step: 2
- file: "{steps_path}/step-02-pre-gap-analysis.md"
- name: "Pre-Gap Analysis"
- description: "Validate tasks against codebase (critical for brownfield)"
- agent: dev
- quality_gate: true
-
- - step: 3
- file: "{steps_path}/step-03-implement.md"
- name: "Implement"
- description: "Adaptive implementation (TDD for new, refactor for existing)"
- agent: dev
- quality_gate: true
-
- - step: 4
- file: "{steps_path}/step-04-post-validation.md"
- name: "Post-Validation"
- description: "Verify completed tasks against codebase reality"
- agent: dev
- quality_gate: true
- iterative: true # May re-invoke step 3 if gaps found
-
- - step: 5
- file: "{steps_path}/step-05-code-review.md"
- name: "Code Review"
- description: "Adversarial code review finding 3-10 issues"
- agent: dev
- quality_gate: true
-
- - step: 6
- file: "{steps_path}/step-06-complete.md"
- name: "Complete"
- description: "Commit and push changes"
- agent: sm
- quality_gate: false
-
- - step: 7
- file: "{steps_path}/step-07-summary.md"
- name: "Summary"
- description: "Generate audit trail"
- agent: null
- quality_gate: false
-
-# Quality gates
-quality_gates:
- pre_gap_analysis:
- step: 2
- criteria:
- - "All tasks validated or refined"
- - "No missing context"
- - "Implementation path clear"
-
- implementation:
- step: 3
- criteria:
- - "All tasks completed"
- - "Tests pass"
- - "Code follows project patterns"
-
- post_validation:
- step: 4
- criteria:
- - "All completed tasks verified against codebase"
- - "Zero false positives remaining"
- - "Files/functions/tests actually exist"
-
- code_review:
- step: 5
- criteria:
- - "3-10 specific issues identified"
- - "All issues resolved or documented"
- - "Security review complete"
-
-# Document loading strategies
-input_file_patterns:
- story:
- description: "Story file being developed"
- pattern: "{sprint_artifacts}/story-*.md"
- load_strategy: "FULL_LOAD"
- cache: true
-
- project_context:
- description: "Critical rules and patterns"
- pattern: "**/project-context.md"
- load_strategy: "FULL_LOAD"
- cache: true
-
-standalone: true