diff --git a/GSDMAD-ARCHITECTURE.md b/GSDMAD-ARCHITECTURE.md index fe52bf82..61e1c538 100644 --- a/GSDMAD-ARCHITECTURE.md +++ b/GSDMAD-ARCHITECTURE.md @@ -394,7 +394,7 @@ validation: fixer: {steps: [8,9]} ``` -### Enhanced: `super-dev-pipeline-v2.md` +### Enhanced: `super-dev-pipeline.md` ```yaml execution_mode: "multi_agent" # single_agent | multi_agent @@ -488,7 +488,7 @@ agents: --- **Next Steps:** -1. Create `super-dev-pipeline-v2/` directory +1. Create `super-dev-pipeline/` directory 2. Write agent prompt files 3. Update `batch-super-dev` for wave execution 4. Test on Epic 17 stories diff --git a/package.json b/package.json index 1c882204..247c2371 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "$schema": "https://json.schemastore.org/package.json", "name": "@jonahschulte/bmad-method", - "version": "6.0.0-Beta.3", + "version": "6.0.0-Beta.4", "description": "Breakthrough Method of Agile AI-driven Development (Enhanced with TDD, intelligent multi-agent review, and production-hardened enforcement)", "keywords": [ "agile", 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 8aca62d1..122750d3 100644 --- a/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml +++ b/src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml @@ -1,4 +1,4 @@ -name: super-dev-pipeline-v2 +name: super-dev-pipeline description: "Multi-agent pipeline with wave-based execution, independent validation, and adversarial code review (GSDMAD)" author: "BMAD Method + GSD" version: "2.0.0" @@ -14,7 +14,7 @@ communication_language: "{config_source}:communication_language" date: system-generated # Workflow paths -installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline-v2" +installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline" agents_path: "{installed_path}/agents" steps_path: "{installed_path}/steps" diff --git a/src/modules/bmm/workflows/4-implementation/batch-super-dev/instructions.md b/src/modules/bmm/workflows/4-implementation/batch-super-dev/instructions.md index 71d21d0e..79d8c72f 100644 --- a/src/modules/bmm/workflows/4-implementation/batch-super-dev/instructions.md +++ b/src/modules/bmm/workflows/4-implementation/batch-super-dev/instructions.md @@ -889,71 +889,35 @@ QUALITY OVER SPEED: Taking time to ensure correctness. -**Choose execution strategy:** +**How should these stories be processed?** -{{#if waves.length > 1}} -[W] WAVE-BASED PARALLEL (Recommended) - - Respects dependencies between stories - - Runs independent stories in parallel within each wave - - Wave 1: {{wave_1_stories}} → Wave 2: {{wave_2_stories}} → ... - - Estimated time: {{wave_time}} ({{savings}}% faster than sequential) - - Safer than full parallel (honors dependencies) -{{/if}} +Options: +- **S**: Sequential - Run stories one-by-one (Task agent finishes before next starts) +- **P**: Parallel - Run stories concurrently (Multiple Task agents running simultaneously) -[S] SEQUENTIAL - - Process stories one-by-one in this session - - Easier to monitor and debug - - Estimated time: {{sequential_time}} - - Best for: When you want full control +**Note:** Both modes use Task agents to keep story context out of the main thread. +The only difference is the number running at once. -{{#if waves.length == 1}} -[P] FULL PARALLEL (All {{count}} stories) - - All stories independent, no dependencies - - Spawn {{count}} agents concurrently - - Estimated time: {{parallel_time}} ({{savings}}% faster) -{{else}} -[P] FULL PARALLEL (Ignore dependencies - RISKY) - - Spawn all {{count}} agents concurrently - - ⚠️ May fail if stories depend on each other - - Use only if you're certain dependencies are wrong -{{/if}} - -Enter: {{#if waves.length > 1}}w{{/if}}/s/p +Enter: S or P Capture response as: execution_strategy - - Set execution_mode = "wave_based" - Set use_task_agents = true - Set wave_execution = true - -✅ Wave-Based Parallel Execution Selected - -Execution plan: -{{#each waves}} -Wave {{@index}}: {{count}} stories{{#if @index > 0}} (after Wave {{@index - 1}} completes){{/if}} -{{#each stories}} - - {{story_key}} -{{/each}} -{{/each}} - -Estimated time: {{wave_time}} ({{savings}}% faster than sequential) - - - Set execution_mode = "sequential" Set parallel_count = 1 - Set use_task_agents = false - Set wave_execution = false - ✅ Sequential mode selected - stories will be processed one-by-one in this session + Set use_task_agents = true + +⏺ ✅ Sequential mode selected - stories will be processed one-by-one + +Each story runs in its own Task agent. Agents execute sequentially (one completes before next starts). +This keeps the main thread clean while maintaining easy monitoring. + - Set execution_mode = "full_parallel" + Set execution_mode = "parallel" Set use_task_agents = true - Set wave_execution = false **How many agents should run in parallel?** @@ -975,26 +939,33 @@ Enter number (2-10) or 'all': ⚠️ Requested {{original_count}} agents, capped at 10 (safety limit) + + +⏺ ✅ Parallel mode selected - {{parallel_count}} Task agents will run concurrently + +Each story runs in its own Task agent. Multiple agents execute in parallel for faster completion. + ## ⚙️ Execution Plan **Mode:** {{execution_mode}} -{{#if use_task_agents}} -**Task Agents:** {{parallel_count}} running concurrently +**Task Agents:** {{parallel_count}} {{#if parallel_count > 1}}running concurrently{{else}}running sequentially{{/if}} **Agent Type:** general-purpose (autonomous) -{{else}} -**Sequential processing** in current session -{{/if}} **Stories to process:** {{count}} **Estimated total time:** -{{#if use_task_agents}} +{{#if parallel_count > 1}} - With {{parallel_count}} agents: {{estimated_hours / parallel_count}} hours {{else}} - Sequential: {{estimated_hours}} hours {{/if}} + +**Complexity Routing:** +{{#each stories_by_complexity}} +- {{complexity}}: {{count}} stories ({{pipeline_description}}) +{{/each}} Confirm execution plan? (yes/no): @@ -1009,16 +980,16 @@ Enter number (2-10) or 'all': Initialize counters: completed=0, failed=0, failed_stories=[], reconciliation_warnings=[], reconciliation_warnings_count=0 Set start_time = current timestamp - - Jump to Step 4-Wave (Wave-based execution) + + Jump to Step 4-Sequential (Task agents, one at a time) - - Jump to Step 4-Parallel (Full parallel execution) + + Jump to Step 4-Wave (Task agents, wave-based parallel) - - Continue to Step 4-Sequential (In-session execution) + + Jump to Step 4-Parallel (Task agents, multiple concurrent) @@ -1028,98 +999,302 @@ Enter number (2-10) or 'all': 🚀 WAVE-BASED PARALLEL PROCESSING STARTED ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Stories:** {{count}} -**Mode:** Wave-based (respects dependencies) -**Waves:** {{waves.length}} +**Total waves:** {{waves.length}} +**Mode:** Task agents (parallel by wave) +**Max concurrent agents:** {{parallel_count}} **Continue on failure:** {{continue_on_failure}} +**Pattern:** Wave barrier (complete wave before next wave) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + +📊 **Wave Plan (from dependency analysis):** +{{#each waves}} +Wave {{@index}}: {{count}} stories +{{#each stories}} + - {{story_key}}{{#if depends_on}} [depends on: {{depends_on}}]{{/if}} +{{/each}} +{{/each}} - For each wave in sequence: + Set abort_batch = false - + For each wave in waves (in order): + + ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -📦 Wave {{wave_num}}/{{waves.length}} ({{stories_in_wave}} stories) +🌊 STARTING WAVE {{@index}} ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -{{#each stories_in_wave}} - - {{story_key}} +Stories in this wave: +{{#each stories}} + - {{story_key}}{{#if depends_on}} (depends on: {{depends_on}}){{/if}} {{/each}} - -Spawning {{stories_in_wave.length}} parallel agents... +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - Spawn Task agents in PARALLEL (send all in single message): + Initialize wave worker pool state: + + - wave_queue = stories + - Resolve wave_queue items to full story objects by matching story_key in selected_stories (include complexity_level, story_file_path) + - active_workers = {} (map of worker_id → {story_key, task_id, started_at}) + - completed_wave_stories = [] + - failed_wave_stories = [] + - next_story_index = 0 + - max_workers = min(parallel_count, wave_queue.length) + + - For each story in this wave: + + +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +🔧 Initializing {{max_workers}} worker slots for Wave {{@index}}... +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + + + Spawn first {{max_workers}} agents (or fewer if less stories): + + While next_story_index < min(max_workers, wave_queue.length): - Task tool: + story_key = wave_queue[next_story_index].story_key + complexity_level = wave_queue[next_story_index].complexity_level + story_file_path = wave_queue[next_story_index].story_file_path + worker_id = next_story_index + 1 + + Spawn Task agent: - subagent_type: "general-purpose" - description: "Implement story {{story_key}}" - - prompt: "Execute super-dev-pipeline for story {{story_key}}. + - prompt: "Execute super-dev-pipeline workflow for story {{story_key}}. Story file: docs/sprint-artifacts/{{story_key}}.md Complexity: {{complexity_level}} - Mode: batch, wave {{wave_num}} + Mode: batch - Follow all 11 steps, commit when complete, report status." - - Store agent_id + Load workflow: /Users/jonahschulte/git/BMAD-METHOD/src/modules/bmm/workflows/4-implementation/super-dev-pipeline + Follow the multi-agent pipeline (builder, inspector, reviewer, fixer). + Commit when complete, update story status, report results." + - run_in_background: true (non-blocking) + + Store in active_workers[worker_id]: + story_key: {{story_key}} + task_id: {{returned_task_id}} + started_at: {{timestamp}} + status: "running" - Wait for ALL agents in this wave to complete + Increment next_story_index + 🚀 Worker {{worker_id}} started: {{story_key}} + - For each completed agent in wave: + + WAVE BARRIER: Complete all stories in this wave before starting next wave - - ✅ Wave {{wave_num}} - Story complete: {{story_key}} - Increment completed counter - Execute Step 4.5: Reconciliation + While active_workers.size > 0 OR next_story_index < wave_queue.length: + + Poll for completed workers (check task outputs non-blocking): + + For each worker_id in active_workers: + + Check if worker task completed using TaskOutput(task_id, block=false) + + + Continue to next worker (don't wait) - - ❌ Wave {{wave_num}} - Story failed: {{story_key}} - Increment failed counter - Add to failed_stories list + + Get worker details: story_key = active_workers[worker_id].story_key - - ⚠️ Stopping all waves due to failure - Jump to Step 5 (Summary) + ✅ Worker {{worker_id}} completed: {{story_key}} + + Execute Step 4.5: Smart Story Reconciliation + Load reconciliation instructions: {installed_path}/step-4.5-reconcile-story-status.md + Execute reconciliation with story_key={{story_key}} + + 🚨 MANDATORY RECONCILIATION AUTO-FIX - MAKE IT RIGHT + Verify reconciliation by checking story file: + 1. Re-read story file: {{story_file_path}} + 2. Count checked tasks vs total tasks + 3. Check Dev Agent Record filled + + + +❌ Story {{story_key}}: Agent FAILED to update story file + +Checked tasks: {{checked_tasks}}/{{total_tasks}} +Dev Agent Record: {{dev_agent_record_status}} + +🔧 EXECUTING AUTO-FIX RECONCILIATION... + + + AUTO-FIX PROCEDURE: + 1. Read agent's commit to see what files were created/modified + 2. Read story Tasks section to see what was supposed to be built + 3. For each task, check if corresponding code exists in commit + 4. If code exists, check off the task using Edit tool + 5. Fill in Dev Agent Record with commit details + 6. Verify fixes worked (re-count checked tasks) + + + ✅ AUTO-FIX SUCCESS: {{checked_tasks}}/{{total_tasks}} tasks now checked + Continue with story completion + + + + +❌ AUTO-FIX FAILED: Cannot reconcile story {{story_key}} + +After auto-fix attempts: +- Checked tasks: {{checked_tasks}}/{{total_tasks}} +- Dev Agent Record: {{dev_agent_record_status}} + +**Agent produced code but story file cannot be updated.** + +Marking story as "in-progress" (not done) and continuing with warnings. + + Override story status to "in-progress" + Add to reconciliation_warnings with detailed diagnostic + Continue (do NOT kill workers) + + + + + ✅ COMPLETED: {{story_key}} (reconciled and verified) + Tasks: {{checked_tasks}}/{{total_tasks}} ({{task_completion_pct}}%) + Increment completed counter + Add to completed_wave_stories + + + + ⚠️ WARNING: {{story_key}} - Low completion ({{task_completion_pct}}%) + Add to reconciliation_warnings: {story_key: {{story_key}}, warning_message: "Only {{task_completion_pct}}% tasks checked - manual verification needed"} + + + Remove worker_id from active_workers (free the slot) + + IMMEDIATELY refill slot if stories remain in this wave: + + story_key = wave_queue[next_story_index].story_key + complexity_level = wave_queue[next_story_index].complexity_level + story_file_path = wave_queue[next_story_index].story_file_path + + 🔄 Worker {{worker_id}} refilled: {{story_key}} + + Spawn new Task agent for this worker_id (same parameters as init) + Update active_workers[worker_id] with new task_id and story_key + Increment next_story_index + + Get worker details: story_key = active_workers[worker_id].story_key + + ❌ Worker {{worker_id}} failed: {{story_key}} + + Increment failed counter + Add story_key to failed_stories list + Add to failed_wave_stories + Remove worker_id from active_workers (free the slot) + + + ⚠️ Stopping wave and batch due to failure (continue_on_failure=false) + Kill all active workers + Clear active_workers + Set abort_batch = true + Break worker pool loop + + + + story_key = wave_queue[next_story_index].story_key + complexity_level = wave_queue[next_story_index].complexity_level + story_file_path = wave_queue[next_story_index].story_file_path + + 🔄 Worker {{worker_id}} refilled: {{story_key}} (despite previous failure) + + Spawn new Task agent for this worker_id + Update active_workers[worker_id] with new task_id and story_key + Increment next_story_index + + + + + Break worker pool loop + + + Display live progress every 30 seconds: -Wave {{wave_num}} complete: {{completed_in_wave}} succeeded, {{failed_in_wave}} failed +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +📊 Live Progress (Wave {{@index}} - {{timestamp}}) +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +✅ Completed: {{completed}} +❌ Failed: {{failed}} +🔄 Active workers: {{active_workers.size}} +📋 Queued in wave: {{wave_queue.length - next_story_index}} +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + + Sleep 5 seconds before next poll (prevents tight loop) + + + ⛔ Aborting remaining waves due to failure and continue_on_failure=false + Jump to Step 5 (Summary) + + + +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +✅ WAVE {{@index}} COMPLETE +Stories completed: {{completed_wave_stories.length}} +Stories failed: {{failed_wave_stories.length}} +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + + After all waves processed, jump to Step 5 (Summary) - + ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🚀 SEQUENTIAL BATCH PROCESSING STARTED ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Stories:** {{count}} -**Mode:** super-dev-pipeline (batch, sequential) +**Mode:** Task agents (sequential, one at a time) **Continue on failure:** {{continue_on_failure}} ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ For each story in selected_stories: - + ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📦 Story {{current_index}}/{{total_count}}: {{story_key}} ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + +Complexity: {{complexity_level}} +Pipeline: {{#if complexity_level == 'micro'}}Lightweight (skip tests, skip review){{else if complexity_level == 'standard'}}Full quality gates{{else}}Enhanced validation{{/if}} + +Spawning Task agent... - Invoke workflow: /bmad:bmm:workflows:super-dev-pipeline - Parameters: mode=batch, story_key={{story_key}}, complexity_level={{story_key}}.complexity.level + + Use Task tool to spawn agent: + - subagent_type: "general-purpose" + - description: "Implement story {{story_key}}" + - prompt: "Execute super-dev-pipeline workflow for story {{story_key}}. - + Story file: docs/sprint-artifacts/{{story_key}}.md + Complexity: {{complexity_level}} + Mode: batch + + Load workflow: /Users/jonahschulte/git/BMAD-METHOD/src/modules/bmm/workflows/4-implementation/super-dev-pipeline + Follow the multi-agent pipeline (builder, inspector, reviewer, fixer). + Commit when complete, update story status, report results." + - Store agent_id + + + WAIT for agent to complete (blocking call) + + ✅ Implementation complete: {{story_key}} Execute Step 4.5: Smart Story Reconciliation @@ -1337,15 +1512,13 @@ Press [C] to continue or [P] to pause: - description: "Implement story {{story_key}}" - prompt: "Execute super-dev-pipeline workflow for story {{story_key}}. - CRITICAL INSTRUCTIONS: - 1. Load workflow.xml: _bmad/core/tasks/workflow.xml - 2. Load workflow config: _bmad/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml - 3. Execute in BATCH mode with story_key={{story_key}} and complexity_level={{story_key}}.complexity.level - 4. Follow all 7 pipeline steps (init, pre-gap, implement, post-validate, code-review, complete, summary) - 5. Commit changes when complete - 6. Report final status (done/failed) with file list + Story file: docs/sprint-artifacts/{{story_key}}.md + Complexity: {{complexity_level}} + Mode: batch - Story file will be auto-resolved from multiple naming conventions." + Load workflow: /Users/jonahschulte/git/BMAD-METHOD/src/modules/bmm/workflows/4-implementation/super-dev-pipeline + Follow the multi-agent pipeline (builder, inspector, reviewer, fixer). + Commit when complete, update story status, report results." - run_in_background: true (non-blocking - critical for semaphore pattern) Store in active_workers[worker_id]: diff --git a/src/modules/bmm/workflows/4-implementation/multi-agent-review/workflow.yaml b/src/modules/bmm/workflows/4-implementation/multi-agent-review/workflow.yaml index 668154c4..d372490e 100644 --- a/src/modules/bmm/workflows/4-implementation/multi-agent-review/workflow.yaml +++ b/src/modules/bmm/workflows/4-implementation/multi-agent-review/workflow.yaml @@ -15,7 +15,7 @@ instructions: "{installed_path}/instructions.md" # Input parameters story_id: "{story_id}" # Required -story_file: "{sprint_artifacts}/{story_id}.md" # CANONICAL FORMAT: epic-story-slug.md (NO "story-" prefix) +story_file: "{sprint_artifacts}/{story_id}.md" # CANONICAL FORMAT: epic-story-slug.md (NO "story-" prefix) base_branch: "main" # Optional: branch to compare against complexity_level: "standard" # micro | standard | complex (passed from super-dev-pipeline) @@ -54,4 +54,4 @@ review_settings: # Output review_report: "{sprint_artifacts}/review-{story_id}-multi-agent.md" -standalone: true \ No newline at end of file +standalone: true diff --git a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/README.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/README.md deleted file mode 100644 index 770ec6ad..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/README.md +++ /dev/null @@ -1,135 +0,0 @@ -# Super-Dev-Pipeline v2.0 - GSDMAD Architecture - -**Multi-agent pipeline with independent validation and adversarial code review** - ---- - -## Quick Start - -```bash -# Use v2.0 for a story -/super-dev-pipeline mode=multi_agent story_key=17-10 - -# Use v1.x (fallback) -/super-dev-pipeline mode=single_agent story_key=17-10 -``` - ---- - -## What's New in v2.0 - -### Multi-Agent Validation -- **4 independent agents** instead of 1 -- 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 - ---- - -## Architecture - -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 - ---- - -## Why v2.0? - -### The Problem with v1.x - -Single agent does ALL steps: -1. Implement code -2. Validate own work ← Conflict of interest -3. Review own code ← Even worse -4. Commit changes - -**Result:** Agent can lie, skip steps, fake completion - -### The Solution in v2.0 - -Separate agents for each phase: -1. Builder implements (no validation) -2. Inspector validates (fresh context, no knowledge of Builder) -3. Reviewer reviews (adversarial, wants to find issues) -4. Fixer fixes (addresses review findings) -5. Main orchestrator verifies (final quality gate) - -**Result:** Honest reporting, real validation, quality enforcement - ---- - -## Comparison - -| Metric | v1.x | v2.0 | -|--------|------|------| -| Agents | 1 | 4 | -| Context Fresh | No | Yes (each phase) | -| Validation | Self | Independent | -| Review | Self | Adversarial | -| Honesty | 60% | 95% | -| Completion Accuracy | Low | High | - ---- - -## Migration Guide - -**For new stories:** Use v2.0 by default -**For existing workflows:** Keep v1.x until tested - -**Testing v2.0:** -1. Run on 3-5 stories -2. Compare results with v1.x -3. Measure time and quality -4. Make v2.0 default after validation - ---- - -## Files in This Directory - -``` -super-dev-pipeline-v2/ -├── 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 from v1.x, adapted for multi-agent) -``` - ---- - -## Next Steps - -1. **Test v2.0** on Epic 18 stories -2. **Measure improvements** (time, quality, honesty) -3. **Refine agent prompts** based on results -4. **Make v2.0 default** after validation -5. **Deprecate v1.x** in 6 months - ---- - -**Philosophy:** Trust but verify. Every agent's work is independently validated by a fresh agent with no conflict of interest. diff --git a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/workflow.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/workflow.md deleted file mode 100644 index 4661e553..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/workflow.md +++ /dev/null @@ -1,375 +0,0 @@ -# Super-Dev-Pipeline v2.0 - Multi-Agent Architecture - -**Version:** 2.0.0 -**Architecture:** GSDMAD (GSD + BMAD) -**Philosophy:** Trust but verify, separation of concerns - ---- - -## Overview - -This workflow implements a story using **4 independent agents** with external validation at each phase. - -**Key Innovation:** Each agent has single responsibility and fresh context. No agent validates its own work. - ---- - -## Execution Flow - -``` -┌─────────────────────────────────────────────────────────────┐ -│ 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 -``` - ---- - -## Agent Spawning Instructions - -### Phase 1: Spawn Builder - -```javascript -Task({ - subagent_type: "general-purpose", - description: "Implement story {{story_key}}", - prompt: ` - You are the BUILDER agent for story {{story_key}}. - - Load and execute: {agents_path}/builder.md - - Story file: {{story_file}} - - Complete Steps 1-4: - 1. Init - Load story - 2. Pre-Gap - Analyze what exists - 3. Write Tests - TDD approach - 4. Implement - Write production code - - 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.** - ---- - -## Final Verification (Main Orchestrator) - -**After all agents complete, verify:** - -```bash -# 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" -``` - ---- - -## 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" - } - ] -} -``` - -**Benefits:** -- Resume interrupted sessions -- Track agent performance -- Debug failed pipelines -- Audit trail - ---- - -## Error Handling - -**If Builder fails:** -- Don't spawn Inspector -- Report failure to user -- Option to resume or retry - -**If Inspector fails:** -- Don't spawn Reviewer -- Report specific failures -- Resume Builder to fix issues - -**If Reviewer finds CRITICAL issues:** -- Must spawn Fixer (not optional) -- Cannot mark story complete until fixed - -**If Fixer fails:** -- Report unfixed issues -- Cannot mark story complete -- Manual intervention required - ---- - -## Comparison: v1.x vs v2.0 - -| 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) | - ---- - -## Migration from v1.x - -**Backward Compatibility:** -```yaml -execution_mode: "single_agent" # Use v1.x -execution_mode: "multi_agent" # Use v2.0 (new) -``` - -**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 - ---- - -## Hospital-Grade Standards - -⚕️ **Lives May Be at Stake** - -- Independent validation catches errors -- Adversarial review finds security flaws -- Multiple checkpoints prevent shortcuts -- Final verification prevents false completion - -**QUALITY >> SPEED** - ---- - -**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/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/workflow.yaml b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/workflow.yaml deleted file mode 100644 index 8aca62d1..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/workflow.yaml +++ /dev/null @@ -1,121 +0,0 @@ -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" -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-v2" -agents_path: "{installed_path}/agents" -steps_path: "{installed_path}/steps" - -# 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" - -# 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 - - 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 - -# Complexity routing -complexity_routing: - micro: - 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_agents: [] # Full pipeline - description: "Balanced path for medium-risk stories" - examples: ["API endpoints", "business logic"] - - complex: - skip_agents: [] # Full pipeline + enhanced review - description: "Enhanced validation for high-risk stories" - examples: ["Auth", "payments", "security", "migrations"] - review_focus: ["security", "performance", "architecture"] - -# Final verification checklist (main orchestrator) -final_verification: - enabled: true - checks: - - name: "git_commits" - command: "git log --oneline -3 | grep {{story_key}}" - failure_message: "No commit found for {{story_key}}" - - - 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" - - - name: "sprint_status" - command: "git diff HEAD~1 {{sprint_status}} | grep '{{story_key}}'" - failure_message: "Sprint status not updated" - - - 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" - -# 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/modules/bmm/workflows/4-implementation/super-dev-pipeline/ALL-STEPS-EMBEDDED.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/ALL-STEPS-EMBEDDED.md deleted file mode 100644 index e6edbe2a..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/ALL-STEPS-EMBEDDED.md +++ /dev/null @@ -1,4226 +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 ---- -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 ---- -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). ---- -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.** ---- -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. ---- -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. ---- -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 ---- -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). ---- -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! ---- -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 ---- -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/modules/bmm/workflows/4-implementation/super-dev-pipeline/IMPLEMENTATION-PLAN.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/IMPLEMENTATION-PLAN.md deleted file mode 100644 index b683ce3b..00000000 --- a/src/modules/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/modules/bmm/workflows/4-implementation/super-dev-pipeline/MULTI-AGENT-ARCHITECTURE.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/MULTI-AGENT-ARCHITECTURE.md deleted file mode 100644 index dc5e9a80..00000000 --- a/src/modules/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/modules/bmm/workflows/4-implementation/super-dev-pipeline/PLAYBOOK-DESIGN.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/PLAYBOOK-DESIGN.md deleted file mode 100644 index dc4fb02a..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/PLAYBOOK-DESIGN.md +++ /dev/null @@ -1,436 +0,0 @@ -# Playbook System Design - Automated Learning Feedback Loop - -**Version:** 1.6.0 -**Purpose:** Build cumulative project intelligence that prevents repeated mistakes - ---- - -## Core Principle - -**Playbooks are NOT general advice. They are SPECIFIC, ACTIONABLE learnings extracted from YOUR codebase.** - -**Bad Playbook Entry:** -```markdown -✅ Follow best practices for database migrations -``` - -**Good Playbook Entry:** -```markdown -✅ Use `date +%Y` before creating migrations (2026, not 2025) - Reason: Migration 20250125_init sorts BEFORE 20260122_add_users (alphabetical) - Story: 18-1 (made this mistake, fixed with new migration) - Prevention: grep "^20[0-9]\{6\}" migrations/ | sort | tail -1 # Check newest -``` - ---- - -## Playbook Structure - -### Required Sections - -**1. Metadata (Frontmatter)** -```yaml ---- -technology: prisma # or domain: billing -keywords: [migration, schema, enum, postgres] -source_stories: [18-1, 18-4, 17-5] # Stories that contributed -last_updated: 2026-01-26 -pattern_count: 12 -pitfall_count: 8 ---- -``` - -**2. Best Practices** (What Worked) -- Specific actions with bash commands -- Why it works (brief explanation) -- Source story reference -- When to apply - -**3. Common Pitfalls** (Mistakes Made & Fixed) -- Exact error message -- Root cause -- Fix applied -- Prevention code/check - -**4. Code Patterns** (Reusable Snippets) -- Actual code from implementation (not made-up examples) -- Source file path -- When to use / when NOT to use -- Test coverage example - -**5. Lessons Learned** (Insights) -- What we thought would work -- What actually worked -- Why the difference matters -- How approach changed - ---- - -## Keyword System - -### Keyword Types - -**Technology Keywords** (tools/frameworks): -- Database ORM name (prisma, sequelize, typeorm) -- Payment processor (stripe, paypal) -- Cache (redis, memcached) -- Queue (sqs, rabbitmq, bull) -- Auth provider (cognito, auth0, clerk) - -**Domain Keywords** (business areas): -- Extracted from YOUR epics (billing, rental, submission, jury, etc.) -- Not generic (not just "crud" or "api") -- Specific to your product - -**Pattern Keywords** (architecture): -- state-machine -- cron -- webhook -- idempotency -- soft-delete -- multi-tenant - -### Keyword Extraction Rules - -**From Story Title:** -```bash -# Extract nouns that are likely technologies or domains -story_title=$(grep "^# Story" "$story_file" | head -1) -# Example: "Story 18.1: Charge Model & State Machine" -# Keywords: charge, model, state-machine -``` - -**From Task Descriptions:** -```bash -# Look for mentions of: -# - File paths (lib/billing → billing) -# - Function names (createCharge → charge, create) -# - Technology names (Prisma, Stripe, SQS) -``` - -**From Files Changed:** -```bash -git diff --name-only HEAD~1 HEAD | \ - grep -oE "[a-z-]+/" | \ - tr -d '/' | \ - sort -u -# Example: lib/billing/file.ts → billing -``` - ---- - -## Step 1b: Load Playbooks (Refined) - -### Precision Loading - -**Don't load everything. Load only what's relevant.** - -```bash -# 1. Extract 3-5 primary keywords from story -primary_keywords=$(analyze_story_for_keywords "$story_file" | head -5) - -# 2. For each primary keyword -for keyword in $primary_keywords; do - playbook="${playbook_dir}/${keyword}-playbook.md" - - if [ -f "$playbook" ]; then - # 3. Read playbook frontmatter - pattern_count=$(grep "^pattern_count:" "$playbook" | cut -d: -f2) - source_stories=$(grep "^source_stories:" "$playbook" | cut -d: -f2) - - echo "📚 Loading: ${keyword}-playbook.md" - echo " Patterns: $pattern_count | Source: $source_stories" - - # 4. Extract ONLY relevant sections (not entire file) - # - Best Practices (top 5) - # - Common Pitfalls (top 3) - # - Most recent Code Pattern - - # 5. Present concisely to agent - else - echo "ℹ️ No playbook for: $keyword (will create if patterns emerge)" - fi -done -``` - -### What Gets Loaded - -**Format for agent consumption:** - -```markdown -📚 **Playbook: {keyword}** - -🎯 **Top 3 Practices:** -1. {Specific action with command} -2. {Specific pattern with example} -3. {Specific check with verification} - -⚠️ **Top 2 Pitfalls:** -1. {Specific mistake with prevention} -2. {Specific error with fix} - -💡 **Latest Pattern** (from Story {story-key}): -```{language} -{10-20 lines of actual code} -``` -When: {specific use case} -``` - -**Keep it focused.** Agent doesn't need entire playbook, just highlights. - ---- - -## Step 12: Extract Learnings (Refined) - -### Precision Extraction - -**Extract ONLY from successful, clean implementations.** - -```bash -# Quality gate: Only extract if story meets standards -checked_tasks=$(grep -c "^- \[x\]" "$story_file") -total_tasks=$(grep -c "^- \[[x ]\]" "$story_file") -completion_pct=$((checked_tasks * 100 / total_tasks)) - -if [ "$completion_pct" -lt 80 ]; then - echo "⏭️ Skipping learning extraction (only $completion_pct% complete)" - exit 0 -fi - -# Check if code review found critical issues -if [ -f "docs/sprint-artifacts/review-${story_key}.md" ]; then - critical_count=$(grep -c "CRITICAL" "docs/sprint-artifacts/review-${story_key}.md") - - if [ "$critical_count" -gt 0 ]; then - echo "⏭️ Skipping learning extraction ($critical_count critical issues found)" - exit 0 - fi -fi - -echo "✅ Story meets quality standards - extracting learnings" -``` - -### What to Extract - -**1. Code Patterns (from git diff)** - -```bash -commit_hash=$(git log --oneline --grep="$story_key" | head -1 | awk '{print $1}') - -# Get functions added in this commit -new_functions=$(git show "$commit_hash" | \ - grep "^+.*export.*function\|^+.*export const" | \ - sed 's/^+//' | head -10) - -# For each function: -# - Extract function signature -# - Get 5 lines before + 20 lines after (full function) -# - Add to Code Patterns section of playbook -# - Include source file path -# - Include story reference -``` - -**2. Pitfalls (from code review fixes)** - -```bash -review_file="docs/sprint-artifacts/review-${story_key}.md" - -if [ -f "$review_file" ]; then - # Extract HIGH and CRITICAL issues that were fixed - issues=$(grep -A 10 "^## Issue #" "$review_file" | \ - grep -E "Severity: (HIGH|CRITICAL)" -B 5) - - # For each issue: - # - Extract: Problem description - # - Extract: Fix that was applied - # - Create pitfall entry with prevention code -fi -``` - -**3. Best Practices (from successful implementation)** - -```bash -# If story completed with: -# - All tests passing -# - Zero critical review issues -# - High task completion (>90%) - -# Extract: -# - Testing approach (test count, coverage %) -# - File structure chosen -# - Naming conventions used -# - Patterns that worked well -``` - -### Playbook Update Algorithm - -```bash -keyword="prisma" # Example -playbook_file="${playbook_dir}/${keyword}-playbook.md" - -if [ ! -f "$playbook_file" ]; then - # Create new playbook from template - cat > "$playbook_file" <> "$playbook_file" <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 +# Use v2.0 for a story +/super-dev-pipeline mode=multi_agent story_key=17-10 + +# Use v1.x (fallback) +/super-dev-pipeline mode=single_agent story_key=17-10 +``` + +--- + +## What's New in v2.0 + +### Multi-Agent Validation +- **4 independent agents** instead of 1 +- 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 + +--- + +## Architecture + +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 + +--- + +## Why v2.0? + +### The Problem with v1.x + +Single agent does ALL steps: +1. Implement code +2. Validate own work ← Conflict of interest +3. Review own code ← Even worse +4. Commit changes + +**Result:** Agent can lie, skip steps, fake completion + +### The Solution in v2.0 + +Separate agents for each phase: +1. Builder implements (no validation) +2. Inspector validates (fresh context, no knowledge of Builder) +3. Reviewer reviews (adversarial, wants to find issues) +4. Fixer fixes (addresses review findings) +5. Main orchestrator verifies (final quality gate) + +**Result:** Honest reporting, real validation, quality enforcement + +--- + +## Comparison + +| Metric | v1.x | v2.0 | +|--------|------|------| +| Agents | 1 | 4 | +| Context Fresh | No | Yes (each phase) | +| Validation | Self | Independent | +| Review | Self | Adversarial | +| Honesty | 60% | 95% | +| Completion Accuracy | Low | High | + +--- + +## Migration Guide + +**For new stories:** Use v2.0 by default +**For existing workflows:** Keep v1.x until tested + +**Testing v2.0:** +1. Run on 3-5 stories +2. Compare results with v1.x +3. Measure time and quality +4. Make v2.0 default after validation + +--- + +## Files in This Directory + +``` +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 from v1.x, adapted for multi-agent) +``` + +--- + +## Next Steps + +1. **Test v2.0** on Epic 18 stories +2. **Measure improvements** (time, quality, honesty) +3. **Refine agent prompts** based on results +4. **Make v2.0 default** after validation +5. **Deprecate v1.x** in 6 months + +--- + +**Philosophy:** Trust but verify. Every agent's work is independently validated by a fresh agent with no conflict of interest. diff --git a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/builder.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/builder.md similarity index 100% rename from src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/builder.md rename to src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/builder.md diff --git a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/fixer.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/fixer.md similarity index 100% rename from src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/fixer.md rename to src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/fixer.md diff --git a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/inspector.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/inspector.md similarity index 100% rename from src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/inspector.md rename to src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/inspector.md diff --git a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/reviewer.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/reviewer.md similarity index 100% rename from src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/reviewer.md rename to src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/reviewer.md diff --git a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md deleted file mode 100644 index 22f4e2e0..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md +++ /dev/null @@ -1,437 +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 (CANONICAL FORMAT ONLY) - -🚨 ONE CANONICAL NAMING FORMAT - NO VARIATIONS ALLOWED - -**Canonical Format:** `{epic}-{story_num}-{slug}.md` - -**Examples:** -- 1-1-multi-tenant-data-isolation-security.md -- 18-1-charge-model-state-machine.md -- 20-3-payment-dashboard.md - -**From input parameters:** -- `story_key`: Full key like "18-1-charge-model-state-machine" -- `story_file`: Full path (if explicitly provided) - -**If story_file not provided:** - -```bash -sprint_artifacts="{sprint_artifacts}" -story_key="{story_key}" # e.g., "18-1-charge-model-state-machine" - -# CANONICAL PATH (only one pattern): -story_file="${sprint_artifacts}/${story_key}.md" - -# Example: /path/to/docs/sprint-artifacts/18-1-charge-model-state-machine.md -``` - -**NO FALLBACKS. NO ALTERNATIVES. ONE FORMAT.** - -### 3. Verify Story Exists (Auto-Create if Missing - NEW v1.4.0) - -### 3. Verify Story File Exists (Auto-Fix Wrong Names) - -```bash -# Check if canonical file exists -if [ ! -f "$story_file" ]; then - echo "⚠️ Canonical file not found: $story_file" - echo "" - echo "🔍 Searching for wrong-named versions..." - - # Check for common wrong patterns - wrong_patterns=( - "${sprint_artifacts}/story-${story_key}.md" # story- prefix (legacy) - "${sprint_artifacts}/${epic_num}.${story_num}-*.md" # dot notation - ) - - found_wrong="" - for wrong_pattern in "${wrong_patterns[@]}"; do - if ls $wrong_pattern 2>/dev/null | head -1 | read wrong_file; then - found_wrong="$wrong_file" - break - fi - done - - if [ -n "$found_wrong" ]; then - echo "✅ Found wrong-named file: $found_wrong" - echo "🔧 AUTO-RENAMING to canonical format: $story_file" - - mv "$found_wrong" "$story_file" - - if [ -f "$story_file" ]; then - echo "✅ Renamed successfully" - else - echo "❌ Rename failed - HALT" - exit 1 - fi - else - echo "❌ No story file found (canonical OR wrong names)" - echo "" - echo "**STORY FILE REQUIRED - CANNOT VIBE CODE**" - echo "" - echo "Creating story file now..." - # Invoke create-story workflow - fi -fi - -echo "✅ Story file verified: $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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01b-load-playbooks.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01b-load-playbooks.md deleted file mode 100644 index a17bc441..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01b-load-playbooks.md +++ /dev/null @@ -1,355 +0,0 @@ -# Step 1b: Load Applicable Playbooks (Agent Reasoning) - -**Goal:** Agent reads playbook index, understands story requirements, decides which playbooks to load - ---- - -## Process - -### 1. Read Playbook Index - -**Load the playbook manifest:** - -```bash -playbook_index="{project-root}/docs/playbooks/index.md" - -if [ ! -f "$playbook_index" ]; then - echo "📚 No playbook index found - skipping (will create after first story)" - exit 0 -fi -``` - -**Index format:** - -```markdown -# Playbook Index - -## Available Playbooks - -### billing-playbook.md -**Topics:** Charge creation, payment processing, idempotency, Stripe integration -**Stories:** 18-1, 18-3, 19-4 -**Patterns:** 8 code patterns, 5 pitfalls documented -**Last Updated:** 2026-01-26 - -### state-machine-playbook.md -**Topics:** State transitions, validation rules, invalid state handling -**Stories:** 18-1, 17-8, 6-1 -**Patterns:** 4 code patterns, 3 pitfalls documented -**Last Updated:** 2026-01-25 - -### database-migration-playbook.md -**Topics:** Prisma migrations, enum handling, transaction splitting, year validation -**Stories:** 18-1, 17-5, 17-1 -**Patterns:** 6 code patterns, 8 pitfalls documented -**Last Updated:** 2026-01-26 -``` - -### 2. Read Story Requirements - -**Understand what this story is about:** - -```bash -# Read from story file: -# - Story description (user story) -# - Acceptance criteria (what to build) -# - Tasks section (how to build it) -# - Technical Requirements (constraints) - -story_description=$(sed -n '/^## Story/,/^##/p' "$story_file" | head -20) -tasks=$(sed -n '/^## Tasks/,/^##/p' "$story_file" | head -50) -technical_reqs=$(sed -n '/^## Technical Requirements/,/^##/p' "$story_file" | head -30) -``` - -### 3. Agent Decides Which Playbooks to Load - -**Reasoning prompt to agent:** - -``` -You are about to implement Story {story_key}. - -Story Description: -{story_description} - -Tasks Overview: -{first 10 tasks from story} - -Technical Requirements: -{technical_requirements} - ---- - -Available Playbooks: - -1. billing-playbook.md - Topics: Charge creation, payment processing, idempotency, Stripe integration - Patterns: 8 | Pitfalls: 5 - -2. state-machine-playbook.md - Topics: State transitions, validation rules, invalid state handling - Patterns: 4 | Pitfalls: 3 - -3. database-migration-playbook.md - Topics: Prisma migrations, enum handling, transaction splitting - Patterns: 6 | Pitfalls: 8 - -4. queue-playbook.md - Topics: SQS integration, message processing, retry logic - Patterns: 5 | Pitfalls: 4 - ---- - -QUESTION: Which playbooks (if any) are relevant to this story's implementation? - -Consider: -- What technologies will you use? (database, payment, queue, etc.) -- What patterns are needed? (state machine, cron, idempotency, etc.) -- What challenges might you face? (migrations, async processing, etc.) - -Respond with: -- Playbook filenames to load (0-3 playbooks maximum) -- Brief reason why each is relevant - -Example response: -"Load: billing-playbook.md (story involves charge creation), state-machine-playbook.md (implementing status transitions)" -``` - -### 4. Load Selected Playbooks - -**Based on agent's decision:** - -```bash -# Agent responded: "Load billing-playbook.md, state-machine-playbook.md" - -for playbook in $selected_playbooks; do - playbook_path="${playbook_dir}/${playbook}" - - echo "📖 Loading: $playbook" - - # Read playbook file - # Extract and present: - # - Top 5 Best Practices - # - Top 3 Common Pitfalls - # - Most recent Code Pattern - # (Not entire file - keep it focused) - - echo "✅ Loaded: $playbook" -done -``` - -### 5. Present to Agent - -**Concise, actionable format:** - -```markdown -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -📚 APPLICABLE PLAYBOOKS LOADED (2) -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -**1. billing-playbook.md** - -🎯 Top Practices: -- Generate idempotency keys: `charge-{agreementId}-{period}-{type}` -- Use Decimal for money: `amount Decimal @db.Decimal(10, 2)` -- Validate before creating: Check agreement exists, amount > 0 - -⚠️ Pitfalls to Avoid: -- Don't create duplicate charges (use idempotency key unique constraint) -- Don't hardcode amounts (pull from agreement.monthlyRent) - -💡 Recent Pattern (Story 18-1): -```typescript -export async function createCharge(input: CreateChargeInput) { - const idempotencyKey = generateIdempotencyKey(...) - - // Check for existing charge first - const existing = await prisma.charge.findUnique({ - where: { idempotencyKey } - }) - if (existing) return existing - - // Create new charge - return prisma.charge.create({...}) -} -``` - -**2. state-machine-playbook.md** - -🎯 Top Practices: -- Define STATE_TRANSITIONS map with all valid paths -- Validate before transition: `if (!isValidTransition()) throw error` -- Log all state changes for audit trail - -⚠️ Pitfalls to Avoid: -- Don't allow arbitrary transitions (use validation map) -- Don't forget to update related entities (e.g., space status) - -💡 Recent Pattern (Story 17-8): -```typescript -const STATE_TRANSITIONS = { - ACTIVE: ['TERMINATING', 'TERMINATED'], - TERMINATING: ['TERMINATED'], - // ... -} - -function isValidTransition(from, to) { - return STATE_TRANSITIONS[from]?.includes(to) ?? false -} -``` - -Apply these learnings to Story {story_key}. -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -``` - ---- - -## Why This is Better Than Keyword Matching - -**Keyword Matching (Dumb):** -``` -Story mentions "billing" → Load billing-playbook.md -Story mentions "payment" → Load payment-playbook.md -``` -- Doesn't understand context -- Might load irrelevant playbooks -- Might miss relevant playbooks (different words, same concept) - -**Agent Reasoning (Smart):** -``` -Agent reads: "Create charge model with state machine" -Agent sees playbooks: billing, state-machine, queue, auth -Agent decides: "This is about billing + state transitions" -Agent loads: billing-playbook.md, state-machine-playbook.md -Agent skips: queue-playbook.md (not relevant), auth-playbook.md (not needed) -``` -- Understands what the story is actually about -- Makes intelligent decisions -- Loads only relevant playbooks -- Can connect concepts (charge creation = billing) - ---- - -## Step 12: Extract Learnings (Self-Reflection) - -### Agent Self-Reflection Prompt - -**After implementation completes, ask agent:** - -``` -You just completed Story {story_key}. - -Implementation Summary: -- Files created: {file_list} -- Tests written: {test_count} -- Code review findings: {issue_count} issues (all fixed) -- Commit: {commit_hash} - ---- - -SELF-REFLECTION: - -1. What went well during this implementation? - - What patterns or approaches worked effectively? - - What code is worth reusing in future stories? - -2. What problems did you encounter? - - What mistakes did you make? - - What errors occurred? - - How did you fix them? - -3. What would you do differently next time? - - What prevention checks would catch these issues earlier? - - What validation would help? - -4. Which playbooks should be updated? - - Look at the technologies/patterns you used - - Which playbooks (if any) helped you? - - Which playbooks should exist but don't? - -Respond with: -- Patterns to add/update (with code examples) -- Pitfalls to document (with prevention) -- Playbooks to create/update (by name) -``` - -### Based on Agent Response, Update Playbooks - -**Agent responds:** - -``` -Went well: -- Idempotency key pattern prevented duplicate charges -- State machine validation caught invalid transitions - -Problems: -- Initially forgot to update space status on agreement termination -- Enum transaction error (tried to add + use in one migration) - -Do differently: -- Add checklist: "After state change, check related entities" -- Always split enum additions into separate migrations - -Playbooks to update: -- billing-playbook.md: Add idempotency pattern -- state-machine-playbook.md: Add "check related entities" reminder -- database-migration-playbook.md: Add enum transaction pitfall -``` - -**Then execute updates:** - -```bash -# For each playbook to update -# 1. Read current playbook -# 2. Append new entry to appropriate section -# 3. Update frontmatter (source_stories, pattern_count, last_updated) -# 4. Write updated playbook -# 5. Commit with message: "docs: update {playbook} from Story {story_key} learnings" -``` - ---- - -## Playbook Index Maintenance - -**Auto-update index when playbooks change:** - -```bash -# After Step 12 updates playbooks, regenerate index - -cat > docs/playbooks/index.md <> docs/playbooks/index.md < 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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-03-write-tests.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-03-write-tests.md deleted file mode 100644 index 534c5a85..00000000 --- a/src/modules/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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-04-implement.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-04-implement.md deleted file mode 100644 index 684e6164..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-04-implement.md +++ /dev/null @@ -1,645 +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 executed successfully! -``` - -🚨 MANDATORY: CHECK OFF ALL BATCH TASKS IMMEDIATELY - -**For EACH task in the batch, execute this verification:** - -```bash -story_file="{story_file}" - -# For each task in batch -for task_text in "{task_1}" "{task_2}" "{task_3}"; do - # Use Edit tool to change: "- [ ] $task_text" → "- [x] $task_text" - - # VERIFY checkbox was updated - if ! grep -q "^\- \[x\].*${task_text}" "$story_file"; then - echo "❌ CRITICAL FAILURE: Batch task NOT checked: $task_text" - echo "" - echo "YOU MUST use Edit tool to check off ALL batch tasks." - echo "HALTING Step 4." - exit 1 - fi -done - -echo "✅ All {task_count} batch tasks verified checked" -``` - -**IF VERIFICATION FAILS:** HALT immediately. Batch is not complete until all checkboxes verified. - -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 - -**MANDATORY: Mark task complete in story file:** - -🚨 YOU MUST CHECK OFF THIS TASK IMMEDIATELY - NO EXCEPTIONS - -```bash -# 1. Find the exact task line in story file -story_file="{story_file}" -task_text="{current_task_description}" # e.g., "1.1: Add ChargeType enum" - -# 2. Update checkbox from [ ] to [x] -# Use Edit tool to change the specific task line -# Example: "- [ ] 1.1: Add ChargeType enum" → "- [x] 1.1: Add ChargeType enum" - -# 3. VERIFY the checkbox was actually updated -if ! grep -q "^\- \[x\].*${task_text}" "$story_file"; then - echo "❌ CRITICAL FAILURE: Task checkbox was NOT checked" - echo "Task: $task_text" - echo "Story file: $story_file" - echo "" - echo "YOU MUST use the Edit tool to check off this task." - echo "The workflow CANNOT continue until this task is marked complete." - echo "" - echo "HALTING Step 4." - exit 1 -fi - -echo "✅ Task checkbox verified: $task_text" -``` - -**IF VERIFICATION FAILS:** HALT immediately. Do not proceed to next task. - -**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 - -**MANDATORY PRE-FLIGHT CHECKS (with verification code):** - -### 1. Verify Files Match Story File List - -```bash -# Extract expected files from story File List section -story_file="{story_file}" - -# Check each file in File List exists -missing_files=0 -while IFS= read -r file_line; do - if [[ "$file_line" =~ ^-[[:space:]]+(.*\.ts|.*\.tsx|.*\.sql)$ ]]; then - expected_file="${BASH_REMATCH[1]}" - if [ ! -f "$expected_file" ]; then - echo "❌ MISSING FILE: $expected_file (specified in File List)" - missing_files=$((missing_files + 1)) - fi - fi -done < <(sed -n '/## File List/,/##/p' "$story_file") - -if [ "$missing_files" -gt 0 ]; then - echo "" - echo "❌ CRITICAL: $missing_files files from File List not created" - echo "This means you built DIFFERENT code than the story specified." - echo "" - echo "HALTING - Implementation does not match story." - exit 1 -fi -``` - -### 2. Verify Tasks Match Implementation - -```bash -# For each task, verify corresponding code exists -# Example: Task says "Create validateStateTransition function" -# Verify: grep "function validateStateTransition" billing-service.ts - -# This requires reading tasks and checking file contents -# Implementation: Read each task checkbox text, extract expected artifact (function/model/file) -# Check if that artifact exists in the codebase -``` - -### 3. Standard Quality Checks - -- [ ] All unchecked tasks completed -- [ ] All tests pass -- [ ] Lint clean -- [ ] Build succeeds -- [ ] No TypeScript errors -- [ ] Followed project patterns -- [ ] **No vibe coding occurred** - -## CRITICAL STEP COMPLETION - -**MANDATORY VERIFICATION BEFORE PROCEEDING:** - -🚨 TASK COMPLETION VERIFICATION - WORKFLOW WILL HALT IF FAILED - -**Execute these verification checks (NO EXCEPTIONS):** - -```bash -# 1. Count checked vs total tasks in story file -story_file="{story_file}" -checked_tasks=$(grep -c "^- \[x\]" "$story_file" || echo "0") -total_tasks=$(grep -c "^- \[[x ]\]" "$story_file" || echo "0") - -if [ "$checked_tasks" -eq 0 ]; then - echo "❌ CRITICAL FAILURE: ZERO tasks checked in story file" - echo "Story: $story_file" - echo "Total tasks: $total_tasks" - echo "" - echo "This means implementation DID NOT update the story file." - echo "This is a WORKFLOW EXECUTION FAILURE." - echo "" - echo "HALTING - Step 4 cannot complete." - exit 1 -fi - -completion_pct=$((checked_tasks * 100 / total_tasks)) - -if [ "$completion_pct" -lt 80 ]; then - echo "⚠️ WARNING: Only $completion_pct% tasks checked ($checked_tasks/$total_tasks)" - echo "Implementation may be incomplete." -fi - -echo "✅ Task verification: $checked_tasks/$total_tasks tasks checked ($completion_pct%)" -``` - -**ONLY WHEN:** -- [x] Tasks verified: checked_tasks > 0 (HALT if zero) -- [x] Completion ≥ 80% (WARN if lower, allow continuation with warning) -- [x] All tests pass -- [x] Lint clean -- [x] Build succeeds -- [x] No TypeScript errors - -**THEN** load and execute `{nextStepFile}` for post-validation. - -**IF VERIFICATION FAILS:** HALT workflow, do not proceed to Step 5. - ---- - -## 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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-05-post-validation.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-05-post-validation.md deleted file mode 100644 index fd63b543..00000000 --- a/src/modules/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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-06-run-quality-checks.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-06-run-quality-checks.md deleted file mode 100644 index 6fb23699..00000000 --- a/src/modules/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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-07-code-review.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-07-code-review.md deleted file mode 100644 index 97e41975..00000000 --- a/src/modules/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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-08-review-analysis.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-08-review-analysis.md deleted file mode 100644 index 020c6597..00000000 --- a/src/modules/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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-09-fix-issues.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-09-fix-issues.md deleted file mode 100644 index 50ce785f..00000000 --- a/src/modules/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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10-complete.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10-complete.md deleted file mode 100644 index bed78080..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10-complete.md +++ /dev/null @@ -1,370 +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 - -**MANDATORY VERIFICATION CHECKS (with enforcement code):** - -```bash -story_file="{story_file}" - -# 1. Verify tasks were checked off during implementation -checked_tasks=$(grep -c "^- \[x\]" "$story_file" || echo "0") -total_tasks=$(grep -c "^- \[[x ]\]" "$story_file" || echo "0") - -if [ "$checked_tasks" -eq 0 ] && [ "$total_tasks" -gt 0 ]; then - echo "❌ CRITICAL FAILURE: Story has $total_tasks tasks but ZERO are checked" - echo "" - echo "This means Step 4 (Implementation) did NOT update the story file." - echo "The agent implemented code but never checked off tasks." - echo "" - echo "HALTING - Cannot mark story complete with unchecked tasks." - exit 1 -fi - -completion_pct=$((checked_tasks * 100 / total_tasks)) -echo "✅ Task completion verified: $checked_tasks/$total_tasks ($completion_pct%)" - -# 2. Verify Dev Agent Record was filled in -if grep -q "To be filled by dev agent" "$story_file"; then - echo "❌ CRITICAL FAILURE: Dev Agent Record is empty" - echo "" - echo "The '## Dev Agent Record' section was not filled in." - echo "This means the agent did not document what was built." - echo "" - echo "HALTING - Cannot complete without documentation." - exit 1 -fi - -echo "✅ Dev Agent Record verified: Documentation present" -``` - -Before proceeding (BLOCKING - ALL must pass): -- [ ] **Tasks verified: checked_tasks > 0 (HALT if zero)** -- [ ] **Dev Agent Record filled (HALT if empty)** -- [ ] 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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10a-queue-commit.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10a-queue-commit.md deleted file mode 100644 index 6c72ee2b..00000000 --- a/src/modules/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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-11-summary.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-11-summary.md deleted file mode 100644 index 15f09431..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-11-summary.md +++ /dev/null @@ -1,221 +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}' -nextStepFile: '{workflow_path}/steps/step-12-extract-learnings.md' - - -# 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/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-12-extract-learnings.md b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-12-extract-learnings.md deleted file mode 100644 index 15d10a1c..00000000 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-12-extract-learnings.md +++ /dev/null @@ -1,407 +0,0 @@ -# Step 12: Extract Learnings & Update Playbooks (Agent Self-Reflection) - -**Goal:** Agent reflects on what was learned during implementation and updates playbooks for future stories - ---- - -## Process - -### 1. Verify Story Quality (Skip if Low Quality) - -**Only extract from successful, clean implementations:** - -```bash -story_file="{story_file}" - -# Check task completion -checked_tasks=$(grep -c "^- \[x\]" "$story_file" || echo "0") -total_tasks=$(grep -c "^- \[[x ]\]" "$story_file" || echo "0") - -if [ "$total_tasks" -eq 0 ]; then - echo "⏭️ No tasks in story - skipping learning extraction" - exit 0 -fi - -completion_pct=$((checked_tasks * 100 / total_tasks)) - -if [ "$completion_pct" -lt 80 ]; then - echo "⏭️ Story only $completion_pct% complete - skipping extraction" - echo " (Only extract learnings from successful implementations)" - exit 0 -fi - -echo "✅ Story completion: $completion_pct% - proceeding with extraction" -``` - -### 2. Gather Implementation Context - -**Collect facts about what was built:** - -```bash -story_key="{story_key}" - -# Get commit for this story -commit_hash=$(git log --oneline --all --grep="$story_key" -i | head -1 | awk '{print $1}') - -if [ -z "$commit_hash" ]; then - echo "⚠️ No commit found for $story_key - skipping" - exit 0 -fi - -# Extract implementation details -files_changed=$(git diff-tree --no-commit-id --name-only -r "$commit_hash") -file_count=$(echo "$files_changed" | wc -l | tr -d ' ') -commit_message=$(git show --no-patch --format="%s" "$commit_hash") - -# Check for code review -review_file="{sprint_artifacts}/review-${story_key}.md" -has_review=false -critical_issues=0 -high_issues=0 - -if [ -f "$review_file" ]; then - has_review=true - critical_issues=$(grep -c "CRITICAL" "$review_file" || echo "0") - high_issues=$(grep -c "HIGH" "$review_file" || echo "0") -fi - -echo "📊 Implementation Context:" -echo " Commit: $commit_hash" -echo " Files: $file_count" -echo " Code Review: $has_review ($critical_issues critical, $high_issues high)" -``` - -### 3. Agent Self-Reflection - -**Present context and ask agent to reflect:** - -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -🤔 STORY COMPLETION SELF-REFLECTION -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -You just completed Story {story_key} ({completion_pct}% complete). - -Implementation Summary: -- Files created/modified: {file_count} files -- Commit: {commit_hash} -- Commit message: {commit_message} -- Code review: {critical_issues} critical, {high_issues} high issues (all fixed) - -Files Changed: -{files_changed} - ---- - -SELF-REFLECTION QUESTIONS: - -1. **What Patterns Emerged?** - - Did you create any reusable functions/utilities? - - Are there code patterns worth documenting for future stories? - - What file structures or naming conventions worked well? - -2. **What Mistakes Were Made?** - - What errors did you encounter during implementation? - - What did code review catch? - - What would have prevented these issues? - -3. **What Was Learned?** - - What surprised you about this implementation? - - What assumptions were wrong? - - What would you do differently next time? - -4. **Technology/Domain Insights?** - - What technologies were used? (database ORM, payment API, queue, etc.) - - What business domain? (billing, auth, notification, etc.) - - What architectural patterns? (state machine, cron, idempotency, etc.) - ---- - -RESPOND WITH STRUCTURED LEARNINGS: - -Format your response as: - -**PATTERNS TO SAVE:** -``` -Pattern: {Name} -Technology: {tech} -Code Example: {10-20 lines from your implementation} -When to Use: {specific scenario} -File: {source file path} -``` - -**PITFALLS TO DOCUMENT:** -``` -Mistake: {What went wrong} -Error: {Exact error message if applicable} -Fix: {How you resolved it} -Prevention: {Code/check to avoid in future} -Technology: {tech where this applies} -``` - -**BEST PRACTICES:** -``` -Practice: {Specific action} -Reason: {Why it works} -Example: {Command or code snippet} -Technology: {tech where this applies} -``` - -**PLAYBOOKS TO UPDATE:** -- {playbook-name}: {what to add} -- {playbook-name}: {what to update} - -Be specific. Include actual code from your implementation, not made-up examples. -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -``` - -### 4. Parse Agent Response - -**Extract structured learnings from agent's self-reflection:** - -```bash -# Agent response will contain sections: -# - PATTERNS TO SAVE -# - PITFALLS TO DOCUMENT -# - BEST PRACTICES -# - PLAYBOOKS TO UPDATE - -# Parse each section -patterns=$(extract_section "PATTERNS TO SAVE" from agent response) -pitfalls=$(extract_section "PITFALLS TO DOCUMENT" from agent response) -practices=$(extract_section "BEST PRACTICES" from agent response) -playbooks_to_update=$(extract_section "PLAYBOOKS TO UPDATE" from agent response) -``` - -### 5. Update or Create Playbooks - -**For each playbook the agent identified:** - -```bash -playbook_dir="{project-root}/docs/playbooks" -mkdir -p "$playbook_dir" - -for playbook_update in $playbooks_to_update; do - # Parse: "billing-playbook.md: Add idempotency pattern" - playbook_name=$(echo "$playbook_update" | cut -d: -f1 | tr -d ' ') - update_description=$(echo "$playbook_update" | cut -d: -f2-) - - playbook_path="${playbook_dir}/${playbook_name}" - - if [ ! -f "$playbook_path" ]; then - # Create new playbook from template - create_playbook_from_template "$playbook_name" "$story_key" - fi - - # Append learnings to appropriate sections - update_playbook_section "$playbook_path" "Best Practices" "$practices" - update_playbook_section "$playbook_path" "Common Pitfalls" "$pitfalls" - update_playbook_section "$playbook_path" "Code Patterns" "$patterns" - - # Update frontmatter - update_frontmatter "$playbook_path" "$story_key" - - echo "✅ Updated: $playbook_name" -done -``` - -### 6. Update Playbook Index - -**Regenerate index.md:** - -```bash -generate_playbook_index() { - index_file="${playbook_dir}/index.md" - - cat > "$index_file" </dev/null | wc -l | tr -d ' ') - -## Available Playbooks - -EOF - - # For each playbook, extract summary - for playbook in ${playbook_dir}/*-playbook.md; do - if [ ! -f "$playbook" ]; then continue; fi - - basename=$(basename "$playbook") - - # Extract from frontmatter - topics=$(sed -n '/^---$/,/^---$/p' "$playbook" | grep "^keywords:" | cut -d: -f2- | tr -d '[]') - stories=$(sed -n '/^---$/,/^---$/p' "$playbook" | grep "^source_stories:" | cut -d: -f2- | tr -d '[]') - pattern_count=$(sed -n '/^---$/,/^---$/p' "$playbook" | grep "^pattern_count:" | cut -d: -f2 | tr -d ' ') - last_updated=$(sed -n '/^---$/,/^---$/p' "$playbook" | grep "^last_updated:" | cut -d: -f2 | tr -d ' ') - - # Append to index - cat >> "$index_file" </dev/null | wc -l | tr -d ' ') playbooks" -} -``` - -### 7. Commit Playbook Updates - -**Commit all changes:** - -```bash -playbooks_updated=$(git diff --name-only docs/playbooks/ | wc -l | tr -d ' ') - -if [ "$playbooks_updated" -gt 0 ]; then - git add docs/playbooks/*.md - - git commit -m "docs: update playbooks from Story ${story_key} learnings - -Updated/created: -$(git diff --cached --name-only docs/playbooks/ | sed 's/^/- /') - -Learnings from successful implementation of ${story_key}." - - echo "✅ Committed: $playbooks_updated playbook updates" -else - echo "ℹ️ No playbook changes to commit" -fi -``` - ---- - -## Output - -``` -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -✅ LEARNINGS EXTRACTED FROM STORY {story_key} -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - -Playbooks Updated: {count} -- billing-playbook.md (added idempotency pattern) -- state-machine-playbook.md (added entity update reminder) -- database-migration-playbook.md (added enum pitfall) - -Patterns Documented: {count} -- Idempotency key generation -- State transition validation -- Related entity updates - -Pitfalls Documented: {count} -- Enum transaction limitation (PostgreSQL) -- Forgotten entity updates on state changes - -Index Updated: docs/playbooks/index.md -- Now tracks {total_playbooks} playbooks -- {total_patterns} patterns documented -- Ready for next story to benefit - -Future stories about billing, state machines, or migrations will -automatically load these learnings in Step 1b. -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -``` - ---- - -## Helper Functions - -### create_playbook_from_template - -```bash -create_playbook_from_template() { - playbook_name="$1" - story_key="$2" - - # Extract technology/domain from filename - # Example: billing-playbook.md → technology: billing - tech_or_domain=$(echo "$playbook_name" | sed 's/-playbook\.md$//') - - cat > "${playbook_dir}/${playbook_name}" < 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/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml index 41c3e582..122750d3 100644 --- a/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml +++ b/src/modules/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, mandatory status updates, and automated learning feedback loop. Risk-based complexity routing with cumulative intelligence." -author: "BMad" -version: "1.6.0" # Adds learning feedback loop (Step 1b load playbooks, Step 12 extract learnings) +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" @@ -12,308 +15,107 @@ date: system-generated # Workflow paths installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline" +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}}" -# Automated learning feedback loop (NEW v1.6.0) -learning_feedback: - enabled: true # Enable automatic playbook loading/saving - playbook_dir: "{project-root}/docs/playbooks" + - 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" - # Step 1b: Load existing playbooks before implementation - load_playbooks: - enabled: true - step: "step-01b-load-playbooks.md" - triggers: - - keywords_detected: 1 # Load if any keywords found in story - - complex_story: true # Always load for COMPLEX stories + - name: "sprint_status" + command: "git diff HEAD~1 {{sprint_status}} | grep '{{story_key}}'" + failure_message: "Sprint status not updated" - # Step 12: Extract learnings after implementation - extract_learnings: - enabled: true - step: "step-12-extract-learnings.md" - triggers: - - on_success: true # Extract after successful completion - - on_code_review: true # Extract from review findings - - on_complex: true # Always extract from COMPLEX stories - - skip_if_failed: true # Don't extract from failed implementations + - 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" - # Keyword extraction - keywords: - auto_detect: true - sources: - - story_title - - task_descriptions - - file_paths - - technical_requirements - common_keywords: - - prisma - - stripe - - auth - - cron - - queue - - state machine - - billing - - payment - - migration - - api - - database - - email - - notification - - terraform - - sqs - - redis - - s3 - - # 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: "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}/*.md" # CANONICAL: epic-story-slug.md (NO "story-" prefix) - 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/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml.backup b/src/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml.backup deleted file mode 100644 index fd417a36..00000000 --- a/src/modules/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 diff --git a/test/TODO-WORKFLOW-TESTS.md b/test/TODO-WORKFLOW-TESTS.md index de48fd5a..73a42d99 100644 --- a/test/TODO-WORKFLOW-TESTS.md +++ b/test/TODO-WORKFLOW-TESTS.md @@ -11,7 +11,7 @@ ### Workflows Without Tests: 1. **batch-super-dev** - Interactive story selector 2. **super-dev-pipeline** - Story implementation pipeline -3. **super-dev-pipeline-v2** - Multi-agent pipeline +3. **super-dev-pipeline** - Multi-agent pipeline 4. **create-story** - Lightweight story creation 5. **create-story-with-gap-analysis** - Story with codebase scan @@ -34,7 +34,7 @@ - [ ] Sprint-status updates - [ ] Commit creation -**super-dev-pipeline-v2:** +**super-dev-pipeline:** - [ ] Multi-agent spawning (builder, inspector, reviewer, fixer) - [ ] Fresh context per agent - [ ] Independent validation