ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity

refactor: consolidate super-dev-pipeline architecture and clarify execution modes 

**Removed:**
- -v2 suffix from super-dev-pipeline (consolidated to single pipeline)
- Old v1.6.0 single-agent pipeline (replaced by v2.0 multi-agent)

**Updated:**
- batch-super-dev execution modes simplified to S (sequential) and P (parallel)
- Both S and P now use Task agents to keep story context out of main thread
- P mode uses smart wave-based execution with dependency analysis
- Sequential mode (S): One Task agent at a time, no dependency analysis
- Parallel mode (P): Wave-based execution respecting story dependencies

**Architecture:**
- Story-level: S (sequential Task agents) vs P (parallel Task agents with waves)
- Within-story: Always multi-agent (builder/inspector/reviewer/fixer)
- Main thread stays clean - all story implementation in Task agent context

**Version:** 6.0.0-Beta.3 → 6.0.0-Beta.4
This commit is contained in:
Jonah Schulte 2026-01-26 19:40:23 -05:00
parent b4217ba65f
commit d3bf02a0af
35 changed files with 831 additions and 12468 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
GSDMAD-ARCHITECTURE.md
View File

@ -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

2
package.json
View File

@ -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",

4
src/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml
View File

@ -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"

389
src/modules/bmm/workflows/4-implementation/batch-super-dev/instructions.md
View File

@ -889,71 +889,35 @@ QUALITY OVER SPEED: Taking time to ensure correctness.
</substep>
<ask>
**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
</ask>
<action>Capture response as: execution_strategy</action>
<check if="execution_strategy == 'w' OR execution_strategy == 'W'">
<action>Set execution_mode = "wave_based"</action>
<action>Set use_task_agents = true</action>
<action>Set wave_execution = true</action>
<output>
✅ 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)
</output>
</check>
<check if="execution_strategy == 's' OR execution_strategy == 'S'">
<action>Set execution_mode = "sequential"</action>
<action>Set parallel_count = 1</action>
<action>Set use_task_agents = false</action>
<action>Set wave_execution = false</action>
<output>✅ Sequential mode selected - stories will be processed one-by-one in this session</output>
<action>Set use_task_agents = true</action>
<output>
⏺ ✅ 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.
</output>
</check>
<check if="execution_strategy == 'p' OR execution_strategy == 'P'">
<action>Set execution_mode = "full_parallel"</action>
<action>Set execution_mode = "parallel"</action>
<action>Set use_task_agents = true</action>
<action>Set wave_execution = false</action>
<ask>
**How many agents should run in parallel?**
@ -975,26 +939,33 @@ Enter number (2-10) or 'all':
<check if="parallel_count was capped at 10">
<output>⚠️ Requested {{original_count}} agents, capped at 10 (safety limit)</output>
</check>
<output>
⏺ ✅ 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.
</output>
</check>
<output>
## ⚙️ 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}}
</output>
<ask>Confirm execution plan? (yes/no):</ask>
@ -1009,16 +980,16 @@ Enter number (2-10) or 'all':
<action>Initialize counters: completed=0, failed=0, failed_stories=[], reconciliation_warnings=[], reconciliation_warnings_count=0</action>
<action>Set start_time = current timestamp</action>
<check if="wave_execution == true">
<action>Jump to Step 4-Wave (Wave-based execution)</action>
<check if="parallel_count == 1">
<action>Jump to Step 4-Sequential (Task agents, one at a time)</action>
</check>
<check if="use_task_agents == true AND wave_execution == false">
<action>Jump to Step 4-Parallel (Full parallel execution)</action>
<check if="parallel_count > 1 AND waves.length > 1">
<action>Jump to Step 4-Wave (Task agents, wave-based parallel)</action>
</check>
<check if="use_task_agents == false">
<action>Continue to Step 4-Sequential (In-session execution)</action>
<check if="parallel_count > 1 AND waves.length <= 1">
<action>Jump to Step 4-Parallel (Task agents, multiple concurrent)</action>
</check>
</step>
@ -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}}
</output>
<iterate>For each wave in sequence:</iterate>
<action>Set abort_batch = false</action>
<substep n="4w-a" title="Execute wave">
<iterate>For each wave in waves (in order):</iterate>
<substep n="4w-start" title="Start wave {{@index}}">
<output>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📦 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...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
</output>
<action>Spawn Task agents in PARALLEL (send all in single message):</action>
<action>Initialize wave worker pool state:</action>
<action>
- 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)
</action>
</substep>
<iterate>For each story in this wave:</iterate>
<substep n="4w-init" title="Fill initial worker slots for wave {{@index}}">
<output>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔧 Initializing {{max_workers}} worker slots for Wave {{@index}}...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
</output>
<action>Spawn first {{max_workers}} agents (or fewer if less stories):</action>
<iterate>While next_story_index < min(max_workers, wave_queue.length):</iterate>
<action>
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"
</action>
<action>Wait for ALL agents in this wave to complete</action>
<action>Increment next_story_index</action>
<output>🚀 Worker {{worker_id}} started: {{story_key}}</output>
</substep>
<iterate>For each completed agent in wave:</iterate>
<substep n="4w-pool" title="Maintain wave worker pool for wave {{@index}}">
<critical>WAVE BARRIER: Complete all stories in this wave before starting next wave</critical>
<check if="agent succeeded">
<output>✅ Wave {{wave_num}} - Story complete: {{story_key}}</output>
<action>Increment completed counter</action>
<action>Execute Step 4.5: Reconciliation</action>
<iterate>While active_workers.size > 0 OR next_story_index < wave_queue.length:</iterate>
<action>Poll for completed workers (check task outputs non-blocking):</action>
<iterate>For each worker_id in active_workers:</iterate>
<action>Check if worker task completed using TaskOutput(task_id, block=false)</action>
<check if="worker task is still running">
<action>Continue to next worker (don't wait)</action>
</check>
<check if="agent failed">
<output>❌ Wave {{wave_num}} - Story failed: {{story_key}}</output>
<action>Increment failed counter</action>
<action>Add to failed_stories list</action>
<check if="worker task completed successfully">
<action>Get worker details: story_key = active_workers[worker_id].story_key</action>
<check if="continue_on_failure == false">
<output>⚠️ Stopping all waves due to failure</output>
<action>Jump to Step 5 (Summary)</action>
<output>✅ Worker {{worker_id}} completed: {{story_key}}</output>
<action>Execute Step 4.5: Smart Story Reconciliation</action>
<action>Load reconciliation instructions: {installed_path}/step-4.5-reconcile-story-status.md</action>
<action>Execute reconciliation with story_key={{story_key}}</action>
<critical>🚨 MANDATORY RECONCILIATION AUTO-FIX - MAKE IT RIGHT</critical>
<action>Verify reconciliation by checking story file:</action>
<action> 1. Re-read story file: {{story_file_path}}</action>
<action> 2. Count checked tasks vs total tasks</action>
<action> 3. Check Dev Agent Record filled</action>
<check if="checked_tasks == 0 OR dev_agent_record_empty">
<output>
❌ 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...
</output>
<action>AUTO-FIX PROCEDURE:</action>
<action>1. Read agent's commit to see what files were created/modified</action>
<action>2. Read story Tasks section to see what was supposed to be built</action>
<action>3. For each task, check if corresponding code exists in commit</action>
<action>4. If code exists, check off the task using Edit tool</action>
<action>5. Fill in Dev Agent Record with commit details</action>
<action>6. Verify fixes worked (re-count checked tasks)</action>
<check if="auto_fix_succeeded AND checked_tasks > 0">
<output>✅ AUTO-FIX SUCCESS: {{checked_tasks}}/{{total_tasks}} tasks now checked</output>
<action>Continue with story completion</action>
</check>
<check if="auto_fix_failed OR checked_tasks still == 0">
<output>
❌ 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.
</output>
<action>Override story status to "in-progress"</action>
<action>Add to reconciliation_warnings with detailed diagnostic</action>
<action>Continue (do NOT kill workers)</action>
</check>
</check>
<check if="reconciliation succeeded AND checked_tasks > 0 AND dev_agent_record_filled">
<output>✅ COMPLETED: {{story_key}} (reconciled and verified)</output>
<output> Tasks: {{checked_tasks}}/{{total_tasks}} ({{task_completion_pct}}%)</output>
<action>Increment completed counter</action>
<action>Add to completed_wave_stories</action>
</check>
<check if="task_completion_pct < 80">
<output>⚠️ WARNING: {{story_key}} - Low completion ({{task_completion_pct}}%)</output>
<action>Add to reconciliation_warnings: {story_key: {{story_key}}, warning_message: "Only {{task_completion_pct}}% tasks checked - manual verification needed"}</action>
</check>
<action>Remove worker_id from active_workers (free the slot)</action>
<action>IMMEDIATELY refill slot if stories remain in this wave:</action>
<check if="next_story_index < wave_queue.length">
<action>story_key = wave_queue[next_story_index].story_key</action>
<action>complexity_level = wave_queue[next_story_index].complexity_level</action>
<action>story_file_path = wave_queue[next_story_index].story_file_path</action>
<output>🔄 Worker {{worker_id}} refilled: {{story_key}}</output>
<action>Spawn new Task agent for this worker_id (same parameters as init)</action>
<action>Update active_workers[worker_id] with new task_id and story_key</action>
<action>Increment next_story_index</action>
</check>
</check>
<check if="worker task failed">
<action>Get worker details: story_key = active_workers[worker_id].story_key</action>
<output>❌ Worker {{worker_id}} failed: {{story_key}}</output>
<action>Increment failed counter</action>
<action>Add story_key to failed_stories list</action>
<action>Add to failed_wave_stories</action>
<action>Remove worker_id from active_workers (free the slot)</action>
<check if="continue_on_failure == false">
<output>⚠️ Stopping wave and batch due to failure (continue_on_failure=false)</output>
<action>Kill all active workers</action>
<action>Clear active_workers</action>
<action>Set abort_batch = true</action>
<action>Break worker pool loop</action>
</check>
<check if="continue_on_failure == true AND next_story_index < wave_queue.length">
<action>story_key = wave_queue[next_story_index].story_key</action>
<action>complexity_level = wave_queue[next_story_index].complexity_level</action>
<action>story_file_path = wave_queue[next_story_index].story_file_path</action>
<output>🔄 Worker {{worker_id}} refilled: {{story_key}} (despite previous failure)</output>
<action>Spawn new Task agent for this worker_id</action>
<action>Update active_workers[worker_id] with new task_id and story_key</action>
<action>Increment next_story_index</action>
</check>
</check>
<check if="abort_batch == true">
<action>Break worker pool loop</action>
</check>
<action>Display live progress every 30 seconds:</action>
<output>
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}}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
</output>
<action>Sleep 5 seconds before next poll (prevents tight loop)</action>
</substep>
<check if="abort_batch == true">
<output>⛔ Aborting remaining waves due to failure and continue_on_failure=false</output>
<action>Jump to Step 5 (Summary)</action>
</check>
<output>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ WAVE {{@index}} COMPLETE
Stories completed: {{completed_wave_stories.length}}
Stories failed: {{failed_wave_stories.length}}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
</output>
<action>After all waves processed, jump to Step 5 (Summary)</action>
</step>
<step n="4-Sequential" goal="Sequential processing in current session">
<step n="4-Sequential" goal="Sequential Task agent execution (one at a time)">
<output>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🚀 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}}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
</output>
<iterate>For each story in selected_stories:</iterate>
<substep n="4s-a" title="Process individual story">
<substep n="4s-a" title="Spawn Task agent for story">
<output>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📦 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...
</output>
<action>Invoke workflow: /bmad:bmm:workflows:super-dev-pipeline</action>
<action>Parameters: mode=batch, story_key={{story_key}}, complexity_level={{story_key}}.complexity.level</action>
<action>
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}}.
<check if="super-dev-pipeline succeeded">
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
</action>
<action>WAIT for agent to complete (blocking call)</action>
<check if="Task agent succeeded">
<output>✅ Implementation complete: {{story_key}}</output>
<action>Execute Step 4.5: Smart Story Reconciliation</action>
@ -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]:

