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
parent
b4217ba65f
commit
d3bf02a0af
|
|
@ -394,7 +394,7 @@ validation:
|
||||||
fixer: {steps: [8,9]}
|
fixer: {steps: [8,9]}
|
||||||
```
|
```
|
||||||
|
|
||||||
### Enhanced: `super-dev-pipeline-v2.md`
|
### Enhanced: `super-dev-pipeline.md`
|
||||||
```yaml
|
```yaml
|
||||||
execution_mode: "multi_agent" # single_agent | multi_agent
|
execution_mode: "multi_agent" # single_agent | multi_agent
|
||||||
|
|
||||||
|
|
@ -488,7 +488,7 @@ agents:
|
||||||
---
|
---
|
||||||
|
|
||||||
**Next Steps:**
|
**Next Steps:**
|
||||||
1. Create `super-dev-pipeline-v2/` directory
|
1. Create `super-dev-pipeline/` directory
|
||||||
2. Write agent prompt files
|
2. Write agent prompt files
|
||||||
3. Update `batch-super-dev` for wave execution
|
3. Update `batch-super-dev` for wave execution
|
||||||
4. Test on Epic 17 stories
|
4. Test on Epic 17 stories
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
{
|
{
|
||||||
"$schema": "https://json.schemastore.org/package.json",
|
"$schema": "https://json.schemastore.org/package.json",
|
||||||
"name": "@jonahschulte/bmad-method",
|
"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)",
|
"description": "Breakthrough Method of Agile AI-driven Development (Enhanced with TDD, intelligent multi-agent review, and production-hardened enforcement)",
|
||||||
"keywords": [
|
"keywords": [
|
||||||
"agile",
|
"agile",
|
||||||
|
|
|
||||||
|
|
@ -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)"
|
description: "Multi-agent pipeline with wave-based execution, independent validation, and adversarial code review (GSDMAD)"
|
||||||
author: "BMAD Method + GSD"
|
author: "BMAD Method + GSD"
|
||||||
version: "2.0.0"
|
version: "2.0.0"
|
||||||
|
|
@ -14,7 +14,7 @@ communication_language: "{config_source}:communication_language"
|
||||||
date: system-generated
|
date: system-generated
|
||||||
|
|
||||||
# Workflow paths
|
# 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"
|
agents_path: "{installed_path}/agents"
|
||||||
steps_path: "{installed_path}/steps"
|
steps_path: "{installed_path}/steps"
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -889,71 +889,35 @@ QUALITY OVER SPEED: Taking time to ensure correctness.
|
||||||
</substep>
|
</substep>
|
||||||
|
|
||||||
<ask>
|
<ask>
|
||||||
**Choose execution strategy:**
|
**How should these stories be processed?**
|
||||||
|
|
||||||
{{#if waves.length > 1}}
|
Options:
|
||||||
[W] WAVE-BASED PARALLEL (Recommended)
|
- **S**: Sequential - Run stories one-by-one (Task agent finishes before next starts)
|
||||||
- Respects dependencies between stories
|
- **P**: Parallel - Run stories concurrently (Multiple Task agents running simultaneously)
|
||||||
- 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}}
|
|
||||||
|
|
||||||
[S] SEQUENTIAL
|
**Note:** Both modes use Task agents to keep story context out of the main thread.
|
||||||
- Process stories one-by-one in this session
|
The only difference is the number running at once.
|
||||||
- Easier to monitor and debug
|
|
||||||
- Estimated time: {{sequential_time}}
|
|
||||||
- Best for: When you want full control
|
|
||||||
|
|
||||||
{{#if waves.length == 1}}
|
Enter: S or P
|
||||||
[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
|
|
||||||
</ask>
|
</ask>
|
||||||
|
|
||||||
<action>Capture response as: execution_strategy</action>
|
<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'">
|
<check if="execution_strategy == 's' OR execution_strategy == 'S'">
|
||||||
<action>Set execution_mode = "sequential"</action>
|
<action>Set execution_mode = "sequential"</action>
|
||||||
<action>Set parallel_count = 1</action>
|
<action>Set parallel_count = 1</action>
|
||||||
<action>Set use_task_agents = false</action>
|
<action>Set use_task_agents = true</action>
|
||||||
<action>Set wave_execution = false</action>
|
<output>
|
||||||
<output>✅ Sequential mode selected - stories will be processed one-by-one in this session</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>
|
||||||
|
|
||||||
<check if="execution_strategy == 'p' OR execution_strategy == 'P'">
|
<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 use_task_agents = true</action>
|
||||||
<action>Set wave_execution = false</action>
|
|
||||||
|
|
||||||
<ask>
|
<ask>
|
||||||
**How many agents should run in parallel?**
|
**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">
|
<check if="parallel_count was capped at 10">
|
||||||
<output>⚠️ Requested {{original_count}} agents, capped at 10 (safety limit)</output>
|
<output>⚠️ Requested {{original_count}} agents, capped at 10 (safety limit)</output>
|
||||||
</check>
|
</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>
|
</check>
|
||||||
|
|
||||||
<output>
|
<output>
|
||||||
## ⚙️ Execution Plan
|
## ⚙️ Execution Plan
|
||||||
|
|
||||||
**Mode:** {{execution_mode}}
|
**Mode:** {{execution_mode}}
|
||||||
{{#if use_task_agents}}
|
**Task Agents:** {{parallel_count}} {{#if parallel_count > 1}}running concurrently{{else}}running sequentially{{/if}}
|
||||||
**Task Agents:** {{parallel_count}} running concurrently
|
|
||||||
**Agent Type:** general-purpose (autonomous)
|
**Agent Type:** general-purpose (autonomous)
|
||||||
{{else}}
|
|
||||||
**Sequential processing** in current session
|
|
||||||
{{/if}}
|
|
||||||
|
|
||||||
**Stories to process:** {{count}}
|
**Stories to process:** {{count}}
|
||||||
**Estimated total time:**
|
**Estimated total time:**
|
||||||
{{#if use_task_agents}}
|
{{#if parallel_count > 1}}
|
||||||
- With {{parallel_count}} agents: {{estimated_hours / parallel_count}} hours
|
- With {{parallel_count}} agents: {{estimated_hours / parallel_count}} hours
|
||||||
{{else}}
|
{{else}}
|
||||||
- Sequential: {{estimated_hours}} hours
|
- Sequential: {{estimated_hours}} hours
|
||||||
{{/if}}
|
{{/if}}
|
||||||
|
|
||||||
|
**Complexity Routing:**
|
||||||
|
{{#each stories_by_complexity}}
|
||||||
|
- {{complexity}}: {{count}} stories ({{pipeline_description}})
|
||||||
|
{{/each}}
|
||||||
</output>
|
</output>
|
||||||
|
|
||||||
<ask>Confirm execution plan? (yes/no):</ask>
|
<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>Initialize counters: completed=0, failed=0, failed_stories=[], reconciliation_warnings=[], reconciliation_warnings_count=0</action>
|
||||||
<action>Set start_time = current timestamp</action>
|
<action>Set start_time = current timestamp</action>
|
||||||
|
|
||||||
<check if="wave_execution == true">
|
<check if="parallel_count == 1">
|
||||||
<action>Jump to Step 4-Wave (Wave-based execution)</action>
|
<action>Jump to Step 4-Sequential (Task agents, one at a time)</action>
|
||||||
</check>
|
</check>
|
||||||
|
|
||||||
<check if="use_task_agents == true AND wave_execution == false">
|
<check if="parallel_count > 1 AND waves.length > 1">
|
||||||
<action>Jump to Step 4-Parallel (Full parallel execution)</action>
|
<action>Jump to Step 4-Wave (Task agents, wave-based parallel)</action>
|
||||||
</check>
|
</check>
|
||||||
|
|
||||||
<check if="use_task_agents == false">
|
<check if="parallel_count > 1 AND waves.length <= 1">
|
||||||
<action>Continue to Step 4-Sequential (In-session execution)</action>
|
<action>Jump to Step 4-Parallel (Task agents, multiple concurrent)</action>
|
||||||
</check>
|
</check>
|
||||||
</step>
|
</step>
|
||||||
|
|
||||||
|
|
@ -1028,98 +999,302 @@ Enter number (2-10) or 'all':
|
||||||
🚀 WAVE-BASED PARALLEL PROCESSING STARTED
|
🚀 WAVE-BASED PARALLEL PROCESSING STARTED
|
||||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
**Stories:** {{count}}
|
**Stories:** {{count}}
|
||||||
**Mode:** Wave-based (respects dependencies)
|
**Total waves:** {{waves.length}}
|
||||||
**Waves:** {{waves.length}}
|
**Mode:** Task agents (parallel by wave)
|
||||||
|
**Max concurrent agents:** {{parallel_count}}
|
||||||
**Continue on failure:** {{continue_on_failure}}
|
**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>
|
</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>
|
<output>
|
||||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
📦 Wave {{wave_num}}/{{waves.length}} ({{stories_in_wave}} stories)
|
🌊 STARTING WAVE {{@index}}
|
||||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
|
Stories in this wave:
|
||||||
{{#each stories_in_wave}}
|
{{#each stories}}
|
||||||
- {{story_key}}
|
- {{story_key}}{{#if depends_on}} (depends on: {{depends_on}}){{/if}}
|
||||||
{{/each}}
|
{{/each}}
|
||||||
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
Spawning {{stories_in_wave.length}} parallel agents...
|
|
||||||
</output>
|
</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>
|
<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"
|
- subagent_type: "general-purpose"
|
||||||
- description: "Implement story {{story_key}}"
|
- 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
|
Story file: docs/sprint-artifacts/{{story_key}}.md
|
||||||
Complexity: {{complexity_level}}
|
Complexity: {{complexity_level}}
|
||||||
Mode: batch, wave {{wave_num}}
|
Mode: batch
|
||||||
|
|
||||||
Follow all 11 steps, commit when complete, report status."
|
Load workflow: /Users/jonahschulte/git/BMAD-METHOD/src/modules/bmm/workflows/4-implementation/super-dev-pipeline
|
||||||
- Store agent_id
|
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>
|
||||||
|
|
||||||
<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">
|
<iterate>While active_workers.size > 0 OR next_story_index < wave_queue.length:</iterate>
|
||||||
<output>✅ Wave {{wave_num}} - Story complete: {{story_key}}</output>
|
|
||||||
<action>Increment completed counter</action>
|
<action>Poll for completed workers (check task outputs non-blocking):</action>
|
||||||
<action>Execute Step 4.5: Reconciliation</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>
|
||||||
|
|
||||||
<check if="agent failed">
|
<check if="worker task completed successfully">
|
||||||
<output>❌ Wave {{wave_num}} - Story failed: {{story_key}}</output>
|
<action>Get worker details: story_key = active_workers[worker_id].story_key</action>
|
||||||
<action>Increment failed counter</action>
|
|
||||||
<action>Add to failed_stories list</action>
|
|
||||||
|
|
||||||
<check if="continue_on_failure == false">
|
<output>✅ Worker {{worker_id}} completed: {{story_key}}</output>
|
||||||
<output>⚠️ Stopping all waves due to failure</output>
|
|
||||||
<action>Jump to Step 5 (Summary)</action>
|
<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>
|
</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>
|
<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>
|
</output>
|
||||||
|
|
||||||
|
<action>Sleep 5 seconds before next poll (prevents tight loop)</action>
|
||||||
|
|
||||||
</substep>
|
</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>
|
<action>After all waves processed, jump to Step 5 (Summary)</action>
|
||||||
</step>
|
</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>
|
<output>
|
||||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
🚀 SEQUENTIAL BATCH PROCESSING STARTED
|
🚀 SEQUENTIAL BATCH PROCESSING STARTED
|
||||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
**Stories:** {{count}}
|
**Stories:** {{count}}
|
||||||
**Mode:** super-dev-pipeline (batch, sequential)
|
**Mode:** Task agents (sequential, one at a time)
|
||||||
**Continue on failure:** {{continue_on_failure}}
|
**Continue on failure:** {{continue_on_failure}}
|
||||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
</output>
|
</output>
|
||||||
|
|
||||||
<iterate>For each story in selected_stories:</iterate>
|
<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>
|
<output>
|
||||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
📦 Story {{current_index}}/{{total_count}}: {{story_key}}
|
📦 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>
|
</output>
|
||||||
|
|
||||||
<action>Invoke workflow: /bmad:bmm:workflows:super-dev-pipeline</action>
|
<action>
|
||||||
<action>Parameters: mode=batch, story_key={{story_key}}, complexity_level={{story_key}}.complexity.level</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>
|
<output>✅ Implementation complete: {{story_key}}</output>
|
||||||
|
|
||||||
<action>Execute Step 4.5: Smart Story Reconciliation</action>
|
<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}}"
|
- description: "Implement story {{story_key}}"
|
||||||
- prompt: "Execute super-dev-pipeline workflow for story {{story_key}}.
|
- prompt: "Execute super-dev-pipeline workflow for story {{story_key}}.
|
||||||
|
|
||||||
CRITICAL INSTRUCTIONS:
|
Story file: docs/sprint-artifacts/{{story_key}}.md
|
||||||
1. Load workflow.xml: _bmad/core/tasks/workflow.xml
|
Complexity: {{complexity_level}}
|
||||||
2. Load workflow config: _bmad/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml
|
Mode: batch
|
||||||
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 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)
|
- run_in_background: true (non-blocking - critical for semaphore pattern)
|
||||||
|
|
||||||
Store in active_workers[worker_id]:
|
Store in active_workers[worker_id]:
|
||||||
|
|
|
||||||
|
|
@ -15,7 +15,7 @@ instructions: "{installed_path}/instructions.md"
|
||||||
|
|
||||||
# Input parameters
|
# Input parameters
|
||||||
story_id: "{story_id}" # Required
|
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
|
base_branch: "main" # Optional: branch to compare against
|
||||||
complexity_level: "standard" # micro | standard | complex (passed from super-dev-pipeline)
|
complexity_level: "standard" # micro | standard | complex (passed from super-dev-pipeline)
|
||||||
|
|
||||||
|
|
@ -54,4 +54,4 @@ review_settings:
|
||||||
# Output
|
# Output
|
||||||
review_report: "{sprint_artifacts}/review-{story_id}-multi-agent.md"
|
review_report: "{sprint_artifacts}/review-{story_id}-multi-agent.md"
|
||||||
|
|
||||||
standalone: true
|
standalone: true
|
||||||
|
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -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
|
|
||||||
File diff suppressed because it is too large
Load Diff
|
|
@ -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
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -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.**
|
|
||||||
|
|
@ -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.**
|
**Multi-agent pipeline with independent validation and adversarial code review**
|
||||||
|
|
||||||
## 🎯 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).
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
**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.
|
||||||
|
|
|
||||||
|
|
@ -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
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -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
|
|
||||||
|
|
@ -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).
|
|
||||||
|
|
@ -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.**
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -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
|
|
||||||
|
|
@ -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).
|
|
||||||
|
|
@ -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!
|
|
||||||
|
|
@ -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
|
|
||||||
|
|
@ -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
|
|
||||||
```
|
|
||||||
|
|
@ -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
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -1,292 +1,375 @@
|
||||||
---
|
# Super-Dev-Pipeline v2.0 - Multi-Agent Architecture
|
||||||
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 Workflow
|
**Version:** 2.0.0
|
||||||
|
**Architecture:** GSDMAD (GSD + BMAD)
|
||||||
**Goal:** Execute story development with disciplined step-file architecture that prevents "vibe coding" and works for both new features and existing codebase modifications.
|
**Philosophy:** Trust but verify, separation of concerns
|
||||||
|
|
||||||
**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.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 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
|
**Key Innovation:** Each agent has single responsibility and fresh context. No agent validates its own work.
|
||||||
|
|
||||||
- **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!
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 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)
|
│ Main Orchestrator (Claude) │
|
||||||
- With batching: 6 batches × 10 min + 20 individual × 2 min = 100 minutes (1.7 hours)
|
│ - Loads story │
|
||||||
- Savings: 100 minutes (50% faster!)
|
│ - 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 |
|
## Agent Spawning Instructions
|
||||||
|---------|--------------|------|------------|
|
|
||||||
| **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 |
|
|
||||||
|
|
||||||
### NON-Batchable (Individual Execution)
|
### Phase 1: Spawn Builder
|
||||||
|
|
||||||
| Pattern | Example Tasks | Risk | Why Individual |
|
```javascript
|
||||||
|---------|--------------|------|----------------|
|
Task({
|
||||||
| **Business Logic** | Circuit breaker fallbacks | MEDIUM-HIGH | Logic varies per case |
|
subagent_type: "general-purpose",
|
||||||
| **Security Code** | Auth/authorization | HIGH | Mistakes are critical |
|
description: "Implement story {{story_key}}",
|
||||||
| **Data Migrations** | Schema changes | HIGH | Irreversible |
|
prompt: `
|
||||||
| **API Integration** | External service calls | MEDIUM | Error handling varies |
|
You are the BUILDER agent for story {{story_key}}.
|
||||||
| **Novel Patterns** | First-time implementation | MEDIUM | Unproven approach |
|
|
||||||
|
|
||||||
### How It Works
|
Load and execute: {agents_path}/builder.md
|
||||||
|
|
||||||
**Step 2 (Pre-Gap Analysis):**
|
Story file: {{story_file}}
|
||||||
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
|
|
||||||
|
|
||||||
**Step 3 (Implementation):**
|
Complete Steps 1-4:
|
||||||
1. Loads batching plan
|
1. Init - Load story
|
||||||
2. Executes pattern batches first
|
2. Pre-Gap - Analyze what exists
|
||||||
3. Validates each batch
|
3. Write Tests - TDD approach
|
||||||
4. Fallback to individual if batch fails
|
4. Implement - Write production code
|
||||||
5. Executes individual tasks with full rigor
|
|
||||||
|
|
||||||
**Safety Mechanisms:**
|
DO NOT:
|
||||||
- Pattern detection uses conservative rules (default to individual)
|
- Validate your work
|
||||||
- Each batch has explicit validation strategy
|
- Review your code
|
||||||
- Failed batch triggers automatic fallback
|
- Update checkboxes
|
||||||
- High-risk tasks never batched
|
- Commit changes
|
||||||
- All validation gates still enforced
|
|
||||||
|
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
|
```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)
|
## Benefits Over Single-Agent
|
||||||
```bash
|
|
||||||
bmad super-dev-pipeline --batch
|
### 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:
|
**Benefits:**
|
||||||
- Auto-proceed through all steps
|
- Resume interrupted sessions
|
||||||
- Fail-fast on errors
|
- Track agent performance
|
||||||
- No vibe coding even at high token counts
|
- 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:
|
**If Inspector fails:**
|
||||||
- `output_folder`, `sprint_artifacts`, `communication_language`
|
- 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:
|
**If Fixer fails:**
|
||||||
- `story_id`: Story identifier (e.g., "1-4")
|
- Report unfixed issues
|
||||||
- `story_file`: Path to story file (must exist!)
|
- Cannot mark story complete
|
||||||
- `mode`: "interactive" or "batch"
|
- Manual intervention required
|
||||||
|
|
||||||
### 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`
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## QUALITY GATES
|
## Comparison: v1.x vs v2.0
|
||||||
|
|
||||||
Each gate must pass before proceeding:
|
| Aspect | v1.x (Single-Agent) | v2.0 (Multi-Agent) |
|
||||||
|
|--------|--------------------|--------------------|
|
||||||
### Pre-Gap Analysis Gate (Step 2)
|
| Agents | 1 | 4 |
|
||||||
- [ ] All tasks validated against codebase
|
| Validation | Self (conflict of interest) | Independent (no conflict) |
|
||||||
- [ ] Existing code analyzed
|
| Code Review | Self-review | Adversarial (fresh eyes) |
|
||||||
- [ ] Tasks refined if needed
|
| Honesty | Low (can lie) | High (verified) |
|
||||||
- [ ] No missing context
|
| Context | Degrades over 11 steps | Fresh each phase |
|
||||||
|
| Catches Issues | Low | High |
|
||||||
### Implementation Gate (Step 3)
|
| Completion Accuracy | ~60% (agents lie) | ~95% (verified) |
|
||||||
- [ ] 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
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 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
|
**Gradual Rollout:**
|
||||||
2. **Micro-file Loading**: Only current step in memory
|
1. Week 1: Test v2.0 on 3-5 stories
|
||||||
3. **Quality Gates**: Must pass criteria to proceed
|
2. Week 2: Make v2.0 default for new stories
|
||||||
4. **State Tracking**: Progress is recorded and verified
|
3. Week 3: Migrate existing stories to v2.0
|
||||||
5. **Explicit Instructions**: No interpretation required
|
4. Week 4: Deprecate v1.x
|
||||||
|
|
||||||
**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.**
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## SUCCESS METRICS
|
## Hospital-Grade Standards
|
||||||
|
|
||||||
### ✅ SUCCESS
|
⚕️ **Lives May Be at Stake**
|
||||||
- Pipeline completes all 7 steps
|
|
||||||
- All quality gates passed
|
|
||||||
- Story status updated
|
|
||||||
- Git commit created
|
|
||||||
- Audit trail generated
|
|
||||||
- **No vibe coding occurred**
|
|
||||||
|
|
||||||
### ❌ FAILURE
|
- Independent validation catches errors
|
||||||
- Step file instructions skipped or optimized
|
- Adversarial review finds security flaws
|
||||||
- Quality gate bypassed without approval
|
- Multiple checkpoints prevent shortcuts
|
||||||
- State file not updated
|
- Final verification prevents false completion
|
||||||
- Tests not verified
|
|
||||||
- Code review accepts "looks good"
|
**QUALITY >> SPEED**
|
||||||
- **Vibe coding detected**
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## COMPARISON WITH OTHER WORKFLOWS
|
**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.
|
||||||
|
|
||||||
| 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!**
|
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,10 @@
|
||||||
name: super-dev-pipeline
|
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."
|
description: "Multi-agent pipeline with wave-based execution, independent validation, and adversarial code review (GSDMAD)"
|
||||||
author: "BMad"
|
author: "BMAD Method + GSD"
|
||||||
version: "1.6.0" # Adds learning feedback loop (Step 1b load playbooks, Step 12 extract learnings)
|
version: "2.0.0"
|
||||||
|
|
||||||
|
# Execution mode
|
||||||
|
execution_mode: "multi_agent" # multi_agent | single_agent (fallback)
|
||||||
|
|
||||||
# Critical variables from config
|
# Critical variables from config
|
||||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||||
|
|
@ -12,308 +15,107 @@ date: system-generated
|
||||||
|
|
||||||
# Workflow paths
|
# Workflow paths
|
||||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
|
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
|
||||||
|
agents_path: "{installed_path}/agents"
|
||||||
steps_path: "{installed_path}/steps"
|
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 management
|
||||||
state_file: "{sprint_artifacts}/super-dev-state-{{story_id}}.yaml"
|
state_file: "{sprint_artifacts}/super-dev-state-{{story_id}}.yaml"
|
||||||
audit_trail: "{sprint_artifacts}/audit-super-dev-{{story_id}}-{{date}}.yaml"
|
audit_trail: "{sprint_artifacts}/audit-super-dev-{{story_id}}-{{date}}.yaml"
|
||||||
|
|
||||||
# Auto-create story settings (NEW v1.4.0)
|
# Multi-agent configuration
|
||||||
# When story is missing or lacks proper context, auto-invoke /create-story-with-gap-analysis
|
agents:
|
||||||
auto_create_story:
|
builder:
|
||||||
enabled: true # Set to false to revert to old HALT behavior
|
description: "Implementation agent - writes code and tests"
|
||||||
create_story_workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story-with-gap-analysis"
|
steps: [1, 2, 3, 4]
|
||||||
triggers:
|
subagent_type: "general-purpose"
|
||||||
- story_not_found # Story file doesn't exist
|
prompt_file: "{agents_path}/builder.md"
|
||||||
- no_tasks # Story exists but has no tasks
|
trust_level: "low" # Assumes agent will cut corners
|
||||||
- missing_sections # Story missing required sections (Tasks, Acceptance Criteria)
|
timeout: 3600 # 1 hour
|
||||||
|
|
||||||
# Complexity level (passed from batch-super-dev or set manually)
|
inspector:
|
||||||
# Controls which pipeline steps to execute
|
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_level: "standard" # micro | standard | complex
|
||||||
|
|
||||||
# Risk-based complexity routing (UPDATED v1.5.0)
|
# Complexity routing
|
||||||
# Complexity determined by RISK level, not task count
|
|
||||||
# Risk keywords: auth, security, payment, file handling, architecture changes
|
|
||||||
complexity_routing:
|
complexity_routing:
|
||||||
micro:
|
micro:
|
||||||
skip_steps: [3, 7, 8, 9] # Skip write-tests, code-review, review-analysis, fix-issues
|
skip_agents: ["reviewer"] # Skip code review for micro stories
|
||||||
description: "Lightweight path for low-risk stories (UI tweaks, text, simple CRUD)"
|
description: "Lightweight path for low-risk stories"
|
||||||
multi_agent_count: 2
|
examples: ["UI tweaks", "text changes", "simple CRUD"]
|
||||||
examples: ["UI tweaks", "text changes", "simple CRUD", "documentation"]
|
|
||||||
standard:
|
standard:
|
||||||
skip_steps: [] # Full pipeline
|
skip_agents: [] # Full pipeline
|
||||||
description: "Balanced path for medium-risk stories (APIs, business logic)"
|
description: "Balanced path for medium-risk stories"
|
||||||
multi_agent_count: 4
|
examples: ["API endpoints", "business logic"]
|
||||||
examples: ["API endpoints", "business logic", "data validation"]
|
|
||||||
complex:
|
complex:
|
||||||
skip_steps: [] # Full pipeline + comprehensive review
|
skip_agents: [] # Full pipeline + enhanced review
|
||||||
description: "Comprehensive path for high-risk stories (auth, payments, security)"
|
description: "Enhanced validation for high-risk stories"
|
||||||
multi_agent_count: 6
|
examples: ["Auth", "payments", "security", "migrations"]
|
||||||
examples: ["auth/security", "payments", "file handling", "architecture changes"]
|
review_focus: ["security", "performance", "architecture"]
|
||||||
warn_before_start: true
|
|
||||||
suggest_split: true
|
|
||||||
|
|
||||||
# Workflow modes
|
# Final verification checklist (main orchestrator)
|
||||||
modes:
|
final_verification:
|
||||||
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
|
enabled: true
|
||||||
detect_patterns: true
|
checks:
|
||||||
default_to_safe: true # When uncertain, execute individually
|
- name: "git_commits"
|
||||||
min_batch_size: 3 # Minimum tasks to form a batch
|
command: "git log --oneline -3 | grep {{story_key}}"
|
||||||
fallback_on_failure: true # Revert to individual if batch fails
|
failure_message: "No commit found for {{story_key}}"
|
||||||
|
|
||||||
# Automated learning feedback loop (NEW v1.6.0)
|
- name: "story_checkboxes"
|
||||||
learning_feedback:
|
command: |
|
||||||
enabled: true # Enable automatic playbook loading/saving
|
before=$(git show HEAD~1:{{story_file}} | grep -c '^- \[x\]')
|
||||||
playbook_dir: "{project-root}/docs/playbooks"
|
after=$(grep -c '^- \[x\]' {{story_file}})
|
||||||
|
[ $after -gt $before ]
|
||||||
|
failure_message: "Story checkboxes not updated"
|
||||||
|
|
||||||
# Step 1b: Load existing playbooks before implementation
|
- name: "sprint_status"
|
||||||
load_playbooks:
|
command: "git diff HEAD~1 {{sprint_status}} | grep '{{story_key}}'"
|
||||||
enabled: true
|
failure_message: "Sprint status not updated"
|
||||||
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
|
|
||||||
|
|
||||||
# Step 12: Extract learnings after implementation
|
- name: "tests_passed"
|
||||||
extract_learnings:
|
# Parse agent output for test evidence
|
||||||
enabled: true
|
validation: "inspector_output must contain 'PASS' or test count"
|
||||||
step: "step-12-extract-learnings.md"
|
failure_message: "No test evidence in validation output"
|
||||||
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
|
|
||||||
|
|
||||||
# Keyword extraction
|
# Backward compatibility
|
||||||
keywords:
|
fallback_to_v1:
|
||||||
auto_detect: true
|
enabled: true
|
||||||
sources:
|
condition: "execution_mode == 'single_agent'"
|
||||||
- story_title
|
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
|
||||||
- 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
|
|
||||||
|
|
||||||
standalone: true
|
standalone: true
|
||||||
|
|
|
||||||
|
|
@ -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
|
|
||||||
|
|
@ -11,7 +11,7 @@
|
||||||
### Workflows Without Tests:
|
### Workflows Without Tests:
|
||||||
1. **batch-super-dev** - Interactive story selector
|
1. **batch-super-dev** - Interactive story selector
|
||||||
2. **super-dev-pipeline** - Story implementation pipeline
|
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
|
4. **create-story** - Lightweight story creation
|
||||||
5. **create-story-with-gap-analysis** - Story with codebase scan
|
5. **create-story-with-gap-analysis** - Story with codebase scan
|
||||||
|
|
||||||
|
|
@ -34,7 +34,7 @@
|
||||||
- [ ] Sprint-status updates
|
- [ ] Sprint-status updates
|
||||||
- [ ] Commit creation
|
- [ ] Commit creation
|
||||||
|
|
||||||
**super-dev-pipeline-v2:**
|
**super-dev-pipeline:**
|
||||||
- [ ] Multi-agent spawning (builder, inspector, reviewer, fixer)
|
- [ ] Multi-agent spawning (builder, inspector, reviewer, fixer)
|
||||||
- [ ] Fresh context per agent
|
- [ ] Fresh context per agent
|
||||||
- [ ] Independent validation
|
- [ ] Independent validation
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue