feat: add super-dev-pipeline for brownfield + anti-vibe-coding enforcement
Create new super-dev-pipeline workflow that solves critical issues: 1. Works for BOTH greenfield AND brownfield development 2. Uses step-file architecture to prevent vibe coding at high token counts 3. Adaptive implementation (TDD for new, refactor for existing) 4. All quality gates with disciplined execution PROBLEM SOLVED: - story-pipeline assumes greenfield (ATDD doesn't work for brownfield) - super-dev-story allows vibe coding when tokens >100K - Need workflow that handles real-world scenarios (most work is brownfield!) NEW WORKFLOW: super-dev-pipeline - 7 step files with mandatory sequences - Detects greenfield vs brownfield automatically - Pre-gap analysis validates against existing code - Adaptive implementation methodology - Post-validation catches false positives - Code review finds 3-10 issues - Anti-vibe-coding enforcement STEPS: 1. Init - Load story, detect development mode 2. Pre-gap - Validate tasks against codebase (critical for brownfield!) 3. Implement - Adaptive (TDD for new, refactor for existing) 4. Post-validate - Verify completion vs reality 5. Code review - Adversarial (3-10 issues) 6. Complete - Commit + push 7. Summary - Audit trail BENEFITS: - Works for greenfield AND brownfield - 40-60K tokens per story (vs 100-150K for orchestration) - Prevents vibe coding even at 200K+ tokens - All super-dev quality gates preserved - Step-file discipline from story-pipeline AUTONOMOUS-EPIC UPDATED: - Now uses super-dev-pipeline instead of story-pipeline - Handles create-story separately for backlog stories - More realistic token estimates (40-60K vs 25-30K) - Updated time estimates FILES ADDED: - src/modules/bmm/workflows/4-implementation/super-dev-pipeline/* (14 files) - .claude-commands/super-dev-pipeline.md - ~/.codex/prompts/bmad-super-dev-pipeline.md FILES MODIFIED: - autonomous-epic/instructions.xml (use super-dev-pipeline) - autonomous-epic/workflow.yaml (updated settings) INSTALLATIONS: - craftedcall: super-dev-pipeline + updated autonomous-epic - usmax-nda: super-dev-pipeline + updated autonomous-epic This is the production-ready solution for autonomous epic processing!
This commit is contained in:
Jonah Schulte
parent
2f539ee4d0
commit
d4b8246bd9
|
|
@ -0,0 +1,13 @@
|
||||||
|
---
|
||||||
|
description: 'Step-file workflow with anti-vibe-coding enforcement - works for greenfield AND brownfield development'
|
||||||
|
---
|
||||||
|
|
||||||
|
IT IS CRITICAL THAT YOU FOLLOW THESE STEPS - while staying in character as the current agent persona you may have loaded:
|
||||||
|
|
||||||
|
<steps CRITICAL="TRUE">
|
||||||
|
1. Always LOAD the FULL @_bmad/core/tasks/workflow.xml
|
||||||
|
2. READ its entire contents - this is the CORE OS for EXECUTING the specific workflow-config @_bmad/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml
|
||||||
|
3. Pass the yaml path _bmad/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml as 'workflow-config' parameter to the workflow.xml instructions
|
||||||
|
4. Follow workflow.xml instructions EXACTLY as written to process and follow the specific workflow config and its instructions
|
||||||
|
5. Save outputs after EACH section when generating any documents from templates
|
||||||
|
</steps>
|
||||||
|
|
@ -24,29 +24,34 @@
|
||||||
<output>🤖 **Autonomous Epic Processing**
|
<output>🤖 **Autonomous Epic Processing**
|
||||||
|
|
||||||
This workflow will automatically:
|
This workflow will automatically:
|
||||||
1. Create and develop each story using story-pipeline
|
1. Create stories (if backlog) using create-story
|
||||||
2. **Verify completion** by checking ALL tasks are done (- [x])
|
2. Develop each story using super-dev-pipeline
|
||||||
3. Commit and push after each story (integrated in story-pipeline)
|
3. **Verify completion** by checking ALL tasks are done (- [x])
|
||||||
4. Generate epic completion report
|
4. Commit and push after each story (integrated in super-dev-pipeline)
|
||||||
|
5. Generate epic completion report
|
||||||
|
|
||||||
**story-pipeline includes:**
|
**super-dev-pipeline includes:**
|
||||||
- Story creation from epic (just-in-time)
|
- Pre-gap analysis (validates existing code - critical for brownfield!)
|
||||||
- Story validation (pre-dev gap analysis)
|
- Adaptive implementation (TDD for new, refactor for existing)
|
||||||
- ATDD test generation (RED phase)
|
|
||||||
- Implementation (GREEN phase)
|
|
||||||
- **Post-implementation validation** (catches false positives!)
|
- **Post-implementation validation** (catches false positives!)
|
||||||
- Code review (adversarial, finds 3-10 issues)
|
- Code review (adversarial, finds 3-10 issues)
|
||||||
- Completion (commit + push)
|
- Completion (commit + push)
|
||||||
|
|
||||||
|
**Key Features:**
|
||||||
|
- ✅ Works for greenfield AND brownfield development
|
||||||
|
- ✅ Step-file architecture prevents vibe coding
|
||||||
|
- ✅ Disciplined execution even at high token counts
|
||||||
|
- ✅ All quality gates enforced
|
||||||
|
|
||||||
**Key Improvement:** Stories in "review" status with unchecked tasks
|
**Key Improvement:** Stories in "review" status with unchecked tasks
|
||||||
WILL be processed - we check actual task completion, not just status!
|
WILL be processed - we check actual task completion, not just status!
|
||||||
|
|
||||||
**Time Estimate:** Varies by epic size
|
**Time Estimate:** Varies by epic size
|
||||||
- Small epic (3-5 stories): 2-4 hours
|
- Small epic (3-5 stories): 2-5 hours
|
||||||
- Medium epic (6-10 stories): 4-8 hours
|
- Medium epic (6-10 stories): 5-10 hours
|
||||||
- Large epic (11+ stories): 8-16 hours
|
- Large epic (11+ stories): 10-20 hours
|
||||||
|
|
||||||
**Token Usage:** ~25-30K per story (65% more efficient!)
|
**Token Usage:** ~40-60K per story (more efficient + brownfield support!)
|
||||||
</output>
|
</output>
|
||||||
|
|
||||||
<check if="{{epic_num}} provided">
|
<check if="{{epic_num}} provided">
|
||||||
|
|
@ -107,14 +112,14 @@
|
||||||
|
|
||||||
<ask>**Proceed with autonomous processing?**
|
<ask>**Proceed with autonomous processing?**
|
||||||
|
|
||||||
[Y] Yes - Use story-pipeline (full lifecycle with post-validation)
|
[Y] Yes - Use super-dev-pipeline (works for greenfield AND brownfield)
|
||||||
[n] No - Cancel
|
[n] No - Cancel
|
||||||
|
|
||||||
Note: story-pipeline is now the default, replacing super-dev-story with 65% token savings!
|
Note: super-dev-pipeline uses step-file architecture to prevent vibe coding!
|
||||||
</ask>
|
</ask>
|
||||||
|
|
||||||
<check if="user says Y">
|
<check if="user says Y">
|
||||||
<action>Set {{use_story_pipeline}} = true</action>
|
<action>Set {{use_super_dev_pipeline}} = true</action>
|
||||||
</check>
|
</check>
|
||||||
|
|
||||||
<check if="user says n">
|
<check if="user says n">
|
||||||
|
|
@ -167,27 +172,45 @@
|
||||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
</output>
|
</output>
|
||||||
|
|
||||||
<!-- PROCESS STORY WITH STORY-PIPELINE (handles both backlog creation AND development) -->
|
<!-- CREATE STORY IF BACKLOG -->
|
||||||
<check if="{{unchecked_count}} > 0 OR status == 'backlog'">
|
<check if="status == 'backlog'">
|
||||||
<output>💻 Processing story with story-pipeline ({{unchecked_count}} tasks remaining)...</output>
|
<output>📝 Creating story from epic...</output>
|
||||||
|
|
||||||
<try>
|
<try>
|
||||||
<invoke-workflow path="{project-root}/_bmad/bmm/workflows/4-implementation/story-pipeline/workflow.yaml">
|
<invoke-workflow path="{project-root}/_bmad/bmm/workflows/4-implementation/create-story/workflow.yaml">
|
||||||
<input name="story_id" value="{{current_story.key}}" />
|
<note>Create story just-in-time</note>
|
||||||
<input name="epic_num" value="{{epic_num}}" />
|
|
||||||
<input name="story_num" value="{{current_story.num}}" />
|
|
||||||
<input name="mode" value="batch" />
|
|
||||||
<note>Full lifecycle: create (if backlog) → validate → ATDD → implement → post-validate → review → commit</note>
|
|
||||||
</invoke-workflow>
|
</invoke-workflow>
|
||||||
|
|
||||||
<!-- story-pipeline handles verification internally, just check final status -->
|
<output>✅ Story created</output>
|
||||||
<output>✅ story-pipeline completed</output>
|
</try>
|
||||||
|
|
||||||
|
<catch>
|
||||||
|
<output>❌ Failed to create story: {{error}}</output>
|
||||||
|
<action>Add to failed_stories, continue to next</action>
|
||||||
|
<continue />
|
||||||
|
</catch>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<!-- DEVELOP STORY WITH SUPER-DEV-PIPELINE (handles both greenfield AND brownfield) -->
|
||||||
|
<check if="{{unchecked_count}} > 0">
|
||||||
|
<output>💻 Developing story with super-dev-pipeline ({{unchecked_count}} tasks remaining)...</output>
|
||||||
|
|
||||||
|
<try>
|
||||||
|
<invoke-workflow path="{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml">
|
||||||
|
<input name="story_id" value="{{current_story.key}}" />
|
||||||
|
<input name="story_file" value="{{current_story_file}}" />
|
||||||
|
<input name="mode" value="batch" />
|
||||||
|
<note>Step-file execution: pre-gap → implement → post-validate → review → commit</note>
|
||||||
|
</invoke-workflow>
|
||||||
|
|
||||||
|
<!-- super-dev-pipeline handles verification internally, just check final status -->
|
||||||
|
<output>✅ super-dev-pipeline completed</output>
|
||||||
|
|
||||||
<!-- VERIFY COMPLETION: Re-check for unchecked tasks -->
|
<!-- VERIFY COMPLETION: Re-check for unchecked tasks -->
|
||||||
<action>Re-read story file and count unchecked tasks</action>
|
<action>Re-read story file and count unchecked tasks</action>
|
||||||
|
|
||||||
<check if="{{remaining_unchecked}} > 0">
|
<check if="{{remaining_unchecked}} > 0">
|
||||||
<output>⚠️ Story still has {{remaining_unchecked}} unchecked tasks after pipeline</output>
|
<output>⚠️ Story still has {{remaining_unchecked}} unchecked tasks after super-dev-pipeline</output>
|
||||||
<action>Log incomplete tasks for review</action>
|
<action>Log incomplete tasks for review</action>
|
||||||
<action>Mark as partial success</action>
|
<action>Mark as partial success</action>
|
||||||
</check>
|
</check>
|
||||||
|
|
@ -202,7 +225,7 @@
|
||||||
</try>
|
</try>
|
||||||
|
|
||||||
<catch>
|
<catch>
|
||||||
<output>❌ story-pipeline failed: {{error}}</output>
|
<output>❌ super-dev-pipeline failed: {{error}}</output>
|
||||||
<action>Add to failed_stories with error details</action>
|
<action>Add to failed_stories with error details</action>
|
||||||
<action>Increment failure_count</action>
|
<action>Increment failure_count</action>
|
||||||
</catch>
|
</catch>
|
||||||
|
|
|
||||||
|
|
@ -22,27 +22,29 @@ project_context: "**/project-context.md"
|
||||||
|
|
||||||
# Autonomous mode settings
|
# Autonomous mode settings
|
||||||
autonomous_settings:
|
autonomous_settings:
|
||||||
use_story_pipeline: true # Use story-pipeline workflow (replaces super-dev-story)
|
# Use super-dev-pipeline: Step-file architecture that works for BOTH greenfield AND brownfield
|
||||||
pipeline_mode: "batch" # Run story-pipeline in batch mode (unattended)
|
use_super_dev_pipeline: true # Disciplined execution, no vibe coding
|
||||||
|
|
||||||
|
pipeline_mode: "batch" # Run workflows in batch mode (unattended)
|
||||||
halt_on_error: false # Continue even if story fails
|
halt_on_error: false # Continue even if story fails
|
||||||
max_retry_per_story: 2 # Retry failed stories
|
max_retry_per_story: 2 # Retry failed stories
|
||||||
create_git_commits: true # Commit after each story (handled by story-pipeline)
|
create_git_commits: true # Commit after each story (handled by super-dev-pipeline)
|
||||||
create_epic_branch: false # When false, stay on current branch (good for parallel epics)
|
create_epic_branch: false # When false, stay on current branch (good for parallel epics)
|
||||||
git_branch_prefix: "auto-epic-" # Branch name format: auto-epic-{epic_num} (only used if create_epic_branch=true)
|
git_branch_prefix: "auto-epic-" # Branch name format: auto-epic-{epic_num} (only used if create_epic_branch=true)
|
||||||
|
|
||||||
# story-pipeline benefits (vs super-dev-story)
|
# super-dev-pipeline benefits
|
||||||
story_pipeline_features:
|
super_dev_pipeline_features:
|
||||||
token_efficiency: "65% savings (25-30K vs 100-150K per story)"
|
token_efficiency: "40-60K per story (vs 100-150K for super-dev-story orchestration)"
|
||||||
|
works_for: "Both greenfield AND brownfield development"
|
||||||
|
anti_vibe_coding: "Step-file architecture prevents deviation at high token counts"
|
||||||
includes:
|
includes:
|
||||||
- "Story creation from epic (just-in-time)"
|
- "Pre-gap analysis (validates against existing code)"
|
||||||
- "Story validation (pre-dev gap analysis)"
|
- "Adaptive implementation (TDD for new, refactor for existing)"
|
||||||
- "ATDD test generation (RED phase)"
|
|
||||||
- "Implementation (GREEN phase)"
|
|
||||||
- "Post-implementation validation (catches false positives)"
|
- "Post-implementation validation (catches false positives)"
|
||||||
- "Code review (adversarial, finds 3-10 issues)"
|
- "Code review (adversarial, finds 3-10 issues)"
|
||||||
- "Completion (commit + push)"
|
- "Completion (targeted commit + push)"
|
||||||
quality_gates: "All super-dev-story gates PLUS post-validation"
|
quality_gates: "All super-dev-story gates with disciplined execution"
|
||||||
checkpoint_resume: "Can resume from any step after failure"
|
brownfield_support: "Validates existing code before implementation"
|
||||||
|
|
||||||
# TASK-BASED COMPLETION SETTINGS (NEW)
|
# TASK-BASED COMPLETION SETTINGS (NEW)
|
||||||
# These settings ensure stories are truly complete, not just marked as such
|
# These settings ensure stories are truly complete, not just marked as such
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,158 @@
|
||||||
|
# super-dev-pipeline
|
||||||
|
|
||||||
|
**Token-efficient step-file workflow that prevents vibe coding and works for both greenfield AND brownfield development.**
|
||||||
|
|
||||||
|
## 🎯 Purpose
|
||||||
|
|
||||||
|
Combines the best of both worlds:
|
||||||
|
- **super-dev-story's flexibility** - works for greenfield and brownfield
|
||||||
|
- **story-pipeline's discipline** - step-file architecture prevents vibe coding
|
||||||
|
|
||||||
|
## 🔑 Key Features
|
||||||
|
|
||||||
|
### 1. **Adaptive Implementation**
|
||||||
|
- Greenfield tasks: TDD approach (test-first)
|
||||||
|
- Brownfield tasks: Refactor approach (understand-first)
|
||||||
|
- Hybrid stories: Mix both as appropriate
|
||||||
|
|
||||||
|
### 2. **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
|
||||||
|
|
||||||
|
### 3. **Brownfield Support**
|
||||||
|
- Pre-gap analysis scans existing code
|
||||||
|
- Validates tasks against current implementation
|
||||||
|
- Refines vague tasks to specific actions
|
||||||
|
- Detects already-completed work
|
||||||
|
|
||||||
|
### 4. **Complete Quality Gates**
|
||||||
|
- ✅ Pre-gap analysis (validates against existing code)
|
||||||
|
- ✅ 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 autonomous-epic
|
||||||
|
```bash
|
||||||
|
bmad autonomous-epic
|
||||||
|
# Automatically uses super-dev-pipeline for each story
|
||||||
|
```
|
||||||
|
|
||||||
|
## 📊 Token Efficiency
|
||||||
|
|
||||||
|
| Metric | super-dev-story | super-dev-pipeline | Improvement |
|
||||||
|
|--------|----------------|-------------------|-------------|
|
||||||
|
| Tokens/story | 100-150K | 40-60K | **~50% savings** |
|
||||||
|
| Architecture | Orchestration | Step-files | Disciplined |
|
||||||
|
| Vibe coding | Possible | Prevented | Enforced |
|
||||||
|
|
||||||
|
## 🛡️ 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)
|
||||||
|
- ❌ 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 autonomous-epic
|
||||||
|
- 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!** 🚀
|
||||||
|
|
@ -0,0 +1,266 @@
|
||||||
|
---
|
||||||
|
name: 'step-01-init'
|
||||||
|
description: 'Initialize pipeline, load story, detect development mode'
|
||||||
|
|
||||||
|
# Path Definitions
|
||||||
|
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||||
|
|
||||||
|
# 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
|
||||||
|
|
||||||
|
- **STORY MUST EXIST** - This workflow does NOT create stories
|
||||||
|
- **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 autonomous-epic
|
||||||
|
- Interactive mode: User-initiated
|
||||||
|
|
||||||
|
Set `{mode}` variable.
|
||||||
|
|
||||||
|
### 2. Resolve Story File Path
|
||||||
|
|
||||||
|
**From input parameters:**
|
||||||
|
- `story_id`: e.g., "1-4"
|
||||||
|
- `story_file`: Full path to story file
|
||||||
|
|
||||||
|
**If story_file not provided:**
|
||||||
|
```
|
||||||
|
story_file = {sprint_artifacts}/story-{story_id}.md
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Verify Story Exists
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Check if story file exists
|
||||||
|
test -f "{story_file}"
|
||||||
|
```
|
||||||
|
|
||||||
|
**If story does NOT exist:**
|
||||||
|
```
|
||||||
|
❌ ERROR: Story file not found at {story_file}
|
||||||
|
|
||||||
|
super-dev-pipeline requires an existing story file.
|
||||||
|
Use create-story or story-pipeline to create new stories.
|
||||||
|
|
||||||
|
HALT
|
||||||
|
```
|
||||||
|
|
||||||
|
**If story exists:**
|
||||||
|
```
|
||||||
|
✅ Story file found: {story_file}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. Load Story File
|
||||||
|
|
||||||
|
Read story file and extract:
|
||||||
|
- Story title
|
||||||
|
- Epic number
|
||||||
|
- Story number
|
||||||
|
- Acceptance criteria
|
||||||
|
- Current tasks (checked and unchecked)
|
||||||
|
- File List section (if exists)
|
||||||
|
|
||||||
|
Count:
|
||||||
|
- Total tasks: `{total_task_count}`
|
||||||
|
- Unchecked tasks: `{unchecked_task_count}`
|
||||||
|
- Checked tasks: `{checked_task_count}`
|
||||||
|
|
||||||
|
### 5. Load Project Context
|
||||||
|
|
||||||
|
Read `**/project-context.md`:
|
||||||
|
- Tech stack
|
||||||
|
- Coding patterns
|
||||||
|
- Database conventions
|
||||||
|
- Testing requirements
|
||||||
|
|
||||||
|
Cache in memory for use across steps.
|
||||||
|
|
||||||
|
### 6. 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)
|
||||||
|
|
||||||
|
### 7. Display Initialization Summary
|
||||||
|
|
||||||
|
```
|
||||||
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
|
🚀 SUPER-DEV PIPELINE - Disciplined Execution
|
||||||
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
|
|
||||||
|
Story: {story_title}
|
||||||
|
File: {story_file}
|
||||||
|
Mode: {mode} (interactive|batch)
|
||||||
|
|
||||||
|
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. ⏳ Pre-Gap Analysis - Validate tasks
|
||||||
|
3. ⏳ Implement - {TDD|Refactor|Hybrid}
|
||||||
|
4. ⏳ Post-Validation - Verify completion
|
||||||
|
5. ⏳ Code Review - Find 3-10 issues
|
||||||
|
6. ⏳ Complete - Commit + push
|
||||||
|
7. ⏳ Summary - Audit trail
|
||||||
|
|
||||||
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
|
|
||||||
|
⚠️ ANTI-VIBE-CODING ENFORCEMENT ACTIVE
|
||||||
|
|
||||||
|
This workflow uses step-file architecture to ensure:
|
||||||
|
- ✅ No skipping steps
|
||||||
|
- ✅ No optimizing sequences
|
||||||
|
- ✅ No looking ahead
|
||||||
|
- ✅ No vibe coding even at 200K tokens
|
||||||
|
|
||||||
|
You will follow each step file PRECISELY.
|
||||||
|
|
||||||
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
|
```
|
||||||
|
|
||||||
|
### 8. 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}"
|
||||||
|
|
||||||
|
stepsCompleted: [1]
|
||||||
|
lastStep: 1
|
||||||
|
currentStep: 2
|
||||||
|
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
|
||||||
|
step-03-implement:
|
||||||
|
status: pending
|
||||||
|
step-04-post-validation:
|
||||||
|
status: pending
|
||||||
|
step-05-code-review:
|
||||||
|
status: pending
|
||||||
|
step-06-complete:
|
||||||
|
status: pending
|
||||||
|
step-07-summary:
|
||||||
|
status: pending
|
||||||
|
```
|
||||||
|
|
||||||
|
### 9. Display Menu (Interactive) or Proceed (Batch)
|
||||||
|
|
||||||
|
**Interactive Mode Menu:**
|
||||||
|
```
|
||||||
|
[C] Continue to Pre-Gap Analysis
|
||||||
|
[H] Halt pipeline
|
||||||
|
```
|
||||||
|
|
||||||
|
**Batch Mode:** Auto-continue to next step
|
||||||
|
|
||||||
|
## CRITICAL STEP COMPLETION
|
||||||
|
|
||||||
|
**ONLY WHEN** initialization is complete,
|
||||||
|
load and execute `{nextStepFile}` for pre-gap analysis.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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
|
||||||
|
|
@ -0,0 +1,360 @@
|
||||||
|
---
|
||||||
|
name: 'step-02-pre-gap-analysis'
|
||||||
|
description: 'Validate tasks against codebase reality - critical for brownfield development'
|
||||||
|
|
||||||
|
# Path Definitions
|
||||||
|
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||||
|
|
||||||
|
# File References
|
||||||
|
thisStepFile: '{workflow_path}/steps/step-02-pre-gap-analysis.md'
|
||||||
|
nextStepFile: '{workflow_path}/steps/step-03-implement.md'
|
||||||
|
|
||||||
|
# Role Switch
|
||||||
|
role: dev
|
||||||
|
agentFile: '{project-root}/_bmad/bmm/agents/dev.md'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Step 2: Pre-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
|
||||||
|
|
||||||
|
### 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. Handle Approval (Interactive Mode Only)
|
||||||
|
|
||||||
|
**Interactive Mode:**
|
||||||
|
|
||||||
|
Display gap analysis report and ask:
|
||||||
|
```
|
||||||
|
Gap Analysis Complete
|
||||||
|
|
||||||
|
Changes proposed:
|
||||||
|
- {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
|
||||||
|
|
||||||
|
Total work: {work_count} tasks
|
||||||
|
|
||||||
|
[A] Accept changes and proceed
|
||||||
|
[E] Edit tasks manually
|
||||||
|
[H] Halt pipeline
|
||||||
|
```
|
||||||
|
|
||||||
|
**Batch Mode:** Auto-accept changes
|
||||||
|
|
||||||
|
### 7. 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}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 8. Present Summary
|
||||||
|
|
||||||
|
Display:
|
||||||
|
```
|
||||||
|
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}
|
||||||
|
|
||||||
|
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
|
||||||
|
|
@ -0,0 +1,342 @@
|
||||||
|
---
|
||||||
|
name: 'step-03-implement'
|
||||||
|
description: 'Adaptive implementation - TDD for greenfield, refactor for brownfield, no vibe coding'
|
||||||
|
|
||||||
|
# Path Definitions
|
||||||
|
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||||
|
|
||||||
|
# File References
|
||||||
|
thisStepFile: '{workflow_path}/steps/step-03-implement.md'
|
||||||
|
nextStepFile: '{workflow_path}/steps/step-04-post-validation.md'
|
||||||
|
|
||||||
|
# Role Continue
|
||||||
|
role: dev
|
||||||
|
---
|
||||||
|
|
||||||
|
# Step 3: Implement Story
|
||||||
|
|
||||||
|
## 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
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES
|
||||||
|
|
||||||
|
### Implementation Principles
|
||||||
|
|
||||||
|
- **ONE TASK AT A TIME** - Never batch multiple tasks
|
||||||
|
- **RUN TESTS FREQUENTLY** - After each significant change
|
||||||
|
- **FOLLOW PROJECT PATTERNS** - Never invent new patterns
|
||||||
|
- **NO VIBE CODING** - Follow the sequence exactly
|
||||||
|
- **VERIFY EACH TASK** - Check works before moving to next
|
||||||
|
|
||||||
|
### 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. Implementation Loop
|
||||||
|
|
||||||
|
**For EACH unchecked task:**
|
||||||
|
|
||||||
|
```
|
||||||
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
|
Task {n}/{total}: {task_description}
|
||||||
|
Type: {greenfield|brownfield}
|
||||||
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||||
|
```
|
||||||
|
|
||||||
|
**A. Identify File(s) Affected:**
|
||||||
|
- New file to create?
|
||||||
|
- Existing file to modify?
|
||||||
|
- Test file to add/update?
|
||||||
|
- Migration file to create?
|
||||||
|
|
||||||
|
**B. For NEW FILES (Greenfield):**
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Determine file path and structure
|
||||||
|
2. Identify dependencies needed
|
||||||
|
3. Write test first (if applicable):
|
||||||
|
- Create test file
|
||||||
|
- Write failing test
|
||||||
|
- Run test, confirm RED
|
||||||
|
|
||||||
|
4. Implement code:
|
||||||
|
- Create file
|
||||||
|
- Add minimal implementation
|
||||||
|
- Follow project patterns from project-context.md
|
||||||
|
|
||||||
|
5. Run test:
|
||||||
|
npm test -- --run
|
||||||
|
Confirm GREEN
|
||||||
|
|
||||||
|
6. Verify:
|
||||||
|
- File created
|
||||||
|
- Exports correct
|
||||||
|
- Test passes
|
||||||
|
```
|
||||||
|
|
||||||
|
**C. For EXISTING FILES (Brownfield):**
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Read existing file completely
|
||||||
|
2. Understand current implementation
|
||||||
|
3. Identify where to make changes
|
||||||
|
4. Check if tests exist for this file
|
||||||
|
|
||||||
|
5. Add test for new behavior (if applicable):
|
||||||
|
- Find or create test file
|
||||||
|
- Add test for new/changed behavior
|
||||||
|
- Run test, may fail or pass depending on change
|
||||||
|
|
||||||
|
6. Modify existing code:
|
||||||
|
- Make minimal changes
|
||||||
|
- Preserve existing functionality
|
||||||
|
- Follow established patterns in the file
|
||||||
|
- Don't refactor unrelated code
|
||||||
|
|
||||||
|
7. Run ALL tests (not just new ones):
|
||||||
|
npm test -- --run
|
||||||
|
Confirm all tests pass
|
||||||
|
|
||||||
|
8. Verify:
|
||||||
|
- Changes made as planned
|
||||||
|
- No regressions (all old tests pass)
|
||||||
|
- New behavior works (new tests pass)
|
||||||
|
```
|
||||||
|
|
||||||
|
**D. For DATABASE TASKS:**
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Create migration file:
|
||||||
|
npx supabase migration new {description}
|
||||||
|
|
||||||
|
2. Write migration SQL:
|
||||||
|
- Create/alter tables
|
||||||
|
- Add RLS policies
|
||||||
|
- Add indexes
|
||||||
|
|
||||||
|
3. Apply migration:
|
||||||
|
npx supabase db push
|
||||||
|
|
||||||
|
4. Verify schema:
|
||||||
|
mcp__supabase__list_tables
|
||||||
|
Confirm changes applied
|
||||||
|
|
||||||
|
5. Generate types:
|
||||||
|
npx supabase gen types typescript --local
|
||||||
|
```
|
||||||
|
|
||||||
|
**E. For TEST TASKS:**
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Identify what to test
|
||||||
|
2. Find or create test file
|
||||||
|
3. Write test with clear assertions
|
||||||
|
4. Run test:
|
||||||
|
npm test -- --run --grep "{test_name}"
|
||||||
|
|
||||||
|
5. Verify test is meaningful (not placeholder)
|
||||||
|
```
|
||||||
|
|
||||||
|
**F. Check Task Complete:**
|
||||||
|
|
||||||
|
After implementing task, verify:
|
||||||
|
- [ ] Code exists where expected
|
||||||
|
- [ ] Tests pass
|
||||||
|
- [ ] No TypeScript errors
|
||||||
|
- [ ] Follows project patterns
|
||||||
|
|
||||||
|
**Mark task complete in story file:**
|
||||||
|
```markdown
|
||||||
|
- [x] {task_description}
|
||||||
|
```
|
||||||
|
|
||||||
|
**Update state file with progress.**
|
||||||
|
|
||||||
|
### 3. Handle Errors Gracefully
|
||||||
|
|
||||||
|
**If implementation fails:**
|
||||||
|
|
||||||
|
```
|
||||||
|
⚠️ Task failed: {task_description}
|
||||||
|
|
||||||
|
Error: {error_message}
|
||||||
|
|
||||||
|
Options:
|
||||||
|
1. Debug and retry
|
||||||
|
2. Skip and document blocker
|
||||||
|
3. Simplify approach
|
||||||
|
|
||||||
|
DO NOT vibe code or guess!
|
||||||
|
Follow error systematically.
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. Run Full Test Suite
|
||||||
|
|
||||||
|
After ALL tasks completed:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npm test -- --run
|
||||||
|
npm run lint
|
||||||
|
npm run build
|
||||||
|
```
|
||||||
|
|
||||||
|
**All must pass before proceeding.**
|
||||||
|
|
||||||
|
### 5. Verify Task Completion
|
||||||
|
|
||||||
|
Re-read story file and count:
|
||||||
|
- Tasks completed this session: {count}
|
||||||
|
- Tasks remaining: {should be 0}
|
||||||
|
- All checked: {should be true}
|
||||||
|
|
||||||
|
### 6. Update Pipeline State
|
||||||
|
|
||||||
|
Update state file:
|
||||||
|
- Add `3` to `stepsCompleted`
|
||||||
|
- Set `lastStep: 3`
|
||||||
|
- Set `steps.step-03-implement.status: completed`
|
||||||
|
- Record:
|
||||||
|
```yaml
|
||||||
|
implementation:
|
||||||
|
files_created: {count}
|
||||||
|
files_modified: {count}
|
||||||
|
migrations_applied: {count}
|
||||||
|
tests_added: {count}
|
||||||
|
tasks_completed: {count}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 7. Display Summary
|
||||||
|
|
||||||
|
```
|
||||||
|
Implementation Complete
|
||||||
|
|
||||||
|
Tasks Completed: {completed_count}
|
||||||
|
|
||||||
|
Files:
|
||||||
|
- Created: {created_files}
|
||||||
|
- Modified: {modified_files}
|
||||||
|
|
||||||
|
Migrations:
|
||||||
|
- {migration_1}
|
||||||
|
- {migration_2}
|
||||||
|
|
||||||
|
Tests:
|
||||||
|
- All passing: {pass_count}/{total_count}
|
||||||
|
- New tests added: {new_test_count}
|
||||||
|
|
||||||
|
Build Status:
|
||||||
|
- Lint: ✓ Clean
|
||||||
|
- TypeScript: ✓ No errors
|
||||||
|
- Build: ✓ Success
|
||||||
|
|
||||||
|
Ready for Post-Validation
|
||||||
|
```
|
||||||
|
|
||||||
|
**Interactive Mode Menu:**
|
||||||
|
```
|
||||||
|
[C] Continue to Post-Validation
|
||||||
|
[T] Run tests again
|
||||||
|
[B] Run build again
|
||||||
|
[H] Halt pipeline
|
||||||
|
```
|
||||||
|
|
||||||
|
**Batch Mode:** Auto-continue
|
||||||
|
|
||||||
|
## QUALITY GATE
|
||||||
|
|
||||||
|
Before proceeding:
|
||||||
|
- [ ] All unchecked tasks completed
|
||||||
|
- [ ] All tests pass
|
||||||
|
- [ ] Lint clean
|
||||||
|
- [ ] Build succeeds
|
||||||
|
- [ ] No TypeScript errors
|
||||||
|
- [ ] Followed project patterns
|
||||||
|
- [ ] **No vibe coding occurred**
|
||||||
|
|
||||||
|
## CRITICAL STEP COMPLETION
|
||||||
|
|
||||||
|
**ONLY WHEN** [all tasks complete AND all tests pass AND lint clean AND build succeeds],
|
||||||
|
load and execute `{nextStepFile}` for post-validation.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## SUCCESS/FAILURE METRICS
|
||||||
|
|
||||||
|
### ✅ SUCCESS
|
||||||
|
- All tasks implemented one at a time
|
||||||
|
- Tests pass for each task
|
||||||
|
- Brownfield code modified carefully
|
||||||
|
- No regressions introduced
|
||||||
|
- Project patterns followed
|
||||||
|
- Build and lint clean
|
||||||
|
- **Disciplined execution maintained**
|
||||||
|
|
||||||
|
### ❌ FAILURE
|
||||||
|
- Vibe coding (guessing implementation)
|
||||||
|
- Batching multiple tasks
|
||||||
|
- Not running tests per task
|
||||||
|
- Breaking existing functionality
|
||||||
|
- Inventing new patterns
|
||||||
|
- Skipping verification
|
||||||
|
- **Deviating from step sequence**
|
||||||
|
|
||||||
|
## ANTI-VIBE-CODING ENFORCEMENT
|
||||||
|
|
||||||
|
This step enforces discipline by:
|
||||||
|
|
||||||
|
1. **One task at a time** - Can't batch or optimize
|
||||||
|
2. **Test after each task** - Immediate verification
|
||||||
|
3. **Follow existing patterns** - No invention
|
||||||
|
4. **Brownfield awareness** - Read existing code first
|
||||||
|
5. **Frequent verification** - Run tests, lint, build
|
||||||
|
|
||||||
|
**Even at 200K tokens, you MUST:**
|
||||||
|
- ✅ Implement ONE task
|
||||||
|
- ✅ Run tests
|
||||||
|
- ✅ Verify it works
|
||||||
|
- ✅ Mark task complete
|
||||||
|
- ✅ Move to next task
|
||||||
|
|
||||||
|
**NO shortcuts. NO optimization. NO vibe coding.**
|
||||||
|
|
@ -0,0 +1,437 @@
|
||||||
|
---
|
||||||
|
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 Code Review
|
||||||
|
[V] Run verification again
|
||||||
|
[T] Run tests again
|
||||||
|
[H] Halt pipeline
|
||||||
|
```
|
||||||
|
|
||||||
|
**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
|
||||||
|
|
||||||
|
**ONLY WHEN** [all tasks verified AND zero false positives],
|
||||||
|
load and execute `{nextStepFile}` for code review.
|
||||||
|
|
||||||
|
**IF** [false positives detected],
|
||||||
|
load and execute `{prevStepFile}` to complete missing work,
|
||||||
|
then RE-RUN this step.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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.
|
||||||
|
|
@ -0,0 +1,294 @@
|
||||||
|
---
|
||||||
|
name: 'step-05-code-review'
|
||||||
|
description: 'Adversarial code review finding 3-10 specific issues'
|
||||||
|
|
||||||
|
# Path Definitions
|
||||||
|
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||||
|
|
||||||
|
# File References
|
||||||
|
thisStepFile: '{workflow_path}/steps/step-05-code-review.md'
|
||||||
|
nextStepFile: '{workflow_path}/steps/step-06-complete.md'
|
||||||
|
checklist: '{workflow_path}/checklists/code-review.md'
|
||||||
|
|
||||||
|
# Role (continue as dev, but reviewer mindset)
|
||||||
|
role: dev
|
||||||
|
requires_fresh_context: true # In batch mode, checkpoint here for unbiased review
|
||||||
|
---
|
||||||
|
|
||||||
|
# Step 6: Code Review
|
||||||
|
|
||||||
|
## 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
|
||||||
|
|
||||||
|
## 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
|
||||||
|
|
@ -0,0 +1,202 @@
|
||||||
|
---
|
||||||
|
name: 'step-06-complete'
|
||||||
|
description: 'Commit and push story changes with targeted file list'
|
||||||
|
|
||||||
|
# Path Definitions
|
||||||
|
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||||
|
|
||||||
|
# File References
|
||||||
|
thisStepFile: '{workflow_path}/steps/step-06-complete.md'
|
||||||
|
nextStepFile: '{workflow_path}/steps/step-07-summary.md'
|
||||||
|
|
||||||
|
# Role Switch
|
||||||
|
role: sm
|
||||||
|
---
|
||||||
|
|
||||||
|
# Step 6: Complete Story
|
||||||
|
|
||||||
|
## 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:
|
||||||
|
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 status
|
||||||
|
|
||||||
|
## 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
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git commit -m "$(cat <<'EOF'
|
||||||
|
{commit_message}
|
||||||
|
EOF
|
||||||
|
)"
|
||||||
|
```
|
||||||
|
|
||||||
|
Verify commit created:
|
||||||
|
```bash
|
||||||
|
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
|
||||||
|
|
||||||
|
Update story file frontmatter:
|
||||||
|
```yaml
|
||||||
|
status: review # Ready for human review
|
||||||
|
```
|
||||||
|
|
||||||
|
### 9. Update Pipeline State
|
||||||
|
|
||||||
|
Update state file:
|
||||||
|
- Add `6` to `stepsCompleted`
|
||||||
|
- Set `lastStep: 6`
|
||||||
|
- Set `steps.step-06-complete.status: completed`
|
||||||
|
- Record commit hash
|
||||||
|
|
||||||
|
### 10. Display Summary
|
||||||
|
|
||||||
|
```
|
||||||
|
Story Completion
|
||||||
|
|
||||||
|
✅ Files staged: {file_count}
|
||||||
|
✅ Commit created: {commit_hash}
|
||||||
|
✅ Status updated: review
|
||||||
|
{if pushed}✅ Pushed to remote{endif}
|
||||||
|
|
||||||
|
Commit: {commit_hash_short}
|
||||||
|
Message: {commit_title}
|
||||||
|
|
||||||
|
Ready for Summary Generation
|
||||||
|
```
|
||||||
|
|
||||||
|
**Interactive Mode Menu:**
|
||||||
|
```
|
||||||
|
[C] Continue to Summary
|
||||||
|
[P] Push to remote (if not done)
|
||||||
|
[H] Halt pipeline
|
||||||
|
```
|
||||||
|
|
||||||
|
**Batch Mode:** Auto-continue
|
||||||
|
|
||||||
|
## QUALITY GATE
|
||||||
|
|
||||||
|
Before proceeding:
|
||||||
|
- [ ] Targeted files staged (from File List)
|
||||||
|
- [ ] Commit message generated
|
||||||
|
- [ ] Commit created successfully
|
||||||
|
- [ ] Story status updated to "review"
|
||||||
|
|
||||||
|
## 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
|
||||||
|
|
@ -0,0 +1,216 @@
|
||||||
|
---
|
||||||
|
name: 'step-07-summary'
|
||||||
|
description: 'Generate 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-07-summary.md'
|
||||||
|
|
||||||
|
# Role
|
||||||
|
role: null
|
||||||
|
---
|
||||||
|
|
||||||
|
# Step 7: 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
|
||||||
|
|
@ -0,0 +1,214 @@
|
||||||
|
---
|
||||||
|
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
|
||||||
|
|
||||||
|
**Goal:** Execute story development with disciplined step-file architecture that prevents "vibe coding" and works for both new features and existing codebase modifications.
|
||||||
|
|
||||||
|
**Your Role:** You are the **BMAD Pipeline Orchestrator**. You will follow each step file precisely, without deviation, optimization, or skipping ahead.
|
||||||
|
|
||||||
|
**Key Principle:** This workflow uses **step-file architecture** for disciplined execution that prevents Claude from veering off-course when token usage is high.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## WORKFLOW ARCHITECTURE
|
||||||
|
|
||||||
|
This uses **step-file architecture** borrowed from story-pipeline:
|
||||||
|
|
||||||
|
### Core Principles
|
||||||
|
|
||||||
|
- **Micro-file Design**: Each step is a self-contained instruction file (~150-300 lines)
|
||||||
|
- **Just-In-Time Loading**: Only the current step file is in memory
|
||||||
|
- **Mandatory Sequences**: Execute all numbered sections in order, never deviate
|
||||||
|
- **State Tracking**: Pipeline state in `{sprint_artifacts}/super-dev-state-{story_id}.yaml`
|
||||||
|
- **No Vibe Coding**: Explicit instructions prevent optimization/deviation
|
||||||
|
|
||||||
|
### Step Processing Rules
|
||||||
|
|
||||||
|
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||||
|
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||||
|
3. **QUALITY GATES**: Complete gate criteria before proceeding to next step
|
||||||
|
4. **WAIT FOR INPUT**: In interactive mode, halt at menus and wait for user selection
|
||||||
|
5. **SAVE STATE**: Update pipeline state file after each step completion
|
||||||
|
6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step
|
||||||
|
|
||||||
|
### Critical Rules (NO EXCEPTIONS)
|
||||||
|
|
||||||
|
- **NEVER** load multiple step files simultaneously
|
||||||
|
- **ALWAYS** read entire step file before execution
|
||||||
|
- **NEVER** skip steps or optimize the sequence
|
||||||
|
- **ALWAYS** update pipeline state after completing each step
|
||||||
|
- **ALWAYS** follow the exact instructions in the step file
|
||||||
|
- **NEVER** create mental todo lists from future steps
|
||||||
|
- **NEVER** look ahead to future step files
|
||||||
|
- **NEVER** vibe code when token usage is high - follow the steps exactly!
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## STEP FILE MAP
|
||||||
|
|
||||||
|
| Step | File | Agent | Purpose |
|
||||||
|
|------|------|-------|---------|
|
||||||
|
| 1 | step-01-init.md | - | Load story, detect greenfield vs brownfield |
|
||||||
|
| 2 | step-02-pre-gap-analysis.md | DEV | Validate/refine tasks against codebase |
|
||||||
|
| 3 | step-03-implement.md | DEV | Adaptive implementation (TDD or refactor) |
|
||||||
|
| 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)
|
||||||
|
- ✅ Implementation is ADAPTIVE (TDD for new, refactor for existing)
|
||||||
|
- ✅ Works for both greenfield and brownfield
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## EXECUTION MODES
|
||||||
|
|
||||||
|
### Interactive Mode (Default)
|
||||||
|
```bash
|
||||||
|
bmad super-dev-pipeline
|
||||||
|
```
|
||||||
|
|
||||||
|
Features:
|
||||||
|
- Menu navigation between steps
|
||||||
|
- User approval at quality gates
|
||||||
|
- Can pause and resume
|
||||||
|
|
||||||
|
### Batch Mode (For autonomous-epic)
|
||||||
|
```bash
|
||||||
|
bmad super-dev-pipeline --batch
|
||||||
|
```
|
||||||
|
|
||||||
|
Features:
|
||||||
|
- Auto-proceed through all steps
|
||||||
|
- Fail-fast on errors
|
||||||
|
- No vibe coding even at high token counts
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## INITIALIZATION SEQUENCE
|
||||||
|
|
||||||
|
### 1. Configuration Loading
|
||||||
|
|
||||||
|
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
|
- `output_folder`, `sprint_artifacts`, `communication_language`
|
||||||
|
|
||||||
|
### 2. Pipeline Parameters
|
||||||
|
|
||||||
|
Resolve from invocation:
|
||||||
|
- `story_id`: Story identifier (e.g., "1-4")
|
||||||
|
- `story_file`: Path to story file (must exist!)
|
||||||
|
- `mode`: "interactive" or "batch"
|
||||||
|
|
||||||
|
### 3. Document Pre-loading
|
||||||
|
|
||||||
|
Load and cache these documents (read once, use across steps):
|
||||||
|
- Story file: Required, must exist
|
||||||
|
- Project context: `**/project-context.md`
|
||||||
|
- Epic file: Optional, for context
|
||||||
|
|
||||||
|
### 4. First Step Execution
|
||||||
|
|
||||||
|
Load, read the full file and then execute:
|
||||||
|
`{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## QUALITY GATES
|
||||||
|
|
||||||
|
Each gate must pass before proceeding:
|
||||||
|
|
||||||
|
### Pre-Gap Analysis Gate (Step 2)
|
||||||
|
- [ ] All tasks validated against codebase
|
||||||
|
- [ ] Existing code analyzed
|
||||||
|
- [ ] Tasks refined if needed
|
||||||
|
- [ ] No missing context
|
||||||
|
|
||||||
|
### Implementation Gate (Step 3)
|
||||||
|
- [ ] All tasks completed
|
||||||
|
- [ ] Tests pass
|
||||||
|
- [ ] Code follows project patterns
|
||||||
|
- [ ] No TypeScript errors
|
||||||
|
|
||||||
|
### Post-Validation Gate (Step 4)
|
||||||
|
- [ ] All completed tasks verified against codebase
|
||||||
|
- [ ] Zero false positives (or re-implementation complete)
|
||||||
|
- [ ] Files/functions/tests actually exist
|
||||||
|
- [ ] Tests actually pass (not just claimed)
|
||||||
|
|
||||||
|
### Code Review Gate (Step 5)
|
||||||
|
- [ ] 3-10 specific issues identified (not "looks good")
|
||||||
|
- [ ] All issues resolved or documented
|
||||||
|
- [ ] Security review complete
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ANTI-VIBE-CODING ENFORCEMENT
|
||||||
|
|
||||||
|
This workflow **prevents vibe coding** through:
|
||||||
|
|
||||||
|
1. **Mandatory Sequence**: Can't skip ahead or optimize
|
||||||
|
2. **Micro-file Loading**: Only current step in memory
|
||||||
|
3. **Quality Gates**: Must pass criteria to proceed
|
||||||
|
4. **State Tracking**: Progress is recorded and verified
|
||||||
|
5. **Explicit Instructions**: No interpretation required
|
||||||
|
|
||||||
|
**Even at 200K tokens**, Claude must:
|
||||||
|
- ✅ Read entire step file
|
||||||
|
- ✅ Follow numbered sequence
|
||||||
|
- ✅ Complete quality gate
|
||||||
|
- ✅ Update state
|
||||||
|
- ✅ Load next step
|
||||||
|
|
||||||
|
**No shortcuts. No optimizations. No vibe coding.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## SUCCESS METRICS
|
||||||
|
|
||||||
|
### ✅ SUCCESS
|
||||||
|
- Pipeline completes all 7 steps
|
||||||
|
- All quality gates passed
|
||||||
|
- Story status updated
|
||||||
|
- Git commit created
|
||||||
|
- Audit trail generated
|
||||||
|
- **No vibe coding occurred**
|
||||||
|
|
||||||
|
### ❌ FAILURE
|
||||||
|
- Step file instructions skipped or optimized
|
||||||
|
- Quality gate bypassed without approval
|
||||||
|
- State file not updated
|
||||||
|
- Tests not verified
|
||||||
|
- Code review accepts "looks good"
|
||||||
|
- **Vibe coding detected**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## COMPARISON WITH OTHER WORKFLOWS
|
||||||
|
|
||||||
|
| Feature | super-dev-story | story-pipeline | super-dev-pipeline |
|
||||||
|
|---------|----------------|----------------|-------------------|
|
||||||
|
| Architecture | Orchestration | Step-files | Step-files |
|
||||||
|
| Story creation | Separate workflow | Included | ❌ Not included |
|
||||||
|
| ATDD mandatory | No | Yes | No (adaptive) |
|
||||||
|
| Greenfield | ✅ | ✅ | ✅ |
|
||||||
|
| Brownfield | ✅ | ❌ Limited | ✅ |
|
||||||
|
| Token efficiency | ~100-150K | ~25-30K | ~40-60K |
|
||||||
|
| Vibe-proof | ❌ | ✅ | ✅ |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**super-dev-pipeline is the best of both worlds for autonomous-epic!**
|
||||||
|
|
@ -0,0 +1,144 @@
|
||||||
|
name: super-dev-pipeline
|
||||||
|
description: "Step-file architecture for super-dev workflow - works for both greenfield and brownfield development with disciplined execution"
|
||||||
|
author: "BMad"
|
||||||
|
version: "1.0.0"
|
||||||
|
|
||||||
|
# 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"
|
||||||
|
|
||||||
|
# Workflow modes
|
||||||
|
modes:
|
||||||
|
interactive:
|
||||||
|
description: "Human-in-the-loop with menu navigation between steps"
|
||||||
|
checkpoint_on_failure: true
|
||||||
|
requires_approval: true
|
||||||
|
batch:
|
||||||
|
description: "Unattended execution for autonomous-epic"
|
||||||
|
checkpoint_on_failure: true
|
||||||
|
requires_approval: false
|
||||||
|
fail_fast: true
|
||||||
|
|
||||||
|
# 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
|
||||||
Loading…
Reference in New Issue