4
src/modules/bmm/workflows/4-implementation/multi-agent-review/workflow.yaml
View File

@ -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
standalone: true

135
src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/README.md
View File

@ -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.

375
src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/workflow.md
View File

@ -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.

121
src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/workflow.yaml
View File

@ -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

4226
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/ALL-STEPS-EMBEDDED.md
View File

File diff suppressed because it is too large Load Diff

391
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/IMPLEMENTATION-PLAN.md
View File

@ -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...
<invoke-workflow path="{multi_agent_review_workflow}">
<input name="story_id">{story_id}</input>
</invoke-workflow>
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

291
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/MULTI-AGENT-ARCHITECTURE.md
View File

@ -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.

436
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/PLAYBOOK-DESIGN.md
View File

@ -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" <<EOF
---
technology: ${keyword}
keywords: [${keyword}]
source_stories: [${story_key}]
last_updated: $(date +%Y-%m-%d)
pattern_count: 0
pitfall_count: 0
---
# ${keyword^} Playbook
**Generated from:** Story ${story_key}
## Best Practices
## Common Pitfalls
## Code Patterns
## Lessons Learned
EOF
else
# Update existing playbook
# - Append to each section
# - Update source_stories list
# - Increment pattern/pitfall counts
# - Update last_updated date
fi
# Append new learning
cat >> "$playbook_file" <<EOF
**Story ${story_key}:**
${extracted_learning}
EOF
```
---
## Storage Format
### Playbook File Naming
```
docs/playbooks/
{technology}-playbook.md # Technology-specific
{domain}-playbook.md # Domain-specific
{pattern}-playbook.md # Pattern-specific
```
**Examples (generic, not project-specific):**
```
database-orm-playbook.md # Whatever ORM you use
payment-processor-playbook.md # Whatever payment system
auth-system-playbook.md # Whatever auth provider
state-machine-playbook.md # Architecture pattern
cron-jobs-playbook.md # Architecture pattern
```
### Playbook Content
**Maximum 200 lines per playbook.** When it grows larger:
1. Archive old learnings
2. Keep only most recent/relevant
3. Prune outdated patterns
**Sections sized:**
- Best Practices: Top 10 (most recent)
- Common Pitfalls: Top 8 (most common)
- Code Patterns: Top 5 (most reused)
- Lessons Learned: Latest 3
---
## Integration with Workflow
**Updated Step Sequence:**
```
Step 1: Init (load story, verify file)
Step 1b: Load Playbooks ← NEW (auto-detect keywords, load applicable)
Step 2: Pre-Gap Analysis (informed by playbooks)
Step 3: Write Tests (use test patterns from playbooks)
Step 4: Implement (follow playbook best practices)
Step 5: Post-Validation
Step 6: Quality Checks
Step 7: Code Review (compare against playbook standards)
Step 8: Review Analysis
Step 9: Fix Issues
Step 10: Complete
Step 11: Summary
Step 12: Extract Learnings ← NEW (save patterns to playbooks)
```
**Workflow version:** 1.6.0 (adds learning feedback loop)
---
## Success Metrics
**Measure effectiveness:**
```bash
# 1. Playbook growth over time
ls -1 docs/playbooks/*.md | wc -l # Number of playbooks
# 2. Pattern reuse
grep "Source:" docs/playbooks/*.md | wc -l # Patterns documented
# 3. Mistake prevention
grep "Pitfall.*Story" docs/playbooks/*.md | \
cut -d: -f2 | sort | uniq -c | sort -rn
# Shows which mistakes were repeated (should decrease over time)
# 4. Coverage
keywords_in_stories=$(analyze all stories for keywords | sort -u | wc -l)
playbooks_created=$(ls -1 docs/playbooks/*.md | wc -l)
coverage_pct=$((playbooks_created * 100 / keywords_in_stories))
# Target: 80%+ keyword coverage
```
---
## Expected Outcomes
**After 10 stories:**
- 5-8 playbooks created
- 30-50 patterns documented
- 15-25 pitfalls catalogued
- Mistakes rarely repeated
**After 50 stories:**
- 15-20 comprehensive playbooks
- 100+ patterns documented
- Stable knowledge base (fewer new pitfalls)
- High pattern reuse
**After 100 stories:**
- Mature playbook system
- Most mistakes already documented
- New stories implement faster (less trial-and-error)
- Onboarding new developers easier
---
## Quality Standards
**Playbook entries must be:**
- ✅ Specific (exact commands, not vague advice)
- ✅ Actionable (copy-paste ready)
- ✅ Evidence-based (from actual code)
- ✅ Sourced (story reference)
- ✅ Verified (pattern actually works)
**Reject entries that are:**
- ❌ Generic advice ("write good code")
- ❌ Theoretical ("this might work")
- ❌ Unsourced (no story reference)
- ❌ Unverified (pattern never tested)
---
**This creates a self-improving system where each story makes the next one better.**

296
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/README.md
View File

@ -1,169 +1,135 @@
# super-dev-pipeline
# Super-Dev-Pipeline v2.0 - GSDMAD Architecture
**Token-efficient step-file workflow that prevents vibe coding and works for both greenfield AND brownfield development.**
## 🎯 Purpose
Combines the best of both worlds:
- **super-dev-story's flexibility** - works for greenfield and brownfield
- **story-pipeline's discipline** - step-file architecture prevents vibe coding
## 🔑 Key Features
### 1. **Smart Batching** ⚡ NEW!
- **Pattern detection**: Automatically identifies similar tasks
- **Intelligent grouping**: Batches low-risk, repetitive tasks
- **50-70% faster** for stories with repetitive work (e.g., package migrations)
- **Safety preserved**: Validation gates still enforced, fallback on failure
- **NOT vibe coding**: Systematic detection + batch validation
### 2. **Adaptive Implementation**
- Greenfield tasks: TDD approach (test-first)
- Brownfield tasks: Refactor approach (understand-first)
- Hybrid stories: Mix both as appropriate
### 3. **Anti-Vibe-Coding Architecture**
- **Step-file design**: One step at a time, no looking ahead
- **Mandatory sequences**: Can't skip or optimize steps
- **Quality gates**: Must pass before proceeding
- **State tracking**: Progress recorded and verified
### 4. **Brownfield Support**
- Pre-gap analysis scans existing code
- Validates tasks against current implementation
- Refines vague tasks to specific actions
- Detects already-completed work
### 5. **Complete Quality Gates**
- ✅ Pre-gap analysis (validates + detects batchable patterns)
- ✅ Smart batching (groups similar tasks, validates batches)
- ✅ Adaptive implementation (TDD or refactor)
- ✅ Post-validation (catches false positives)
- ✅ Code review (finds 3-10 issues)
- ✅ Commit + push (targeted files only)
## 📁 Workflow Steps
| Step | File | Purpose |
|------|------|---------|
| 1 | step-01-init.md | Load story, detect greenfield vs brownfield |
| 2 | step-02-pre-gap-analysis.md | Validate tasks against codebase |
| 3 | step-03-implement.md | Adaptive implementation (no vibe coding!) |
| 4 | step-04-post-validation.md | Verify completion vs reality |
| 5 | step-05-code-review.md | Adversarial review (3-10 issues) |
| 6 | step-06-complete.md | Commit and push changes |
| 7 | step-07-summary.md | Audit trail generation |
## 🚀 Usage
### Standalone
```bash
bmad super-dev-pipeline
```
### From batch-super-dev
```bash
bmad batch-super-dev
# Automatically uses super-dev-pipeline for each story
```
## 📊 Efficiency Metrics
| Metric | super-dev-story | super-dev-pipeline | super-dev-pipeline + batching |
|--------|----------------|-------------------|-------------------------------|
| Tokens/story | 100-150K | 40-60K | 40-60K (same) |
| Time/100 tasks | 200 min | 200 min | **100 min** (50% faster!) |
| Architecture | Orchestration | Step-files | Step-files + batching |
| Vibe coding | Possible | Prevented | Prevented |
| Repetitive work | Slow | Slow | **Fast** |
## 🛡️ Why This Prevents Vibe Coding
**The Problem:**
When token counts get high (>100K), Claude tends to:
- Skip verification steps
- Batch multiple tasks
- "Trust me, I got this" syndrome
- Deviate from intended workflow
**The Solution:**
Step-file architecture enforces:
- ✅ ONE step loaded at a time
- ✅ MUST read entire step file first
- ✅ MUST follow numbered sequence
- ✅ MUST complete quality gate
- ✅ MUST update state before proceeding
**Result:** Disciplined execution even at 200K+ tokens!
## 🔄 Comparison with Other Workflows
### vs super-dev-story (Original)
- ✅ Same quality gates
- ✅ Same brownfield support
- ✅ 50% more token efficient
- ✅ **Prevents vibe coding** (new!)
### vs story-pipeline
- ✅ Same step-file discipline
- ✅ **Works for brownfield** (story-pipeline doesn't!)
- ✅ No mandatory ATDD (more flexible)
- ✅ **Smart batching** (50-70% faster for repetitive work!)
- ❌ Slightly less token efficient (40-60K vs 25-30K)
## 🎓 When to Use
**Use super-dev-pipeline when:**
- Working with existing codebase (brownfield)
- Need vibe-coding prevention
- Running batch-super-dev
- Token counts will be high
- Want disciplined execution
**Use story-pipeline when:**
- Creating entirely new features (pure greenfield)
- Story doesn't exist yet (needs creation)
- Maximum token efficiency needed
- TDD/ATDD is appropriate
**Use super-dev-story when:**
- Need quick one-off development
- Interactive development preferred
- Traditional orchestration is fine
## 📝 Requirements
- Story file must exist (does NOT create stories)
- Project context must exist
- Works with both `_bmad` and `.bmad` conventions
## 🏗️ Architecture Notes
### Development Mode Detection
Auto-detects based on File List:
- **Greenfield**: All files are new
- **Brownfield**: All files exist
- **Hybrid**: Mix of new and existing
### Adaptive Implementation
Step 3 adapts methodology:
- New files → TDD approach
- Existing files → Refactor approach
- Tests → Add/update as needed
- Migrations → Apply and verify
### State Management
Uses `super-dev-state-{story_id}.yaml` for:
- Progress tracking
- Quality gate results
- File lists
- Metrics collection
Cleaned up after completion (audit trail is permanent record).
**Multi-agent pipeline with independent validation and adversarial code review**
---
**super-dev-pipeline: Disciplined development for the real world!** 🚀
## Quick Start
```bash
# 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.

0
src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/builder.md → src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/builder.md
View File

0
src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/fixer.md → src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/fixer.md
View File

0
src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/inspector.md → src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/inspector.md
View File

0
src/modules/bmm/workflows/4-implementation/super-dev-pipeline-v2/agents/reviewer.md → src/modules/bmm/workflows/4-implementation/super-dev-pipeline/agents/reviewer.md
View File

437
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md
View File

@ -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)
<critical>🚨 ONE CANONICAL NAMING FORMAT - NO VARIATIONS ALLOWED</critical>
**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...
```
<invoke-workflow path="{create_story_workflow}/workflow.yaml">
<input name="story_id">{story_id}</input>
<input name="story_file">{story_file}</input>
<input name="regenerate">true</input>
</invoke-workflow>
# 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...
```
<invoke-workflow path="{create_story_workflow}/workflow.yaml">
<input name="story_id">{story_id}</input>
<input name="story_file">{story_file}</input>
<input name="regenerate">true</input>
</invoke-workflow>
# 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

355
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01b-load-playbooks.md
View File

@ -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 <<EOF
# Playbook Index
Last Updated: $(date +%Y-%m-%d)
Total Playbooks: $(ls -1 docs/playbooks/*-playbook.md | wc -l | tr -d ' ')
## Available Playbooks
EOF
# For each playbook
for playbook in docs/playbooks/*-playbook.md; do
basename=$(basename "$playbook")
# Extract frontmatter
topics=$(grep "^keywords:" "$playbook" | cut -d: -f2)
stories=$(grep "^source_stories:" "$playbook" | cut -d: -f2)
pattern_count=$(grep "^pattern_count:" "$playbook" | cut -d: -f2)
last_updated=$(grep "^last_updated:" "$playbook" | cut -d: -f2)
# Generate index entry
cat >> docs/playbooks/index.md <<ENTRY
### $basename
**Topics:** $topics
**Stories:** $stories
**Patterns:** $pattern_count patterns documented
**Last Updated:** $last_updated
ENTRY
done
git add docs/playbooks/index.md
git commit -m "docs: update playbook index (${playbook_count} playbooks)"
```
---
**Key Difference:** Agent READS index, UNDERSTANDS story, DECIDES which playbooks are relevant. Not dumb keyword matching.

653
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-02-pre-gap-analysis.md
View File

@ -1,653 +0,0 @@
---
name: 'step-02-smart-gap-analysis'
description: 'Smart gap analysis - skip if story just created with gap analysis in step 1'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
# File References
thisStepFile: '{workflow_path}/steps/step-02-smart-gap-analysis.md'
stateFile: '{state_file}'
nextStepFile: '{workflow_path}/steps/step-03-write-tests.md'
# Role Switch
role: dev
agentFile: '{project-root}/_bmad/bmm/agents/dev.md'
---
# Step 2: Smart Gap Analysis
## ROLE SWITCH
**Switching to DEV (Developer) perspective.**
You are now analyzing the story tasks against codebase reality.
## STEP GOAL
Validate all story tasks against the actual codebase:
1. Scan codebase for existing implementations
2. Identify which tasks are truly needed vs already done
3. Refine vague tasks to be specific and actionable
4. Add missing tasks that were overlooked
5. Uncheck any tasks that claim completion incorrectly
6. Ensure tasks align with existing code patterns
## MANDATORY EXECUTION RULES
### Gap Analysis Principles
- **TRUST NOTHING** - Verify every task against codebase
- **SCAN THOROUGHLY** - Use Glob, Grep, Read to understand existing code
- **BE SPECIFIC** - Vague tasks like "Add feature X" need breakdown
- **ADD MISSING** - If something is needed but not tasked, add it
- **BROWNFIELD AWARE** - Check for existing implementations
## EXECUTION SEQUENCE
### 0. Smart Gap Analysis Check (NEW v1.5.0)
**Check if gap analysis already performed in step 1:**
```yaml
# Read state from step 1
Read {stateFile}
If story_just_created == true:
Display:
✅ GAP ANALYSIS SKIPPED
Story was just created via /create-story-with-gap-analysis in step 1.
Gap analysis already performed as part of story creation.
Skipping redundant gap analysis.
Proceeding directly to test writing (step 3).
Exit step 2
```
**If story was NOT just created, proceed with gap analysis below.**
### 1. Load Story Tasks
Read story file and extract all tasks (checked and unchecked):
```regex
- \[ \] (.+) # Unchecked
- \[x\] (.+) # Checked
```
Build list of all tasks to analyze.
### 2. Scan Existing Codebase
**For development_type = "brownfield" or "hybrid":**
Scan all files mentioned in File List:
```bash
# For each file in File List
for file in {file_list}; do
if test -f "$file"; then
# Read file to understand current implementation
read "$file"
# Check what's already implemented
grep -E "function|class|interface|export" "$file"
fi
done
```
Document existing implementations.
### 3. Analyze Each Task
For EACH task in story:
**A. Determine Task Type:**
- Component creation
- Function/method addition
- Database migration
- API endpoint
- UI element
- Test creation
- Refactoring
- Bug fix
**B. Check Against Codebase:**
```typescript
interface TaskAnalysis {
task: string;
type: string;
status: "needed" | "partially_done" | "already_done" | "unclear";
reasoning: string;
existing_code?: string;
refinement?: string;
}
```
**For each task, ask:**
1. Does related code already exist?
2. If yes, what needs to change?
3. If no, what needs to be created?
4. Is the task specific enough to implement?
**C. Categorize Task:**
**NEEDED** - Task is clear and required:
```yaml
- task: "Add deleteUser server action"
status: needed
reasoning: "No deleteUser function found in codebase"
action: "Implement as specified"
```
**PARTIALLY_DONE** - Some work exists, needs completion:
```yaml
- task: "Add error handling to createUser"
status: partially_done
reasoning: "createUser exists but only handles success case"
existing_code: "src/actions/createUser.ts"
action: "Add error handling for DB failures, validation errors"
```
**ALREADY_DONE** - Task is complete:
```yaml
- task: "Create users table"
status: already_done
reasoning: "users table exists with correct schema"
existing_code: "migrations/20250101_create_users.sql"
action: "Check this task, no work needed"
```
**UNCLEAR** - Task is too vague:
```yaml
- task: "Improve user flow"
status: unclear
reasoning: "Ambiguous - what specifically needs improvement?"
action: "Refine to specific sub-tasks"
refinement:
- "Add loading states to user forms"
- "Add error toast on user creation failure"
- "Add success confirmation modal"
```
### 4. Generate Gap Analysis Report
Create report showing findings:
```markdown
## Pre-Gap Analysis Results
**Development Mode:** {greenfield|brownfield|hybrid}
**Task Analysis:**
### ✅ Tasks Ready for Implementation ({needed_count})
1. {task_1} - {reasoning}
2. {task_2} - {reasoning}
### ⚠️ Tasks Partially Implemented ({partial_count})
1. {task_1}
- Current: {existing_implementation}
- Needed: {what_to_add}
- File: {file_path}
### ✓ Tasks Already Complete ({done_count})
1. {task_1}
- Evidence: {existing_code_location}
- Action: Will check this task
### 🔍 Tasks Need Refinement ({unclear_count})
1. {original_vague_task}
- Issue: {why_unclear}
- Refined to:
- [ ] {specific_sub_task_1}
- [ ] {specific_sub_task_2}
### ➕ Missing Tasks Discovered ({missing_count})
1. {missing_task_1} - {why_needed}
2. {missing_task_2} - {why_needed}
**Summary:**
- Ready to implement: {needed_count}
- Need completion: {partial_count}
- Already done: {done_count}
- Need refinement: {unclear_count}
- Missing tasks: {missing_count}
**Total work remaining:** {work_count} tasks
```
### 5. Update Story File
**A. Check already-done tasks:**
```markdown
- [x] Create users table (verified in gap analysis)
```
**B. Refine unclear tasks:**
```markdown
~~- [ ] Improve user flow~~ (too vague)
Refined to:
- [ ] Add loading states to user forms
- [ ] Add error toast on user creation failure
- [ ] Add success confirmation modal
```
**C. Add missing tasks:**
```markdown
## Tasks (Updated after Pre-Gap Analysis)
{existing_tasks}
### Added from Gap Analysis
- [ ] {missing_task_1}
- [ ] {missing_task_2}
```
**D. Add Gap Analysis section:**
```markdown
## Gap Analysis
### Pre-Development Analysis
- **Date:** {timestamp}
- **Development Type:** {greenfield|brownfield|hybrid}
- **Existing Files:** {count}
- **New Files:** {count}
**Findings:**
- Tasks ready: {needed_count}
- Tasks partially done: {partial_count}
- Tasks already complete: {done_count}
- Tasks refined: {unclear_count}
- Tasks added: {missing_count}
**Codebase Scan:**
{list existing implementations found}
**Status:** Ready for implementation
```
### 6. Pattern Detection for Smart Batching (NEW!)
After validating tasks, detect repeating patterns that can be batched:
```typescript
interface TaskPattern {
pattern_name: string;
pattern_type: "package_install" | "module_registration" | "code_deletion" | "import_update" | "custom";
tasks: Task[];
batchable: boolean;
risk_level: "low" | "medium" | "high";
validation_strategy: string;
estimated_time_individual: number; // minutes if done one-by-one
estimated_time_batched: number; // minutes if batched
}
```
**Common Batchable Patterns:**
**Pattern: Package Installation**
```
Tasks like:
- [ ] Add @company/shared-utils to package.json
- [ ] Add @company/validation to package.json
- [ ] Add @company/http-client to package.json
Batchable: YES
Risk: LOW
Validation: npm install && npm run build
Time: 5 min batch vs 15 min individual (3x faster!)
```
**Pattern: Module Registration**
```
Tasks like:
- [ ] Import SharedUtilsModule in app.module.ts
- [ ] Import ValidationModule in app.module.ts
- [ ] Import HttpClientModule in app.module.ts
Batchable: YES
Risk: LOW
Validation: TypeScript compile
Time: 10 min batch vs 20 min individual (2x faster!)
```
**Pattern: Code Deletion**
```
Tasks like:
- [ ] Delete src/old-audit.service.ts
- [ ] Remove OldAuditModule from imports
- [ ] Delete src/old-cache.service.ts
Batchable: YES
Risk: LOW (tests will catch issues)
Validation: Build + test suite
Time: 15 min batch vs 30 min individual (2x faster!)
```
**Pattern: Business Logic (NOT batchable)**
```
Tasks like:
- [ ] Add circuit breaker fallback for WIS API
- [ ] Implement 3-tier caching for user data
- [ ] Add audit logging for theme updates
Batchable: NO
Risk: MEDIUM-HIGH (logic varies per case)
Validation: Per-task testing
Time: Execute individually with full rigor
```
**Detection Algorithm:**
```bash
# For each task, check if it matches a known pattern
for task in tasks; do
case "$task" in
*"Add @"*"to package.json"*)
pattern="package_install"
batchable=true
;;
*"Import"*"Module in app.module"*)
pattern="module_registration"
batchable=true
;;
*"Delete"*|*"Remove"*)
pattern="code_deletion"
batchable=true
;;
*"circuit breaker"*|*"fallback"*|*"caching for"*)
pattern="business_logic"
batchable=false
;;
*)
pattern="custom"
batchable=false # Default to safe
;;
esac
done
```
**Generate Batching Plan:**
```markdown
## Smart Batching Analysis
**Detected Patterns:**
### ✅ Batchable Patterns (Execute Together)
1. **Package Installation** (5 tasks)
- Add @dealer/audit-logging
- Add @dealer/http-client
- Add @dealer/caching
- Add @dealer/circuit-breaker
- Run pnpm install
Validation: Build succeeds
Time: 5 min (vs 10 min individual)
Risk: LOW
2. **Module Registration** (5 tasks)
- Import 5 modules
- Register in app.module
- Configure each
Validation: TypeScript compile
Time: 10 min (vs 20 min individual)
Risk: LOW
### ⚠️ Individual Execution Required
3. **Circuit Breaker Logic** (3 tasks)
- WIS API fallback strategy
- i18n client fallback
- Cache fallback
Reason: Fallback logic varies per API
Time: 60 min (cannot batch)
Risk: MEDIUM
**Total Estimated Time:**
- With smart batching: ~2.5 hours
- Without batching: ~5.5 hours
- Savings: 3 hours (54% faster!)
**Safety:**
- Batchable tasks: Validated as a group
- Individual tasks: Full rigor maintained
- No vibe coding: All validation gates enforced
```
### 7. Handle Approval (Interactive Mode Only)
**Interactive Mode:**
Display gap analysis report with conditional batching menu.
**CRITICAL DECISION LOGIC:**
- If `batchable_count > 0 AND time_saved > 0`: Show batching options
- If `batchable_count = 0 OR time_saved = 0`: Skip batching options (no benefit)
**When Batching Has Benefit (time_saved > 0):**
```
Gap Analysis Complete + Smart Batching Plan
Task Analysis:
- {done_count} tasks already complete (will check)
- {unclear_count} tasks refined to {refined_count} specific tasks
- {missing_count} new tasks added
- {needed_count} tasks ready for implementation
Smart Batching Detected:
- {batchable_count} tasks can be batched into {batch_count} pattern groups
- {individual_count} tasks require individual execution
- Estimated time savings: {time_saved} hours
Total work: {work_count} tasks
Estimated time: {estimated_hours} hours (with batching)
[A] Accept changes and batching plan
[B] Accept but disable batching (slower, safer)
[E] Edit tasks manually
[H] Halt pipeline
```
**When Batching Has NO Benefit (time_saved = 0):**
```
Gap Analysis Complete
Task Analysis:
- {done_count} tasks already complete (will check)
- {unclear_count} tasks refined to {refined_count} specific tasks
- {missing_count} new tasks added
- {needed_count} tasks ready for implementation
Smart Batching Analysis:
- Batchable patterns detected: 0
- Tasks requiring individual execution: {work_count}
- Estimated time savings: none (tasks require individual attention)
Total work: {work_count} tasks
Estimated time: {estimated_hours} hours
[A] Accept changes
[E] Edit tasks manually
[H] Halt pipeline
```
**Why Skip Batching Option When Benefit = 0:**
- Reduces decision fatigue
- Prevents pointless "batch vs no-batch" choice when outcome is identical
- Cleaner UX when batching isn't applicable
**Batch Mode:** Auto-accept changes (batching plan applied only if benefit > 0)
### 8. Update Story File with Batching Plan (Conditional)
**ONLY add batching plan if `time_saved > 0`.**
If batching has benefit (time_saved > 0), add batching plan to story file:
```markdown
## Smart Batching Plan
**Pattern Groups Detected:**
### Batch 1: Package Installation (5 tasks, 5 min)
- [ ] Add @company/shared-utils to package.json
- [ ] Add @company/validation to package.json
- [ ] Add @company/http-client to package.json
- [ ] Add @company/database-client to package.json
- [ ] Run npm install
**Validation:** Build succeeds
### Batch 2: Module Registration (5 tasks, 10 min)
{list tasks}
### Individual Tasks: Business Logic (15 tasks, 90 min)
{list tasks that can't be batched}
**Time Estimate:**
- With batching: {batched_time} hours
- Without batching: {individual_time} hours
- Savings: {savings} hours
```
If batching has NO benefit (time_saved = 0), **skip this section entirely** and just add gap analysis results.
### 9. Update Pipeline State
Update state file:
- Add `2` to `stepsCompleted`
- Set `lastStep: 2`
- Set `steps.step-02-pre-gap-analysis.status: completed`
- Record gap analysis results:
```yaml
gap_analysis:
development_type: "{mode}"
tasks_ready: {count}
tasks_partial: {count}
tasks_done: {count}
tasks_refined: {count}
tasks_added: {count}
smart_batching:
enabled: {true if time_saved > 0, false otherwise}
patterns_detected: {count}
batchable_tasks: {count}
individual_tasks: {count}
estimated_time_with_batching: {hours}
estimated_time_without_batching: {hours}
estimated_savings: {hours}
```
**Note:** `smart_batching.enabled` is set to `false` when batching has no benefit, preventing unnecessary batching plan generation.
### 10. Present Summary (Conditional Format)
**When Batching Has Benefit (time_saved > 0):**
```
Pre-Gap Analysis Complete + Smart Batching Plan
Development Type: {greenfield|brownfield|hybrid}
Work Remaining: {work_count} tasks
Codebase Status:
- Existing implementations reviewed: {existing_count}
- New implementations needed: {new_count}
Smart Batching Analysis:
- Batchable patterns detected: {batch_count}
- Tasks that can be batched: {batchable_count} ({percent}%)
- Tasks requiring individual execution: {individual_count}
Time Estimate:
- With smart batching: {batched_time} hours ⚡
- Without batching: {individual_time} hours
- Time savings: {savings} hours ({savings_percent}% faster!)
Ready for Implementation
```
**When Batching Has NO Benefit (time_saved = 0):**
```
Pre-Gap Analysis Complete
Development Type: {greenfield|brownfield|hybrid}
Work Remaining: {work_count} tasks
Codebase Status:
- Existing implementations reviewed: {existing_count}
- New implementations needed: {new_count}
Smart Batching Analysis:
- Batchable patterns detected: 0
- Tasks requiring individual execution: {work_count}
- Estimated time: {estimated_hours} hours
Ready for Implementation
```
**Interactive Mode Menu:**
```
[C] Continue to Implementation
[R] Re-run gap analysis
[H] Halt pipeline
```
**Batch Mode:** Auto-continue
## QUALITY GATE
Before proceeding:
- [ ] All tasks analyzed against codebase
- [ ] Vague tasks refined to specific actions
- [ ] Already-done tasks checked
- [ ] Missing tasks added
- [ ] Gap analysis section added to story
- [ ] Story file updated with refinements
## CRITICAL STEP COMPLETION
**ONLY WHEN** [all tasks analyzed AND story file updated],
load and execute `{nextStepFile}` for implementation.
---
## SUCCESS/FAILURE METRICS
### ✅ SUCCESS
- Every task analyzed against codebase
- Vague tasks made specific
- Missing work identified and added
- Already-done work verified
- Gap analysis documented
### ❌ FAILURE
- Skipping codebase scan
- Accepting vague tasks ("Add feature X")
- Not checking for existing implementations
- Missing obvious gaps
- No refinement of unclear tasks
## WHY THIS STEP PREVENTS VIBE CODING
Pre-gap analysis forces Claude to:
1. **Understand existing code** before implementing
2. **Be specific** about what to build
3. **Verify assumptions** against reality
4. **Plan work properly** instead of guessing
This is especially critical for **brownfield** where vibe coding causes:
- Breaking existing functionality
- Duplicating existing code
- Missing integration points
- Ignoring established patterns

248
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-03-write-tests.md
View File

@ -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(<UserDashboard user={mockUser} />);
expect(screen.getByText('John Doe')).toBeInTheDocument();
});
it('should render user email', () => {
render(<UserDashboard user={mockUser} />);
expect(screen.getByText('john@example.com')).toBeInTheDocument();
});
it('should render user avatar', () => {
render(<UserDashboard user={mockUser} />);
expect(screen.getByAltText('User avatar')).toBeInTheDocument();
});
});
describe('AC2: Allow user to edit profile', () => {
it('should show edit button when not in edit mode', () => {
render(<UserDashboard user={mockUser} />);
expect(screen.getByRole('button', { name: /edit/i })).toBeInTheDocument();
});
it('should enable edit mode when edit button clicked', () => {
render(<UserDashboard user={mockUser} />);
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(<UserDashboard user={mockUser} onSave={onSave} />);
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).

645
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-04-implement.md
View File

@ -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!
```
<critical>🚨 MANDATORY: CHECK OFF ALL BATCH TASKS IMMEDIATELY</critical>
**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:**
<critical>🚨 YOU MUST CHECK OFF THIS TASK IMMEDIATELY - NO EXCEPTIONS</critical>
```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:**
<critical>🚨 TASK COMPLETION VERIFICATION - WORKFLOW WILL HALT IF FAILED</critical>
**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.**

450
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-05-post-validation.md
View File

@ -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.

368
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-06-run-quality-checks.md
View File

@ -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.

337
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-07-code-review.md
View File

@ -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
<invoke-workflow path="{project-root}/_bmad/bmm/workflows/4-implementation/multi-agent-review/workflow.yaml">
<input name="story_id">{story_id}</input>
<input name="complexity_level">{complexity_level}</input>
<input name="fresh_context">true</input>
</invoke-workflow>
```
**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

327
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-08-review-analysis.md
View File

@ -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).

371
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-09-fix-issues.md
View File

@ -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!

370
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10-complete.md
View File

@ -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

279
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-10a-queue-commit.md
View File

@ -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
```

221
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-11-summary.md
View File

@ -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

407
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-12-extract-learnings.md
View File

@ -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" <<EOF
# Playbook Index
**Last Updated:** $(date +%Y-%m-%d)
**Total Playbooks:** $(ls -1 ${playbook_dir}/*-playbook.md 2>/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" <<ENTRY
### $basename
**Topics:** $topics
**Stories:** $stories
**Patterns:** $pattern_count patterns documented
**Last Updated:** $last_updated
ENTRY
done
echo "✅ Index updated: $(ls -1 ${playbook_dir}/*-playbook.md 2>/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}" <<EOF
---
technology: ${tech_or_domain}
keywords: [${tech_or_domain}]
source_stories: [${story_key}]
last_updated: $(date +%Y-%m-%d)
pattern_count: 0
pitfall_count: 0
practice_count: 0
---
# ${tech_or_domain^} Playbook
**Created from:** Story ${story_key}
## Best Practices
## Common Pitfalls
## Code Patterns
## Lessons Learned
EOF
echo "📝 Created new playbook: $playbook_name"
}
```
### update_playbook_section
```bash
update_playbook_section() {
playbook_file="$1"
section_name="$2" # "Best Practices", "Common Pitfalls", "Code Patterns"
new_content="$3"
if [ -z "$new_content" ]; then
return 0 # Nothing to add
fi
# Find section in file
# Append new content
# Use Edit tool for surgical update
echo "✏️ Updated section: $section_name in $(basename "$playbook_file")"
}
```
### update_frontmatter
```bash
update_frontmatter() {
playbook_file="$1"
story_key="$2"
# Update source_stories list (append if not already present)
# Increment pattern_count / pitfall_count / practice_count
# Update last_updated to today
# Use Edit tool to update frontmatter
echo "✏️ Updated frontmatter in $(basename "$playbook_file")"
}
```
---
## Success Criteria
**Step 12 succeeds when:**
- [x] Agent provided self-reflection
- [x] Learnings extracted and categorized
- [x] Playbooks updated or created
- [x] Index regenerated
- [x] Changes committed to git
**Step 12 can be skipped when:**
- Story completion < 80%
- No commit found
- Agent reflection yields no learnings
---
**Next:** Workflow complete. Story finished with learnings extracted for future benefit.

559
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.md
View File

@ -1,292 +1,375 @@
---
name: super-dev-pipeline
description: Step-file architecture for super-dev workflow - disciplined execution for both greenfield and brownfield development
web_bundle: true
---
# Super-Dev-Pipeline v2.0 - Multi-Agent Architecture
# Super-Dev Pipeline Workflow
**Goal:** Execute story development with disciplined step-file architecture that prevents "vibe coding" and works for both new features and existing codebase modifications.
**Your Role:** You are the **BMAD Pipeline Orchestrator**. You will follow each step file precisely, without deviation, optimization, or skipping ahead.
**Key Principle:** This workflow uses **step-file architecture** for disciplined execution that prevents Claude from veering off-course when token usage is high.
**Version:** 2.0.0
**Architecture:** GSDMAD (GSD + BMAD)
**Philosophy:** Trust but verify, separation of concerns
---
## WORKFLOW ARCHITECTURE
## Overview
This uses **step-file architecture** borrowed from story-pipeline:
This workflow implements a story using **4 independent agents** with external validation at each phase.
### Core Principles
- **Micro-file Design**: Each step is a self-contained instruction file (~150-300 lines)
- **Just-In-Time Loading**: Only the current step file is in memory
- **Mandatory Sequences**: Execute all numbered sections in order, never deviate
- **State Tracking**: Pipeline state in `{sprint_artifacts}/super-dev-state-{story_id}.yaml`
- **No Vibe Coding**: Explicit instructions prevent optimization/deviation
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
3. **QUALITY GATES**: Complete gate criteria before proceeding to next step
4. **WAIT FOR INPUT**: In interactive mode, halt at menus and wait for user selection
5. **SAVE STATE**: Update pipeline state file after each step completion
6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step
### Critical Rules (NO EXCEPTIONS)
- **NEVER** load multiple step files simultaneously
- **ALWAYS** read entire step file before execution
- **NEVER** skip steps or optimize the sequence
- **ALWAYS** update pipeline state after completing each step
- **ALWAYS** follow the exact instructions in the step file
- **NEVER** create mental todo lists from future steps
- **NEVER** look ahead to future step files
- **NEVER** vibe code when token usage is high - follow the steps exactly!
**Key Innovation:** Each agent has single responsibility and fresh context. No agent validates its own work.
---
## STEP FILE MAP
## Execution Flow
| Step | File | Agent | Purpose |
|------|------|-------|---------|
| 1 | step-01-init.md | - | Load story, detect greenfield vs brownfield |
| 2 | step-02-pre-gap-analysis.md | DEV | Validate tasks + **detect batchable patterns** |
| 3 | step-03-implement.md | DEV | **Smart batching** + adaptive implementation |
| 4 | step-04-post-validation.md | DEV | Verify completed tasks vs reality |
| 5 | step-05-code-review.md | DEV | Find 3-10 specific issues |
| 6 | step-06-complete.md | SM | Commit and push changes |
| 7 | step-07-summary.md | - | Audit trail generation |
---
## KEY DIFFERENCES FROM story-pipeline
### What's REMOVED:
- ❌ Step 2 (create-story) - assumes story already exists
- ❌ Step 4 (ATDD) - not mandatory for brownfield
### What's ENHANCED:
- ✅ Pre-gap analysis is MORE thorough (validates against existing code)
- ✅ **Smart Batching** - detects and groups similar tasks automatically
- ✅ Implementation is ADAPTIVE (TDD for new, refactor for existing)
- ✅ Works for both greenfield and brownfield
### What's NEW:
- ⚡ **Pattern Detection** - automatically identifies batchable tasks
- ⚡ **Intelligent Grouping** - groups similar tasks for batch execution
- ⚡ **Time Optimization** - 50-70% faster for repetitive work
- ⚡ **Safety Preserved** - validation gates enforce discipline
---
## SMART BATCHING FEATURE
### What is Smart Batching?
**Smart batching** is an intelligent optimization that groups similar, low-risk tasks for batch execution while maintaining full validation discipline.
**NOT Vibe Coding:**
- ✅ Pattern detection is systematic (not guesswork)
- ✅ Batches are validated as a group (not skipped)
- ✅ Failure triggers fallback to one-at-a-time
- ✅ High-risk tasks always executed individually
**When It Helps:**
- Large stories with repetitive tasks (100+ tasks)
- Package migration work (installing multiple packages)
- Module refactoring (same pattern across files)
- Code cleanup (delete old implementations)
**Time Savings:**
```
Example: 100-task story
- Without batching: 100 tasks × 2 min = 200 minutes (3.3 hours)
- With batching: 6 batches × 10 min + 20 individual × 2 min = 100 minutes (1.7 hours)
- Savings: 100 minutes (50% faster!)
┌─────────────────────────────────────────────────────────────┐
│ Main Orchestrator (Claude) │
│ - Loads story │
│ - Spawns agents sequentially │
│ - Verifies each phase │
│ - Final quality gate │
└─────────────────────────────────────────────────────────────┘
│
├──> Phase 1: Builder (Steps 1-4)
│ - Load story, analyze gaps
│ - Write tests (TDD)
│ - Implement code
│ - Report what was built (NO VALIDATION)
│
├──> Phase 2: Inspector (Steps 5-6)
│ - Fresh context, no Builder knowledge
│ - Verify files exist
│ - Run tests independently
│ - Run quality checks
│ - PASS or FAIL verdict
│
├──> Phase 3: Reviewer (Step 7)
│ - Fresh context, adversarial stance
│ - Find security vulnerabilities
│ - Find performance problems
│ - Find logic bugs
│ - Report issues with severity
│
├──> Phase 4: Fixer (Steps 8-9)
│ - Fix CRITICAL issues (all)
│ - Fix HIGH issues (all)
│ - Fix MEDIUM issues (if time)
│ - Skip LOW issues (gold-plating)
│ - Update story + sprint-status
│ - Commit changes
│
└──> Final Verification (Main)
- Check git commits exist
- Check story checkboxes updated
- Check sprint-status updated
- Check tests passed
- Mark COMPLETE or FAILED
```
### Batchable Pattern Types
---
| Pattern | Example Tasks | Risk | Validation |
|---------|--------------|------|------------|
| **Package Install** | Add dependencies | LOW | Build succeeds |
| **Module Registration** | Import modules | LOW | TypeScript compiles |
| **Code Deletion** | Remove old code | LOW | Tests pass |
| **Import Updates** | Update import paths | LOW | Build succeeds |
| **Config Changes** | Update settings | LOW | App starts |
## Agent Spawning Instructions
### NON-Batchable (Individual Execution)
### Phase 1: Spawn Builder
| Pattern | Example Tasks | Risk | Why Individual |
|---------|--------------|------|----------------|
| **Business Logic** | Circuit breaker fallbacks | MEDIUM-HIGH | Logic varies per case |
| **Security Code** | Auth/authorization | HIGH | Mistakes are critical |
| **Data Migrations** | Schema changes | HIGH | Irreversible |
| **API Integration** | External service calls | MEDIUM | Error handling varies |
| **Novel Patterns** | First-time implementation | MEDIUM | Unproven approach |
```javascript
Task({
subagent_type: "general-purpose",
description: "Implement story {{story_key}}",
prompt: `
You are the BUILDER agent for story {{story_key}}.
### How It Works
Load and execute: {agents_path}/builder.md
**Step 2 (Pre-Gap Analysis):**
1. Analyzes all tasks
2. Detects repeating patterns
3. Categorizes as batchable or individual
4. Generates batching plan with time estimates
5. Adds plan to story file
Story file: {{story_file}}
**Step 3 (Implementation):**
1. Loads batching plan
2. Executes pattern batches first
3. Validates each batch
4. Fallback to individual if batch fails
5. Executes individual tasks with full rigor
Complete Steps 1-4:
1. Init - Load story
2. Pre-Gap - Analyze what exists
3. Write Tests - TDD approach
4. Implement - Write production code
**Safety Mechanisms:**
- Pattern detection uses conservative rules (default to individual)
- Each batch has explicit validation strategy
- Failed batch triggers automatic fallback
- High-risk tasks never batched
- All validation gates still enforced
DO NOT:
- Validate your work
- Review your code
- Update checkboxes
- Commit changes
Just build it and report what you created.
`
});
```
**Wait for Builder to complete. Store agent_id in agent-history.json.**
### Phase 2: Spawn Inspector
```javascript
Task({
subagent_type: "general-purpose",
description: "Validate story {{story_key}} implementation",
prompt: `
You are the INSPECTOR agent for story {{story_key}}.
Load and execute: {agents_path}/inspector.md
Story file: {{story_file}}
You have NO KNOWLEDGE of what the Builder did.
Complete Steps 5-6:
5. Post-Validation - Verify files exist and have content
6. Quality Checks - Run type-check, lint, build, tests
Run all checks yourself. Don't trust Builder claims.
Output: PASS or FAIL verdict with evidence.
`
});
```
**Wait for Inspector to complete. If FAIL, halt pipeline.**
### Phase 3: Spawn Reviewer
```javascript
Task({
subagent_type: "bmad_bmm_multi-agent-review",
description: "Adversarial review of story {{story_key}}",
prompt: `
You are the ADVERSARIAL REVIEWER for story {{story_key}}.
Load and execute: {agents_path}/reviewer.md
Story file: {{story_file}}
Complexity: {{complexity_level}}
Your goal is to FIND PROBLEMS.
Complete Step 7:
7. Code Review - Find security, performance, logic issues
Be critical. Look for flaws.
Output: List of issues with severity ratings.
`
});
```
**Wait for Reviewer to complete. Parse issues by severity.**
### Phase 4: Spawn Fixer
```javascript
Task({
subagent_type: "general-purpose",
description: "Fix issues in story {{story_key}}",
prompt: `
You are the FIXER agent for story {{story_key}}.
Load and execute: {agents_path}/fixer.md
Story file: {{story_file}}
Review issues: {{review_findings}}
Complete Steps 8-9:
8. Review Analysis - Categorize issues, filter gold-plating
9. Fix Issues - Fix CRITICAL/HIGH, consider MEDIUM, skip LOW
After fixing:
- Update story checkboxes
- Update sprint-status.yaml
- Commit with descriptive message
Output: Fix summary with git commit hash.
`
});
```
**Wait for Fixer to complete.**
---
## EXECUTION MODES
## Final Verification (Main Orchestrator)
**After all agents complete, verify:**
### Interactive Mode (Default)
```bash
bmad super-dev-pipeline
# 1. Check git commits
git log --oneline -3 | grep "{{story_key}}"
if [ $? -ne 0 ]; then
echo "❌ FAILED: No commit found"
exit 1
fi
# 2. Check story checkboxes
before=$(git show HEAD~1:{{story_file}} | grep -c '^- \[x\]')
after=$(grep -c '^- \[x\]' {{story_file}})
if [ $after -le $before ]; then
echo "❌ FAILED: Checkboxes not updated"
exit 1
fi
# 3. Check sprint-status
git diff HEAD~1 {{sprint_status}} | grep "{{story_key}}: done"
if [ $? -ne 0 ]; then
echo "❌ FAILED: Sprint status not updated"
exit 1
fi
# 4. Check Inspector output for test evidence
grep -E "PASS|tests.*passing" inspector_output.txt
if [ $? -ne 0 ]; then
echo "❌ FAILED: No test evidence"
exit 1
fi
echo "✅ STORY COMPLETE - All verifications passed"
```
Features:
- Menu navigation between steps
- User approval at quality gates
- Can pause and resume
---
### Batch Mode (For batch-super-dev)
```bash
bmad super-dev-pipeline --batch
## Benefits Over Single-Agent
### Separation of Concerns
- Builder doesn't validate own work
- Inspector has no incentive to lie
- Reviewer approaches with fresh eyes
- Fixer can't skip issues
### Fresh Context Each Phase
- Each agent starts at 0% context
- No accumulated fatigue
- No degraded quality
- Honest reporting
### Adversarial Review
- Reviewer WANTS to find issues
- Not defensive about the code
- More thorough than self-review
### Honest Verification
- Inspector runs tests independently
- Main orchestrator verifies everything
- Can't fake completion
---
## Complexity Routing
**MICRO stories:**
- Skip Reviewer (low risk)
- 2 agents: Builder → Inspector → Fixer
**STANDARD stories:**
- Full pipeline
- 4 agents: Builder → Inspector → Reviewer → Fixer
**COMPLEX stories:**
- Enhanced review (6 reviewers instead of 4)
- Full pipeline + extra scrutiny
- 4 agents: Builder → Inspector → Reviewer (enhanced) → Fixer
---
## Agent Tracking
Track all agents in `agent-history.json`:
```json
{
"version": "1.0",
"max_entries": 50,
"entries": [
{
"agent_id": "abc123",
"story_key": "17-10",
"phase": "builder",
"steps": [1,2,3,4],
"timestamp": "2026-01-25T21:00:00Z",
"status": "completed",
"completion_timestamp": "2026-01-25T21:15:00Z"
},
{
"agent_id": "def456",
"story_key": "17-10",
"phase": "inspector",
"steps": [5,6],
"timestamp": "2026-01-25T21:16:00Z",
"status": "completed",
"completion_timestamp": "2026-01-25T21:20:00Z"
}
]
}
```
Features:
- Auto-proceed through all steps
- Fail-fast on errors
- No vibe coding even at high token counts
**Benefits:**
- Resume interrupted sessions
- Track agent performance
- Debug failed pipelines
- Audit trail
---
## INITIALIZATION SEQUENCE
## Error Handling
### 1. Configuration Loading
**If Builder fails:**
- Don't spawn Inspector
- Report failure to user
- Option to resume or retry
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
- `output_folder`, `sprint_artifacts`, `communication_language`
**If Inspector fails:**
- Don't spawn Reviewer
- Report specific failures
- Resume Builder to fix issues
### 2. Pipeline Parameters
**If Reviewer finds CRITICAL issues:**
- Must spawn Fixer (not optional)
- Cannot mark story complete until fixed
Resolve from invocation:
- `story_id`: Story identifier (e.g., "1-4")
- `story_file`: Path to story file (must exist!)
- `mode`: "interactive" or "batch"
### 3. Document Pre-loading
Load and cache these documents (read once, use across steps):
- Story file: Required, must exist
- Project context: `**/project-context.md`
- Epic file: Optional, for context
### 4. First Step Execution
Load, read the full file and then execute:
`{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md`
**If Fixer fails:**
- Report unfixed issues
- Cannot mark story complete
- Manual intervention required
---
## QUALITY GATES
## Comparison: v1.x vs v2.0
Each gate must pass before proceeding:
### Pre-Gap Analysis Gate (Step 2)
- [ ] All tasks validated against codebase
- [ ] Existing code analyzed
- [ ] Tasks refined if needed
- [ ] No missing context
### Implementation Gate (Step 3)
- [ ] All tasks completed
- [ ] Tests pass
- [ ] Code follows project patterns
- [ ] No TypeScript errors
### Post-Validation Gate (Step 4)
- [ ] All completed tasks verified against codebase
- [ ] Zero false positives (or re-implementation complete)
- [ ] Files/functions/tests actually exist
- [ ] Tests actually pass (not just claimed)
### Code Review Gate (Step 5)
- [ ] 3-10 specific issues identified (not "looks good")
- [ ] All issues resolved or documented
- [ ] Security review complete
| Aspect | v1.x (Single-Agent) | v2.0 (Multi-Agent) |
|--------|--------------------|--------------------|
| Agents | 1 | 4 |
| Validation | Self (conflict of interest) | Independent (no conflict) |
| Code Review | Self-review | Adversarial (fresh eyes) |
| Honesty | Low (can lie) | High (verified) |
| Context | Degrades over 11 steps | Fresh each phase |
| Catches Issues | Low | High |
| Completion Accuracy | ~60% (agents lie) | ~95% (verified) |
---
## ANTI-VIBE-CODING ENFORCEMENT
## Migration from v1.x
This workflow **prevents vibe coding** through:
**Backward Compatibility:**
```yaml
execution_mode: "single_agent" # Use v1.x
execution_mode: "multi_agent" # Use v2.0 (new)
```
1. **Mandatory Sequence**: Can't skip ahead or optimize
2. **Micro-file Loading**: Only current step in memory
3. **Quality Gates**: Must pass criteria to proceed
4. **State Tracking**: Progress is recorded and verified
5. **Explicit Instructions**: No interpretation required
**Even at 200K tokens**, Claude must:
- ✅ Read entire step file
- ✅ Follow numbered sequence
- ✅ Complete quality gate
- ✅ Update state
- ✅ Load next step
**No shortcuts. No optimizations. No vibe coding.**
**Gradual Rollout:**
1. Week 1: Test v2.0 on 3-5 stories
2. Week 2: Make v2.0 default for new stories
3. Week 3: Migrate existing stories to v2.0
4. Week 4: Deprecate v1.x
---
## SUCCESS METRICS
## Hospital-Grade Standards
### ✅ SUCCESS
- Pipeline completes all 7 steps
- All quality gates passed
- Story status updated
- Git commit created
- Audit trail generated
- **No vibe coding occurred**
⚕️ **Lives May Be at Stake**
### ❌ FAILURE
- Step file instructions skipped or optimized
- Quality gate bypassed without approval
- State file not updated
- Tests not verified
- Code review accepts "looks good"
- **Vibe coding detected**
- Independent validation catches errors
- Adversarial review finds security flaws
- Multiple checkpoints prevent shortcuts
- Final verification prevents false completion
**QUALITY >> SPEED**
---
## COMPARISON WITH OTHER WORKFLOWS
| Feature | super-dev-story | story-pipeline | super-dev-pipeline |
|---------|----------------|----------------|-------------------|
| Architecture | Orchestration | Step-files | Step-files |
| Story creation | Separate workflow | Included | ❌ Not included |
| ATDD mandatory | No | Yes | No (adaptive) |
| Greenfield | ✅ | ✅ | ✅ |
| Brownfield | ✅ | ❌ Limited | ✅ |
| Token efficiency | ~100-150K | ~25-30K | ~40-60K |
| Vibe-proof | ❌ | ✅ | ✅ |
---
**super-dev-pipeline is the best of both worlds for batch-super-dev!**
**Key Takeaway:** Don't trust a single agent to build, validate, review, and commit its own work. Use independent agents with fresh context at each phase.

376
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml
View File

@ -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

218
src/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml.backup
View File

@ -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

4
test/TODO-WORKFLOW-TESTS.md
View File

@ -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