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**
|
||||
|
||||
This workflow will automatically:
|
||||
1. Create and develop each story using story-pipeline
|
||||
2. **Verify completion** by checking ALL tasks are done (- [x])
|
||||
3. Commit and push after each story (integrated in story-pipeline)
|
||||
4. Generate epic completion report
|
||||
1. Create stories (if backlog) using create-story
|
||||
2. Develop each story using super-dev-pipeline
|
||||
3. **Verify completion** by checking ALL tasks are done (- [x])
|
||||
4. Commit and push after each story (integrated in super-dev-pipeline)
|
||||
5. Generate epic completion report
|
||||
|
||||
**story-pipeline includes:**
|
||||
- Story creation from epic (just-in-time)
|
||||
- Story validation (pre-dev gap analysis)
|
||||
- ATDD test generation (RED phase)
|
||||
- Implementation (GREEN phase)
|
||||
**super-dev-pipeline includes:**
|
||||
- Pre-gap analysis (validates existing code - critical for brownfield!)
|
||||
- Adaptive implementation (TDD for new, refactor for existing)
|
||||
- **Post-implementation validation** (catches false positives!)
|
||||
- Code review (adversarial, finds 3-10 issues)
|
||||
- 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
|
||||
WILL be processed - we check actual task completion, not just status!
|
||||
|
||||
**Time Estimate:** Varies by epic size
|
||||
- Small epic (3-5 stories): 2-4 hours
|
||||
- Medium epic (6-10 stories): 4-8 hours
|
||||
- Large epic (11+ stories): 8-16 hours
|
||||
- Small epic (3-5 stories): 2-5 hours
|
||||
- Medium epic (6-10 stories): 5-10 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>
|
||||
|
||||
<check if="{{epic_num}} provided">
|
||||
|
|
@ -107,14 +112,14 @@
|
|||
|
||||
<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
|
||||
|
||||
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>
|
||||
|
||||
<check if="user says Y">
|
||||
<action>Set {{use_story_pipeline}} = true</action>
|
||||
<action>Set {{use_super_dev_pipeline}} = true</action>
|
||||
</check>
|
||||
|
||||
<check if="user says n">
|
||||
|
|
@ -167,27 +172,45 @@
|
|||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
</output>
|
||||
|
||||
<!-- PROCESS STORY WITH STORY-PIPELINE (handles both backlog creation AND development) -->
|
||||
<check if="{{unchecked_count}} > 0 OR status == 'backlog'">
|
||||
<output>💻 Processing story with story-pipeline ({{unchecked_count}} tasks remaining)...</output>
|
||||
<!-- CREATE STORY IF BACKLOG -->
|
||||
<check if="status == 'backlog'">
|
||||
<output>📝 Creating story from epic...</output>
|
||||
|
||||
<try>
|
||||
<invoke-workflow path="{project-root}/_bmad/bmm/workflows/4-implementation/story-pipeline/workflow.yaml">
|
||||
<input name="story_id" value="{{current_story.key}}" />
|
||||
<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 path="{project-root}/_bmad/bmm/workflows/4-implementation/create-story/workflow.yaml">
|
||||
<note>Create story just-in-time</note>
|
||||
</invoke-workflow>
|
||||
|
||||
<!-- story-pipeline handles verification internally, just check final status -->
|
||||
<output>✅ story-pipeline completed</output>
|
||||
<output>✅ Story created</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 -->
|
||||
<action>Re-read story file and count unchecked tasks</action>
|
||||
|
||||
<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>Mark as partial success</action>
|
||||
</check>
|
||||
|
|
@ -202,7 +225,7 @@
|
|||
</try>
|
||||
|
||||
<catch>
|
||||
<output>❌ story-pipeline failed: {{error}}</output>
|
||||
<output>❌ super-dev-pipeline failed: {{error}}</output>
|
||||
<action>Add to failed_stories with error details</action>
|
||||
<action>Increment failure_count</action>
|
||||
</catch>
|
||||
|
|
|
|||
|
|
@ -22,27 +22,29 @@ project_context: "**/project-context.md"
|
|||
|
||||
# Autonomous mode settings
|
||||
autonomous_settings:
|
||||
use_story_pipeline: true # Use story-pipeline workflow (replaces super-dev-story)
|
||||
pipeline_mode: "batch" # Run story-pipeline in batch mode (unattended)
|
||||
# Use super-dev-pipeline: Step-file architecture that works for BOTH greenfield AND brownfield
|
||||
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
|
||||
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)
|
||||
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)
|
||||
story_pipeline_features:
|
||||
token_efficiency: "65% savings (25-30K vs 100-150K per story)"
|
||||
# super-dev-pipeline benefits
|
||||
super_dev_pipeline_features:
|
||||
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:
|
||||
- "Story creation from epic (just-in-time)"
|
||||
- "Story validation (pre-dev gap analysis)"
|
||||
- "ATDD test generation (RED phase)"
|
||||
- "Implementation (GREEN phase)"
|
||||
- "Pre-gap analysis (validates against existing code)"
|
||||
- "Adaptive implementation (TDD for new, refactor for existing)"
|
||||
- "Post-implementation validation (catches false positives)"
|
||||
- "Code review (adversarial, finds 3-10 issues)"
|
||||
- "Completion (commit + push)"
|
||||
quality_gates: "All super-dev-story gates PLUS post-validation"
|
||||
checkpoint_resume: "Can resume from any step after failure"
|
||||
- "Completion (targeted commit + push)"
|
||||
quality_gates: "All super-dev-story gates with disciplined execution"
|
||||
brownfield_support: "Validates existing code before implementation"
|
||||
|
||||
# TASK-BASED COMPLETION SETTINGS (NEW)
|
||||
# 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