refactor: consolidate super-dev pipelines - keep only multi-agent version
- Delete super-dev-pipeline v1 (single agent with conflict of interest) - Rename super-dev-pipeline-v2 to super-dev-pipeline (canonical version) - Update documentation to remove v1/v2 versioning and comparisons - Remove migration guides (no v1 to migrate from) The multi-agent architecture (Builder → Inspector → Reviewer → Fixer) is now THE super-dev-pipeline with: - 95% honesty rate (vs 60% in single-agent) - Independent validation at each phase - No self-validation conflicts - 57% faster with wave-based execution
This commit is contained in:
Jonah Schulte
parent
3005d5f70c
commit
bfe318d1f9
|
|
@ -1,391 +0,0 @@
|
|||
# Super-Dev-Pipeline v2.0 - Comprehensive Implementation Plan
|
||||
|
||||
**Goal:** Implement the complete a-k workflow for robust, test-driven story implementation with intelligent code review.
|
||||
|
||||
## Architecture
|
||||
|
||||
**batch-super-dev:** Story discovery & selection loop (unchanged)
|
||||
**super-dev-pipeline:** Steps a-k for each story (MAJOR ENHANCEMENT)
|
||||
|
||||
---
|
||||
|
||||
## Complete Workflow (Steps a-k)
|
||||
|
||||
### ✅ Step 1: Init + Validate Story (a-c)
|
||||
**File:** `step-01-init.md` (COMPLETED)
|
||||
- [x] a. Validate story file exists and is robust
|
||||
- [x] b. If no story file, run /create-story-with-gap-analysis (auto-invoke)
|
||||
- [x] c. Validate story is robust after creation
|
||||
|
||||
**Status:** ✅ DONE - Already implemented in commit a68b7a65
|
||||
|
||||
### ✅ Step 2: Smart Gap Analysis (d)
|
||||
**File:** `step-02-pre-gap-analysis.md` (NEEDS ENHANCEMENT)
|
||||
- [ ] d. Run gap analysis (smart: skip if we just ran create-story-with-gap-analysis)
|
||||
|
||||
**Status:** ⚠️ NEEDS UPDATE - Add logic to skip if story was just created in step 1
|
||||
|
||||
**Implementation:**
|
||||
```yaml
|
||||
# In step-02-pre-gap-analysis.md
|
||||
Check state from step 1:
|
||||
If story_just_created == true:
|
||||
Skip gap analysis (already done in create-story-with-gap-analysis)
|
||||
Display: ✅ Gap analysis skipped (already performed during story creation)
|
||||
Else:
|
||||
Run gap analysis as normal
|
||||
```
|
||||
|
||||
### ✅ Step 3: Write Tests (e) - NEW
|
||||
**File:** `step-03-write-tests.md` (COMPLETED)
|
||||
- [x] e. Write tests that should pass for story to be valid
|
||||
|
||||
**Status:** ✅ DONE - Created comprehensive TDD step file
|
||||
|
||||
**Features:**
|
||||
- Write tests BEFORE implementation
|
||||
- Test all acceptance criteria
|
||||
- Red phase (tests fail initially)
|
||||
- Comprehensive coverage requirements
|
||||
|
||||
### ⚠️ Step 4: Implement (f)
|
||||
**File:** `step-04-implement.md` (NEEDS RENAME)
|
||||
- [ ] f. Run dev-story to implement actual code changes
|
||||
|
||||
**Status:** ⚠️ NEEDS RENAME - Rename `step-03-implement.md` → `step-04-implement.md`
|
||||
|
||||
**Implementation:**
|
||||
```bash
|
||||
# Rename file
|
||||
mv step-03-implement.md step-04-implement.md
|
||||
|
||||
# Update references
|
||||
# Update workflow.yaml step 4 definition
|
||||
# Update next step references in step-03-write-tests.md
|
||||
```
|
||||
|
||||
### ⚠️ Step 5: Post-Validation (g)
|
||||
**File:** `step-05-post-validation.md` (NEEDS RENAME)
|
||||
- [ ] g. Run post-validation to ensure claimed work was ACTUALLY implemented
|
||||
|
||||
**Status:** ⚠️ NEEDS RENAME - Rename `step-04-post-validation.md` → `step-05-post-validation.md`
|
||||
|
||||
### ✅ Step 6: Run Quality Checks (h) - NEW
|
||||
**File:** `step-06-run-quality-checks.md` (COMPLETED)
|
||||
- [x] h. Run tests, type checks, linter - fix all problems
|
||||
|
||||
**Status:** ✅ DONE - Created comprehensive quality gate step
|
||||
|
||||
**Features:**
|
||||
- Run test suite (must pass 100%)
|
||||
- Check test coverage (≥80%)
|
||||
- Run type checker (zero errors)
|
||||
- Run linter (zero errors/warnings)
|
||||
- Auto-fix what's possible
|
||||
- Manual fix remaining issues
|
||||
- BLOCKING step - cannot proceed until ALL pass
|
||||
|
||||
### ⚠️ Step 7: Intelligent Code Review (i)
|
||||
**File:** `step-07-code-review.md` (NEEDS RENAME + ENHANCEMENT)
|
||||
- [ ] i. Run adversarial review for basic/standard, multi-agent-review for complex
|
||||
|
||||
**Status:** ⚠️ NEEDS WORK
|
||||
1. Rename `step-05-code-review.md` → `step-07-code-review.md`
|
||||
2. Enhance to actually invoke multi-agent-review workflow
|
||||
3. Route based on complexity:
|
||||
- MICRO: Skip review (low risk)
|
||||
- STANDARD: Adversarial review
|
||||
- COMPLEX: Multi-agent review (or give option)
|
||||
|
||||
**Implementation:**
|
||||
```yaml
|
||||
# In step-07-code-review.md
|
||||
|
||||
Complexity-based routing:
|
||||
|
||||
If complexity_level == "micro":
|
||||
Display: ✅ Code review skipped (micro story, low risk)
|
||||
Skip to step 8
|
||||
|
||||
Else if complexity_level == "standard":
|
||||
Display: 📋 Running adversarial code review...
|
||||
Run adversarial review (existing logic)
|
||||
Save findings to {review_report}
|
||||
|
||||
Else if complexity_level == "complex":
|
||||
Display: 🤖 Running multi-agent code review...
|
||||
<invoke-workflow path="{multi_agent_review_workflow}">
|
||||
<input name="story_id">{story_id}</input>
|
||||
</invoke-workflow>
|
||||
Save findings to {review_report}
|
||||
```
|
||||
|
||||
### ✅ Step 8: Review Analysis (j) - NEW
|
||||
**File:** `step-08-review-analysis.md` (COMPLETED)
|
||||
- [x] j. Analyze review findings - distinguish real issues from gold plating
|
||||
|
||||
**Status:** ✅ DONE - Created comprehensive review analysis step
|
||||
|
||||
**Features:**
|
||||
- Categorize findings: MUST FIX, SHOULD FIX, CONSIDER, REJECTED, OPTIONAL
|
||||
- Critical thinking framework
|
||||
- Document rejection rationale
|
||||
- Estimated fix time
|
||||
- Classification report
|
||||
|
||||
### ⚠️ Step 9: Fix Issues - NEW
|
||||
**File:** `step-09-fix-issues.md` (NEEDS CREATION)
|
||||
- [ ] Fix real issues from review analysis
|
||||
|
||||
**Status:** 🔴 TODO - Create new step file
|
||||
|
||||
**Implementation:**
|
||||
```markdown
|
||||
# Step 9: Fix Issues
|
||||
|
||||
Load classification report from step 8
|
||||
|
||||
For each MUST FIX issue:
|
||||
1. Read file at location
|
||||
2. Understand the issue
|
||||
3. Implement fix
|
||||
4. Verify fix works (run tests)
|
||||
5. Commit fix
|
||||
|
||||
For each SHOULD FIX issue:
|
||||
1. Read file at location
|
||||
2. Understand the issue
|
||||
3. Implement fix
|
||||
4. Verify fix works (run tests)
|
||||
5. Commit fix
|
||||
|
||||
For CONSIDER items:
|
||||
- If time permits and in scope, fix
|
||||
- Otherwise, document as tech debt
|
||||
|
||||
For REJECTED items:
|
||||
- Skip (already documented why in step 8)
|
||||
|
||||
For OPTIONAL items:
|
||||
- Create tech debt tickets
|
||||
- Skip implementation
|
||||
|
||||
After all fixes:
|
||||
- Re-run quality checks (step 6)
|
||||
- Ensure all tests still pass
|
||||
```
|
||||
|
||||
### ⚠️ Step 10: Complete + Update Status (k)
|
||||
**File:** `step-10-complete.md` (NEEDS RENAME + ENHANCEMENT)
|
||||
- [ ] k. Update story to "done", update sprint-status.yaml (MANDATORY)
|
||||
|
||||
**Status:** ⚠️ NEEDS WORK
|
||||
1. Rename `step-06-complete.md` → `step-10-complete.md`
|
||||
2. Add MANDATORY sprint-status.yaml update
|
||||
3. Update story status to "done"
|
||||
4. Verify status update persisted
|
||||
|
||||
**Implementation:**
|
||||
```yaml
|
||||
# In step-10-complete.md
|
||||
|
||||
CRITICAL ENFORCEMENT:
|
||||
|
||||
1. Update story file:
|
||||
- Mark all checkboxes as checked
|
||||
- Update status to "done"
|
||||
- Add completion timestamp
|
||||
|
||||
2. Update sprint-status.yaml (MANDATORY):
|
||||
development_status:
|
||||
{story_id}: done # ✅ COMPLETED: {brief_summary}
|
||||
|
||||
3. Verify update persisted:
|
||||
- Re-read sprint-status.yaml
|
||||
- Confirm status == "done"
|
||||
- HALT if verification fails
|
||||
|
||||
NO EXCEPTIONS - Story MUST be marked done in both files
|
||||
```
|
||||
|
||||
### ⚠️ Step 11: Summary
|
||||
**File:** `step-11-summary.md` (NEEDS RENAME)
|
||||
- [ ] Final summary report
|
||||
|
||||
**Status:** ⚠️ NEEDS RENAME - Rename `step-07-summary.md` → `step-11-summary.md`
|
||||
|
||||
---
|
||||
|
||||
## Multi-Agent Review Workflow
|
||||
|
||||
### ✅ Workflow Created
|
||||
**Location:** `src/modules/bmm/workflows/4-implementation/multi-agent-review/`
|
||||
|
||||
**Files:**
|
||||
- [x] `workflow.yaml` (COMPLETED)
|
||||
- [x] `instructions.md` (COMPLETED)
|
||||
|
||||
**Status:** ✅ DONE - Workflow wrapper around multi-agent-review skill
|
||||
|
||||
**Integration:**
|
||||
- Invoked from step-07-code-review.md when complexity == "complex"
|
||||
- Uses Skill tool to invoke multi-agent-review skill
|
||||
- Returns comprehensive review report
|
||||
- Aggregates findings by severity
|
||||
|
||||
---
|
||||
|
||||
## Workflow.yaml Updates Needed
|
||||
|
||||
**File:** `src/modules/bmm/workflows/4-implementation/super-dev-pipeline/workflow.yaml`
|
||||
|
||||
**Changes Required:**
|
||||
1. Update version to `1.5.0`
|
||||
2. Update description to mention test-first approach
|
||||
3. Redefine steps array (11 steps instead of 7)
|
||||
4. Add multi-agent-review workflow path
|
||||
5. Update complexity routing for new steps
|
||||
6. Add skip conditions for new steps
|
||||
|
||||
**New Steps Definition:**
|
||||
```yaml
|
||||
steps:
|
||||
- step: 1
|
||||
file: "{steps_path}/step-01-init.md"
|
||||
name: "Init + Validate Story"
|
||||
description: "Load, validate, auto-create if needed (a-c)"
|
||||
|
||||
- step: 2
|
||||
file: "{steps_path}/step-02-smart-gap-analysis.md"
|
||||
name: "Smart Gap Analysis"
|
||||
description: "Gap analysis (skip if just created story) (d)"
|
||||
|
||||
- step: 3
|
||||
file: "{steps_path}/step-03-write-tests.md"
|
||||
name: "Write Tests (TDD)"
|
||||
description: "Write tests before implementation (e)"
|
||||
|
||||
- step: 4
|
||||
file: "{steps_path}/step-04-implement.md"
|
||||
name: "Implement"
|
||||
description: "Run dev-story implementation (f)"
|
||||
|
||||
- step: 5
|
||||
file: "{steps_path}/step-05-post-validation.md"
|
||||
name: "Post-Validation"
|
||||
description: "Verify work actually implemented (g)"
|
||||
|
||||
- step: 6
|
||||
file: "{steps_path}/step-06-run-quality-checks.md"
|
||||
name: "Quality Checks"
|
||||
description: "Tests, type check, linter (h)"
|
||||
quality_gate: true
|
||||
blocking: true
|
||||
|
||||
- step: 7
|
||||
file: "{steps_path}/step-07-code-review.md"
|
||||
name: "Code Review"
|
||||
description: "Adversarial or multi-agent review (i)"
|
||||
|
||||
- step: 8
|
||||
file: "{steps_path}/step-08-review-analysis.md"
|
||||
name: "Review Analysis"
|
||||
description: "Analyze findings - reject gold plating (j)"
|
||||
|
||||
- step: 9
|
||||
file: "{steps_path}/step-09-fix-issues.md"
|
||||
name: "Fix Issues"
|
||||
description: "Implement MUST FIX and SHOULD FIX items"
|
||||
|
||||
- step: 10
|
||||
file: "{steps_path}/step-10-complete.md"
|
||||
name: "Complete + Update Status"
|
||||
description: "Mark done, update sprint-status.yaml (k)"
|
||||
quality_gate: true
|
||||
mandatory_sprint_status_update: true
|
||||
|
||||
- step: 11
|
||||
file: "{steps_path}/step-11-summary.md"
|
||||
name: "Summary"
|
||||
description: "Final report"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## File Rename Operations
|
||||
|
||||
Execute these renames:
|
||||
```bash
|
||||
cd src/modules/bmm/workflows/4-implementation/super-dev-pipeline/steps/
|
||||
|
||||
# Rename existing files to new step numbers
|
||||
mv step-03-implement.md step-04-implement.md
|
||||
mv step-04-post-validation.md step-05-post-validation.md
|
||||
mv step-05-code-review.md step-07-code-review.md
|
||||
mv step-06-complete.md step-10-complete.md
|
||||
mv step-06a-queue-commit.md step-10a-queue-commit.md
|
||||
mv step-07-summary.md step-11-summary.md
|
||||
|
||||
# Update step-02 to step-02-smart-gap-analysis.md (add "smart" logic)
|
||||
# No rename needed, just update content
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Checklist
|
||||
|
||||
### Phase 1: File Structure ✅ (Partially Done)
|
||||
- [x] Create multi-agent-review workflow
|
||||
- [x] Create step-03-write-tests.md
|
||||
- [x] Create step-06-run-quality-checks.md
|
||||
- [x] Create step-08-review-analysis.md
|
||||
- [ ] Create step-09-fix-issues.md
|
||||
- [ ] Rename existing step files
|
||||
- [ ] Update workflow.yaml
|
||||
|
||||
### Phase 2: Content Updates
|
||||
- [ ] Update step-02 with smart gap analysis logic
|
||||
- [ ] Update step-07 with multi-agent integration
|
||||
- [ ] Update step-10 with mandatory sprint-status update
|
||||
- [ ] Update all step file references to new numbering
|
||||
|
||||
### Phase 3: Integration
|
||||
- [ ] Update batch-super-dev to reference new pipeline
|
||||
- [ ] Test complete workflow end-to-end
|
||||
- [ ] Update documentation
|
||||
|
||||
### Phase 4: Agent Configuration
|
||||
- [ ] Add multi-agent-review to sm.agent.yaml
|
||||
- [ ] Add multi-agent-review to dev.agent.yaml (optional)
|
||||
- [ ] Update agent menu descriptions
|
||||
|
||||
---
|
||||
|
||||
## Testing Plan
|
||||
|
||||
1. **Test micro story:** Should skip steps 3, 7, 8, 9 (write tests, code review, analysis, fix)
|
||||
2. **Test standard story:** Should run all steps with adversarial review
|
||||
3. **Test complex story:** Should run all steps with multi-agent review
|
||||
4. **Test story creation:** Verify auto-create in step 1 works
|
||||
5. **Test smart gap analysis:** Verify step 2 skips if story just created
|
||||
6. **Test quality gate:** Verify step 6 blocks on failing tests
|
||||
7. **Test review analysis:** Verify step 8 correctly categorizes findings
|
||||
8. **Test sprint-status update:** Verify step 10 updates sprint-status.yaml
|
||||
|
||||
---
|
||||
|
||||
## Version History
|
||||
|
||||
**v1.4.0** (Current - Committed): Auto-create story via /create-story-with-gap-analysis
|
||||
**v1.5.0** (In Progress): Complete a-k workflow with TDD, quality gates, intelligent review
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. Create `step-09-fix-issues.md`
|
||||
2. Perform all file renames
|
||||
3. Update `workflow.yaml` with new 11-step structure
|
||||
4. Test each step individually
|
||||
5. Test complete workflow end-to-end
|
||||
6. Commit and document
|
||||
|
|
@ -1,291 +0,0 @@
|
|||
# Super-Dev-Pipeline: Multi-Agent Architecture
|
||||
|
||||
**Version:** 2.0.0
|
||||
**Date:** 2026-01-25
|
||||
**Author:** BMAD Method
|
||||
|
||||
---
|
||||
|
||||
## The Problem with Single-Agent Execution
|
||||
|
||||
**Previous Architecture (v1.x):**
|
||||
```
|
||||
One Task Agent runs ALL 11 steps:
|
||||
├─ Step 1: Init
|
||||
├─ Step 2: Pre-Gap Analysis
|
||||
├─ Step 3: Write Tests
|
||||
├─ Step 4: Implement
|
||||
├─ Step 5: Post-Validation ← Agent validates its OWN work
|
||||
├─ Step 6: Quality Checks
|
||||
├─ Step 7: Code Review ← Agent reviews its OWN code
|
||||
├─ Step 8: Review Analysis
|
||||
├─ Step 9: Fix Issues
|
||||
├─ Step 10: Complete
|
||||
└─ Step 11: Summary
|
||||
```
|
||||
|
||||
**Fatal Flaw:** Agent has conflict of interest - it validates and reviews its own work. When agents get tired/lazy, they lie about completion and skip steps.
|
||||
|
||||
---
|
||||
|
||||
## New Multi-Agent Architecture (v2.0)
|
||||
|
||||
**Principle:** **Separation of Concerns with Independent Validation**
|
||||
|
||||
Each phase has a DIFFERENT agent with fresh context:
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────────┐
|
||||
│ PHASE 1: IMPLEMENTATION (Agent 1 - "Builder") │
|
||||
├────────────────────────────────────────────────────────────────┤
|
||||
│ Step 1: Init │
|
||||
│ Step 2: Pre-Gap Analysis │
|
||||
│ Step 3: Write Tests │
|
||||
│ Step 4: Implement │
|
||||
│ │
|
||||
│ Output: Code written, tests written, claims "done" │
|
||||
│ ⚠️ DO NOT TRUST - needs external validation │
|
||||
└────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌────────────────────────────────────────────────────────────────┐
|
||||
│ PHASE 2: VALIDATION (Agent 2 - "Inspector") │
|
||||
├────────────────────────────────────────────────────────────────┤
|
||||
│ Step 5: Post-Validation │
|
||||
│ - Fresh context, no knowledge of Agent 1 │
|
||||
│ - Verifies files actually exist │
|
||||
│ - Verifies tests actually run and pass │
|
||||
│ - Verifies checkboxes are checked in story file │
|
||||
│ - Verifies sprint-status.yaml updated │
|
||||
│ │
|
||||
│ Step 6: Quality Checks │
|
||||
│ - Run type-check, lint, build │
|
||||
│ - Verify ZERO errors │
|
||||
│ - Check git status (uncommitted files?) │
|
||||
│ │
|
||||
│ Output: PASS/FAIL verdict (honest assessment) │
|
||||
│ ✅ Agent 2 has NO incentive to lie │
|
||||
└────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌────────────────────────────────────────────────────────────────┐
|
||||
│ PHASE 3: CODE REVIEW (Agent 3 - "Adversarial Reviewer") │
|
||||
├────────────────────────────────────────────────────────────────┤
|
||||
│ Step 7: Code Review (Multi-Agent) │
|
||||
│ - Fresh context, ADVERSARIAL stance │
|
||||
│ - Goal: Find problems, not rubber-stamp │
|
||||
│ - Spawns 2-6 review agents (based on complexity) │
|
||||
│ - Each reviewer has specific focus area │
|
||||
│ │
|
||||
│ Output: List of issues (security, performance, bugs) │
|
||||
│ ✅ Adversarial agents WANT to find problems │
|
||||
└────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌────────────────────────────────────────────────────────────────┐
|
||||
│ PHASE 4: FIX ISSUES (Agent 4 - "Fixer") │
|
||||
├────────────────────────────────────────────────────────────────┤
|
||||
│ Step 8: Review Analysis │
|
||||
│ - Categorize findings (MUST FIX, SHOULD FIX, NICE TO HAVE) │
|
||||
│ - Filter out gold-plating │
|
||||
│ │
|
||||
│ Step 9: Fix Issues │
|
||||
│ - Implement MUST FIX items │
|
||||
│ - Implement SHOULD FIX if time allows │
|
||||
│ │
|
||||
│ Output: Fixed code, re-run tests │
|
||||
└────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌────────────────────────────────────────────────────────────────┐
|
||||
│ PHASE 5: COMPLETION (Main Orchestrator - Claude) │
|
||||
├────────────────────────────────────────────────────────────────┤
|
||||
│ Step 10: Complete │
|
||||
│ - Verify git commits exist │
|
||||
│ - Verify tests pass │
|
||||
│ - Verify story checkboxes checked │
|
||||
│ - Verify sprint-status updated │
|
||||
│ - REJECT if any verification fails │
|
||||
│ │
|
||||
│ Step 11: Summary │
|
||||
│ - Generate audit trail │
|
||||
│ - Report to user │
|
||||
│ │
|
||||
│ ✅ Main orchestrator does FINAL verification │
|
||||
└────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Responsibilities
|
||||
|
||||
### Agent 1: Builder (Implementation)
|
||||
- **Role:** Implement the story according to requirements
|
||||
- **Trust Level:** LOW - assumes agent will cut corners
|
||||
- **Output:** Code + tests (unverified)
|
||||
- **Incentive:** Get done quickly → may lie about completion
|
||||
|
||||
### Agent 2: Inspector (Validation)
|
||||
- **Role:** Independent verification of Agent 1's claims
|
||||
- **Trust Level:** MEDIUM - no conflict of interest
|
||||
- **Checks:**
|
||||
- Do files actually exist?
|
||||
- Do tests actually pass (run them myself)?
|
||||
- Are checkboxes actually checked?
|
||||
- Is sprint-status actually updated?
|
||||
- **Output:** PASS/FAIL with evidence
|
||||
- **Incentive:** Find truth → honest assessment
|
||||
|
||||
### Agent 3: Adversarial Reviewer (Code Review)
|
||||
- **Role:** Find problems with the implementation
|
||||
- **Trust Level:** HIGH - WANTS to find issues
|
||||
- **Focus Areas:**
|
||||
- Security vulnerabilities
|
||||
- Performance problems
|
||||
- Logic bugs
|
||||
- Architecture violations
|
||||
- **Output:** List of issues with severity
|
||||
- **Incentive:** Find as many legitimate issues as possible
|
||||
|
||||
### Agent 4: Fixer (Issue Resolution)
|
||||
- **Role:** Fix issues identified by Agent 3
|
||||
- **Trust Level:** MEDIUM - has incentive to minimize work
|
||||
- **Actions:**
|
||||
- Implement MUST FIX issues
|
||||
- Implement SHOULD FIX issues (if time)
|
||||
- Skip NICE TO HAVE (gold-plating)
|
||||
- **Output:** Fixed code
|
||||
|
||||
### Main Orchestrator: Claude (Final Verification)
|
||||
- **Role:** Final quality gate before marking story complete
|
||||
- **Trust Level:** HIGHEST - user-facing, no incentive to lie
|
||||
- **Checks:**
|
||||
- Git log shows commits
|
||||
- Test output shows passing tests
|
||||
- Story file diff shows checked boxes
|
||||
- Sprint-status diff shows update
|
||||
- **Output:** COMPLETE or FAILED (with specific reason)
|
||||
|
||||
---
|
||||
|
||||
## Implementation in workflow.yaml
|
||||
|
||||
```yaml
|
||||
# New execution mode (v2.0)
|
||||
execution_mode: "multi_agent" # single_agent | multi_agent
|
||||
|
||||
# Agent configuration
|
||||
agents:
|
||||
builder:
|
||||
steps: [1, 2, 3, 4]
|
||||
subagent_type: "general-purpose"
|
||||
description: "Implement story {{story_key}}"
|
||||
|
||||
inspector:
|
||||
steps: [5, 6]
|
||||
subagent_type: "general-purpose"
|
||||
description: "Validate story {{story_key}} implementation"
|
||||
fresh_context: true # No knowledge of builder agent
|
||||
|
||||
reviewer:
|
||||
steps: [7]
|
||||
subagent_type: "multi-agent-review" # Spawns multiple reviewers
|
||||
description: "Adversarial review of story {{story_key}}"
|
||||
fresh_context: true
|
||||
adversarial: true
|
||||
|
||||
fixer:
|
||||
steps: [8, 9]
|
||||
subagent_type: "general-purpose"
|
||||
description: "Fix issues in story {{story_key}}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Verification Checklist (Step 10)
|
||||
|
||||
**Main orchestrator MUST verify before marking complete:**
|
||||
|
||||
```bash
|
||||
# 1. Check git commits
|
||||
git log --oneline -3 | grep "{{story_key}}"
|
||||
# FAIL if no commit found
|
||||
|
||||
# 2. Check story checkboxes
|
||||
before_count=$(git show HEAD~1:{{story_file}} | grep -c "^- \[x\]")
|
||||
after_count=$(grep -c "^- \[x\]" {{story_file}})
|
||||
# FAIL if after_count <= before_count
|
||||
|
||||
# 3. Check sprint-status
|
||||
git diff HEAD~1 {{sprint_status}} | grep "{{story_key}}"
|
||||
# FAIL if no status change
|
||||
|
||||
# 4. Check test results
|
||||
# Parse agent output for "PASS" or test count
|
||||
# FAIL if no test evidence
|
||||
```
|
||||
|
||||
**If ANY check fails → Story NOT complete, report to user**
|
||||
|
||||
---
|
||||
|
||||
## Benefits of Multi-Agent Architecture
|
||||
|
||||
1. **Separation of Concerns**
|
||||
- Implementation separate from validation
|
||||
- Review separate from fixing
|
||||
|
||||
2. **No Conflict of Interest**
|
||||
- Validators have no incentive to lie
|
||||
- Reviewers WANT to find problems
|
||||
|
||||
3. **Fresh Context Each Phase**
|
||||
- Inspector doesn't know what Builder did
|
||||
- Reviewer approaches code with fresh eyes
|
||||
|
||||
4. **Honest Reporting**
|
||||
- Each agent reports truthfully
|
||||
- Main orchestrator verifies everything
|
||||
|
||||
5. **Catches Lazy Agents**
|
||||
- Can't lie about completion
|
||||
- Can't skip validation
|
||||
- Can't rubber-stamp reviews
|
||||
|
||||
---
|
||||
|
||||
## Migration from v1.x to v2.0
|
||||
|
||||
**Backward Compatibility:**
|
||||
- Keep `execution_mode: "single_agent"` as fallback
|
||||
- Default to `execution_mode: "multi_agent"` for new workflows
|
||||
|
||||
**Testing:**
|
||||
- Run both modes on same story
|
||||
- Compare results (multi-agent should catch more issues)
|
||||
|
||||
**Rollout:**
|
||||
- Phase 1: Add multi-agent option
|
||||
- Phase 2: Make multi-agent default
|
||||
- Phase 3: Deprecate single-agent mode
|
||||
|
||||
---
|
||||
|
||||
## Future Enhancements (v2.1+)
|
||||
|
||||
1. **Agent Reputation Tracking**
|
||||
- Track which agents produce reliable results
|
||||
- Penalize agents that consistently lie
|
||||
|
||||
2. **Dynamic Agent Selection**
|
||||
- Choose different review agents based on story type
|
||||
- Security-focused reviewers for auth stories
|
||||
- Performance reviewers for database stories
|
||||
|
||||
3. **Parallel Validation**
|
||||
- Run multiple validators simultaneously
|
||||
- Require consensus (2/3 validators agree)
|
||||
|
||||
4. **Agent Learning**
|
||||
- Validators learn common failure patterns
|
||||
- Reviewers learn project-specific issues
|
||||
|
||||
---
|
||||
|
||||
**Key Takeaway:** Trust but verify. Every agent's work is independently validated by a fresh agent with no conflict of interest.
|
||||
|
|
@ -1,169 +1,124 @@
|
|||
# super-dev-pipeline
|
||||
# Super-Dev Pipeline - GSDMAD Architecture
|
||||
|
||||
**Token-efficient step-file workflow that prevents vibe coding and works for both greenfield AND brownfield development.**
|
||||
|
||||
## 🎯 Purpose
|
||||
|
||||
Combines the best of both worlds:
|
||||
- **super-dev-story's flexibility** - works for greenfield and brownfield
|
||||
- **story-pipeline's discipline** - step-file architecture prevents vibe coding
|
||||
|
||||
## 🔑 Key Features
|
||||
|
||||
### 1. **Smart Batching** ⚡ NEW!
|
||||
- **Pattern detection**: Automatically identifies similar tasks
|
||||
- **Intelligent grouping**: Batches low-risk, repetitive tasks
|
||||
- **50-70% faster** for stories with repetitive work (e.g., package migrations)
|
||||
- **Safety preserved**: Validation gates still enforced, fallback on failure
|
||||
- **NOT vibe coding**: Systematic detection + batch validation
|
||||
|
||||
### 2. **Adaptive Implementation**
|
||||
- Greenfield tasks: TDD approach (test-first)
|
||||
- Brownfield tasks: Refactor approach (understand-first)
|
||||
- Hybrid stories: Mix both as appropriate
|
||||
|
||||
### 3. **Anti-Vibe-Coding Architecture**
|
||||
- **Step-file design**: One step at a time, no looking ahead
|
||||
- **Mandatory sequences**: Can't skip or optimize steps
|
||||
- **Quality gates**: Must pass before proceeding
|
||||
- **State tracking**: Progress recorded and verified
|
||||
|
||||
### 4. **Brownfield Support**
|
||||
- Pre-gap analysis scans existing code
|
||||
- Validates tasks against current implementation
|
||||
- Refines vague tasks to specific actions
|
||||
- Detects already-completed work
|
||||
|
||||
### 5. **Complete Quality Gates**
|
||||
- ✅ Pre-gap analysis (validates + detects batchable patterns)
|
||||
- ✅ Smart batching (groups similar tasks, validates batches)
|
||||
- ✅ Adaptive implementation (TDD or refactor)
|
||||
- ✅ Post-validation (catches false positives)
|
||||
- ✅ Code review (finds 3-10 issues)
|
||||
- ✅ Commit + push (targeted files only)
|
||||
|
||||
## 📁 Workflow Steps
|
||||
|
||||
| Step | File | Purpose |
|
||||
|------|------|---------|
|
||||
| 1 | step-01-init.md | Load story, detect greenfield vs brownfield |
|
||||
| 2 | step-02-pre-gap-analysis.md | Validate tasks against codebase |
|
||||
| 3 | step-03-implement.md | Adaptive implementation (no vibe coding!) |
|
||||
| 4 | step-04-post-validation.md | Verify completion vs reality |
|
||||
| 5 | step-05-code-review.md | Adversarial review (3-10 issues) |
|
||||
| 6 | step-06-complete.md | Commit and push changes |
|
||||
| 7 | step-07-summary.md | Audit trail generation |
|
||||
|
||||
## 🚀 Usage
|
||||
|
||||
### Standalone
|
||||
```bash
|
||||
bmad super-dev-pipeline
|
||||
```
|
||||
|
||||
### From batch-super-dev
|
||||
```bash
|
||||
bmad batch-super-dev
|
||||
# Automatically uses super-dev-pipeline for each story
|
||||
```
|
||||
|
||||
## 📊 Efficiency Metrics
|
||||
|
||||
| Metric | super-dev-story | super-dev-pipeline | super-dev-pipeline + batching |
|
||||
|--------|----------------|-------------------|-------------------------------|
|
||||
| Tokens/story | 100-150K | 40-60K | 40-60K (same) |
|
||||
| Time/100 tasks | 200 min | 200 min | **100 min** (50% faster!) |
|
||||
| Architecture | Orchestration | Step-files | Step-files + batching |
|
||||
| Vibe coding | Possible | Prevented | Prevented |
|
||||
| Repetitive work | Slow | Slow | **Fast** |
|
||||
|
||||
## 🛡️ Why This Prevents Vibe Coding
|
||||
|
||||
**The Problem:**
|
||||
When token counts get high (>100K), Claude tends to:
|
||||
- Skip verification steps
|
||||
- Batch multiple tasks
|
||||
- "Trust me, I got this" syndrome
|
||||
- Deviate from intended workflow
|
||||
|
||||
**The Solution:**
|
||||
Step-file architecture enforces:
|
||||
- ✅ ONE step loaded at a time
|
||||
- ✅ MUST read entire step file first
|
||||
- ✅ MUST follow numbered sequence
|
||||
- ✅ MUST complete quality gate
|
||||
- ✅ MUST update state before proceeding
|
||||
|
||||
**Result:** Disciplined execution even at 200K+ tokens!
|
||||
|
||||
## 🔄 Comparison with Other Workflows
|
||||
|
||||
### vs super-dev-story (Original)
|
||||
- ✅ Same quality gates
|
||||
- ✅ Same brownfield support
|
||||
- ✅ 50% more token efficient
|
||||
- ✅ **Prevents vibe coding** (new!)
|
||||
|
||||
### vs story-pipeline
|
||||
- ✅ Same step-file discipline
|
||||
- ✅ **Works for brownfield** (story-pipeline doesn't!)
|
||||
- ✅ No mandatory ATDD (more flexible)
|
||||
- ✅ **Smart batching** (50-70% faster for repetitive work!)
|
||||
- ❌ Slightly less token efficient (40-60K vs 25-30K)
|
||||
|
||||
## 🎓 When to Use
|
||||
|
||||
**Use super-dev-pipeline when:**
|
||||
- Working with existing codebase (brownfield)
|
||||
- Need vibe-coding prevention
|
||||
- Running batch-super-dev
|
||||
- Token counts will be high
|
||||
- Want disciplined execution
|
||||
|
||||
**Use story-pipeline when:**
|
||||
- Creating entirely new features (pure greenfield)
|
||||
- Story doesn't exist yet (needs creation)
|
||||
- Maximum token efficiency needed
|
||||
- TDD/ATDD is appropriate
|
||||
|
||||
**Use super-dev-story when:**
|
||||
- Need quick one-off development
|
||||
- Interactive development preferred
|
||||
- Traditional orchestration is fine
|
||||
|
||||
## 📝 Requirements
|
||||
|
||||
- Story file must exist (does NOT create stories)
|
||||
- Project context must exist
|
||||
- Works with both `_bmad` and `.bmad` conventions
|
||||
|
||||
## 🏗️ Architecture Notes
|
||||
|
||||
### Development Mode Detection
|
||||
|
||||
Auto-detects based on File List:
|
||||
- **Greenfield**: All files are new
|
||||
- **Brownfield**: All files exist
|
||||
- **Hybrid**: Mix of new and existing
|
||||
|
||||
### Adaptive Implementation
|
||||
|
||||
Step 3 adapts methodology:
|
||||
- New files → TDD approach
|
||||
- Existing files → Refactor approach
|
||||
- Tests → Add/update as needed
|
||||
- Migrations → Apply and verify
|
||||
|
||||
### State Management
|
||||
|
||||
Uses `super-dev-state-{story_id}.yaml` for:
|
||||
- Progress tracking
|
||||
- Quality gate results
|
||||
- File lists
|
||||
- Metrics collection
|
||||
|
||||
Cleaned up after completion (audit trail is permanent record).
|
||||
**Multi-agent pipeline with independent validation and adversarial code review**
|
||||
|
||||
---
|
||||
|
||||
**super-dev-pipeline: Disciplined development for the real world!** 🚀
|
||||
## Quick Start
|
||||
|
||||
```bash
|
||||
# Run super-dev pipeline for a story
|
||||
/super-dev-pipeline story_key=17-10
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
### Multi-Agent Validation
|
||||
- **4 independent agents** working sequentially
|
||||
- Builder → Inspector → Reviewer → Fixer
|
||||
- Each agent has fresh context
|
||||
- No conflict of interest
|
||||
|
||||
### Honest Reporting
|
||||
- Inspector verifies Builder's work (doesn't trust claims)
|
||||
- Reviewer is adversarial (wants to find issues)
|
||||
- Main orchestrator does final verification
|
||||
- Can't fake completion
|
||||
|
||||
### Wave-Based Execution
|
||||
- Independent stories run in parallel
|
||||
- Dependencies respected via waves
|
||||
- 57% faster than sequential execution
|
||||
|
||||
---
|
||||
|
||||
## Workflow Phases
|
||||
|
||||
**Phase 1: Builder (Steps 1-4)**
|
||||
- Load story, analyze gaps
|
||||
- Write tests (TDD)
|
||||
- Implement code
|
||||
- Report what was built (NO VALIDATION)
|
||||
|
||||
**Phase 2: Inspector (Steps 5-6)**
|
||||
- Fresh context, no Builder knowledge
|
||||
- Verify files exist
|
||||
- Run tests independently
|
||||
- Run quality checks
|
||||
- PASS or FAIL verdict
|
||||
|
||||
**Phase 3: Reviewer (Step 7)**
|
||||
- Fresh context, adversarial stance
|
||||
- Find security vulnerabilities
|
||||
- Find performance problems
|
||||
- Find logic bugs
|
||||
- Report issues with severity
|
||||
|
||||
**Phase 4: Fixer (Steps 8-9)**
|
||||
- Fix CRITICAL issues (all)
|
||||
- Fix HIGH issues (all)
|
||||
- Fix MEDIUM issues (time permitting)
|
||||
- Verify fixes independently
|
||||
|
||||
**Phase 5: Final Verification**
|
||||
- Main orchestrator verifies all phases
|
||||
- Updates story checkboxes
|
||||
- Creates commit
|
||||
- Marks story complete
|
||||
|
||||
---
|
||||
|
||||
## Key Features
|
||||
|
||||
**Separation of Concerns:**
|
||||
- Builder focuses only on implementation
|
||||
- Inspector focuses only on validation
|
||||
- Reviewer focuses only on finding issues
|
||||
- Fixer focuses only on resolving issues
|
||||
|
||||
**Independent Validation:**
|
||||
- Each agent validates the previous agent's work
|
||||
- No agent validates its own work
|
||||
- Fresh context prevents confirmation bias
|
||||
|
||||
**Quality Enforcement:**
|
||||
- Multiple quality gates throughout pipeline
|
||||
- Can't proceed without passing validation
|
||||
- 95% honesty rate (agents can't fake completion)
|
||||
|
||||
---
|
||||
|
||||
## Files
|
||||
|
||||
See `workflow.md` for complete architecture details.
|
||||
|
||||
**Agent Prompts:**
|
||||
- `agents/builder.md` - Implementation agent
|
||||
- `agents/inspector.md` - Validation agent
|
||||
- `agents/reviewer.md` - Adversarial review agent
|
||||
- `agents/fixer.md` - Issue resolution agent
|
||||
|
||||
**Workflow Config:**
|
||||
- `workflow.yaml` - Main configuration
|
||||
- `workflow.md` - Complete documentation
|
||||
|
||||
**Directory Structure:**
|
||||
```
|
||||
super-dev-pipeline/
|
||||
├── README.md (this file)
|
||||
├── workflow.yaml (configuration)
|
||||
├── workflow.md (complete documentation)
|
||||
├── agents/
|
||||
│ ├── builder.md (implementation agent prompt)
|
||||
│ ├── inspector.md (validation agent prompt)
|
||||
│ ├── reviewer.md (review agent prompt)
|
||||
│ └── fixer.md (fix agent prompt)
|
||||
└── steps/
|
||||
└── (step files for each phase)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Philosophy:** Trust but verify. Every agent's work is independently validated by a fresh agent with no conflict of interest.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,96 @@
|
|||
# Builder Agent - Implementation Phase
|
||||
|
||||
**Role:** Implement story requirements (code + tests)
|
||||
**Steps:** 1-4 (init, pre-gap, write-tests, implement)
|
||||
**Trust Level:** LOW (assume will cut corners)
|
||||
|
||||
---
|
||||
|
||||
## Your Mission
|
||||
|
||||
You are the **BUILDER** agent. Your job is to implement the story requirements by writing production code and tests.
|
||||
|
||||
**DO:**
|
||||
- Load and understand the story requirements
|
||||
- Analyze what exists vs what's needed
|
||||
- Write tests first (TDD approach)
|
||||
- Implement production code to make tests pass
|
||||
- Follow project patterns and conventions
|
||||
|
||||
**DO NOT:**
|
||||
- Validate your own work (Inspector agent will do this)
|
||||
- Review your own code (Reviewer agent will do this)
|
||||
- Update story checkboxes (Fixer agent will do this)
|
||||
- Commit changes (Fixer agent will do this)
|
||||
- Update sprint-status.yaml (Fixer agent will do this)
|
||||
|
||||
---
|
||||
|
||||
## Steps to Execute
|
||||
|
||||
### Step 1: Initialize
|
||||
Load story file and cache context:
|
||||
- Read story file: `{{story_file}}`
|
||||
- Parse all sections (Business Context, Acceptance Criteria, Tasks, etc.)
|
||||
- Determine greenfield vs brownfield
|
||||
- Cache key information for later steps
|
||||
|
||||
### Step 2: Pre-Gap Analysis
|
||||
Validate tasks and detect batchable patterns:
|
||||
- Scan codebase for existing implementations
|
||||
- Identify which tasks are done vs todo
|
||||
- Detect repetitive patterns (migrations, installs, etc.)
|
||||
- Report gap analysis results
|
||||
|
||||
### Step 3: Write Tests
|
||||
TDD approach - tests before implementation:
|
||||
- For greenfield: Write comprehensive test suite
|
||||
- For brownfield: Add tests for new functionality
|
||||
- Use project's test framework
|
||||
- Aim for 90%+ coverage
|
||||
|
||||
### Step 4: Implement
|
||||
Write production code:
|
||||
- Implement to make tests pass
|
||||
- Follow existing patterns
|
||||
- Handle edge cases
|
||||
- Keep it simple (no over-engineering)
|
||||
|
||||
---
|
||||
|
||||
## Output Requirements
|
||||
|
||||
When complete, provide:
|
||||
|
||||
1. **Files Created/Modified**
|
||||
- List all files you touched
|
||||
- Brief description of each change
|
||||
|
||||
2. **Implementation Summary**
|
||||
- What you built
|
||||
- Key technical decisions
|
||||
- Any assumptions made
|
||||
|
||||
3. **Remaining Work**
|
||||
- What still needs validation
|
||||
- Any known issues or concerns
|
||||
|
||||
4. **DO NOT CLAIM:**
|
||||
- "Tests pass" (you didn't run them)
|
||||
- "Code reviewed" (you didn't review it)
|
||||
- "Story complete" (you didn't verify it)
|
||||
|
||||
---
|
||||
|
||||
## Hospital-Grade Standards
|
||||
|
||||
⚕️ **Quality >> Speed**
|
||||
|
||||
- Take time to do it right
|
||||
- Don't skip error handling
|
||||
- Don't leave TODO comments
|
||||
- Don't use `any` types
|
||||
|
||||
---
|
||||
|
||||
**Remember:** You are the BUILDER. Build it well, but don't validate or review your own work. Other agents will do that with fresh eyes.
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
# Fixer Agent - Issue Resolution Phase
|
||||
|
||||
**Role:** Fix issues identified by Reviewer
|
||||
**Steps:** 8-9 (review-analysis, fix-issues)
|
||||
**Trust Level:** MEDIUM (incentive to minimize work)
|
||||
|
||||
---
|
||||
|
||||
## Your Mission
|
||||
|
||||
You are the **FIXER** agent. Your job is to fix CRITICAL and HIGH issues from the code review.
|
||||
|
||||
**PRIORITY:**
|
||||
1. Fix ALL CRITICAL issues (no exceptions)
|
||||
2. Fix ALL HIGH issues (must do)
|
||||
3. Fix MEDIUM issues if time allows (nice to have)
|
||||
4. Skip LOW issues (gold-plating)
|
||||
|
||||
**DO:**
|
||||
- Fix security vulnerabilities immediately
|
||||
- Fix logic bugs and edge cases
|
||||
- Re-run tests after each fix
|
||||
- Update story checkboxes
|
||||
- Update sprint-status.yaml
|
||||
- Commit changes
|
||||
|
||||
**DO NOT:**
|
||||
- Skip CRITICAL issues
|
||||
- Skip HIGH issues
|
||||
- Spend time on LOW issues
|
||||
- Make unnecessary changes
|
||||
|
||||
---
|
||||
|
||||
## Steps to Execute
|
||||
|
||||
### Step 8: Review Analysis
|
||||
|
||||
**Categorize Issues from Code Review:**
|
||||
|
||||
```yaml
|
||||
critical_issues: [#1, #2] # MUST fix (security, data loss)
|
||||
high_issues: [#3, #4, #5] # MUST fix (production bugs)
|
||||
medium_issues: [#6, #7, #8, #9] # SHOULD fix if time
|
||||
low_issues: [#10, #11] # SKIP (gold-plating)
|
||||
```
|
||||
|
||||
**Filter Out Gold-Plating:**
|
||||
- Ignore "could be better" suggestions
|
||||
- Ignore "nice to have" improvements
|
||||
- Focus on real problems only
|
||||
|
||||
### Step 9: Fix Issues
|
||||
|
||||
**For Each CRITICAL and HIGH Issue:**
|
||||
|
||||
1. **Understand the Problem:**
|
||||
- Read reviewer's description
|
||||
- Locate the code
|
||||
- Understand the security/logic flaw
|
||||
|
||||
2. **Implement Fix:**
|
||||
- Write the fix
|
||||
- Verify it addresses the issue
|
||||
- Don't introduce new problems
|
||||
|
||||
3. **Re-run Tests:**
|
||||
```bash
|
||||
npm run type-check # Must pass
|
||||
npm run lint # Must pass
|
||||
npm test # Must pass
|
||||
```
|
||||
|
||||
4. **Verify Fix:**
|
||||
- Check the specific issue is resolved
|
||||
- Ensure no regressions
|
||||
|
||||
---
|
||||
|
||||
## After Fixing Issues
|
||||
|
||||
### 1. Update Story File
|
||||
|
||||
**Mark completed tasks:**
|
||||
```bash
|
||||
# Update checkboxes in story file
|
||||
# Change [ ] to [x] for completed tasks
|
||||
```
|
||||
|
||||
### 2. Update Sprint Status
|
||||
|
||||
**Update sprint-status.yaml:**
|
||||
```yaml
|
||||
17-10-occupant-agreement-view: done # was: ready-for-dev
|
||||
```
|
||||
|
||||
### 3. Commit Changes
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "fix: {{story_key}} - address code review findings
|
||||
|
||||
Fixed issues:
|
||||
- #1: SQL injection in agreement route (CRITICAL)
|
||||
- #2: Missing authorization check (CRITICAL)
|
||||
- #3: N+1 query pattern (HIGH)
|
||||
- #4: Missing error handling (HIGH)
|
||||
- #5: Unhandled edge case (HIGH)
|
||||
|
||||
All tests passing, type check clean, lint clean."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Requirements
|
||||
|
||||
**Provide Fix Summary:**
|
||||
|
||||
```markdown
|
||||
## Issue Resolution Summary
|
||||
|
||||
### Fixed Issues:
|
||||
|
||||
**#1: SQL Injection (CRITICAL)**
|
||||
- Location: api/occupant/agreement/route.ts:45
|
||||
- Fix: Changed to parameterized query using Prisma
|
||||
- Verification: Security test added and passing
|
||||
|
||||
**#2: Missing Auth Check (CRITICAL)**
|
||||
- Location: api/admin/rentals/spaces/[id]/route.ts:23
|
||||
- Fix: Added organizationId validation
|
||||
- Verification: Cross-tenant test added and passing
|
||||
|
||||
**#3: N+1 Query (HIGH)**
|
||||
- Location: lib/rentals/expiration-alerts.ts:67
|
||||
- Fix: Batch-loaded admins with Map lookup
|
||||
- Verification: Performance test shows 10x improvement
|
||||
|
||||
[Continue for all CRITICAL + HIGH issues]
|
||||
|
||||
### Deferred Issues:
|
||||
|
||||
**MEDIUM (4 issues):** Deferred to follow-up story
|
||||
**LOW (2 issues):** Rejected as gold-plating
|
||||
|
||||
---
|
||||
|
||||
**Quality Checks:**
|
||||
- ✅ Type check: PASS (0 errors)
|
||||
- ✅ Linter: PASS (0 warnings)
|
||||
- ✅ Build: PASS
|
||||
- ✅ Tests: 48/48 passing (96% coverage)
|
||||
|
||||
**Git:**
|
||||
- ✅ Commit created: a1b2c3d
|
||||
- ✅ Story checkboxes updated
|
||||
- ✅ Sprint status updated
|
||||
|
||||
**Story Status:** COMPLETE
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Fix Priority Matrix
|
||||
|
||||
| Severity | Action | Reason |
|
||||
|----------|--------|--------|
|
||||
| CRITICAL | MUST FIX | Security / Data loss |
|
||||
| HIGH | MUST FIX | Production bugs |
|
||||
| MEDIUM | SHOULD FIX | Technical debt |
|
||||
| LOW | SKIP | Gold-plating |
|
||||
|
||||
---
|
||||
|
||||
## Hospital-Grade Standards
|
||||
|
||||
⚕️ **Fix It Right**
|
||||
|
||||
- Don't skip security fixes
|
||||
- Don't rush fixes (might break things)
|
||||
- Test after each fix
|
||||
- Verify the issue is actually resolved
|
||||
|
||||
---
|
||||
|
||||
**Remember:** You are the FIXER. Fix real problems, skip gold-plating, commit when done.
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
# Inspector Agent - Validation Phase
|
||||
|
||||
**Role:** Independent verification of Builder's work
|
||||
**Steps:** 5-6 (post-validation, quality-checks)
|
||||
**Trust Level:** MEDIUM (no conflict of interest)
|
||||
|
||||
---
|
||||
|
||||
## Your Mission
|
||||
|
||||
You are the **INSPECTOR** agent. Your job is to verify that the Builder actually did what they claimed.
|
||||
|
||||
**KEY PRINCIPLE: You have NO KNOWLEDGE of what the Builder did. You are starting fresh.**
|
||||
|
||||
**DO:**
|
||||
- Verify files actually exist
|
||||
- Run tests yourself (don't trust claims)
|
||||
- Run quality checks (type-check, lint, build)
|
||||
- Give honest PASS/FAIL verdict
|
||||
|
||||
**DO NOT:**
|
||||
- Take the Builder's word for anything
|
||||
- Skip verification steps
|
||||
- Assume tests pass without running them
|
||||
- Give PASS verdict if ANY check fails
|
||||
|
||||
---
|
||||
|
||||
## Steps to Execute
|
||||
|
||||
### Step 5: Post-Validation
|
||||
|
||||
**Verify Implementation Against Story:**
|
||||
|
||||
1. **Check Files Exist:**
|
||||
```bash
|
||||
# For each file mentioned in story tasks
|
||||
ls -la {{file_path}}
|
||||
# FAIL if file missing or empty
|
||||
```
|
||||
|
||||
2. **Verify File Contents:**
|
||||
- Open each file
|
||||
- Check it has actual code (not just TODO/stub)
|
||||
- Verify it matches story requirements
|
||||
|
||||
3. **Check Tests Exist:**
|
||||
```bash
|
||||
# Find test files
|
||||
find . -name "*.test.ts" -o -name "__tests__"
|
||||
# FAIL if no tests found for new code
|
||||
```
|
||||
|
||||
### Step 6: Quality Checks
|
||||
|
||||
**Run All Quality Gates:**
|
||||
|
||||
1. **Type Check:**
|
||||
```bash
|
||||
npm run type-check
|
||||
# FAIL if any errors
|
||||
```
|
||||
|
||||
2. **Linter:**
|
||||
```bash
|
||||
npm run lint
|
||||
# FAIL if any errors or warnings
|
||||
```
|
||||
|
||||
3. **Build:**
|
||||
```bash
|
||||
npm run build
|
||||
# FAIL if build fails
|
||||
```
|
||||
|
||||
4. **Tests:**
|
||||
```bash
|
||||
npm test -- {{story_specific_tests}}
|
||||
# FAIL if any tests fail
|
||||
# FAIL if tests are skipped
|
||||
# FAIL if coverage < 90%
|
||||
```
|
||||
|
||||
5. **Git Status:**
|
||||
```bash
|
||||
git status
|
||||
# Check for uncommitted files
|
||||
# List what was changed
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Requirements
|
||||
|
||||
**Provide Evidence-Based Verdict:**
|
||||
|
||||
### If PASS:
|
||||
```markdown
|
||||
✅ VALIDATION PASSED
|
||||
|
||||
Evidence:
|
||||
- Files verified: [list files checked]
|
||||
- Type check: PASS (0 errors)
|
||||
- Linter: PASS (0 warnings)
|
||||
- Build: PASS
|
||||
- Tests: 45/45 passing (95% coverage)
|
||||
- Git: 12 files modified, 3 new files
|
||||
|
||||
Ready for code review.
|
||||
```
|
||||
|
||||
### If FAIL:
|
||||
```markdown
|
||||
❌ VALIDATION FAILED
|
||||
|
||||
Failures:
|
||||
1. File missing: app/api/occupant/agreement/route.ts
|
||||
2. Type check: 3 errors in lib/api/auth.ts
|
||||
3. Tests: 2 failing (api/occupant tests)
|
||||
|
||||
Cannot proceed to code review until these are fixed.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
**Before giving PASS verdict, confirm:**
|
||||
|
||||
- [ ] All story files exist and have content
|
||||
- [ ] Type check returns 0 errors
|
||||
- [ ] Linter returns 0 errors/warnings
|
||||
- [ ] Build succeeds
|
||||
- [ ] Tests run and pass (not skipped)
|
||||
- [ ] Test coverage >= 90%
|
||||
- [ ] Git status is clean or has expected changes
|
||||
|
||||
**If ANY checkbox is unchecked → FAIL verdict**
|
||||
|
||||
---
|
||||
|
||||
## Hospital-Grade Standards
|
||||
|
||||
⚕️ **Be Thorough**
|
||||
|
||||
- Don't skip checks
|
||||
- Run tests yourself (don't trust claims)
|
||||
- Verify every file exists
|
||||
- Give specific evidence
|
||||
|
||||
---
|
||||
|
||||
**Remember:** You are the INSPECTOR. Your job is to find the truth, not rubber-stamp the Builder's work. If something is wrong, say so with evidence.
|
||||
|
|
@ -0,0 +1,190 @@
|
|||
# Reviewer Agent - Adversarial Code Review
|
||||
|
||||
**Role:** Find problems with the implementation
|
||||
**Steps:** 7 (code-review)
|
||||
**Trust Level:** HIGH (wants to find issues)
|
||||
|
||||
---
|
||||
|
||||
## Your Mission
|
||||
|
||||
You are the **ADVERSARIAL REVIEWER**. Your job is to find problems, not rubber-stamp code.
|
||||
|
||||
**MINDSET: Be critical. Look for flaws. Find issues.**
|
||||
|
||||
**DO:**
|
||||
- Approach code with skepticism
|
||||
- Look for security vulnerabilities
|
||||
- Find performance problems
|
||||
- Identify logic bugs
|
||||
- Check architecture compliance
|
||||
|
||||
**DO NOT:**
|
||||
- Rubber-stamp code as "looks good"
|
||||
- Skip areas because they seem simple
|
||||
- Assume the Builder did it right
|
||||
- Give generic feedback
|
||||
|
||||
---
|
||||
|
||||
## Review Focuses
|
||||
|
||||
### CRITICAL (Security/Data Loss):
|
||||
- SQL injection vulnerabilities
|
||||
- XSS vulnerabilities
|
||||
- Authentication bypasses
|
||||
- Authorization gaps
|
||||
- Hardcoded secrets
|
||||
- Data loss scenarios
|
||||
|
||||
### HIGH (Production Bugs):
|
||||
- Logic errors
|
||||
- Edge cases not handled
|
||||
- Off-by-one errors
|
||||
- Race conditions
|
||||
- N+1 query patterns
|
||||
|
||||
### MEDIUM (Technical Debt):
|
||||
- Missing error handling
|
||||
- Tight coupling
|
||||
- Pattern violations
|
||||
- Missing indexes
|
||||
- Inefficient algorithms
|
||||
|
||||
### LOW (Nice-to-Have):
|
||||
- Missing optimistic UI
|
||||
- Code duplication
|
||||
- Better naming
|
||||
- Additional tests
|
||||
|
||||
---
|
||||
|
||||
## Review Process
|
||||
|
||||
### 1. Security Review
|
||||
```bash
|
||||
# Check for common vulnerabilities
|
||||
grep -r "eval\|exec\|innerHTML" .
|
||||
grep -r "hardcoded.*password\|api.*key" .
|
||||
grep -r "SELECT.*\+\|INSERT.*\+" . # SQL injection
|
||||
```
|
||||
|
||||
### 2. Performance Review
|
||||
```bash
|
||||
# Look for N+1 patterns
|
||||
grep -A 5 "\.map\|\.forEach" . | grep "await\|prisma"
|
||||
# Check for missing indexes
|
||||
grep "@@index" prisma/schema.prisma
|
||||
```
|
||||
|
||||
### 3. Logic Review
|
||||
- Read each function
|
||||
- Trace execution paths
|
||||
- Check edge cases
|
||||
- Verify error handling
|
||||
|
||||
### 4. Architecture Review
|
||||
- Check pattern compliance
|
||||
- Verify separation of concerns
|
||||
- Check dependency directions
|
||||
|
||||
---
|
||||
|
||||
## Output Requirements
|
||||
|
||||
**Provide Specific, Actionable Issues:**
|
||||
|
||||
```markdown
|
||||
## Code Review Findings
|
||||
|
||||
### CRITICAL Issues (2):
|
||||
|
||||
**Issue #1: SQL Injection Vulnerability**
|
||||
- **Location:** `api/occupant/agreement/route.ts:45`
|
||||
- **Problem:** User input concatenated into query
|
||||
- **Code:**
|
||||
```typescript
|
||||
const query = `SELECT * FROM agreements WHERE id = '${params.id}'`
|
||||
```
|
||||
- **Fix:** Use parameterized queries
|
||||
- **Severity:** CRITICAL (data breach risk)
|
||||
|
||||
**Issue #2: Missing Authorization Check**
|
||||
- **Location:** `api/admin/rentals/spaces/[id]/route.ts:23`
|
||||
- **Problem:** No check that user owns the space
|
||||
- **Impact:** Cross-tenant data access
|
||||
- **Fix:** Add organizationId check
|
||||
- **Severity:** CRITICAL (security bypass)
|
||||
|
||||
### HIGH Issues (3):
|
||||
[List specific issues with code locations]
|
||||
|
||||
### MEDIUM Issues (4):
|
||||
[List specific issues with code locations]
|
||||
|
||||
### LOW Issues (2):
|
||||
[List specific issues with code locations]
|
||||
|
||||
---
|
||||
|
||||
**Summary:**
|
||||
- Total issues: 11
|
||||
- MUST FIX: 5 (CRITICAL + HIGH)
|
||||
- SHOULD FIX: 4 (MEDIUM)
|
||||
- NICE TO HAVE: 2 (LOW)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Issue Rating Guidelines
|
||||
|
||||
**CRITICAL:** Security vulnerability or data loss
|
||||
- SQL injection
|
||||
- Auth bypass
|
||||
- Hardcoded secrets
|
||||
- Data corruption risk
|
||||
|
||||
**HIGH:** Will cause production bugs
|
||||
- Logic errors
|
||||
- Unhandled edge cases
|
||||
- N+1 queries
|
||||
- Missing indexes
|
||||
|
||||
**MEDIUM:** Technical debt or maintainability
|
||||
- Missing error handling
|
||||
- Pattern violations
|
||||
- Tight coupling
|
||||
|
||||
**LOW:** Nice-to-have improvements
|
||||
- Optimistic UI
|
||||
- Better naming
|
||||
- Code duplication
|
||||
|
||||
---
|
||||
|
||||
## Review Checklist
|
||||
|
||||
Before completing review, check:
|
||||
|
||||
- [ ] Reviewed all new files
|
||||
- [ ] Checked for security vulnerabilities
|
||||
- [ ] Looked for performance problems
|
||||
- [ ] Verified error handling
|
||||
- [ ] Checked architecture compliance
|
||||
- [ ] Provided specific code locations for each issue
|
||||
- [ ] Rated each issue (CRITICAL/HIGH/MEDIUM/LOW)
|
||||
|
||||
---
|
||||
|
||||
## Hospital-Grade Standards
|
||||
|
||||
⚕️ **Be Thorough and Critical**
|
||||
|
||||
- Don't let things slide
|
||||
- Find real problems
|
||||
- Be specific (not generic)
|
||||
- Assume code has issues (it usually does)
|
||||
|
||||
---
|
||||
|
||||
**Remember:** You are the ADVERSARIAL REVIEWER. Your success is measured by finding legitimate issues. Don't be nice - be thorough.
|
||||
|
|
@ -1,406 +0,0 @@
|
|||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize pipeline, load story (auto-create if needed), detect development mode'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
create_story_workflow: '{project-root}/_bmad/bmm/workflows/4-implementation/create-story-with-gap-analysis'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-01-init.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-pre-gap-analysis.md'
|
||||
|
||||
# Role
|
||||
role: null # No agent role yet
|
||||
---
|
||||
|
||||
# Step 1: Initialize Pipeline
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Initialize the super-dev-pipeline:
|
||||
1. Load story file (must exist!)
|
||||
2. Cache project context
|
||||
3. Detect development mode (greenfield vs brownfield)
|
||||
4. Initialize state tracking
|
||||
5. Display execution plan
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
### Initialization Principles
|
||||
|
||||
- **AUTO-CREATE IF NEEDED** - If story is missing or incomplete, auto-invoke /create-story-with-gap-analysis (NEW v1.4.0)
|
||||
- **READ COMPLETELY** - Load all context before proceeding
|
||||
- **DETECT MODE** - Determine if greenfield or brownfield
|
||||
- **NO ASSUMPTIONS** - Verify all files and paths
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Detect Execution Mode
|
||||
|
||||
Check if running in batch or interactive mode:
|
||||
- Batch mode: Invoked from batch-super-dev
|
||||
- Interactive mode: User-initiated
|
||||
|
||||
Set `{mode}` variable.
|
||||
|
||||
### 2. Resolve Story File Path
|
||||
|
||||
**From input parameters:**
|
||||
- `story_id`: e.g., "1-4"
|
||||
- `story_file`: Full path to story file
|
||||
|
||||
**If story_file not provided:**
|
||||
```
|
||||
story_file = {sprint_artifacts}/story-{story_id}.md
|
||||
```
|
||||
|
||||
### 3. Verify Story Exists (Auto-Create if Missing - NEW v1.4.0)
|
||||
|
||||
```bash
|
||||
# Check if story file exists
|
||||
test -f "{story_file}"
|
||||
```
|
||||
|
||||
**If story does NOT exist:**
|
||||
```
|
||||
⚠️ Story file not found at {story_file}
|
||||
|
||||
🔄 AUTO-CREATING: Invoking /create-story-with-gap-analysis...
|
||||
```
|
||||
|
||||
<invoke-workflow path="{create_story_workflow}/workflow.yaml">
|
||||
<input name="story_id">{story_id}</input>
|
||||
<input name="epic_num">{epic_num}</input>
|
||||
<input name="story_num">{story_num}</input>
|
||||
</invoke-workflow>
|
||||
|
||||
After workflow completes, verify story was created:
|
||||
```bash
|
||||
test -f "{story_file}" && echo "✅ Story created successfully" || echo "❌ Story creation failed - HALT"
|
||||
```
|
||||
|
||||
**If story was created, set flag for smart gap analysis:**
|
||||
```yaml
|
||||
# Set state flag to skip redundant gap analysis in step 2
|
||||
story_just_created: true
|
||||
gap_analysis_completed: true # Already done in create-story-with-gap-analysis
|
||||
```
|
||||
|
||||
**If story exists:**
|
||||
```
|
||||
✅ Story file found: {story_file}
|
||||
```
|
||||
|
||||
### 4. Load Story File
|
||||
|
||||
Read story file and extract:
|
||||
- Story title
|
||||
- Epic number
|
||||
- Story number
|
||||
- Acceptance criteria
|
||||
- Current tasks (checked and unchecked)
|
||||
- File List section (if exists)
|
||||
|
||||
Count:
|
||||
- Total tasks: `{total_task_count}`
|
||||
- Unchecked tasks: `{unchecked_task_count}`
|
||||
- Checked tasks: `{checked_task_count}`
|
||||
|
||||
### 4.5 Pre-Flight Check & Auto-Regenerate (UPDATED v1.4.0)
|
||||
|
||||
**Check story quality and auto-regenerate if insufficient:**
|
||||
|
||||
```
|
||||
If total_task_count == 0:
|
||||
Display:
|
||||
⚠️ Story has no tasks - needs gap analysis
|
||||
|
||||
🔄 AUTO-REGENERATING: Invoking /create-story-with-gap-analysis...
|
||||
```
|
||||
<invoke-workflow path="{create_story_workflow}/workflow.yaml">
|
||||
<input name="story_id">{story_id}</input>
|
||||
<input name="story_file">{story_file}</input>
|
||||
<input name="regenerate">true</input>
|
||||
</invoke-workflow>
|
||||
|
||||
# Story created - skip redundant gap analysis
|
||||
story_just_created: true
|
||||
gap_analysis_completed: true
|
||||
|
||||
Then re-load story and continue.
|
||||
|
||||
```
|
||||
If unchecked_task_count == 0:
|
||||
Display:
|
||||
✅ EARLY BAILOUT: Story Already Complete
|
||||
|
||||
All {checked_task_count} tasks are already marked complete.
|
||||
- No implementation work required
|
||||
- Story may need status update to "review" or "done"
|
||||
|
||||
{if batch mode: Continue to next story}
|
||||
{if interactive mode: HALT - Story complete}
|
||||
|
||||
If story file missing required sections (Tasks, Acceptance Criteria):
|
||||
Display:
|
||||
⚠️ Story missing required sections: {missing_sections}
|
||||
|
||||
🔄 AUTO-REGENERATING: Invoking /create-story-with-gap-analysis...
|
||||
```
|
||||
<invoke-workflow path="{create_story_workflow}/workflow.yaml">
|
||||
<input name="story_id">{story_id}</input>
|
||||
<input name="story_file">{story_file}</input>
|
||||
<input name="regenerate">true</input>
|
||||
</invoke-workflow>
|
||||
|
||||
# Story regenerated - mark flags to skip duplicate gap analysis
|
||||
story_just_created: true
|
||||
gap_analysis_completed: true
|
||||
|
||||
Then re-load story and continue.
|
||||
|
||||
**If all checks pass:**
|
||||
```
|
||||
✅ Pre-flight checks passed
|
||||
- Story valid: {total_task_count} tasks
|
||||
- Work remaining: {unchecked_task_count} unchecked
|
||||
- Ready for implementation
|
||||
```
|
||||
|
||||
## 5. Load Project Context
|
||||
|
||||
Read `**/project-context.md`:
|
||||
- Tech stack
|
||||
- Coding patterns
|
||||
- Database conventions
|
||||
- Testing requirements
|
||||
|
||||
Cache in memory for use across steps.
|
||||
|
||||
### 6. Apply Complexity Routing (NEW v1.2.0)
|
||||
|
||||
**Check complexity_level parameter:**
|
||||
- `micro`: Lightweight path - skip pre-gap analysis (step 2) and code review (step 5)
|
||||
- `standard`: Full pipeline - all steps
|
||||
- `complex`: Full pipeline with warnings
|
||||
|
||||
**Determine skip_steps based on complexity:**
|
||||
```
|
||||
If complexity_level == "micro":
|
||||
skip_steps = [2, 5]
|
||||
pipeline_mode = "lightweight"
|
||||
|
||||
Display:
|
||||
🚀 MICRO COMPLEXITY DETECTED
|
||||
|
||||
Lightweight path enabled:
|
||||
- ⏭️ Skipping Pre-Gap Analysis (low risk)
|
||||
- ⏭️ Skipping Code Review (simple changes)
|
||||
- Estimated token savings: 50-70%
|
||||
|
||||
If complexity_level == "complex":
|
||||
skip_steps = []
|
||||
pipeline_mode = "enhanced"
|
||||
|
||||
Display:
|
||||
🔒 COMPLEX STORY DETECTED
|
||||
|
||||
Enhanced validation enabled:
|
||||
- Full pipeline with all quality gates
|
||||
- Consider splitting if story fails
|
||||
|
||||
⚠️ Warning: This story has high-risk elements.
|
||||
Proceeding with extra attention.
|
||||
|
||||
If complexity_level == "standard":
|
||||
skip_steps = []
|
||||
pipeline_mode = "standard"
|
||||
```
|
||||
|
||||
Store `skip_steps` and `pipeline_mode` in state file.
|
||||
|
||||
### 7. Detect Development Mode
|
||||
|
||||
**Check File List section in story:**
|
||||
|
||||
```typescript
|
||||
interface DetectionResult {
|
||||
mode: "greenfield" | "brownfield" | "hybrid";
|
||||
reasoning: string;
|
||||
existing_files: string[];
|
||||
new_files: string[];
|
||||
}
|
||||
```
|
||||
|
||||
**Detection logic:**
|
||||
|
||||
```bash
|
||||
# Extract files from File List section
|
||||
files_in_story=()
|
||||
|
||||
# For each file, check if it exists
|
||||
existing_count=0
|
||||
new_count=0
|
||||
|
||||
for file in files_in_story; do
|
||||
if test -f "$file"; then
|
||||
existing_count++
|
||||
existing_files+=("$file")
|
||||
else
|
||||
new_count++
|
||||
new_files+=("$file")
|
||||
fi
|
||||
done
|
||||
```
|
||||
|
||||
**Mode determination:**
|
||||
- `existing_count == 0` → **greenfield** (all new files)
|
||||
- `new_count == 0` → **brownfield** (all existing files)
|
||||
- Both > 0 → **hybrid** (mix of new and existing)
|
||||
|
||||
### 8. Display Initialization Summary
|
||||
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
🚀 SUPER-DEV PIPELINE - Disciplined Execution
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Story: {story_title}
|
||||
File: {story_file}
|
||||
Mode: {mode} (interactive|batch)
|
||||
Complexity: {complexity_level} → {pipeline_mode} path
|
||||
|
||||
Development Type: {greenfield|brownfield|hybrid}
|
||||
- Existing files: {existing_count}
|
||||
- New files: {new_count}
|
||||
|
||||
Tasks:
|
||||
- Total: {total_task_count}
|
||||
- Completed: {checked_task_count} ✅
|
||||
- Remaining: {unchecked_task_count} ⏳
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Pipeline Steps:
|
||||
1. ✅ Initialize (current)
|
||||
2. {⏭️ SKIP|⏳} Pre-Gap Analysis - Validate tasks {if micro: "(skipped - low risk)"}
|
||||
3. ⏳ Implement - {TDD|Refactor|Hybrid}
|
||||
4. ⏳ Post-Validation - Verify completion
|
||||
5. {⏭️ SKIP|⏳} Code Review - Find issues {if micro: "(skipped - simple changes)"}
|
||||
6. ⏳ Complete - Commit + push
|
||||
7. ⏳ Summary - Audit trail
|
||||
|
||||
{if pipeline_mode == "lightweight":
|
||||
🚀 LIGHTWEIGHT PATH: Steps 2 and 5 will be skipped (50-70% token savings)
|
||||
}
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
⚠️ ANTI-VIBE-CODING ENFORCEMENT ACTIVE
|
||||
|
||||
This workflow uses step-file architecture to ensure:
|
||||
- ✅ No skipping steps (except complexity-based routing)
|
||||
- ✅ No optimizing sequences
|
||||
- ✅ No looking ahead
|
||||
- ✅ No vibe coding even at 200K tokens
|
||||
|
||||
You will follow each step file PRECISELY.
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
### 9. Initialize State File
|
||||
|
||||
Create state file at `{sprint_artifacts}/super-dev-state-{story_id}.yaml`:
|
||||
|
||||
```yaml
|
||||
---
|
||||
story_id: "{story_id}"
|
||||
story_file: "{story_file}"
|
||||
mode: "{mode}"
|
||||
development_type: "{greenfield|brownfield|hybrid}"
|
||||
|
||||
# Complexity routing (NEW v1.2.0)
|
||||
complexity:
|
||||
level: "{complexity_level}" # micro | standard | complex
|
||||
pipeline_mode: "{pipeline_mode}" # lightweight | standard | enhanced
|
||||
skip_steps: {skip_steps} # e.g., [2, 5] for micro
|
||||
|
||||
stepsCompleted: [1]
|
||||
lastStep: 1
|
||||
currentStep: 2 # Or 3 if step 2 is skipped
|
||||
status: "in_progress"
|
||||
|
||||
started_at: "{timestamp}"
|
||||
updated_at: "{timestamp}"
|
||||
|
||||
cached_context:
|
||||
story_loaded: true
|
||||
project_context_loaded: true
|
||||
|
||||
development_analysis:
|
||||
existing_files: {existing_count}
|
||||
new_files: {new_count}
|
||||
total_tasks: {total_task_count}
|
||||
unchecked_tasks: {unchecked_task_count}
|
||||
|
||||
steps:
|
||||
step-01-init:
|
||||
status: completed
|
||||
completed_at: "{timestamp}"
|
||||
step-02-pre-gap-analysis:
|
||||
status: {pending|skipped} # skipped if complexity == micro
|
||||
step-03-implement:
|
||||
status: pending
|
||||
step-04-post-validation:
|
||||
status: pending
|
||||
step-05-code-review:
|
||||
status: {pending|skipped} # skipped if complexity == micro
|
||||
step-06-complete:
|
||||
status: pending
|
||||
step-07-summary:
|
||||
status: pending
|
||||
```
|
||||
|
||||
### 10. Display Menu (Interactive) or Proceed (Batch)
|
||||
|
||||
**Interactive Mode Menu:**
|
||||
```
|
||||
[C] Continue to {next step name}
|
||||
[H] Halt pipeline
|
||||
```
|
||||
|
||||
**Batch Mode:** Auto-continue to next step
|
||||
|
||||
## CRITICAL STEP COMPLETION
|
||||
|
||||
**Determine next step based on complexity routing:**
|
||||
|
||||
```
|
||||
If 2 in skip_steps (micro complexity):
|
||||
nextStepFile = '{workflow_path}/steps/step-03-implement.md'
|
||||
Display: "⏭️ Skipping Pre-Gap Analysis (micro complexity) → Proceeding to Implementation"
|
||||
Else:
|
||||
nextStepFile = '{workflow_path}/steps/step-02-pre-gap-analysis.md'
|
||||
```
|
||||
|
||||
**ONLY WHEN** initialization is complete,
|
||||
load and execute `{nextStepFile}`.
|
||||
|
||||
---
|
||||
|
||||
## SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS
|
||||
- Story file loaded successfully
|
||||
- Development mode detected accurately
|
||||
- State file initialized
|
||||
- Context cached in memory
|
||||
- Ready for pre-gap analysis
|
||||
|
||||
### ❌ FAILURE
|
||||
- Story file not found
|
||||
- Invalid story file format
|
||||
- Missing project context
|
||||
- State file creation failed
|
||||
|
|
@ -1,653 +0,0 @@
|
|||
---
|
||||
name: 'step-02-smart-gap-analysis'
|
||||
description: 'Smart gap analysis - skip if story just created with gap analysis in step 1'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-02-smart-gap-analysis.md'
|
||||
stateFile: '{state_file}'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-write-tests.md'
|
||||
|
||||
# Role Switch
|
||||
role: dev
|
||||
agentFile: '{project-root}/_bmad/bmm/agents/dev.md'
|
||||
---
|
||||
|
||||
# Step 2: Smart Gap Analysis
|
||||
|
||||
## ROLE SWITCH
|
||||
|
||||
**Switching to DEV (Developer) perspective.**
|
||||
|
||||
You are now analyzing the story tasks against codebase reality.
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate all story tasks against the actual codebase:
|
||||
1. Scan codebase for existing implementations
|
||||
2. Identify which tasks are truly needed vs already done
|
||||
3. Refine vague tasks to be specific and actionable
|
||||
4. Add missing tasks that were overlooked
|
||||
5. Uncheck any tasks that claim completion incorrectly
|
||||
6. Ensure tasks align with existing code patterns
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
### Gap Analysis Principles
|
||||
|
||||
- **TRUST NOTHING** - Verify every task against codebase
|
||||
- **SCAN THOROUGHLY** - Use Glob, Grep, Read to understand existing code
|
||||
- **BE SPECIFIC** - Vague tasks like "Add feature X" need breakdown
|
||||
- **ADD MISSING** - If something is needed but not tasked, add it
|
||||
- **BROWNFIELD AWARE** - Check for existing implementations
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 0. Smart Gap Analysis Check (NEW v1.5.0)
|
||||
|
||||
**Check if gap analysis already performed in step 1:**
|
||||
|
||||
```yaml
|
||||
# Read state from step 1
|
||||
Read {stateFile}
|
||||
|
||||
If story_just_created == true:
|
||||
Display:
|
||||
✅ GAP ANALYSIS SKIPPED
|
||||
|
||||
Story was just created via /create-story-with-gap-analysis in step 1.
|
||||
Gap analysis already performed as part of story creation.
|
||||
|
||||
Skipping redundant gap analysis.
|
||||
Proceeding directly to test writing (step 3).
|
||||
|
||||
Exit step 2
|
||||
```
|
||||
|
||||
**If story was NOT just created, proceed with gap analysis below.**
|
||||
|
||||
### 1. Load Story Tasks
|
||||
|
||||
Read story file and extract all tasks (checked and unchecked):
|
||||
|
||||
```regex
|
||||
- \[ \] (.+) # Unchecked
|
||||
- \[x\] (.+) # Checked
|
||||
```
|
||||
|
||||
Build list of all tasks to analyze.
|
||||
|
||||
### 2. Scan Existing Codebase
|
||||
|
||||
**For development_type = "brownfield" or "hybrid":**
|
||||
|
||||
Scan all files mentioned in File List:
|
||||
|
||||
```bash
|
||||
# For each file in File List
|
||||
for file in {file_list}; do
|
||||
if test -f "$file"; then
|
||||
# Read file to understand current implementation
|
||||
read "$file"
|
||||
|
||||
# Check what's already implemented
|
||||
grep -E "function|class|interface|export" "$file"
|
||||
fi
|
||||
done
|
||||
```
|
||||
|
||||
Document existing implementations.
|
||||
|
||||
### 3. Analyze Each Task
|
||||
|
||||
For EACH task in story:
|
||||
|
||||
**A. Determine Task Type:**
|
||||
- Component creation
|
||||
- Function/method addition
|
||||
- Database migration
|
||||
- API endpoint
|
||||
- UI element
|
||||
- Test creation
|
||||
- Refactoring
|
||||
- Bug fix
|
||||
|
||||
**B. Check Against Codebase:**
|
||||
|
||||
```typescript
|
||||
interface TaskAnalysis {
|
||||
task: string;
|
||||
type: string;
|
||||
status: "needed" | "partially_done" | "already_done" | "unclear";
|
||||
reasoning: string;
|
||||
existing_code?: string;
|
||||
refinement?: string;
|
||||
}
|
||||
```
|
||||
|
||||
**For each task, ask:**
|
||||
1. Does related code already exist?
|
||||
2. If yes, what needs to change?
|
||||
3. If no, what needs to be created?
|
||||
4. Is the task specific enough to implement?
|
||||
|
||||
**C. Categorize Task:**
|
||||
|
||||
**NEEDED** - Task is clear and required:
|
||||
```yaml
|
||||
- task: "Add deleteUser server action"
|
||||
status: needed
|
||||
reasoning: "No deleteUser function found in codebase"
|
||||
action: "Implement as specified"
|
||||
```
|
||||
|
||||
**PARTIALLY_DONE** - Some work exists, needs completion:
|
||||
```yaml
|
||||
- task: "Add error handling to createUser"
|
||||
status: partially_done
|
||||
reasoning: "createUser exists but only handles success case"
|
||||
existing_code: "src/actions/createUser.ts"
|
||||
action: "Add error handling for DB failures, validation errors"
|
||||
```
|
||||
|
||||
**ALREADY_DONE** - Task is complete:
|
||||
```yaml
|
||||
- task: "Create users table"
|
||||
status: already_done
|
||||
reasoning: "users table exists with correct schema"
|
||||
existing_code: "migrations/20250101_create_users.sql"
|
||||
action: "Check this task, no work needed"
|
||||
```
|
||||
|
||||
**UNCLEAR** - Task is too vague:
|
||||
```yaml
|
||||
- task: "Improve user flow"
|
||||
status: unclear
|
||||
reasoning: "Ambiguous - what specifically needs improvement?"
|
||||
action: "Refine to specific sub-tasks"
|
||||
refinement:
|
||||
- "Add loading states to user forms"
|
||||
- "Add error toast on user creation failure"
|
||||
- "Add success confirmation modal"
|
||||
```
|
||||
|
||||
### 4. Generate Gap Analysis Report
|
||||
|
||||
Create report showing findings:
|
||||
|
||||
```markdown
|
||||
## Pre-Gap Analysis Results
|
||||
|
||||
**Development Mode:** {greenfield|brownfield|hybrid}
|
||||
|
||||
**Task Analysis:**
|
||||
|
||||
### ✅ Tasks Ready for Implementation ({needed_count})
|
||||
1. {task_1} - {reasoning}
|
||||
2. {task_2} - {reasoning}
|
||||
|
||||
### ⚠️ Tasks Partially Implemented ({partial_count})
|
||||
1. {task_1}
|
||||
- Current: {existing_implementation}
|
||||
- Needed: {what_to_add}
|
||||
- File: {file_path}
|
||||
|
||||
### ✓ Tasks Already Complete ({done_count})
|
||||
1. {task_1}
|
||||
- Evidence: {existing_code_location}
|
||||
- Action: Will check this task
|
||||
|
||||
### 🔍 Tasks Need Refinement ({unclear_count})
|
||||
1. {original_vague_task}
|
||||
- Issue: {why_unclear}
|
||||
- Refined to:
|
||||
- [ ] {specific_sub_task_1}
|
||||
- [ ] {specific_sub_task_2}
|
||||
|
||||
### ➕ Missing Tasks Discovered ({missing_count})
|
||||
1. {missing_task_1} - {why_needed}
|
||||
2. {missing_task_2} - {why_needed}
|
||||
|
||||
**Summary:**
|
||||
- Ready to implement: {needed_count}
|
||||
- Need completion: {partial_count}
|
||||
- Already done: {done_count}
|
||||
- Need refinement: {unclear_count}
|
||||
- Missing tasks: {missing_count}
|
||||
|
||||
**Total work remaining:** {work_count} tasks
|
||||
```
|
||||
|
||||
### 5. Update Story File
|
||||
|
||||
**A. Check already-done tasks:**
|
||||
```markdown
|
||||
- [x] Create users table (verified in gap analysis)
|
||||
```
|
||||
|
||||
**B. Refine unclear tasks:**
|
||||
```markdown
|
||||
~~- [ ] Improve user flow~~ (too vague)
|
||||
|
||||
Refined to:
|
||||
- [ ] Add loading states to user forms
|
||||
- [ ] Add error toast on user creation failure
|
||||
- [ ] Add success confirmation modal
|
||||
```
|
||||
|
||||
**C. Add missing tasks:**
|
||||
```markdown
|
||||
## Tasks (Updated after Pre-Gap Analysis)
|
||||
|
||||
{existing_tasks}
|
||||
|
||||
### Added from Gap Analysis
|
||||
- [ ] {missing_task_1}
|
||||
- [ ] {missing_task_2}
|
||||
```
|
||||
|
||||
**D. Add Gap Analysis section:**
|
||||
```markdown
|
||||
## Gap Analysis
|
||||
|
||||
### Pre-Development Analysis
|
||||
- **Date:** {timestamp}
|
||||
- **Development Type:** {greenfield|brownfield|hybrid}
|
||||
- **Existing Files:** {count}
|
||||
- **New Files:** {count}
|
||||
|
||||
**Findings:**
|
||||
- Tasks ready: {needed_count}
|
||||
- Tasks partially done: {partial_count}
|
||||
- Tasks already complete: {done_count}
|
||||
- Tasks refined: {unclear_count}
|
||||
- Tasks added: {missing_count}
|
||||
|
||||
**Codebase Scan:**
|
||||
{list existing implementations found}
|
||||
|
||||
**Status:** Ready for implementation
|
||||
```
|
||||
|
||||
### 6. Pattern Detection for Smart Batching (NEW!)
|
||||
|
||||
After validating tasks, detect repeating patterns that can be batched:
|
||||
|
||||
```typescript
|
||||
interface TaskPattern {
|
||||
pattern_name: string;
|
||||
pattern_type: "package_install" | "module_registration" | "code_deletion" | "import_update" | "custom";
|
||||
tasks: Task[];
|
||||
batchable: boolean;
|
||||
risk_level: "low" | "medium" | "high";
|
||||
validation_strategy: string;
|
||||
estimated_time_individual: number; // minutes if done one-by-one
|
||||
estimated_time_batched: number; // minutes if batched
|
||||
}
|
||||
```
|
||||
|
||||
**Common Batchable Patterns:**
|
||||
|
||||
**Pattern: Package Installation**
|
||||
```
|
||||
Tasks like:
|
||||
- [ ] Add @company/shared-utils to package.json
|
||||
- [ ] Add @company/validation to package.json
|
||||
- [ ] Add @company/http-client to package.json
|
||||
|
||||
Batchable: YES
|
||||
Risk: LOW
|
||||
Validation: npm install && npm run build
|
||||
Time: 5 min batch vs 15 min individual (3x faster!)
|
||||
```
|
||||
|
||||
**Pattern: Module Registration**
|
||||
```
|
||||
Tasks like:
|
||||
- [ ] Import SharedUtilsModule in app.module.ts
|
||||
- [ ] Import ValidationModule in app.module.ts
|
||||
- [ ] Import HttpClientModule in app.module.ts
|
||||
|
||||
Batchable: YES
|
||||
Risk: LOW
|
||||
Validation: TypeScript compile
|
||||
Time: 10 min batch vs 20 min individual (2x faster!)
|
||||
```
|
||||
|
||||
**Pattern: Code Deletion**
|
||||
```
|
||||
Tasks like:
|
||||
- [ ] Delete src/old-audit.service.ts
|
||||
- [ ] Remove OldAuditModule from imports
|
||||
- [ ] Delete src/old-cache.service.ts
|
||||
|
||||
Batchable: YES
|
||||
Risk: LOW (tests will catch issues)
|
||||
Validation: Build + test suite
|
||||
Time: 15 min batch vs 30 min individual (2x faster!)
|
||||
```
|
||||
|
||||
**Pattern: Business Logic (NOT batchable)**
|
||||
```
|
||||
Tasks like:
|
||||
- [ ] Add circuit breaker fallback for WIS API
|
||||
- [ ] Implement 3-tier caching for user data
|
||||
- [ ] Add audit logging for theme updates
|
||||
|
||||
Batchable: NO
|
||||
Risk: MEDIUM-HIGH (logic varies per case)
|
||||
Validation: Per-task testing
|
||||
Time: Execute individually with full rigor
|
||||
```
|
||||
|
||||
**Detection Algorithm:**
|
||||
|
||||
```bash
|
||||
# For each task, check if it matches a known pattern
|
||||
for task in tasks; do
|
||||
case "$task" in
|
||||
*"Add @"*"to package.json"*)
|
||||
pattern="package_install"
|
||||
batchable=true
|
||||
;;
|
||||
*"Import"*"Module in app.module"*)
|
||||
pattern="module_registration"
|
||||
batchable=true
|
||||
;;
|
||||
*"Delete"*|*"Remove"*)
|
||||
pattern="code_deletion"
|
||||
batchable=true
|
||||
;;
|
||||
*"circuit breaker"*|*"fallback"*|*"caching for"*)
|
||||
pattern="business_logic"
|
||||
batchable=false
|
||||
;;
|
||||
*)
|
||||
pattern="custom"
|
||||
batchable=false # Default to safe
|
||||
;;
|
||||
esac
|
||||
done
|
||||
```
|
||||
|
||||
**Generate Batching Plan:**
|
||||
|
||||
```markdown
|
||||
## Smart Batching Analysis
|
||||
|
||||
**Detected Patterns:**
|
||||
|
||||
### ✅ Batchable Patterns (Execute Together)
|
||||
1. **Package Installation** (5 tasks)
|
||||
- Add @dealer/audit-logging
|
||||
- Add @dealer/http-client
|
||||
- Add @dealer/caching
|
||||
- Add @dealer/circuit-breaker
|
||||
- Run pnpm install
|
||||
|
||||
Validation: Build succeeds
|
||||
Time: 5 min (vs 10 min individual)
|
||||
Risk: LOW
|
||||
|
||||
2. **Module Registration** (5 tasks)
|
||||
- Import 5 modules
|
||||
- Register in app.module
|
||||
- Configure each
|
||||
|
||||
Validation: TypeScript compile
|
||||
Time: 10 min (vs 20 min individual)
|
||||
Risk: LOW
|
||||
|
||||
### ⚠️ Individual Execution Required
|
||||
3. **Circuit Breaker Logic** (3 tasks)
|
||||
- WIS API fallback strategy
|
||||
- i18n client fallback
|
||||
- Cache fallback
|
||||
|
||||
Reason: Fallback logic varies per API
|
||||
Time: 60 min (cannot batch)
|
||||
Risk: MEDIUM
|
||||
|
||||
**Total Estimated Time:**
|
||||
- With smart batching: ~2.5 hours
|
||||
- Without batching: ~5.5 hours
|
||||
- Savings: 3 hours (54% faster!)
|
||||
|
||||
**Safety:**
|
||||
- Batchable tasks: Validated as a group
|
||||
- Individual tasks: Full rigor maintained
|
||||
- No vibe coding: All validation gates enforced
|
||||
```
|
||||
|
||||
### 7. Handle Approval (Interactive Mode Only)
|
||||
|
||||
**Interactive Mode:**
|
||||
|
||||
Display gap analysis report with conditional batching menu.
|
||||
|
||||
**CRITICAL DECISION LOGIC:**
|
||||
- If `batchable_count > 0 AND time_saved > 0`: Show batching options
|
||||
- If `batchable_count = 0 OR time_saved = 0`: Skip batching options (no benefit)
|
||||
|
||||
**When Batching Has Benefit (time_saved > 0):**
|
||||
|
||||
```
|
||||
Gap Analysis Complete + Smart Batching Plan
|
||||
|
||||
Task Analysis:
|
||||
- {done_count} tasks already complete (will check)
|
||||
- {unclear_count} tasks refined to {refined_count} specific tasks
|
||||
- {missing_count} new tasks added
|
||||
- {needed_count} tasks ready for implementation
|
||||
|
||||
Smart Batching Detected:
|
||||
- {batchable_count} tasks can be batched into {batch_count} pattern groups
|
||||
- {individual_count} tasks require individual execution
|
||||
- Estimated time savings: {time_saved} hours
|
||||
|
||||
Total work: {work_count} tasks
|
||||
Estimated time: {estimated_hours} hours (with batching)
|
||||
|
||||
[A] Accept changes and batching plan
|
||||
[B] Accept but disable batching (slower, safer)
|
||||
[E] Edit tasks manually
|
||||
[H] Halt pipeline
|
||||
```
|
||||
|
||||
**When Batching Has NO Benefit (time_saved = 0):**
|
||||
|
||||
```
|
||||
Gap Analysis Complete
|
||||
|
||||
Task Analysis:
|
||||
- {done_count} tasks already complete (will check)
|
||||
- {unclear_count} tasks refined to {refined_count} specific tasks
|
||||
- {missing_count} new tasks added
|
||||
- {needed_count} tasks ready for implementation
|
||||
|
||||
Smart Batching Analysis:
|
||||
- Batchable patterns detected: 0
|
||||
- Tasks requiring individual execution: {work_count}
|
||||
- Estimated time savings: none (tasks require individual attention)
|
||||
|
||||
Total work: {work_count} tasks
|
||||
Estimated time: {estimated_hours} hours
|
||||
|
||||
[A] Accept changes
|
||||
[E] Edit tasks manually
|
||||
[H] Halt pipeline
|
||||
```
|
||||
|
||||
**Why Skip Batching Option When Benefit = 0:**
|
||||
- Reduces decision fatigue
|
||||
- Prevents pointless "batch vs no-batch" choice when outcome is identical
|
||||
- Cleaner UX when batching isn't applicable
|
||||
|
||||
**Batch Mode:** Auto-accept changes (batching plan applied only if benefit > 0)
|
||||
|
||||
### 8. Update Story File with Batching Plan (Conditional)
|
||||
|
||||
**ONLY add batching plan if `time_saved > 0`.**
|
||||
|
||||
If batching has benefit (time_saved > 0), add batching plan to story file:
|
||||
|
||||
```markdown
|
||||
## Smart Batching Plan
|
||||
|
||||
**Pattern Groups Detected:**
|
||||
|
||||
### Batch 1: Package Installation (5 tasks, 5 min)
|
||||
- [ ] Add @company/shared-utils to package.json
|
||||
- [ ] Add @company/validation to package.json
|
||||
- [ ] Add @company/http-client to package.json
|
||||
- [ ] Add @company/database-client to package.json
|
||||
- [ ] Run npm install
|
||||
|
||||
**Validation:** Build succeeds
|
||||
|
||||
### Batch 2: Module Registration (5 tasks, 10 min)
|
||||
{list tasks}
|
||||
|
||||
### Individual Tasks: Business Logic (15 tasks, 90 min)
|
||||
{list tasks that can't be batched}
|
||||
|
||||
**Time Estimate:**
|
||||
- With batching: {batched_time} hours
|
||||
- Without batching: {individual_time} hours
|
||||
- Savings: {savings} hours
|
||||
```
|
||||
|
||||
If batching has NO benefit (time_saved = 0), **skip this section entirely** and just add gap analysis results.
|
||||
|
||||
### 9. Update Pipeline State
|
||||
|
||||
Update state file:
|
||||
- Add `2` to `stepsCompleted`
|
||||
- Set `lastStep: 2`
|
||||
- Set `steps.step-02-pre-gap-analysis.status: completed`
|
||||
- Record gap analysis results:
|
||||
```yaml
|
||||
gap_analysis:
|
||||
development_type: "{mode}"
|
||||
tasks_ready: {count}
|
||||
tasks_partial: {count}
|
||||
tasks_done: {count}
|
||||
tasks_refined: {count}
|
||||
tasks_added: {count}
|
||||
|
||||
smart_batching:
|
||||
enabled: {true if time_saved > 0, false otherwise}
|
||||
patterns_detected: {count}
|
||||
batchable_tasks: {count}
|
||||
individual_tasks: {count}
|
||||
estimated_time_with_batching: {hours}
|
||||
estimated_time_without_batching: {hours}
|
||||
estimated_savings: {hours}
|
||||
```
|
||||
|
||||
**Note:** `smart_batching.enabled` is set to `false` when batching has no benefit, preventing unnecessary batching plan generation.
|
||||
|
||||
### 10. Present Summary (Conditional Format)
|
||||
|
||||
**When Batching Has Benefit (time_saved > 0):**
|
||||
|
||||
```
|
||||
Pre-Gap Analysis Complete + Smart Batching Plan
|
||||
|
||||
Development Type: {greenfield|brownfield|hybrid}
|
||||
Work Remaining: {work_count} tasks
|
||||
|
||||
Codebase Status:
|
||||
- Existing implementations reviewed: {existing_count}
|
||||
- New implementations needed: {new_count}
|
||||
|
||||
Smart Batching Analysis:
|
||||
- Batchable patterns detected: {batch_count}
|
||||
- Tasks that can be batched: {batchable_count} ({percent}%)
|
||||
- Tasks requiring individual execution: {individual_count}
|
||||
|
||||
Time Estimate:
|
||||
- With smart batching: {batched_time} hours ⚡
|
||||
- Without batching: {individual_time} hours
|
||||
- Time savings: {savings} hours ({savings_percent}% faster!)
|
||||
|
||||
Ready for Implementation
|
||||
```
|
||||
|
||||
**When Batching Has NO Benefit (time_saved = 0):**
|
||||
|
||||
```
|
||||
Pre-Gap Analysis Complete
|
||||
|
||||
Development Type: {greenfield|brownfield|hybrid}
|
||||
Work Remaining: {work_count} tasks
|
||||
|
||||
Codebase Status:
|
||||
- Existing implementations reviewed: {existing_count}
|
||||
- New implementations needed: {new_count}
|
||||
|
||||
Smart Batching Analysis:
|
||||
- Batchable patterns detected: 0
|
||||
- Tasks requiring individual execution: {work_count}
|
||||
- Estimated time: {estimated_hours} hours
|
||||
|
||||
Ready for Implementation
|
||||
```
|
||||
|
||||
**Interactive Mode Menu:**
|
||||
```
|
||||
[C] Continue to Implementation
|
||||
[R] Re-run gap analysis
|
||||
[H] Halt pipeline
|
||||
```
|
||||
|
||||
**Batch Mode:** Auto-continue
|
||||
|
||||
## QUALITY GATE
|
||||
|
||||
Before proceeding:
|
||||
- [ ] All tasks analyzed against codebase
|
||||
- [ ] Vague tasks refined to specific actions
|
||||
- [ ] Already-done tasks checked
|
||||
- [ ] Missing tasks added
|
||||
- [ ] Gap analysis section added to story
|
||||
- [ ] Story file updated with refinements
|
||||
|
||||
## CRITICAL STEP COMPLETION
|
||||
|
||||
**ONLY WHEN** [all tasks analyzed AND story file updated],
|
||||
load and execute `{nextStepFile}` for implementation.
|
||||
|
||||
---
|
||||
|
||||
## SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS
|
||||
- Every task analyzed against codebase
|
||||
- Vague tasks made specific
|
||||
- Missing work identified and added
|
||||
- Already-done work verified
|
||||
- Gap analysis documented
|
||||
|
||||
### ❌ FAILURE
|
||||
- Skipping codebase scan
|
||||
- Accepting vague tasks ("Add feature X")
|
||||
- Not checking for existing implementations
|
||||
- Missing obvious gaps
|
||||
- No refinement of unclear tasks
|
||||
|
||||
## WHY THIS STEP PREVENTS VIBE CODING
|
||||
|
||||
Pre-gap analysis forces Claude to:
|
||||
1. **Understand existing code** before implementing
|
||||
2. **Be specific** about what to build
|
||||
3. **Verify assumptions** against reality
|
||||
4. **Plan work properly** instead of guessing
|
||||
|
||||
This is especially critical for **brownfield** where vibe coding causes:
|
||||
- Breaking existing functionality
|
||||
- Duplicating existing code
|
||||
- Missing integration points
|
||||
- Ignoring established patterns
|
||||
|
|
@ -1,248 +0,0 @@
|
|||
---
|
||||
name: 'step-03-write-tests'
|
||||
description: 'Write comprehensive tests BEFORE implementation (TDD approach)'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-03-write-tests.md'
|
||||
stateFile: '{state_file}'
|
||||
storyFile: '{story_file}'
|
||||
|
||||
# Next step
|
||||
nextStep: '{workflow_path}/steps/step-04-implement.md'
|
||||
---
|
||||
|
||||
# Step 3: Write Tests (TDD Approach)
|
||||
|
||||
**Goal:** Write comprehensive tests that validate story acceptance criteria BEFORE writing implementation code.
|
||||
|
||||
## Why Test-First?
|
||||
|
||||
1. **Clear requirements**: Writing tests forces clarity about what "done" means
|
||||
2. **Better design**: TDD leads to more testable, modular code
|
||||
3. **Confidence**: Know immediately when implementation is complete
|
||||
4. **Regression safety**: Tests catch future breakage
|
||||
|
||||
## Principles
|
||||
|
||||
- **Test acceptance criteria**: Each AC should have corresponding tests
|
||||
- **Test behavior, not implementation**: Focus on what, not how
|
||||
- **Red-Green-Refactor**: Tests should fail initially (red), then pass when implemented (green)
|
||||
- **Comprehensive coverage**: Unit tests, integration tests, and E2E tests as needed
|
||||
|
||||
---
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze Story Requirements
|
||||
|
||||
```
|
||||
Read {storyFile} completely.
|
||||
|
||||
Extract:
|
||||
- All Acceptance Criteria
|
||||
- All Tasks and Subtasks
|
||||
- All Files in File List
|
||||
- Definition of Done requirements
|
||||
```
|
||||
|
||||
### 2. Determine Test Strategy
|
||||
|
||||
For each acceptance criterion, determine:
|
||||
```
|
||||
Testing Level:
|
||||
- Unit tests: For individual functions/components
|
||||
- Integration tests: For component interactions
|
||||
- E2E tests: For full user workflows
|
||||
|
||||
Test Framework:
|
||||
- Jest (JavaScript/TypeScript)
|
||||
- PyTest (Python)
|
||||
- xUnit (C#/.NET)
|
||||
- JUnit (Java)
|
||||
- Etc. based on project stack
|
||||
```
|
||||
|
||||
### 3. Write Test Stubs
|
||||
|
||||
Create test files FIRST (before implementation):
|
||||
|
||||
```bash
|
||||
Example for React component:
|
||||
__tests__/components/UserDashboard.test.tsx
|
||||
|
||||
Example for API endpoint:
|
||||
__tests__/api/users.test.ts
|
||||
|
||||
Example for service:
|
||||
__tests__/services/auth.test.ts
|
||||
```
|
||||
|
||||
### 4. Write Test Cases
|
||||
|
||||
For each acceptance criterion:
|
||||
|
||||
```typescript
|
||||
// Example: React component test
|
||||
describe('UserDashboard', () => {
|
||||
describe('AC1: Display user profile information', () => {
|
||||
it('should render user name', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
expect(screen.getByText('John Doe')).toBeInTheDocument();
|
||||
});
|
||||
|
||||
it('should render user email', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
expect(screen.getByText('john@example.com')).toBeInTheDocument();
|
||||
});
|
||||
|
||||
it('should render user avatar', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
expect(screen.getByAltText('User avatar')).toBeInTheDocument();
|
||||
});
|
||||
});
|
||||
|
||||
describe('AC2: Allow user to edit profile', () => {
|
||||
it('should show edit button when not in edit mode', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
expect(screen.getByRole('button', { name: /edit/i })).toBeInTheDocument();
|
||||
});
|
||||
|
||||
it('should enable edit mode when edit button clicked', () => {
|
||||
render(<UserDashboard user={mockUser} />);
|
||||
fireEvent.click(screen.getByRole('button', { name: /edit/i }));
|
||||
expect(screen.getByRole('textbox', { name: /name/i })).toBeInTheDocument();
|
||||
});
|
||||
|
||||
it('should save changes when save button clicked', async () => {
|
||||
const onSave = vi.fn();
|
||||
render(<UserDashboard user={mockUser} onSave={onSave} />);
|
||||
|
||||
fireEvent.click(screen.getByRole('button', { name: /edit/i }));
|
||||
fireEvent.change(screen.getByRole('textbox', { name: /name/i }), {
|
||||
target: { value: 'Jane Doe' }
|
||||
});
|
||||
fireEvent.click(screen.getByRole('button', { name: /save/i }));
|
||||
|
||||
await waitFor(() => {
|
||||
expect(onSave).toHaveBeenCalledWith({ ...mockUser, name: 'Jane Doe' });
|
||||
});
|
||||
});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
### 5. Verify Tests Fail (Red Phase)
|
||||
|
||||
```bash
|
||||
# Run tests - they SHOULD fail because implementation doesn't exist yet
|
||||
npm test
|
||||
|
||||
# Expected output:
|
||||
# ❌ FAIL __tests__/components/UserDashboard.test.tsx
|
||||
# UserDashboard
|
||||
# AC1: Display user profile information
|
||||
# ✕ should render user name (5ms)
|
||||
# ✕ should render user email (3ms)
|
||||
# ✕ should render user avatar (2ms)
|
||||
#
|
||||
# This is GOOD! Tests failing = requirements are clear
|
||||
```
|
||||
|
||||
**If tests pass unexpectedly:**
|
||||
```
|
||||
⚠️ WARNING: Some tests are passing before implementation!
|
||||
|
||||
This means either:
|
||||
1. Functionality already exists (brownfield - verify and document)
|
||||
2. Tests are not actually testing the new requirements
|
||||
3. Tests have mocking issues (testing mocks instead of real code)
|
||||
|
||||
Review and fix before proceeding.
|
||||
```
|
||||
|
||||
### 6. Document Test Coverage
|
||||
|
||||
Create test coverage report:
|
||||
```yaml
|
||||
Test Coverage Summary:
|
||||
Acceptance Criteria: {total_ac_count}
|
||||
Acceptance Criteria with Tests: {tested_ac_count}
|
||||
Coverage: {coverage_percentage}%
|
||||
|
||||
Tasks: {total_task_count}
|
||||
Tasks with Tests: {tested_task_count}
|
||||
Coverage: {task_coverage_percentage}%
|
||||
|
||||
Test Files Created:
|
||||
- {test_file_1}
|
||||
- {test_file_2}
|
||||
- {test_file_3}
|
||||
|
||||
Total Test Cases: {test_case_count}
|
||||
```
|
||||
|
||||
### 7. Commit Tests
|
||||
|
||||
```bash
|
||||
git add {test_files}
|
||||
git commit -m "test(story-{story_id}): add tests for {story_title}
|
||||
|
||||
Write comprehensive tests for all acceptance criteria:
|
||||
{list_of_acs}
|
||||
|
||||
Test coverage:
|
||||
- {tested_ac_count}/{total_ac_count} ACs covered
|
||||
- {test_case_count} test cases
|
||||
- Unit tests: {unit_test_count}
|
||||
- Integration tests: {integration_test_count}
|
||||
- E2E tests: {e2e_test_count}
|
||||
|
||||
Tests currently failing (red phase) - expected behavior.
|
||||
Will implement functionality in next step."
|
||||
```
|
||||
|
||||
### 8. Update State
|
||||
|
||||
```yaml
|
||||
# Update {stateFile}
|
||||
current_step: 3
|
||||
tests_written: true
|
||||
test_files: [{test_file_list}]
|
||||
test_coverage: {coverage_percentage}%
|
||||
tests_status: "failing (red phase - expected)"
|
||||
ready_for_implementation: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
Before proceeding to implementation:
|
||||
|
||||
✅ **All acceptance criteria have corresponding tests**
|
||||
✅ **Tests are comprehensive (happy path + edge cases + error cases)**
|
||||
✅ **Tests follow project testing conventions**
|
||||
✅ **Tests are isolated and don't depend on each other**
|
||||
✅ **Tests have clear, descriptive names**
|
||||
✅ **Mock data is realistic and well-organized**
|
||||
✅ **Tests are failing for the right reasons (not implemented yet)**
|
||||
|
||||
---
|
||||
|
||||
## Skip Conditions
|
||||
|
||||
This step can be skipped if:
|
||||
- Complexity level = "micro" AND tasks ≤ 2
|
||||
- Story is documentation-only (no code changes)
|
||||
- Story is pure refactoring with existing comprehensive tests
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
Proceed to **Step 4: Implement** ({nextStep})
|
||||
|
||||
Now that tests are written and failing (red phase), implement the functionality to make them pass (green phase).
|
||||
|
|
@ -1,515 +0,0 @@
|
|||
---
|
||||
name: 'step-04-implement'
|
||||
description: 'HOSPITAL-GRADE implementation - safety-critical code with comprehensive testing'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-04-implement.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-05-post-validation.md'
|
||||
|
||||
# Role Continue
|
||||
role: dev
|
||||
---
|
||||
|
||||
# Step 4: Implement Story (Hospital-Grade Quality)
|
||||
|
||||
## ROLE CONTINUATION
|
||||
|
||||
**Continuing as DEV (Developer) perspective.**
|
||||
|
||||
You are now implementing the story tasks with adaptive methodology based on development type.
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Implement all unchecked tasks using appropriate methodology:
|
||||
1. **Greenfield**: TDD approach (write tests first, then implement)
|
||||
2. **Brownfield**: Refactor approach (understand existing, modify carefully)
|
||||
3. **Hybrid**: Mix both approaches as appropriate per task
|
||||
|
||||
## ⚕️ HOSPITAL-GRADE CODE STANDARDS ⚕️
|
||||
|
||||
**CRITICAL: Lives May Depend on This Code**
|
||||
|
||||
This code may be used in healthcare/safety-critical environments.
|
||||
Every line must meet hospital-grade reliability standards.
|
||||
|
||||
### Safety-Critical Quality Requirements:
|
||||
|
||||
✅ **CORRECTNESS OVER SPEED**
|
||||
- Take 5 hours to do it right, not 1 hour to do it poorly
|
||||
- Double-check ALL logic, especially edge cases
|
||||
- ZERO tolerance for shortcuts or "good enough"
|
||||
|
||||
✅ **DEFENSIVE PROGRAMMING**
|
||||
- Validate ALL inputs (never trust external data)
|
||||
- Handle ALL error cases explicitly
|
||||
- Fail safely (graceful degradation, never silent failures)
|
||||
|
||||
✅ **COMPREHENSIVE TESTING**
|
||||
- Test happy path AND all edge cases
|
||||
- Test error handling (what happens when things fail?)
|
||||
- Test boundary conditions (min/max values, empty/null)
|
||||
|
||||
✅ **CODE CLARITY**
|
||||
- Prefer readability over cleverness
|
||||
- Comment WHY, not what (code shows what, comments explain why)
|
||||
- No magic numbers (use named constants)
|
||||
|
||||
✅ **ROBUST ERROR HANDLING**
|
||||
- Never swallow errors silently
|
||||
- Log errors with context (what, when, why)
|
||||
- Provide actionable error messages
|
||||
|
||||
⚠️ **WHEN IN DOUBT: ASK, DON'T GUESS**
|
||||
If you're uncertain about a requirement, HALT and ask for clarification.
|
||||
Guessing in safety-critical code is UNACCEPTABLE.
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
### Implementation Principles
|
||||
|
||||
- **DEFAULT: ONE TASK AT A TIME** - Execute tasks individually unless smart batching applies
|
||||
- **SMART BATCHING EXCEPTION** - Low-risk patterns (package installs, imports) may batch
|
||||
- **RUN TESTS FREQUENTLY** - After each task or batch completion
|
||||
- **FOLLOW PROJECT PATTERNS** - Never invent new patterns
|
||||
- **NO VIBE CODING** - Follow the sequence exactly
|
||||
- **VERIFY BEFORE PROCEEDING** - Confirm success before next task/batch
|
||||
|
||||
### Adaptive Methodology
|
||||
|
||||
**For Greenfield tasks (new files):**
|
||||
1. Write test first (if applicable)
|
||||
2. Implement minimal code to pass
|
||||
3. Verify test passes
|
||||
4. Move to next task
|
||||
|
||||
**For Brownfield tasks (existing files):**
|
||||
1. Read and understand existing code
|
||||
2. Write test for new behavior (if applicable)
|
||||
3. Modify existing code carefully
|
||||
4. Verify all tests pass (old and new)
|
||||
5. Move to next task
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Review Refined Tasks
|
||||
|
||||
Load story file and get all unchecked tasks (from pre-gap analysis).
|
||||
|
||||
Display:
|
||||
```
|
||||
Implementation Plan
|
||||
|
||||
Total tasks: {unchecked_count}
|
||||
|
||||
Development breakdown:
|
||||
- Greenfield tasks: {new_file_tasks}
|
||||
- Brownfield tasks: {existing_file_tasks}
|
||||
- Test tasks: {test_tasks}
|
||||
- Database tasks: {db_tasks}
|
||||
|
||||
Starting implementation loop...
|
||||
```
|
||||
|
||||
### 2. Load Smart Batching Plan
|
||||
|
||||
Load batching plan from story file (created in Step 2):
|
||||
|
||||
Extract:
|
||||
- Pattern batches (groups of similar tasks)
|
||||
- Individual tasks (require one-by-one execution)
|
||||
- Validation strategy per batch
|
||||
- Time estimates
|
||||
|
||||
### 3. Implementation Strategy Selection
|
||||
|
||||
**If smart batching plan exists:**
|
||||
```
|
||||
Smart Batching Enabled
|
||||
|
||||
Execution Plan:
|
||||
- {batch_count} pattern batches (execute together)
|
||||
- {individual_count} individual tasks (execute separately)
|
||||
|
||||
Proceeding with pattern-based execution...
|
||||
```
|
||||
|
||||
**If no batching plan:**
|
||||
```
|
||||
Standard Execution (One-at-a-Time)
|
||||
|
||||
All tasks will be executed individually with full rigor.
|
||||
```
|
||||
|
||||
### 4. Pattern Batch Execution (NEW!)
|
||||
|
||||
**For EACH pattern batch (if batching enabled):**
|
||||
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Batch {n}/{total_batches}: {pattern_name}
|
||||
Tasks in batch: {task_count}
|
||||
Type: {pattern_type}
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
**A. Display Batch Tasks:**
|
||||
```
|
||||
Executing together:
|
||||
1. {task_1}
|
||||
2. {task_2}
|
||||
3. {task_3}
|
||||
...
|
||||
|
||||
Validation strategy: {validation_strategy}
|
||||
Estimated time: {estimated_minutes} minutes
|
||||
```
|
||||
|
||||
**B. Execute All Tasks in Batch:**
|
||||
|
||||
**Example: Package Installation Batch**
|
||||
```bash
|
||||
# Execute all package installations together
|
||||
npm pkg set dependencies.@company/shared-utils="^1.0.0"
|
||||
npm pkg set dependencies.@company/validation="^2.0.0"
|
||||
npm pkg set dependencies.@company/http-client="^1.5.0"
|
||||
npm pkg set dependencies.@company/database-client="^3.0.0"
|
||||
|
||||
# Single install command
|
||||
npm install
|
||||
```
|
||||
|
||||
**Example: Module Registration Batch**
|
||||
```typescript
|
||||
// Add all imports at once
|
||||
import { SharedUtilsModule } from '@company/shared-utils';
|
||||
import { ValidationModule } from '@company/validation';
|
||||
import { HttpClientModule } from '@company/http-client';
|
||||
import { DatabaseModule } from '@company/database-client';
|
||||
|
||||
// Register all modules together
|
||||
@Module({
|
||||
imports: [
|
||||
SharedUtilsModule.forRoot(),
|
||||
ValidationModule.forRoot(validationConfig),
|
||||
HttpClientModule.forRoot(httpConfig),
|
||||
DatabaseModule.forRoot(dbConfig),
|
||||
// ... existing imports
|
||||
]
|
||||
})
|
||||
```
|
||||
|
||||
**C. Validate Entire Batch:**
|
||||
|
||||
Run validation strategy for this pattern:
|
||||
```bash
|
||||
# For package installs
|
||||
npm run build
|
||||
|
||||
# For module registrations
|
||||
tsc --noEmit
|
||||
|
||||
# For code deletions
|
||||
npm test -- --run && npm run lint
|
||||
```
|
||||
|
||||
**D. If Validation Succeeds:**
|
||||
```
|
||||
✅ Batch Complete
|
||||
|
||||
All {task_count} tasks in batch executed successfully!
|
||||
|
||||
Marking all tasks complete:
|
||||
- [x] {task_1}
|
||||
- [x] {task_2}
|
||||
- [x] {task_3}
|
||||
...
|
||||
|
||||
Time: {actual_time} minutes
|
||||
```
|
||||
|
||||
**E. If Validation Fails:**
|
||||
```
|
||||
❌ Batch Validation Failed
|
||||
|
||||
Error: {error_message}
|
||||
|
||||
Falling back to one-at-a-time execution for this batch...
|
||||
```
|
||||
|
||||
**Fallback to individual execution:**
|
||||
- Execute each task in the failed batch one-by-one
|
||||
- Identify which task caused the failure
|
||||
- Fix and continue
|
||||
|
||||
### 5. Individual Task Execution
|
||||
|
||||
**For EACH individual task (non-batchable):**
|
||||
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Task {n}/{total}: {task_description}
|
||||
Type: {greenfield|brownfield}
|
||||
Reason: {why_not_batchable}
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
**A. Identify File(s) Affected:**
|
||||
- New file to create?
|
||||
- Existing file to modify?
|
||||
- Test file to add/update?
|
||||
- Migration file to create?
|
||||
|
||||
**B. For NEW FILES (Greenfield):**
|
||||
|
||||
```
|
||||
1. Determine file path and structure
|
||||
2. Identify dependencies needed
|
||||
3. Write test first (if applicable):
|
||||
- Create test file
|
||||
- Write failing test
|
||||
- Run test, confirm RED
|
||||
|
||||
4. Implement code:
|
||||
- Create file
|
||||
- Add minimal implementation
|
||||
- Follow project patterns from project-context.md
|
||||
|
||||
5. Run test:
|
||||
npm test -- --run
|
||||
Confirm GREEN
|
||||
|
||||
6. Verify:
|
||||
- File created
|
||||
- Exports correct
|
||||
- Test passes
|
||||
```
|
||||
|
||||
**C. For EXISTING FILES (Brownfield):**
|
||||
|
||||
```
|
||||
1. Read existing file completely
|
||||
2. Understand current implementation
|
||||
3. Identify where to make changes
|
||||
4. Check if tests exist for this file
|
||||
|
||||
5. Add test for new behavior (if applicable):
|
||||
- Find or create test file
|
||||
- Add test for new/changed behavior
|
||||
- Run test, may fail or pass depending on change
|
||||
|
||||
6. Modify existing code:
|
||||
- Make minimal changes
|
||||
- Preserve existing functionality
|
||||
- Follow established patterns in the file
|
||||
- Don't refactor unrelated code
|
||||
|
||||
7. Run ALL tests (not just new ones):
|
||||
npm test -- --run
|
||||
Confirm all tests pass
|
||||
|
||||
8. Verify:
|
||||
- Changes made as planned
|
||||
- No regressions (all old tests pass)
|
||||
- New behavior works (new tests pass)
|
||||
```
|
||||
|
||||
**D. For DATABASE TASKS:**
|
||||
|
||||
```
|
||||
1. Create migration file:
|
||||
npx supabase migration new {description}
|
||||
|
||||
2. Write migration SQL:
|
||||
- Create/alter tables
|
||||
- Add RLS policies
|
||||
- Add indexes
|
||||
|
||||
3. Apply migration:
|
||||
npx supabase db push
|
||||
|
||||
4. Verify schema:
|
||||
mcp__supabase__list_tables
|
||||
Confirm changes applied
|
||||
|
||||
5. Generate types:
|
||||
npx supabase gen types typescript --local
|
||||
```
|
||||
|
||||
**E. For TEST TASKS:**
|
||||
|
||||
```
|
||||
1. Identify what to test
|
||||
2. Find or create test file
|
||||
3. Write test with clear assertions
|
||||
4. Run test:
|
||||
npm test -- --run --grep "{test_name}"
|
||||
|
||||
5. Verify test is meaningful (not placeholder)
|
||||
```
|
||||
|
||||
**F. Check Task Complete:**
|
||||
|
||||
After implementing task, verify:
|
||||
- [ ] Code exists where expected
|
||||
- [ ] Tests pass
|
||||
- [ ] No TypeScript errors
|
||||
- [ ] Follows project patterns
|
||||
|
||||
**Mark task complete in story file:**
|
||||
```markdown
|
||||
- [x] {task_description}
|
||||
```
|
||||
|
||||
**Update state file with progress.**
|
||||
|
||||
### 3. Handle Errors Gracefully
|
||||
|
||||
**If implementation fails:**
|
||||
|
||||
```
|
||||
⚠️ Task failed: {task_description}
|
||||
|
||||
Error: {error_message}
|
||||
|
||||
Options:
|
||||
1. Debug and retry
|
||||
2. Skip and document blocker
|
||||
3. Simplify approach
|
||||
|
||||
DO NOT vibe code or guess!
|
||||
Follow error systematically.
|
||||
```
|
||||
|
||||
### 4. Run Full Test Suite
|
||||
|
||||
After ALL tasks completed:
|
||||
|
||||
```bash
|
||||
npm test -- --run
|
||||
npm run lint
|
||||
npm run build
|
||||
```
|
||||
|
||||
**All must pass before proceeding.**
|
||||
|
||||
### 5. Verify Task Completion
|
||||
|
||||
Re-read story file and count:
|
||||
- Tasks completed this session: {count}
|
||||
- Tasks remaining: {should be 0}
|
||||
- All checked: {should be true}
|
||||
|
||||
### 6. Update Pipeline State
|
||||
|
||||
Update state file:
|
||||
- Add `3` to `stepsCompleted`
|
||||
- Set `lastStep: 3`
|
||||
- Set `steps.step-03-implement.status: completed`
|
||||
- Record:
|
||||
```yaml
|
||||
implementation:
|
||||
files_created: {count}
|
||||
files_modified: {count}
|
||||
migrations_applied: {count}
|
||||
tests_added: {count}
|
||||
tasks_completed: {count}
|
||||
```
|
||||
|
||||
### 7. Display Summary
|
||||
|
||||
```
|
||||
Implementation Complete
|
||||
|
||||
Tasks Completed: {completed_count}
|
||||
|
||||
Files:
|
||||
- Created: {created_files}
|
||||
- Modified: {modified_files}
|
||||
|
||||
Migrations:
|
||||
- {migration_1}
|
||||
- {migration_2}
|
||||
|
||||
Tests:
|
||||
- All passing: {pass_count}/{total_count}
|
||||
- New tests added: {new_test_count}
|
||||
|
||||
Build Status:
|
||||
- Lint: ✓ Clean
|
||||
- TypeScript: ✓ No errors
|
||||
- Build: ✓ Success
|
||||
|
||||
Ready for Post-Validation
|
||||
```
|
||||
|
||||
**Interactive Mode Menu:**
|
||||
```
|
||||
[C] Continue to Post-Validation
|
||||
[T] Run tests again
|
||||
[B] Run build again
|
||||
[H] Halt pipeline
|
||||
```
|
||||
|
||||
**Batch Mode:** Auto-continue
|
||||
|
||||
## QUALITY GATE
|
||||
|
||||
Before proceeding:
|
||||
- [ ] All unchecked tasks completed
|
||||
- [ ] All tests pass
|
||||
- [ ] Lint clean
|
||||
- [ ] Build succeeds
|
||||
- [ ] No TypeScript errors
|
||||
- [ ] Followed project patterns
|
||||
- [ ] **No vibe coding occurred**
|
||||
|
||||
## CRITICAL STEP COMPLETION
|
||||
|
||||
**ONLY WHEN** [all tasks complete AND all tests pass AND lint clean AND build succeeds],
|
||||
load and execute `{nextStepFile}` for post-validation.
|
||||
|
||||
---
|
||||
|
||||
## SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS
|
||||
- All tasks implemented one at a time
|
||||
- Tests pass for each task
|
||||
- Brownfield code modified carefully
|
||||
- No regressions introduced
|
||||
- Project patterns followed
|
||||
- Build and lint clean
|
||||
- **Disciplined execution maintained**
|
||||
|
||||
### ❌ FAILURE
|
||||
- Vibe coding (guessing implementation)
|
||||
- Batching multiple tasks
|
||||
- Not running tests per task
|
||||
- Breaking existing functionality
|
||||
- Inventing new patterns
|
||||
- Skipping verification
|
||||
- **Deviating from step sequence**
|
||||
|
||||
## ANTI-VIBE-CODING ENFORCEMENT
|
||||
|
||||
This step enforces discipline by:
|
||||
|
||||
1. **One task at a time** - Can't batch or optimize
|
||||
2. **Test after each task** - Immediate verification
|
||||
3. **Follow existing patterns** - No invention
|
||||
4. **Brownfield awareness** - Read existing code first
|
||||
5. **Frequent verification** - Run tests, lint, build
|
||||
|
||||
**Even at 200K tokens, you MUST:**
|
||||
- ✅ Implement ONE task
|
||||
- ✅ Run tests
|
||||
- ✅ Verify it works
|
||||
- ✅ Mark task complete
|
||||
- ✅ Move to next task
|
||||
|
||||
**NO shortcuts. NO optimization. NO vibe coding.**
|
||||
|
|
@ -1,450 +0,0 @@
|
|||
---
|
||||
name: 'step-04-post-validation'
|
||||
description: 'Verify completed tasks against codebase reality (catch false positives)'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-04-post-validation.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-05-code-review.md'
|
||||
prevStepFile: '{workflow_path}/steps/step-03-implement.md'
|
||||
|
||||
# Role Switch
|
||||
role: dev
|
||||
requires_fresh_context: false # Continue from implementation context
|
||||
---
|
||||
|
||||
# Step 5b: Post-Implementation Validation
|
||||
|
||||
## ROLE CONTINUATION - VERIFICATION MODE
|
||||
|
||||
**Continuing as DEV but switching to VERIFICATION mindset.**
|
||||
|
||||
You are now verifying that completed work actually exists in the codebase.
|
||||
This catches the common problem of tasks marked [x] but implementation is incomplete.
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Verify all completed tasks against codebase reality:
|
||||
1. Re-read story file and extract completed tasks
|
||||
2. For each completed task, identify what should exist
|
||||
3. Use codebase search tools to verify existence
|
||||
4. Run tests to verify they actually pass
|
||||
5. Identify false positives (marked done but not actually done)
|
||||
6. If gaps found, uncheck tasks and add missing work
|
||||
7. Re-run implementation if needed
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
### Verification Principles
|
||||
|
||||
- **TRUST NOTHING** - Verify every completed task
|
||||
- **CHECK EXISTENCE** - Files, functions, components must exist
|
||||
- **CHECK COMPLETENESS** - Not just existence, but full implementation
|
||||
- **TEST VERIFICATION** - Claimed test coverage must be real
|
||||
- **NO ASSUMPTIONS** - Re-scan the codebase with fresh eyes
|
||||
|
||||
### What to Verify
|
||||
|
||||
For each task marked [x]:
|
||||
- Files mentioned exist at correct paths
|
||||
- Functions/components declared and exported
|
||||
- Tests exist and actually pass
|
||||
- Database migrations applied
|
||||
- API endpoints respond correctly
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Load Story and Extract Completed Tasks
|
||||
|
||||
Load story file: `{story_file}`
|
||||
|
||||
Extract all tasks from story that are marked [x]:
|
||||
```regex
|
||||
- \[x\] (.+)
|
||||
```
|
||||
|
||||
Build list of `completed_tasks` to verify.
|
||||
|
||||
### 2. Categorize Tasks by Type
|
||||
|
||||
For each completed task, determine what needs verification:
|
||||
|
||||
**File Creation Tasks:**
|
||||
- Pattern: "Create {file_path}"
|
||||
- Verify: File exists at path
|
||||
|
||||
**Component/Function Tasks:**
|
||||
- Pattern: "Add {name} function/component"
|
||||
- Verify: Symbol exists and is exported
|
||||
|
||||
**Test Tasks:**
|
||||
- Pattern: "Add test for {feature}"
|
||||
- Verify: Test file exists and test passes
|
||||
|
||||
**Database Tasks:**
|
||||
- Pattern: "Add {table} table", "Create migration"
|
||||
- Verify: Migration file exists, schema matches
|
||||
|
||||
**API Tasks:**
|
||||
- Pattern: "Create {endpoint} endpoint"
|
||||
- Verify: Route file exists, handler implemented
|
||||
|
||||
**UI Tasks:**
|
||||
- Pattern: "Add {element} to UI"
|
||||
- Verify: Component has data-testid attribute
|
||||
|
||||
### 3. Verify File Existence
|
||||
|
||||
For all file-related tasks:
|
||||
|
||||
```bash
|
||||
# Use Glob to find files
|
||||
glob: "**/{mentioned_filename}"
|
||||
```
|
||||
|
||||
**Check:**
|
||||
- [ ] File exists
|
||||
- [ ] File is not empty
|
||||
- [ ] File has expected exports
|
||||
|
||||
**False Positive Indicators:**
|
||||
- File doesn't exist
|
||||
- File exists but is empty
|
||||
- File exists but missing expected symbols
|
||||
|
||||
### 4. Verify Function/Component Implementation
|
||||
|
||||
For code implementation tasks:
|
||||
|
||||
```bash
|
||||
# Use Grep to find symbols
|
||||
grep: "{function_name|component_name}"
|
||||
glob: "**/*.{ts,tsx}"
|
||||
output_mode: "content"
|
||||
```
|
||||
|
||||
**Check:**
|
||||
- [ ] Symbol is declared
|
||||
- [ ] Symbol is exported
|
||||
- [ ] Implementation is not a stub/placeholder
|
||||
- [ ] Required logic is present
|
||||
|
||||
**False Positive Indicators:**
|
||||
- Symbol not found
|
||||
- Symbol exists but marked TODO
|
||||
- Symbol exists but throws "Not implemented"
|
||||
- Symbol exists but returns empty/null
|
||||
|
||||
### 5. Verify Test Coverage
|
||||
|
||||
For all test-related tasks:
|
||||
|
||||
```bash
|
||||
# Find test files
|
||||
glob: "**/*.test.{ts,tsx}"
|
||||
glob: "**/*.spec.{ts,tsx}"
|
||||
|
||||
# Run specific tests
|
||||
npm test -- --run --grep "{feature_name}"
|
||||
```
|
||||
|
||||
**Check:**
|
||||
- [ ] Test file exists
|
||||
- [ ] Test describes the feature
|
||||
- [ ] Test actually runs (not skipped)
|
||||
- [ ] Test passes (GREEN)
|
||||
|
||||
**False Positive Indicators:**
|
||||
- No test file found
|
||||
- Test exists but skipped (it.skip)
|
||||
- Test exists but fails
|
||||
- Test exists but doesn't test the feature (placeholder)
|
||||
|
||||
### 6. Verify Database Changes
|
||||
|
||||
For database migration tasks:
|
||||
|
||||
```bash
|
||||
# Find migration files
|
||||
glob: "**/migrations/*.sql"
|
||||
|
||||
# Check Supabase schema
|
||||
mcp__supabase__list_tables
|
||||
```
|
||||
|
||||
**Check:**
|
||||
- [ ] Migration file exists
|
||||
- [ ] Migration has been applied
|
||||
- [ ] Table/column exists in schema
|
||||
- [ ] RLS policies are present
|
||||
|
||||
**False Positive Indicators:**
|
||||
- Migration file missing
|
||||
- Migration not applied to database
|
||||
- Table/column doesn't exist
|
||||
- RLS policies missing
|
||||
|
||||
### 7. Verify API Endpoints
|
||||
|
||||
For API endpoint tasks:
|
||||
|
||||
```bash
|
||||
# Find route files
|
||||
glob: "**/app/api/**/{endpoint}/route.ts"
|
||||
grep: "export async function {METHOD}"
|
||||
```
|
||||
|
||||
**Check:**
|
||||
- [ ] Route file exists
|
||||
- [ ] Handler function implemented
|
||||
- [ ] Returns proper Response type
|
||||
- [ ] Error handling present
|
||||
|
||||
**False Positive Indicators:**
|
||||
- Route file doesn't exist
|
||||
- Handler throws "Not implemented"
|
||||
- Handler returns stub response
|
||||
|
||||
### 8. Run Full Verification
|
||||
|
||||
Execute verification for ALL completed tasks:
|
||||
|
||||
```typescript
|
||||
interface VerificationResult {
|
||||
task: string;
|
||||
status: "verified" | "false_positive";
|
||||
evidence: string;
|
||||
missing?: string;
|
||||
}
|
||||
|
||||
const results: VerificationResult[] = [];
|
||||
|
||||
for (const task of completed_tasks) {
|
||||
const result = await verifyTask(task);
|
||||
results.push(result);
|
||||
}
|
||||
```
|
||||
|
||||
### 9. Analyze Verification Results
|
||||
|
||||
Count results:
|
||||
```
|
||||
Total Verified: {verified_count}
|
||||
False Positives: {false_positive_count}
|
||||
```
|
||||
|
||||
### 10. Handle False Positives
|
||||
|
||||
**IF false positives found (count > 0):**
|
||||
|
||||
Display:
|
||||
```
|
||||
⚠️ POST-IMPLEMENTATION GAPS DETECTED
|
||||
|
||||
Tasks marked complete but implementation incomplete:
|
||||
|
||||
{for each false_positive}
|
||||
- [ ] {task_description}
|
||||
Missing: {what_is_missing}
|
||||
Evidence: {grep/glob results}
|
||||
|
||||
{add new tasks for missing work}
|
||||
- [ ] Actually implement {missing_part}
|
||||
```
|
||||
|
||||
**Actions:**
|
||||
1. Uncheck false positive tasks in story file
|
||||
2. Add new tasks for the missing work
|
||||
3. Update "Gap Analysis" section in story
|
||||
4. Set state to re-run implementation
|
||||
|
||||
**Re-run implementation:**
|
||||
```
|
||||
Detected {false_positive_count} incomplete tasks.
|
||||
Re-running Step 5: Implementation to complete missing work...
|
||||
|
||||
{load and execute step-05-implement.md}
|
||||
```
|
||||
|
||||
After re-implementation, **RE-RUN THIS STEP** (step-05b-post-validation.md)
|
||||
|
||||
### 11. Handle Verified Success
|
||||
|
||||
**IF no false positives (all verified):**
|
||||
|
||||
Display:
|
||||
```
|
||||
✅ POST-IMPLEMENTATION VALIDATION PASSED
|
||||
|
||||
All {verified_count} completed tasks verified against codebase:
|
||||
- Files exist and are complete
|
||||
- Functions/components implemented
|
||||
- Tests exist and pass
|
||||
- Database changes applied
|
||||
- API endpoints functional
|
||||
|
||||
Ready for Code Review
|
||||
```
|
||||
|
||||
Update story file "Gap Analysis" section:
|
||||
```markdown
|
||||
## Gap Analysis
|
||||
|
||||
### Post-Implementation Validation
|
||||
- **Date:** {timestamp}
|
||||
- **Tasks Verified:** {verified_count}
|
||||
- **False Positives:** 0
|
||||
- **Status:** ✅ All work verified complete
|
||||
|
||||
**Verification Evidence:**
|
||||
{for each verified task}
|
||||
- ✅ {task}: {evidence}
|
||||
```
|
||||
|
||||
### 12. Update Pipeline State
|
||||
|
||||
Update state file:
|
||||
- Add `5b` to `stepsCompleted`
|
||||
- Set `lastStep: 5b`
|
||||
- Set `steps.step-05b-post-validation.status: completed`
|
||||
- Record verification results:
|
||||
```yaml
|
||||
verification:
|
||||
tasks_verified: {count}
|
||||
false_positives: {count}
|
||||
re_implementation_required: {true|false}
|
||||
```
|
||||
|
||||
### 13. Present Summary and Menu
|
||||
|
||||
Display:
|
||||
```
|
||||
Post-Implementation Validation Complete
|
||||
|
||||
Verification Summary:
|
||||
- Tasks Checked: {total_count}
|
||||
- Verified Complete: {verified_count}
|
||||
- False Positives: {false_positive_count}
|
||||
- Re-implementations: {retry_count}
|
||||
|
||||
{if false_positives}
|
||||
Re-running implementation to complete missing work...
|
||||
{else}
|
||||
All work verified. Proceeding to Code Review...
|
||||
{endif}
|
||||
```
|
||||
|
||||
**Interactive Mode Menu (only if no false positives):**
|
||||
```
|
||||
[C] Continue to {next step based on complexity: Code Review | Complete}
|
||||
[V] Run verification again
|
||||
[T] Run tests again
|
||||
[H] Halt pipeline
|
||||
```
|
||||
|
||||
{if micro complexity: "⏭️ Code Review will be skipped (lightweight path)"}
|
||||
|
||||
**Batch Mode:**
|
||||
- Auto re-run implementation if false positives
|
||||
- Auto-continue if all verified
|
||||
|
||||
## QUALITY GATE
|
||||
|
||||
Before proceeding to code review:
|
||||
- [ ] All completed tasks verified against codebase
|
||||
- [ ] Zero false positives remaining
|
||||
- [ ] All tests still passing
|
||||
- [ ] Build still succeeds
|
||||
- [ ] Gap analysis updated with verification results
|
||||
|
||||
## VERIFICATION TOOLS
|
||||
|
||||
Use these tools for verification:
|
||||
|
||||
```typescript
|
||||
// File existence
|
||||
glob("{pattern}")
|
||||
|
||||
// Symbol search
|
||||
grep("{symbol_name}", { glob: "**/*.{ts,tsx}", output_mode: "content" })
|
||||
|
||||
// Test execution
|
||||
bash("npm test -- --run --grep '{test_name}'")
|
||||
|
||||
// Database check
|
||||
mcp__supabase__list_tables()
|
||||
|
||||
// Read file contents
|
||||
read("{file_path}")
|
||||
```
|
||||
|
||||
## CRITICAL STEP COMPLETION
|
||||
|
||||
**IF** [false positives detected],
|
||||
load and execute `{prevStepFile}` to complete missing work,
|
||||
then RE-RUN this step.
|
||||
|
||||
**ONLY WHEN** [all tasks verified AND zero false positives]:
|
||||
|
||||
**Determine next step based on complexity routing:**
|
||||
|
||||
```
|
||||
If 5 in skip_steps (micro complexity):
|
||||
nextStepFile = '{workflow_path}/steps/step-06-complete.md'
|
||||
Display: "⏭️ Skipping Code Review (micro complexity) → Proceeding to Complete"
|
||||
Else:
|
||||
nextStepFile = '{workflow_path}/steps/step-05-code-review.md'
|
||||
```
|
||||
|
||||
Load and execute `{nextStepFile}`.
|
||||
|
||||
---
|
||||
|
||||
## SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS
|
||||
- All completed tasks verified against codebase
|
||||
- No false positives (or all re-implemented)
|
||||
- Tests still passing
|
||||
- Evidence documented for each task
|
||||
- Gap analysis updated
|
||||
|
||||
### ❌ FAILURE
|
||||
- Skipping verification ("trust the marks")
|
||||
- Not checking actual code existence
|
||||
- Not running tests to verify claims
|
||||
- Allowing false positives to proceed
|
||||
- Not documenting verification evidence
|
||||
|
||||
## COMMON FALSE POSITIVE PATTERNS
|
||||
|
||||
Watch for these common issues:
|
||||
|
||||
1. **Stub Implementations**
|
||||
- Function exists but returns `null`
|
||||
- Function throws "Not implemented"
|
||||
- Component returns empty div
|
||||
|
||||
2. **Placeholder Tests**
|
||||
- Test exists but skipped (it.skip)
|
||||
- Test doesn't actually test the feature
|
||||
- Test always passes (no assertions)
|
||||
|
||||
3. **Incomplete Files**
|
||||
- File created but empty
|
||||
- Missing required exports
|
||||
- TODO comments everywhere
|
||||
|
||||
4. **Database Drift**
|
||||
- Migration file exists but not applied
|
||||
- Schema doesn't match migration
|
||||
- RLS policies missing
|
||||
|
||||
5. **API Stubs**
|
||||
- Route exists but returns 501
|
||||
- Handler not implemented
|
||||
- No error handling
|
||||
|
||||
This step is the **safety net** that catches incomplete work before code review.
|
||||
|
|
@ -1,368 +0,0 @@
|
|||
---
|
||||
name: 'step-06-run-quality-checks'
|
||||
description: 'Run tests, type checks, and linter - fix all problems before code review'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-06-run-quality-checks.md'
|
||||
stateFile: '{state_file}'
|
||||
storyFile: '{story_file}'
|
||||
|
||||
# Next step
|
||||
nextStep: '{workflow_path}/steps/step-07-code-review.md'
|
||||
---
|
||||
|
||||
# Step 6: Run Quality Checks
|
||||
|
||||
**Goal:** Verify implementation quality through automated checks: tests, type checking, and linting. Fix ALL problems before proceeding to human/AI code review.
|
||||
|
||||
## Why Automate First?
|
||||
|
||||
1. **Fast feedback**: Automated checks run in seconds
|
||||
2. **Catch obvious issues**: Type errors, lint violations, failing tests
|
||||
3. **Save review time**: Don't waste code review time on mechanical issues
|
||||
4. **Enforce standards**: Consistent code style and quality
|
||||
|
||||
## Principles
|
||||
|
||||
- **Zero tolerance**: ALL checks must pass
|
||||
- **Fix, don't skip**: If a check fails, fix it - don't disable the check
|
||||
- **Iterate quickly**: Run-fix-run loop until all green
|
||||
- **Document workarounds**: If you must suppress a check, document why
|
||||
|
||||
---
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Run Test Suite
|
||||
|
||||
```bash
|
||||
echo "📋 Running test suite..."
|
||||
|
||||
# Run all tests
|
||||
npm test
|
||||
|
||||
# Or for other stacks:
|
||||
# pytest
|
||||
# dotnet test
|
||||
# mvn test
|
||||
# cargo test
|
||||
```
|
||||
|
||||
**Expected output:**
|
||||
```
|
||||
✅ PASS __tests__/components/UserDashboard.test.tsx
|
||||
UserDashboard
|
||||
AC1: Display user profile information
|
||||
✓ should render user name (12ms)
|
||||
✓ should render user email (8ms)
|
||||
✓ should render user avatar (6ms)
|
||||
AC2: Allow user to edit profile
|
||||
✓ should show edit button when not in edit mode (10ms)
|
||||
✓ should enable edit mode when edit button clicked (15ms)
|
||||
✓ should save changes when save button clicked (22ms)
|
||||
|
||||
Test Suites: 1 passed, 1 total
|
||||
Tests: 6 passed, 6 total
|
||||
Time: 2.134s
|
||||
```
|
||||
|
||||
**If tests fail:**
|
||||
```
|
||||
❌ Test failures detected!
|
||||
|
||||
Failed tests:
|
||||
- UserDashboard › AC2 › should save changes when save button clicked
|
||||
Expected: { name: 'Jane Doe', email: 'john@example.com' }
|
||||
Received: undefined
|
||||
|
||||
Action required:
|
||||
1. Analyze the failure
|
||||
2. Fix the implementation
|
||||
3. Re-run tests
|
||||
4. Repeat until all tests pass
|
||||
|
||||
DO NOT PROCEED until all tests pass.
|
||||
```
|
||||
|
||||
### 2. Check Test Coverage
|
||||
|
||||
```bash
|
||||
echo "📊 Checking test coverage..."
|
||||
|
||||
# Generate coverage report
|
||||
npm run test:coverage
|
||||
|
||||
# Or for other stacks:
|
||||
# pytest --cov
|
||||
# dotnet test /p:CollectCoverage=true
|
||||
# cargo tarpaulin
|
||||
```
|
||||
|
||||
**Minimum coverage thresholds:**
|
||||
```yaml
|
||||
Line Coverage: ≥80%
|
||||
Branch Coverage: ≥75%
|
||||
Function Coverage: ≥80%
|
||||
Statement Coverage: ≥80%
|
||||
```
|
||||
|
||||
**If coverage is low:**
|
||||
```
|
||||
⚠️ Test coverage below threshold!
|
||||
|
||||
Current coverage:
|
||||
Lines: 72% (threshold: 80%)
|
||||
Branches: 68% (threshold: 75%)
|
||||
Functions: 85% (threshold: 80%)
|
||||
|
||||
Uncovered areas:
|
||||
- src/components/UserDashboard.tsx: lines 45-52 (error handling)
|
||||
- src/services/userService.ts: lines 23-28 (edge case)
|
||||
|
||||
Action required:
|
||||
1. Add tests for uncovered code paths
|
||||
2. Re-run coverage check
|
||||
3. Achieve ≥80% coverage before proceeding
|
||||
```
|
||||
|
||||
### 3. Run Type Checker
|
||||
|
||||
```bash
|
||||
echo "🔍 Running type checker..."
|
||||
|
||||
# For TypeScript
|
||||
npx tsc --noEmit
|
||||
|
||||
# For Python
|
||||
# mypy src/
|
||||
|
||||
# For C#
|
||||
# dotnet build
|
||||
|
||||
# For Java
|
||||
# mvn compile
|
||||
```
|
||||
|
||||
**Expected output:**
|
||||
```
|
||||
✅ No type errors found
|
||||
```
|
||||
|
||||
**If type errors found:**
|
||||
```
|
||||
❌ Type errors detected!
|
||||
|
||||
src/components/UserDashboard.tsx:45:12 - error TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
|
||||
|
||||
45 onSave(user.name);
|
||||
~~~~~~~~~
|
||||
|
||||
src/services/userService.ts:23:18 - error TS2339: Property 'id' does not exist on type 'User'.
|
||||
|
||||
23 return user.id;
|
||||
~~
|
||||
|
||||
Found 2 errors in 2 files.
|
||||
|
||||
Action required:
|
||||
1. Fix type errors
|
||||
2. Re-run type checker
|
||||
3. Repeat until zero errors
|
||||
|
||||
DO NOT PROCEED with type errors.
|
||||
```
|
||||
|
||||
### 4. Run Linter
|
||||
|
||||
```bash
|
||||
echo "✨ Running linter..."
|
||||
|
||||
# For JavaScript/TypeScript
|
||||
npm run lint
|
||||
|
||||
# For Python
|
||||
# pylint src/
|
||||
|
||||
# For C#
|
||||
# dotnet format --verify-no-changes
|
||||
|
||||
# For Java
|
||||
# mvn checkstyle:check
|
||||
```
|
||||
|
||||
**Expected output:**
|
||||
```
|
||||
✅ No linting errors found
|
||||
```
|
||||
|
||||
**If lint errors found:**
|
||||
```
|
||||
❌ Lint errors detected!
|
||||
|
||||
src/components/UserDashboard.tsx
|
||||
45:1 error 'useState' is not defined no-undef
|
||||
52:12 error Unexpected console statement no-console
|
||||
67:5 warning Unexpected var, use let or const instead no-var
|
||||
|
||||
src/services/userService.ts
|
||||
23:1 error Missing return type on function @typescript-eslint/explicit-function-return-type
|
||||
|
||||
✖ 4 problems (3 errors, 1 warning)
|
||||
|
||||
Action required:
|
||||
1. Run auto-fix if available: npm run lint:fix
|
||||
2. Manually fix remaining errors
|
||||
3. Re-run linter
|
||||
4. Repeat until zero errors and zero warnings
|
||||
|
||||
DO NOT PROCEED with lint errors.
|
||||
```
|
||||
|
||||
### 5. Auto-Fix What's Possible
|
||||
|
||||
```bash
|
||||
echo "🔧 Attempting auto-fixes..."
|
||||
|
||||
# Run formatters and auto-fixable linters
|
||||
npm run lint:fix
|
||||
npm run format
|
||||
|
||||
# Stage the auto-fixes
|
||||
git add .
|
||||
```
|
||||
|
||||
### 6. Manual Fixes
|
||||
|
||||
For issues that can't be auto-fixed:
|
||||
|
||||
```typescript
|
||||
// Example: Fix type error
|
||||
// Before:
|
||||
const userName = user.name; // Type error if name is optional
|
||||
onSave(userName);
|
||||
|
||||
// After:
|
||||
const userName = user.name ?? ''; // Handle undefined case
|
||||
onSave(userName);
|
||||
```
|
||||
|
||||
```typescript
|
||||
// Example: Fix lint error
|
||||
// Before:
|
||||
var count = 0; // ESLint: no-var
|
||||
|
||||
// After:
|
||||
let count = 0; // Use let instead of var
|
||||
```
|
||||
|
||||
### 7. Verify All Checks Pass
|
||||
|
||||
Run everything again to confirm:
|
||||
|
||||
```bash
|
||||
echo "✅ Final verification..."
|
||||
|
||||
# Run all checks
|
||||
npm test && \
|
||||
npx tsc --noEmit && \
|
||||
npm run lint
|
||||
|
||||
echo "✅ ALL QUALITY CHECKS PASSED!"
|
||||
```
|
||||
|
||||
### 8. Commit Quality Fixes
|
||||
|
||||
```bash
|
||||
# Only if fixes were needed
|
||||
if git diff --cached --quiet; then
|
||||
echo "No fixes needed - all checks passed first time!"
|
||||
else
|
||||
git commit -m "fix(story-{story_id}): address quality check issues
|
||||
|
||||
- Fix type errors
|
||||
- Resolve lint violations
|
||||
- Improve test coverage to {coverage}%
|
||||
|
||||
All automated checks now passing:
|
||||
✅ Tests: {test_count} passed
|
||||
✅ Type check: No errors
|
||||
✅ Linter: No violations
|
||||
✅ Coverage: {coverage}%"
|
||||
fi
|
||||
```
|
||||
|
||||
### 9. Update State
|
||||
|
||||
```yaml
|
||||
# Update {stateFile}
|
||||
current_step: 6
|
||||
quality_checks:
|
||||
tests_passed: true
|
||||
test_count: {test_count}
|
||||
coverage: {coverage}%
|
||||
type_check_passed: true
|
||||
lint_passed: true
|
||||
all_checks_passed: true
|
||||
ready_for_code_review: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Gate
|
||||
|
||||
**CRITICAL:** This is a **BLOCKING STEP**. You **MUST NOT** proceed to code review until ALL of the following pass:
|
||||
|
||||
✅ **All tests passing** (0 failures)
|
||||
✅ **Test coverage ≥80%** (or project threshold)
|
||||
✅ **Zero type errors**
|
||||
✅ **Zero lint errors**
|
||||
✅ **Zero lint warnings** (or all warnings justified and documented)
|
||||
|
||||
If ANY check fails:
|
||||
1. Fix the issue
|
||||
2. Re-run all checks
|
||||
3. Repeat until ALL PASS
|
||||
4. THEN proceed to next step
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Tests fail sporadically:**
|
||||
- Check for test interdependencies
|
||||
- Look for timing issues (use `waitFor` in async tests)
|
||||
- Check for environment-specific issues
|
||||
|
||||
**Type errors in third-party libraries:**
|
||||
- Install `@types` packages
|
||||
- Use type assertions carefully (document why)
|
||||
- Consider updating library versions
|
||||
|
||||
**Lint rules conflict with team standards:**
|
||||
- Discuss with team before changing config
|
||||
- Document exceptions in comments
|
||||
- Update lint config if truly inappropriate
|
||||
|
||||
**Coverage can't reach 80%:**
|
||||
- Focus on critical paths first
|
||||
- Test error cases and edge cases
|
||||
- Consider if untested code is actually needed
|
||||
|
||||
---
|
||||
|
||||
## Skip Conditions
|
||||
|
||||
This step CANNOT be skipped. All stories must pass quality checks.
|
||||
|
||||
The only exception: Documentation-only stories with zero code changes.
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
Proceed to **Step 7: Code Review** ({nextStep})
|
||||
|
||||
Now that all automated checks pass, the code is ready for human/AI review.
|
||||
|
|
@ -1,337 +0,0 @@
|
|||
---
|
||||
name: 'step-07-code-review'
|
||||
description: 'Multi-agent code review with fresh context and variable agent count'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
multi_agent_review_workflow: '{project-root}/_bmad/bmm/workflows/4-implementation/multi-agent-review'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-07-code-review.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-08-review-analysis.md'
|
||||
stateFile: '{state_file}'
|
||||
reviewReport: '{sprint_artifacts}/review-{story_id}.md'
|
||||
|
||||
# Role (continue as dev, but reviewer mindset)
|
||||
role: dev
|
||||
requires_fresh_context: true # CRITICAL: Review MUST happen in fresh context
|
||||
---
|
||||
|
||||
# Step 7: Code Review (Multi-Agent with Fresh Context)
|
||||
|
||||
## ROLE CONTINUATION - ADVERSARIAL MODE
|
||||
|
||||
**Continuing as DEV but switching to ADVERSARIAL REVIEWER mindset.**
|
||||
|
||||
You are now a critical code reviewer. Your job is to FIND PROBLEMS.
|
||||
- **NEVER** say "looks good" - that's a failure
|
||||
- **MUST** find 3-10 specific issues
|
||||
- **FIX** every issue you find
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Perform adversarial code review:
|
||||
1. Query Supabase advisors for security/performance issues
|
||||
2. Identify all files changed for this story
|
||||
3. Review each file against checklist
|
||||
4. Find and document 3-10 issues (MANDATORY)
|
||||
5. Fix all issues
|
||||
6. Verify tests still pass
|
||||
|
||||
### Multi-Agent Review with Fresh Context (NEW v1.5.0)
|
||||
|
||||
**All reviews now use multi-agent approach with variable agent counts based on risk.**
|
||||
|
||||
**CRITICAL: Review in FRESH CONTEXT (unbiased perspective)**
|
||||
|
||||
```
|
||||
⚠️ CHECKPOINT: Starting fresh review session
|
||||
|
||||
Multi-agent review will run in NEW context to avoid bias from implementation.
|
||||
|
||||
Agent count based on complexity level:
|
||||
- MICRO: 2 agents (Security + Code Quality)
|
||||
- STANDARD: 4 agents (+ Architecture + Testing)
|
||||
- COMPLEX: 6 agents (+ Performance + Domain Expert)
|
||||
|
||||
Smart agent selection analyzes changed files to select most relevant reviewers.
|
||||
```
|
||||
|
||||
**Invoke multi-agent-review workflow:**
|
||||
|
||||
```xml
|
||||
<invoke-workflow path="{project-root}/_bmad/bmm/workflows/4-implementation/multi-agent-review/workflow.yaml">
|
||||
<input name="story_id">{story_id}</input>
|
||||
<input name="complexity_level">{complexity_level}</input>
|
||||
<input name="fresh_context">true</input>
|
||||
</invoke-workflow>
|
||||
```
|
||||
|
||||
**The multi-agent-review workflow will:**
|
||||
1. Create fresh context (new session, unbiased)
|
||||
2. Analyze changed files
|
||||
3. Select appropriate agents based on code changes
|
||||
4. Run parallel reviews from multiple perspectives
|
||||
5. Aggregate findings with severity ratings
|
||||
6. Return comprehensive review report
|
||||
|
||||
**After review completes:**
|
||||
- Review report saved to: `{sprint_artifacts}/review-{story_id}.md`
|
||||
- Proceed to step 8 (Review Analysis) to categorize findings
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
### Adversarial Requirements
|
||||
|
||||
- **MINIMUM 3 ISSUES** - If you found fewer, look harder
|
||||
- **MAXIMUM 10 ISSUES** - Prioritize if more found
|
||||
- **NO "LOOKS GOOD"** - This is FORBIDDEN
|
||||
- **FIX EVERYTHING** - Don't just report, fix
|
||||
|
||||
### Review Categories (find issues in EACH)
|
||||
|
||||
1. Security
|
||||
2. Performance
|
||||
3. Error Handling
|
||||
4. Test Coverage
|
||||
5. Code Quality
|
||||
6. Architecture
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Query Supabase Advisors
|
||||
|
||||
Use MCP tools:
|
||||
|
||||
```
|
||||
mcp__supabase__get_advisors:
|
||||
type: "security"
|
||||
|
||||
mcp__supabase__get_advisors:
|
||||
type: "performance"
|
||||
```
|
||||
|
||||
Document any issues found.
|
||||
|
||||
### 2. Identify Changed Files
|
||||
|
||||
```bash
|
||||
git status
|
||||
git diff --name-only HEAD~1
|
||||
```
|
||||
|
||||
List all files changed for story {story_id}.
|
||||
|
||||
### 3. Review Each Category
|
||||
|
||||
#### SECURITY REVIEW
|
||||
|
||||
For each file, check:
|
||||
- [ ] No SQL injection vulnerabilities
|
||||
- [ ] No XSS vulnerabilities
|
||||
- [ ] Auth checks on all protected routes
|
||||
- [ ] RLS policies exist and are correct
|
||||
- [ ] No credential exposure (API keys, secrets)
|
||||
- [ ] Input validation present
|
||||
- [ ] Rate limiting considered
|
||||
|
||||
#### PERFORMANCE REVIEW
|
||||
|
||||
- [ ] No N+1 query patterns
|
||||
- [ ] Indexes exist for query patterns
|
||||
- [ ] No unnecessary re-renders
|
||||
- [ ] Proper caching strategy
|
||||
- [ ] Efficient data fetching
|
||||
- [ ] Bundle size impact considered
|
||||
|
||||
#### ERROR HANDLING REVIEW
|
||||
|
||||
- [ ] Result type used consistently
|
||||
- [ ] Error messages are user-friendly
|
||||
- [ ] Edge cases handled
|
||||
- [ ] Null/undefined checked
|
||||
- [ ] Network errors handled gracefully
|
||||
|
||||
#### TEST COVERAGE REVIEW
|
||||
|
||||
- [ ] All AC have tests
|
||||
- [ ] Edge cases tested
|
||||
- [ ] Error paths tested
|
||||
- [ ] Mocking is appropriate (not excessive)
|
||||
- [ ] Tests are deterministic
|
||||
|
||||
#### CODE QUALITY REVIEW
|
||||
|
||||
- [ ] DRY - no duplicate code
|
||||
- [ ] SOLID principles followed
|
||||
- [ ] TypeScript strict mode compliant
|
||||
- [ ] No any types
|
||||
- [ ] Functions are focused (single responsibility)
|
||||
- [ ] Naming is clear and consistent
|
||||
|
||||
#### ARCHITECTURE REVIEW
|
||||
|
||||
- [ ] Module boundaries respected
|
||||
- [ ] Imports from index.ts only
|
||||
- [ ] Server/client separation correct
|
||||
- [ ] Data flow is clear
|
||||
- [ ] No circular dependencies
|
||||
|
||||
### 4. Document All Issues
|
||||
|
||||
For each issue found:
|
||||
|
||||
```yaml
|
||||
issue_{n}:
|
||||
severity: critical|high|medium|low
|
||||
category: security|performance|error-handling|testing|quality|architecture
|
||||
file: "{file_path}"
|
||||
line: {line_number}
|
||||
problem: |
|
||||
{Clear description of the issue}
|
||||
risk: |
|
||||
{What could go wrong if not fixed}
|
||||
fix: |
|
||||
{How to fix it}
|
||||
```
|
||||
|
||||
### 5. Fix All Issues
|
||||
|
||||
For EACH issue documented:
|
||||
|
||||
1. Edit the file to fix the issue
|
||||
2. Add test if issue wasn't covered
|
||||
3. Verify the fix is correct
|
||||
4. Mark as fixed
|
||||
|
||||
### 6. Run Verification
|
||||
|
||||
After all fixes:
|
||||
|
||||
```bash
|
||||
npm run lint
|
||||
npm run build
|
||||
npm test -- --run
|
||||
```
|
||||
|
||||
All must pass.
|
||||
|
||||
### 7. Create Review Report
|
||||
|
||||
Append to story file or create `{sprint_artifacts}/review-{story_id}.md`:
|
||||
|
||||
```markdown
|
||||
# Code Review Report - Story {story_id}
|
||||
|
||||
## Summary
|
||||
- Issues Found: {count}
|
||||
- Issues Fixed: {count}
|
||||
- Categories Reviewed: {list}
|
||||
|
||||
## Issues Detail
|
||||
|
||||
### Issue 1: {title}
|
||||
- **Severity:** {severity}
|
||||
- **Category:** {category}
|
||||
- **File:** {file}:{line}
|
||||
- **Problem:** {description}
|
||||
- **Fix Applied:** {fix_description}
|
||||
|
||||
### Issue 2: {title}
|
||||
...
|
||||
|
||||
## Security Checklist
|
||||
- [x] RLS policies verified
|
||||
- [x] No credential exposure
|
||||
- [x] Input validation present
|
||||
|
||||
## Performance Checklist
|
||||
- [x] No N+1 queries
|
||||
- [x] Indexes verified
|
||||
|
||||
## Final Status
|
||||
All issues resolved. Tests passing.
|
||||
|
||||
Reviewed by: DEV (adversarial)
|
||||
Reviewed at: {timestamp}
|
||||
```
|
||||
|
||||
### 8. Update Pipeline State
|
||||
|
||||
Update state file:
|
||||
- Add `6` to `stepsCompleted`
|
||||
- Set `lastStep: 6`
|
||||
- Set `steps.step-06-code-review.status: completed`
|
||||
- Record `issues_found` and `issues_fixed`
|
||||
|
||||
### 9. Present Summary and Menu
|
||||
|
||||
Display:
|
||||
```
|
||||
Code Review Complete
|
||||
|
||||
Issues Found: {count} (minimum 3 required)
|
||||
Issues Fixed: {count}
|
||||
|
||||
By Category:
|
||||
- Security: {count}
|
||||
- Performance: {count}
|
||||
- Error Handling: {count}
|
||||
- Test Coverage: {count}
|
||||
- Code Quality: {count}
|
||||
- Architecture: {count}
|
||||
|
||||
All Tests: PASSING
|
||||
Lint: CLEAN
|
||||
Build: SUCCESS
|
||||
|
||||
Review Report: {report_path}
|
||||
```
|
||||
|
||||
**Interactive Mode Menu:**
|
||||
```
|
||||
[C] Continue to Completion
|
||||
[R] Run another review pass
|
||||
[T] Run tests again
|
||||
[H] Halt pipeline
|
||||
```
|
||||
|
||||
**Batch Mode:** Auto-continue if minimum issues found and fixed
|
||||
|
||||
## QUALITY GATE
|
||||
|
||||
Before proceeding:
|
||||
- [ ] Minimum 3 issues found and fixed
|
||||
- [ ] All categories reviewed
|
||||
- [ ] All tests still passing
|
||||
- [ ] Lint clean
|
||||
- [ ] Build succeeds
|
||||
- [ ] Review report created
|
||||
|
||||
## MCP TOOLS AVAILABLE
|
||||
|
||||
- `mcp__supabase__get_advisors` - Security/performance checks
|
||||
- `mcp__supabase__execute_sql` - Query verification
|
||||
|
||||
## CRITICAL STEP COMPLETION
|
||||
|
||||
**ONLY WHEN** [minimum 3 issues found AND all fixed AND tests pass],
|
||||
load and execute `{nextStepFile}` for story completion.
|
||||
|
||||
---
|
||||
|
||||
## SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS
|
||||
- Found and fixed 3-10 issues
|
||||
- All categories reviewed
|
||||
- Tests still passing after fixes
|
||||
- Review report complete
|
||||
- No "looks good" shortcuts
|
||||
|
||||
### ❌ FAILURE
|
||||
- Saying "looks good" or "no issues found"
|
||||
- Finding fewer than 3 issues
|
||||
- Not fixing issues found
|
||||
- Tests failing after fixes
|
||||
- Skipping review categories
|
||||
|
|
@ -1,327 +0,0 @@
|
|||
---
|
||||
name: 'step-08-review-analysis'
|
||||
description: 'Intelligently analyze code review findings - distinguish real issues from gold plating'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-08-review-analysis.md'
|
||||
stateFile: '{state_file}'
|
||||
storyFile: '{story_file}'
|
||||
reviewReport: '{sprint_artifacts}/review-{story_id}.md'
|
||||
|
||||
# Next step
|
||||
nextStep: '{workflow_path}/steps/step-09-fix-issues.md'
|
||||
---
|
||||
|
||||
# Step 8: Review Analysis
|
||||
|
||||
**Goal:** Critically analyze code review findings to distinguish **real problems** from **gold plating**, **false positives**, and **overzealous suggestions**.
|
||||
|
||||
## The Problem
|
||||
|
||||
AI code reviewers (and human reviewers) sometimes:
|
||||
- 🎨 **Gold plate**: Suggest unnecessary perfectionism
|
||||
- 🔍 **Overreact**: Flag non-issues to appear thorough
|
||||
- 📚 **Over-engineer**: Suggest abstractions for simple cases
|
||||
- ⚖️ **Misjudge context**: Apply rules without understanding tradeoffs
|
||||
|
||||
## The Solution
|
||||
|
||||
**Critical thinking filter**: Evaluate each finding objectively.
|
||||
|
||||
---
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Load Review Report
|
||||
|
||||
```bash
|
||||
# Read the code review report
|
||||
review_report="{reviewReport}"
|
||||
test -f "$review_report" || (echo "⚠️ No review report found" && exit 0)
|
||||
```
|
||||
|
||||
Parse findings by severity:
|
||||
- 🔴 CRITICAL
|
||||
- 🟠 HIGH
|
||||
- 🟡 MEDIUM
|
||||
- 🔵 LOW
|
||||
- ℹ️ INFO
|
||||
|
||||
### 2. Categorize Each Finding
|
||||
|
||||
For EACH finding, ask these questions:
|
||||
|
||||
#### Question 1: Is this a REAL problem?
|
||||
|
||||
```
|
||||
Real Problem Indicators:
|
||||
✅ Would cause bugs or incorrect behavior
|
||||
✅ Would cause security vulnerabilities
|
||||
✅ Would cause performance issues in production
|
||||
✅ Would make future maintenance significantly harder
|
||||
✅ Violates team/project standards documented in codebase
|
||||
|
||||
NOT Real Problems:
|
||||
❌ "Could be more elegant" (subjective style preference)
|
||||
❌ "Consider adding abstraction" (YAGNI - you aren't gonna need it)
|
||||
❌ "This pattern is not ideal" (works fine, alternative is marginal)
|
||||
❌ "Add comprehensive error handling" (for impossible error cases)
|
||||
❌ "Add logging everywhere" (log signal, not noise)
|
||||
```
|
||||
|
||||
#### Question 2: Does this finding understand CONTEXT?
|
||||
|
||||
```
|
||||
Context Considerations:
|
||||
📋 Story scope: Does fixing this exceed story requirements?
|
||||
🎯 Project maturity: Is this MVP, beta, or production-hardened?
|
||||
⚡ Performance criticality: Is this a hot path or cold path?
|
||||
👥 Team standards: Does team actually follow this pattern?
|
||||
📊 Data scale: Does this handle actual expected volume?
|
||||
|
||||
Example of MISSING context:
|
||||
Finding: "Add database indexing for better performance"
|
||||
Reality: Table has 100 rows total, query runs once per day
|
||||
Verdict: ❌ REJECT - Premature optimization
|
||||
```
|
||||
|
||||
#### Question 3: Is this ACTIONABLE?
|
||||
|
||||
```
|
||||
Actionable Findings:
|
||||
✅ Specific file, line number, exact issue
|
||||
✅ Clear explanation of problem
|
||||
✅ Concrete recommendation for fix
|
||||
✅ Can be fixed in reasonable time
|
||||
|
||||
NOT Actionable:
|
||||
❌ Vague: "Code quality could be improved"
|
||||
❌ No location: "Some error handling is missing"
|
||||
❌ No recommendation: "This might cause issues"
|
||||
❌ Massive scope: "Refactor entire architecture"
|
||||
```
|
||||
|
||||
### 3. Classification Decision Tree
|
||||
|
||||
For each finding, classify as:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Finding Classification Decision Tree │
|
||||
└─────────────────────────────────────────┘
|
||||
|
||||
Is it a CRITICAL security/correctness issue?
|
||||
├─ YES → 🔴 MUST FIX
|
||||
└─ NO ↓
|
||||
|
||||
Does it violate documented project standards?
|
||||
├─ YES → 🟠 SHOULD FIX
|
||||
└─ NO ↓
|
||||
|
||||
Would it prevent future maintenance?
|
||||
├─ YES → 🟡 CONSIDER FIX (if in scope)
|
||||
└─ NO ↓
|
||||
|
||||
Is it gold plating / over-engineering?
|
||||
├─ YES → ⚪ REJECT (document why)
|
||||
└─ NO ↓
|
||||
|
||||
Is it a style/opinion without real impact?
|
||||
├─ YES → ⚪ REJECT (document why)
|
||||
└─ NO → 🔵 OPTIONAL (tech debt backlog)
|
||||
```
|
||||
|
||||
### 4. Create Classification Report
|
||||
|
||||
```markdown
|
||||
# Code Review Analysis: Story {story_id}
|
||||
|
||||
## Review Metadata
|
||||
- Reviewer: {reviewer_type} (Adversarial / Multi-Agent)
|
||||
- Total Findings: {total_findings}
|
||||
- Review Date: {date}
|
||||
|
||||
## Classification Results
|
||||
|
||||
### 🔴 MUST FIX (Critical - Blocking)
|
||||
Total: {must_fix_count}
|
||||
|
||||
1. **[SECURITY] Unvalidated user input in API endpoint**
|
||||
- File: `src/api/users.ts:45`
|
||||
- Issue: POST /api/users accepts unvalidated input, SQL injection risk
|
||||
- Why this is real: Security vulnerability, could lead to data breach
|
||||
- Action: Add input validation with Zod schema
|
||||
- Estimated effort: 30 min
|
||||
|
||||
2. **[CORRECTNESS] Race condition in state update**
|
||||
- File: `src/components/UserForm.tsx:67`
|
||||
- Issue: Multiple async setState calls without proper sequencing
|
||||
- Why this is real: Causes intermittent bugs in production
|
||||
- Action: Use functional setState or useReducer
|
||||
- Estimated effort: 20 min
|
||||
|
||||
### 🟠 SHOULD FIX (High Priority)
|
||||
Total: {should_fix_count}
|
||||
|
||||
3. **[STANDARDS] Missing error handling per team convention**
|
||||
- File: `src/services/userService.ts:34`
|
||||
- Issue: API calls lack try-catch per documented standards
|
||||
- Why this matters: Team standard in CONTRIBUTING.md section 3.2
|
||||
- Action: Wrap in try-catch, log errors
|
||||
- Estimated effort: 15 min
|
||||
|
||||
### 🟡 CONSIDER FIX (Medium - If in scope)
|
||||
Total: {consider_count}
|
||||
|
||||
4. **[MAINTAINABILITY] Complex nested conditional**
|
||||
- File: `src/utils/validation.ts:23`
|
||||
- Issue: 4-level nested if-else hard to read
|
||||
- Why this matters: Could confuse future maintainers
|
||||
- Action: Extract to guard clauses or lookup table
|
||||
- Estimated effort: 45 min
|
||||
- **Scope consideration**: Nice to have, but not blocking
|
||||
|
||||
### ⚪ REJECTED (Gold Plating / False Positives)
|
||||
Total: {rejected_count}
|
||||
|
||||
5. **[REJECTED] "Add comprehensive logging to all functions"**
|
||||
- Reason: Gold plating - logging should be signal, not noise
|
||||
- Context: These are simple utility functions, no debugging issues
|
||||
- Verdict: REJECT - Would create log spam
|
||||
|
||||
6. **[REJECTED] "Extract component for reusability"**
|
||||
- Reason: YAGNI - component used only once, no reuse planned
|
||||
- Context: Story scope is single-use dashboard widget
|
||||
- Verdict: REJECT - Premature abstraction
|
||||
|
||||
7. **[REJECTED] "Add database connection pooling"**
|
||||
- Reason: Premature optimization - current load is minimal
|
||||
- Context: App has 10 concurrent users max, no performance issues
|
||||
- Verdict: REJECT - Optimize when needed, not speculatively
|
||||
|
||||
8. **[REJECTED] "Consider microservices architecture"**
|
||||
- Reason: Out of scope - architectural decision beyond story
|
||||
- Context: Story is adding a single API endpoint
|
||||
- Verdict: REJECT - Massive overreach
|
||||
|
||||
### 🔵 OPTIONAL (Tech Debt Backlog)
|
||||
Total: {optional_count}
|
||||
|
||||
9. **[STYLE] Inconsistent naming convention**
|
||||
- File: `src/utils/helpers.ts:12`
|
||||
- Issue: camelCase vs snake_case mixing
|
||||
- Why low priority: Works fine, linter doesn't flag it
|
||||
- Action: Standardize to camelCase when touching this file later
|
||||
- Create tech debt ticket: TD-{number}
|
||||
|
||||
## Summary
|
||||
|
||||
**Action Plan:**
|
||||
- 🔴 MUST FIX: {must_fix_count} issues (blocking)
|
||||
- 🟠 SHOULD FIX: {should_fix_count} issues (high priority)
|
||||
- 🟡 CONSIDER: {consider_count} issues (if time permits)
|
||||
- ⚪ REJECTED: {rejected_count} findings (documented why)
|
||||
- 🔵 OPTIONAL: {optional_count} items (tech debt backlog)
|
||||
|
||||
**Estimated fix time:** {total_fix_time_hours} hours
|
||||
|
||||
**Proceed to:** Step 9 - Fix Issues (implement MUST FIX + SHOULD FIX items)
|
||||
```
|
||||
|
||||
### 5. Document Rejections
|
||||
|
||||
**CRITICAL:** When rejecting findings, ALWAYS document WHY:
|
||||
|
||||
```markdown
|
||||
## Rejected Findings - Rationale
|
||||
|
||||
### Finding: "Add caching layer for all API calls"
|
||||
**Rejected because:**
|
||||
- ⚡ Premature optimization - no performance issues detected
|
||||
- 📊 Traffic analysis shows <100 requests/day
|
||||
- 🎯 Story scope is feature addition, not optimization
|
||||
- 💰 Cost: 2 days implementation, 0 proven benefit
|
||||
- 📝 Decision: Monitor first, optimize if needed
|
||||
|
||||
### Finding: "Refactor to use dependency injection"
|
||||
**Rejected because:**
|
||||
- 🏗️ Over-engineering - current approach works fine
|
||||
- 📏 Codebase size doesn't justify DI complexity
|
||||
- 👥 Team unfamiliar with DI patterns
|
||||
- 🎯 Story scope: simple feature, not architecture overhaul
|
||||
- 📝 Decision: Keep it simple, revisit if codebase grows
|
||||
|
||||
### Finding: "Add comprehensive JSDoc to all functions"
|
||||
**Rejected because:**
|
||||
- 📚 Gold plating - TypeScript types provide documentation
|
||||
- ⏱️ Time sink - 4+ hours for marginal benefit
|
||||
- 🎯 Team standard: JSDoc only for public APIs
|
||||
- 📝 Decision: Follow team convention, not reviewer preference
|
||||
```
|
||||
|
||||
### 6. Update State
|
||||
|
||||
```yaml
|
||||
# Update {stateFile}
|
||||
current_step: 8
|
||||
review_analysis:
|
||||
must_fix: {must_fix_count}
|
||||
should_fix: {should_fix_count}
|
||||
consider: {consider_count}
|
||||
rejected: {rejected_count}
|
||||
optional: {optional_count}
|
||||
estimated_fix_time: "{total_fix_time_hours}h"
|
||||
rejections_documented: true
|
||||
analysis_complete: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Critical Thinking Framework
|
||||
|
||||
Use this framework to evaluate EVERY finding:
|
||||
|
||||
### The "So What?" Test
|
||||
- **Ask:** "So what if we don't fix this?"
|
||||
- **If answer is:** "Nothing bad happens" → REJECT
|
||||
- **If answer is:** "Production breaks" → MUST FIX
|
||||
|
||||
### The "YAGNI" Test (You Aren't Gonna Need It)
|
||||
- **Ask:** "Do we need this NOW for current requirements?"
|
||||
- **If answer is:** "Maybe someday" → REJECT
|
||||
- **If answer is:** "Yes, breaks without it" → FIX
|
||||
|
||||
### The "Scope" Test
|
||||
- **Ask:** "Is this within the story's scope?"
|
||||
- **If answer is:** "No, requires new story" → REJECT (or create new story)
|
||||
- **If answer is:** "Yes, part of ACs" → FIX
|
||||
|
||||
### The "Team Standard" Test
|
||||
- **Ask:** "Does our team actually do this?"
|
||||
- **If answer is:** "No, reviewer's opinion" → REJECT
|
||||
- **If answer is:** "Yes, in CONTRIBUTING.md" → FIX
|
||||
|
||||
---
|
||||
|
||||
## Common Rejection Patterns
|
||||
|
||||
Learn to recognize these patterns:
|
||||
|
||||
1. **"Consider adding..."** - Usually gold plating unless critical
|
||||
2. **"It would be better if..."** - Subjective opinion, often rejectable
|
||||
3. **"For maximum performance..."** - Premature optimization
|
||||
4. **"To follow best practices..."** - Check if team actually follows it
|
||||
5. **"This could be refactored..."** - Does it need refactoring NOW?
|
||||
6. **"Add comprehensive..."** - Comprehensive = overkill most of the time
|
||||
7. **"Future-proof by..."** - Can't predict future, solve current problems
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
Proceed to **Step 9: Fix Issues** ({nextStep})
|
||||
|
||||
Implement MUST FIX and SHOULD FIX items. Skip rejected items (already documented why).
|
||||
|
|
@ -1,371 +0,0 @@
|
|||
---
|
||||
name: 'step-09-fix-issues'
|
||||
description: 'Fix MUST FIX and SHOULD FIX issues from review analysis'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-09-fix-issues.md'
|
||||
stateFile: '{state_file}'
|
||||
storyFile: '{story_file}'
|
||||
reviewAnalysis: '{sprint_artifacts}/review-analysis-{story_id}.md'
|
||||
|
||||
# Next step
|
||||
nextStep: '{workflow_path}/steps/step-10-complete.md'
|
||||
---
|
||||
|
||||
# Step 9: Fix Issues
|
||||
|
||||
**Goal:** Implement fixes for MUST FIX and SHOULD FIX items identified in review analysis. Skip rejected items (gold plating already documented).
|
||||
|
||||
## Principles
|
||||
|
||||
- **Fix real problems only**: MUST FIX and SHOULD FIX categories
|
||||
- **Skip rejected items**: Already documented why in step 8
|
||||
- **Verify each fix**: Run tests after each fix
|
||||
- **Commit incrementally**: One fix per commit for traceability
|
||||
|
||||
---
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Load Review Analysis
|
||||
|
||||
```bash
|
||||
# Read review analysis from step 8
|
||||
review_analysis="{reviewAnalysis}"
|
||||
test -f "$review_analysis" || (echo "⚠️ No review analysis found - skipping fix step" && exit 0)
|
||||
```
|
||||
|
||||
Parse the analysis report to extract:
|
||||
- MUST FIX items (count: {must_fix_count})
|
||||
- SHOULD FIX items (count: {should_fix_count})
|
||||
- Rejected items (for reference - DO NOT fix these)
|
||||
|
||||
### 2. Fix MUST FIX Items (Critical - Blocking)
|
||||
|
||||
**These are MANDATORY fixes - cannot proceed without fixing.**
|
||||
|
||||
For each MUST FIX issue:
|
||||
|
||||
```
|
||||
🔴 Issue #{number}: {title}
|
||||
File: {file}:{line}
|
||||
Severity: CRITICAL
|
||||
Category: {category} (SECURITY | CORRECTNESS | etc.)
|
||||
|
||||
Problem:
|
||||
{description}
|
||||
|
||||
Fix Required:
|
||||
{recommendation}
|
||||
|
||||
Estimated Time: {estimate}
|
||||
```
|
||||
|
||||
**Fix Process:**
|
||||
1. Read the file at the specified location
|
||||
2. Understand the issue context
|
||||
3. Implement the recommended fix
|
||||
4. Add test if issue was caught by testing gap
|
||||
5. Run tests to verify fix works
|
||||
6. Commit the fix
|
||||
|
||||
```bash
|
||||
# Example fix commit
|
||||
git add {file}
|
||||
git commit -m "fix(story-{story_id}): {issue_title}
|
||||
|
||||
{category}: {brief_description}
|
||||
|
||||
- Issue: {problem_summary}
|
||||
- Fix: {fix_summary}
|
||||
- Testing: {test_verification}
|
||||
|
||||
Addresses review finding #{number} (MUST FIX)
|
||||
Related to story {story_id}"
|
||||
```
|
||||
|
||||
**Quality Check After Each Fix:**
|
||||
```bash
|
||||
# Verify fix doesn't break anything
|
||||
npm test
|
||||
|
||||
# If tests fail:
|
||||
# 1. Fix the test or the code
|
||||
# 2. Re-run tests
|
||||
# 3. Only commit when tests pass
|
||||
```
|
||||
|
||||
### 3. Fix SHOULD FIX Items (High Priority)
|
||||
|
||||
**These are important for code quality and team standards.**
|
||||
|
||||
For each SHOULD FIX issue:
|
||||
|
||||
```
|
||||
🟠 Issue #{number}: {title}
|
||||
File: {file}:{line}
|
||||
Severity: HIGH
|
||||
Category: {category} (STANDARDS | MAINTAINABILITY | etc.)
|
||||
|
||||
Problem:
|
||||
{description}
|
||||
|
||||
Fix Required:
|
||||
{recommendation}
|
||||
|
||||
Estimated Time: {estimate}
|
||||
```
|
||||
|
||||
Same fix process as MUST FIX items, but with SHOULD FIX label in commit.
|
||||
|
||||
### 4. Consider CONSIDER Items (If Time/Scope Permits)
|
||||
|
||||
For CONSIDER items, evaluate:
|
||||
|
||||
```
|
||||
🟡 Issue #{number}: {title}
|
||||
File: {file}:{line}
|
||||
Severity: MEDIUM
|
||||
|
||||
Scope Check:
|
||||
- Is this within story scope? {yes/no}
|
||||
- Time remaining in story? {estimate}
|
||||
- Would this improve maintainability? {yes/no}
|
||||
|
||||
Decision:
|
||||
[ ] FIX NOW - In scope and quick
|
||||
[ ] CREATE TECH DEBT TICKET - Out of scope
|
||||
[ ] SKIP - Not worth the effort
|
||||
```
|
||||
|
||||
If fixing:
|
||||
- Same process as SHOULD FIX
|
||||
- Label as "refactor" or "improve" instead of "fix"
|
||||
|
||||
If creating tech debt ticket:
|
||||
```markdown
|
||||
# Tech Debt: {title}
|
||||
|
||||
**Source:** Code review finding from story {story_id}
|
||||
**Priority:** Medium
|
||||
**Estimated Effort:** {estimate}
|
||||
|
||||
**Description:**
|
||||
{issue_description}
|
||||
|
||||
**Recommendation:**
|
||||
{recommendation}
|
||||
|
||||
**Why Deferred:**
|
||||
{reason} (e.g., out of scope, time constraints, etc.)
|
||||
```
|
||||
|
||||
### 5. Skip REJECTED Items
|
||||
|
||||
**DO NOT fix rejected items.**
|
||||
|
||||
Display confirmation:
|
||||
```
|
||||
⚪ REJECTED ITEMS (Skipped):
|
||||
Total: {rejected_count}
|
||||
|
||||
These findings were analyzed and rejected in step 8:
|
||||
- #{number}: {title} - {rejection_reason}
|
||||
- #{number}: {title} - {rejection_reason}
|
||||
|
||||
✅ Correctly skipped (documented as gold plating/false positives)
|
||||
```
|
||||
|
||||
### 6. Skip OPTIONAL Items (Tech Debt Backlog)
|
||||
|
||||
For OPTIONAL items:
|
||||
- Create tech debt tickets (if not already created)
|
||||
- Do NOT implement now
|
||||
- Add to project backlog
|
||||
|
||||
### 7. Verify All Fixes Work Together
|
||||
|
||||
After all fixes applied, run complete quality check:
|
||||
|
||||
```bash
|
||||
echo "🔍 Verifying all fixes together..."
|
||||
|
||||
# Run full test suite
|
||||
npm test
|
||||
|
||||
# Run type checker
|
||||
npx tsc --noEmit
|
||||
|
||||
# Run linter
|
||||
npm run lint
|
||||
|
||||
# Check test coverage
|
||||
npm run test:coverage
|
||||
```
|
||||
|
||||
**If any check fails:**
|
||||
```
|
||||
❌ Quality checks failed after fixes!
|
||||
|
||||
This means fixes introduced new issues.
|
||||
|
||||
Action required:
|
||||
1. Identify which fix broke which test
|
||||
2. Fix the issue
|
||||
3. Re-run quality checks
|
||||
4. Repeat until all checks pass
|
||||
|
||||
DO NOT PROCEED until all quality checks pass.
|
||||
```
|
||||
|
||||
### 8. Summary Report
|
||||
|
||||
```markdown
|
||||
# Fix Summary: Story {story_id}
|
||||
|
||||
## Issues Addressed
|
||||
|
||||
### 🔴 MUST FIX: {must_fix_count} issues
|
||||
- [x] Issue #1: {title} - FIXED ✅
|
||||
- [x] Issue #2: {title} - FIXED ✅
|
||||
|
||||
### 🟠 SHOULD FIX: {should_fix_count} issues
|
||||
- [x] Issue #3: {title} - FIXED ✅
|
||||
- [x] Issue #4: {title} - FIXED ✅
|
||||
|
||||
### 🟡 CONSIDER: {consider_fixed_count}/{consider_count} issues
|
||||
- [x] Issue #5: {title} - FIXED ✅
|
||||
- [ ] Issue #6: {title} - Tech debt ticket created
|
||||
|
||||
### ⚪ REJECTED: {rejected_count} items
|
||||
- Correctly skipped (documented in review analysis)
|
||||
|
||||
### 🔵 OPTIONAL: {optional_count} items
|
||||
- Tech debt tickets created
|
||||
- Added to backlog
|
||||
|
||||
## Commits Made
|
||||
|
||||
Total commits: {commit_count}
|
||||
- MUST FIX commits: {must_fix_commits}
|
||||
- SHOULD FIX commits: {should_fix_commits}
|
||||
- Other commits: {other_commits}
|
||||
|
||||
## Final Quality Check
|
||||
|
||||
✅ All tests passing: {test_count} tests
|
||||
✅ Type check: No errors
|
||||
✅ Linter: No violations
|
||||
✅ Coverage: {coverage}%
|
||||
|
||||
## Time Spent
|
||||
|
||||
Estimated: {estimated_time}
|
||||
Actual: {actual_time}
|
||||
Efficiency: {efficiency_percentage}%
|
||||
```
|
||||
|
||||
### 9. Update State
|
||||
|
||||
```yaml
|
||||
# Update {stateFile}
|
||||
current_step: 9
|
||||
issues_fixed:
|
||||
must_fix: {must_fix_count}
|
||||
should_fix: {should_fix_count}
|
||||
consider: {consider_fixed_count}
|
||||
rejected: {rejected_count} (skipped - documented)
|
||||
optional: {optional_count} (tech debt created)
|
||||
fixes_verified: true
|
||||
all_quality_checks_passed: true
|
||||
ready_for_completion: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**BLOCKING:** Cannot proceed to step 10 until:
|
||||
|
||||
✅ **All MUST FIX issues resolved**
|
||||
✅ **All SHOULD FIX issues resolved**
|
||||
✅ **All tests passing**
|
||||
✅ **Type check passing**
|
||||
✅ **Linter passing**
|
||||
✅ **Coverage maintained or improved**
|
||||
|
||||
If any gate fails:
|
||||
1. Fix the issue
|
||||
2. Re-run quality checks
|
||||
3. Repeat until ALL PASS
|
||||
4. THEN proceed to next step
|
||||
|
||||
---
|
||||
|
||||
## Skip Conditions
|
||||
|
||||
This step can be skipped only if:
|
||||
- Review analysis (step 8) found zero issues requiring fixes
|
||||
- All findings were REJECTED or OPTIONAL
|
||||
|
||||
Display when skipping:
|
||||
```
|
||||
✅ No fixes required!
|
||||
|
||||
Review analysis found no critical or high-priority issues.
|
||||
All findings were either rejected as gold plating or marked as optional tech debt.
|
||||
|
||||
Proceeding to completion...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
**If a fix causes test failures:**
|
||||
```
|
||||
⚠️ Fix introduced regression!
|
||||
|
||||
Test failures after applying fix for: {issue_title}
|
||||
|
||||
Failed tests:
|
||||
- {test_name_1}
|
||||
- {test_name_2}
|
||||
|
||||
Action:
|
||||
1. Review the fix - did it break existing functionality?
|
||||
2. Either fix the implementation or update the tests
|
||||
3. Re-run tests
|
||||
4. Only proceed when tests pass
|
||||
```
|
||||
|
||||
**If stuck on a fix:**
|
||||
```
|
||||
⚠️ Fix is more complex than estimated
|
||||
|
||||
Issue: {issue_title}
|
||||
Estimated: {estimate}
|
||||
Actual time spent: {actual} (exceeded estimate)
|
||||
|
||||
Options:
|
||||
[C] Continue - Keep working on this fix
|
||||
[D] Defer - Create tech debt ticket and continue
|
||||
[H] Help - Request human intervention
|
||||
|
||||
If deferring:
|
||||
- Document current progress
|
||||
- Create detailed tech debt ticket
|
||||
- Note blocking issues
|
||||
- Continue with other fixes
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
Proceed to **Step 10: Complete + Update Status** ({nextStep})
|
||||
|
||||
All issues fixed, all quality checks passed. Ready to mark story as done!
|
||||
|
|
@ -1,332 +0,0 @@
|
|||
---
|
||||
name: 'step-10-complete'
|
||||
description: 'Complete story with MANDATORY sprint-status.yaml update and verification'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-10-complete.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-11-summary.md'
|
||||
stateFile: '{state_file}'
|
||||
sprint_status: '{sprint_artifacts}/sprint-status.yaml'
|
||||
|
||||
# Role Switch
|
||||
role: sm
|
||||
---
|
||||
|
||||
# Step 10: Complete Story (v1.5.0: Mandatory Status Update)
|
||||
|
||||
## ROLE SWITCH
|
||||
|
||||
**Switching to SM (Scrum Master) perspective.**
|
||||
|
||||
You are now completing the story and preparing changes for git commit.
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Complete the story with safety checks and MANDATORY status updates:
|
||||
1. Extract file list from story
|
||||
2. Stage only story-related files
|
||||
3. Generate commit message
|
||||
4. Create commit
|
||||
5. Push to remote (if configured)
|
||||
6. Update story file status to "done"
|
||||
7. **UPDATE sprint-status.yaml (MANDATORY - NO EXCEPTIONS)**
|
||||
8. **VERIFY sprint-status.yaml update persisted (CRITICAL)**
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
### Completion Principles
|
||||
|
||||
- **TARGETED COMMIT** - Only files from this story's File List
|
||||
- **SAFETY CHECKS** - Verify no secrets, proper commit message
|
||||
- **STATUS UPDATE** - Mark story as "review" (ready for human review)
|
||||
- **NO FORCE PUSH** - Normal push only
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Extract File List from Story
|
||||
|
||||
Read story file and find "File List" section:
|
||||
|
||||
```markdown
|
||||
## File List
|
||||
- src/components/UserProfile.tsx
|
||||
- src/actions/updateUser.ts
|
||||
- tests/user.test.ts
|
||||
```
|
||||
|
||||
Extract all file paths.
|
||||
Add story file itself to the list.
|
||||
|
||||
Store as `{story_files}` (space-separated list).
|
||||
|
||||
### 2. Verify Files Exist
|
||||
|
||||
For each file in list:
|
||||
```bash
|
||||
test -f "{file}" && echo "✓ {file}" || echo "⚠️ {file} not found"
|
||||
```
|
||||
|
||||
### 3. Check Git Status
|
||||
|
||||
```bash
|
||||
git status --short
|
||||
```
|
||||
|
||||
Display files changed.
|
||||
|
||||
### 4. Stage Story Files Only
|
||||
|
||||
```bash
|
||||
git add {story_files}
|
||||
```
|
||||
|
||||
**This ensures parallel-safe commits** (other agents won't conflict).
|
||||
|
||||
### 5. Generate Commit Message
|
||||
|
||||
Based on story title and changes:
|
||||
|
||||
```
|
||||
feat(story-{story_id}): {story_title}
|
||||
|
||||
Implemented:
|
||||
{list acceptance criteria or key changes}
|
||||
|
||||
Files changed:
|
||||
- {file_1}
|
||||
- {file_2}
|
||||
|
||||
Story: {story_file}
|
||||
```
|
||||
|
||||
### 6. Create Commit (With Queue for Parallel Mode)
|
||||
|
||||
**Check execution mode:**
|
||||
```
|
||||
If mode == "batch" AND parallel execution:
|
||||
use_commit_queue = true
|
||||
Else:
|
||||
use_commit_queue = false
|
||||
```
|
||||
|
||||
**If use_commit_queue == true:**
|
||||
|
||||
```bash
|
||||
# Commit queue with file-based locking
|
||||
lock_file=".git/bmad-commit.lock"
|
||||
max_wait=300 # 5 minutes
|
||||
wait_time=0
|
||||
retry_delay=1
|
||||
|
||||
while [ $wait_time -lt $max_wait ]; do
|
||||
if [ ! -f "$lock_file" ]; then
|
||||
# Acquire lock
|
||||
echo "locked_by: {{story_key}}
|
||||
locked_at: $(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
worker_id: {{worker_id}}
|
||||
pid: $$" > "$lock_file"
|
||||
|
||||
echo "🔒 Commit lock acquired for {{story_key}}"
|
||||
|
||||
# Execute commit
|
||||
git commit -m "$(cat <<'EOF'
|
||||
{commit_message}
|
||||
EOF
|
||||
)"
|
||||
|
||||
commit_result=$?
|
||||
|
||||
# Release lock
|
||||
rm -f "$lock_file"
|
||||
echo "🔓 Lock released"
|
||||
|
||||
if [ $commit_result -eq 0 ]; then
|
||||
git log -1 --oneline
|
||||
break
|
||||
else
|
||||
echo "❌ Commit failed"
|
||||
exit $commit_result
|
||||
fi
|
||||
else
|
||||
# Lock exists, check if stale
|
||||
lock_age=$(( $(date +%s) - $(date -r "$lock_file" +%s) ))
|
||||
if [ $lock_age -gt 300 ]; then
|
||||
echo "⚠️ Stale lock detected (${lock_age}s old) - removing"
|
||||
rm -f "$lock_file"
|
||||
continue
|
||||
fi
|
||||
|
||||
locked_by=$(grep "locked_by:" "$lock_file" | cut -d' ' -f2-)
|
||||
echo "⏳ Waiting for commit lock... (held by $locked_by, ${wait_time}s elapsed)"
|
||||
sleep $retry_delay
|
||||
wait_time=$(( wait_time + retry_delay ))
|
||||
retry_delay=$(( retry_delay < 30 ? retry_delay * 3 / 2 : 30 )) # Exponential backoff, max 30s
|
||||
fi
|
||||
done
|
||||
|
||||
if [ $wait_time -ge $max_wait ]; then
|
||||
echo "❌ TIMEOUT: Could not acquire commit lock after 5 minutes"
|
||||
echo "Lock holder: $(cat $lock_file)"
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
**If use_commit_queue == false (sequential mode):**
|
||||
|
||||
```bash
|
||||
# Direct commit (no queue needed)
|
||||
git commit -m "$(cat <<'EOF'
|
||||
{commit_message}
|
||||
EOF
|
||||
)"
|
||||
|
||||
git log -1 --oneline
|
||||
```
|
||||
|
||||
### 7. Push to Remote (Optional)
|
||||
|
||||
**If configured to push:**
|
||||
```bash
|
||||
git push
|
||||
```
|
||||
|
||||
**If push succeeds:**
|
||||
```
|
||||
✅ Changes pushed to remote
|
||||
```
|
||||
|
||||
**If push fails (e.g., need to pull first):**
|
||||
```
|
||||
⚠️ Push failed - changes committed locally
|
||||
You can push manually when ready
|
||||
```
|
||||
|
||||
### 8. Update Story Status (File + Sprint-Status)
|
||||
|
||||
**CRITICAL: Two-location update with verification**
|
||||
|
||||
#### 8.1: Update Story File
|
||||
|
||||
Update story file frontmatter:
|
||||
```yaml
|
||||
status: done # Story completed (v1.5.0: changed from "review" to "done")
|
||||
completed_date: {date}
|
||||
```
|
||||
|
||||
#### 8.2: Update sprint-status.yaml (MANDATORY - NO EXCEPTIONS)
|
||||
|
||||
**This is CRITICAL and CANNOT be skipped.**
|
||||
|
||||
```bash
|
||||
# Read current sprint-status.yaml
|
||||
sprint_status_file="{sprint_artifacts}/sprint-status.yaml"
|
||||
story_key="{story_id}"
|
||||
|
||||
# Update development_status section
|
||||
# Change status from whatever it was to "done"
|
||||
|
||||
development_status:
|
||||
{story_id}: done # ✅ COMPLETED: {story_title}
|
||||
```
|
||||
|
||||
**Implementation:**
|
||||
```bash
|
||||
# Read current status
|
||||
current_status=$(grep "^\s*{story_id}:" "$sprint_status_file" | awk '{print $2}')
|
||||
|
||||
# Update to done
|
||||
sed -i'' "s/^\s*{story_id}:.*/ {story_id}: done # ✅ COMPLETED: {story_title}/" "$sprint_status_file"
|
||||
|
||||
echo "✅ Updated sprint-status.yaml: {story_id} → done"
|
||||
```
|
||||
|
||||
#### 8.3: Verify Update Persisted (CRITICAL)
|
||||
|
||||
```bash
|
||||
# Re-read sprint-status.yaml to verify change
|
||||
verification=$(grep "^\s*{story_id}:" "$sprint_status_file" | awk '{print $2}')
|
||||
|
||||
if [ "$verification" != "done" ]; then
|
||||
echo "❌ CRITICAL: sprint-status.yaml update FAILED!"
|
||||
echo "Expected: done"
|
||||
echo "Got: $verification"
|
||||
echo ""
|
||||
echo "HALTING pipeline - status update is MANDATORY"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "✅ Verified: sprint-status.yaml correctly updated"
|
||||
```
|
||||
|
||||
**NO EXCEPTIONS:** If verification fails, pipeline MUST HALT.
|
||||
|
||||
### 9. Update Pipeline State
|
||||
|
||||
Update state file:
|
||||
- Add `6` to `stepsCompleted`
|
||||
- Set `lastStep: 6`
|
||||
- Set `steps.step-06-complete.status: completed`
|
||||
- Record commit hash
|
||||
|
||||
### 10. Display Summary
|
||||
|
||||
```
|
||||
Story Completion
|
||||
|
||||
✅ Files staged: {file_count}
|
||||
✅ Commit created: {commit_hash}
|
||||
✅ Status updated: review
|
||||
{if pushed}✅ Pushed to remote{endif}
|
||||
|
||||
Commit: {commit_hash_short}
|
||||
Message: {commit_title}
|
||||
|
||||
Ready for Summary Generation
|
||||
```
|
||||
|
||||
**Interactive Mode Menu:**
|
||||
```
|
||||
[C] Continue to Summary
|
||||
[P] Push to remote (if not done)
|
||||
[H] Halt pipeline
|
||||
```
|
||||
|
||||
**Batch Mode:** Auto-continue
|
||||
|
||||
## QUALITY GATE
|
||||
|
||||
Before proceeding (BLOCKING - ALL must pass):
|
||||
- [ ] Targeted files staged (from File List)
|
||||
- [ ] Commit message generated
|
||||
- [ ] Commit created successfully
|
||||
- [ ] Story file status updated to "done"
|
||||
- [ ] **sprint-status.yaml updated to "done" (MANDATORY)**
|
||||
- [ ] **sprint-status.yaml update VERIFIED (CRITICAL)**
|
||||
|
||||
**If ANY check fails, pipeline MUST HALT.**
|
||||
|
||||
## CRITICAL STEP COMPLETION
|
||||
|
||||
**ONLY WHEN** [commit created],
|
||||
load and execute `{nextStepFile}` for summary generation.
|
||||
|
||||
---
|
||||
|
||||
## SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS
|
||||
- Only story files committed
|
||||
- Commit message is clear
|
||||
- Status updated properly
|
||||
- No secrets committed
|
||||
- Push succeeded or skipped safely
|
||||
|
||||
### ❌ FAILURE
|
||||
- Committing unrelated files
|
||||
- Generic commit message
|
||||
- Not updating story status
|
||||
- Pushing secrets
|
||||
- Force pushing
|
||||
|
|
@ -1,279 +0,0 @@
|
|||
---
|
||||
name: 'step-06a-queue-commit'
|
||||
description: 'Queued git commit with file-based locking for parallel safety'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-06a-queue-commit.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-07-summary.md'
|
||||
|
||||
# Role
|
||||
role: dev
|
||||
requires_fresh_context: false
|
||||
---
|
||||
|
||||
# Step 6a: Queued Git Commit (Parallel-Safe)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Execute git commit with file-based locking to prevent concurrent commit conflicts in parallel batch mode.
|
||||
|
||||
**Problem Solved:**
|
||||
- Multiple parallel agents trying to commit simultaneously
|
||||
- Git lock file conflicts (.git/index.lock)
|
||||
- "Another git process seems to be running" errors
|
||||
- Commit failures requiring manual intervention
|
||||
|
||||
**Solution:**
|
||||
- File-based commit queue using .git/bmad-commit.lock
|
||||
- Automatic retry with exponential backoff
|
||||
- Lock cleanup on success or failure
|
||||
- Maximum wait time enforcement
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Check if Commit Queue is Needed
|
||||
|
||||
```
|
||||
If mode == "batch" AND execution_mode == "parallel":
|
||||
use_commit_queue = true
|
||||
Display: "🔒 Using commit queue (parallel mode)"
|
||||
Else:
|
||||
use_commit_queue = false
|
||||
Display: "Committing directly (sequential mode)"
|
||||
goto Step 3 (Direct Commit)
|
||||
```
|
||||
|
||||
### 2. Acquire Commit Lock (Parallel Mode Only)
|
||||
|
||||
**Lock file:** `.git/bmad-commit.lock`
|
||||
|
||||
**Acquisition algorithm:**
|
||||
```
|
||||
max_wait_time = 300 seconds (5 minutes)
|
||||
retry_delay = 1 second (exponential backoff)
|
||||
start_time = now()
|
||||
|
||||
WHILE elapsed_time < max_wait_time:
|
||||
|
||||
IF lock file does NOT exist:
|
||||
Create lock file with content:
|
||||
locked_by: {{story_key}}
|
||||
locked_at: {{timestamp}}
|
||||
worker_id: {{worker_id}}
|
||||
pid: {{process_id}}
|
||||
|
||||
Display: "🔓 Lock acquired for {{story_key}}"
|
||||
BREAK (proceed to commit)
|
||||
|
||||
ELSE:
|
||||
Read lock file to check who has it
|
||||
Display: "⏳ Waiting for commit lock... (held by {{locked_by}}, {{wait_duration}}s elapsed)"
|
||||
|
||||
Sleep retry_delay seconds
|
||||
retry_delay = min(retry_delay * 1.5, 30) # Exponential backoff, max 30s
|
||||
|
||||
Check if lock is stale (>5 minutes old):
|
||||
IF lock_age > 300 seconds:
|
||||
Display: "⚠️ Stale lock detected ({{lock_age}}s old) - removing"
|
||||
Delete lock file
|
||||
Continue (try again)
|
||||
```
|
||||
|
||||
**Timeout handling:**
|
||||
```
|
||||
IF elapsed_time >= max_wait_time:
|
||||
Display:
|
||||
❌ TIMEOUT: Could not acquire commit lock after 5 minutes
|
||||
|
||||
Lock held by: {{locked_by}}
|
||||
Lock age: {{lock_age}} seconds
|
||||
|
||||
Possible causes:
|
||||
- Another agent crashed while holding lock
|
||||
- Commit taking abnormally long
|
||||
- Lock file not cleaned up
|
||||
|
||||
HALT - Manual intervention required:
|
||||
- Check if lock holder is still running
|
||||
- Delete .git/bmad-commit.lock if safe
|
||||
- Retry this story
|
||||
```
|
||||
|
||||
### 3. Execute Git Commit
|
||||
|
||||
**Stage changes:**
|
||||
```bash
|
||||
git add {files_changed_for_this_story}
|
||||
```
|
||||
|
||||
**Generate commit message:**
|
||||
```
|
||||
feat: implement story {{story_key}}
|
||||
|
||||
{{implementation_summary_from_dev_agent_record}}
|
||||
|
||||
Files changed:
|
||||
{{#each files_changed}}
|
||||
- {{this}}
|
||||
{{/each}}
|
||||
|
||||
Tasks completed: {{checked_tasks}}/{{total_tasks}}
|
||||
Story status: {{story_status}}
|
||||
```
|
||||
|
||||
**Commit:**
|
||||
```bash
|
||||
git commit -m "$(cat <<'EOF'
|
||||
{commit_message}
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
**Verification:**
|
||||
```bash
|
||||
git log -1 --oneline
|
||||
```
|
||||
|
||||
Confirm commit SHA returned.
|
||||
|
||||
### 4. Release Commit Lock (Parallel Mode Only)
|
||||
|
||||
```
|
||||
IF use_commit_queue == true:
|
||||
Delete lock file: .git/bmad-commit.lock
|
||||
|
||||
Verify lock removed:
|
||||
IF lock file still exists:
|
||||
Display: "⚠️ WARNING: Could not remove lock file"
|
||||
Try force delete
|
||||
ELSE:
|
||||
Display: "🔓 Lock released for {{story_key}}"
|
||||
```
|
||||
|
||||
**Error handling:**
|
||||
```
|
||||
IF commit failed:
|
||||
Release lock (if held)
|
||||
Display:
|
||||
❌ COMMIT FAILED: {{error_message}}
|
||||
|
||||
Story implemented but not committed.
|
||||
Changes are staged but not in git history.
|
||||
|
||||
HALT - Fix commit issue before continuing
|
||||
```
|
||||
|
||||
### 5. Update State
|
||||
|
||||
Update state file:
|
||||
- Add `6a` to `stepsCompleted`
|
||||
- Set `lastStep: 6a`
|
||||
- Record `commit_sha`
|
||||
- Record `committed_at` timestamp
|
||||
|
||||
### 6. Present Summary
|
||||
|
||||
Display:
|
||||
```
|
||||
✅ Story {{story_key}} Committed
|
||||
|
||||
Commit: {{commit_sha}}
|
||||
Files: {{files_count}} changed
|
||||
{{#if use_commit_queue}}Lock wait: {{lock_wait_duration}}s{{/if}}
|
||||
```
|
||||
|
||||
**Interactive Mode Menu:**
|
||||
```
|
||||
[C] Continue to Summary
|
||||
[P] Push to remote
|
||||
[H] Halt pipeline
|
||||
```
|
||||
|
||||
**Batch Mode:** Auto-continue to step-07-summary.md
|
||||
|
||||
## CRITICAL STEP COMPLETION
|
||||
|
||||
Load and execute `{nextStepFile}` for summary.
|
||||
|
||||
---
|
||||
|
||||
## SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS
|
||||
- Changes committed to git
|
||||
- Commit SHA recorded
|
||||
- Lock acquired and released cleanly (parallel mode)
|
||||
- No lock file remaining
|
||||
- State updated
|
||||
|
||||
### ❌ FAILURE
|
||||
- Commit timed out
|
||||
- Lock acquisition timed out (>5 min)
|
||||
- Lock not released (leaked lock)
|
||||
- Commit command failed
|
||||
- Stale lock not cleaned up
|
||||
|
||||
---
|
||||
|
||||
## LOCK FILE FORMAT
|
||||
|
||||
`.git/bmad-commit.lock` contains:
|
||||
```yaml
|
||||
locked_by: "2-7-image-file-handling"
|
||||
locked_at: "2026-01-07T18:45:32Z"
|
||||
worker_id: 3
|
||||
pid: 12345
|
||||
story_file: "docs/sprint-artifacts/2-7-image-file-handling.md"
|
||||
```
|
||||
|
||||
This allows debugging if lock gets stuck.
|
||||
|
||||
---
|
||||
|
||||
## QUEUE BENEFITS
|
||||
|
||||
**Before (No Queue):**
|
||||
```
|
||||
Worker 1: git commit → acquires .git/index.lock
|
||||
Worker 2: git commit → ERROR: index.lock exists
|
||||
Worker 3: git commit → ERROR: index.lock exists
|
||||
Worker 2: retries → ERROR: index.lock exists
|
||||
Worker 3: retries → ERROR: index.lock exists
|
||||
Workers 2 & 3: HALT - manual intervention needed
|
||||
```
|
||||
|
||||
**After (With Queue):**
|
||||
```
|
||||
Worker 1: acquires bmad-commit.lock → git commit → releases lock
|
||||
Worker 2: waits for lock → acquires → git commit → releases
|
||||
Worker 3: waits for lock → acquires → git commit → releases
|
||||
All workers: SUCCESS ✅
|
||||
```
|
||||
|
||||
**Throughput Impact:**
|
||||
- Implementation: Fully parallel (no blocking)
|
||||
- Commits: Serialized (necessary to prevent conflicts)
|
||||
- Overall: Still much faster than sequential mode (implementation is 90% of the time)
|
||||
|
||||
---
|
||||
|
||||
## STALE LOCK RECOVERY
|
||||
|
||||
**Automatic cleanup:**
|
||||
- Locks older than 5 minutes are considered stale
|
||||
- Automatically removed before retrying
|
||||
- Prevents permanent deadlock from crashed agents
|
||||
|
||||
**Manual recovery:**
|
||||
```bash
|
||||
# If workflow stuck on lock acquisition:
|
||||
rm .git/bmad-commit.lock
|
||||
|
||||
# Check if any git process is actually running:
|
||||
ps aux | grep git
|
||||
|
||||
# If no git process, safe to remove lock
|
||||
```
|
||||
|
|
@ -1,219 +0,0 @@
|
|||
---
|
||||
name: 'step-11-summary'
|
||||
description: 'Generate comprehensive audit trail and pipeline summary'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-11-summary.md'
|
||||
stateFile: '{state_file}'
|
||||
storyFile: '{story_file}'
|
||||
auditTrail: '{audit_trail}'
|
||||
|
||||
# Role
|
||||
role: null
|
||||
---
|
||||
|
||||
# Step 11: Pipeline Summary
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Generate comprehensive audit trail and summary:
|
||||
1. Calculate total duration
|
||||
2. Summarize work completed
|
||||
3. Generate audit trail file
|
||||
4. Display final summary
|
||||
5. Clean up state file
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Calculate Metrics
|
||||
|
||||
From state file, calculate:
|
||||
- Total duration: `{completed_at} - {started_at}`
|
||||
- Step durations
|
||||
- Files modified count
|
||||
- Issues found and fixed
|
||||
- Tasks completed
|
||||
|
||||
### 2. Generate Audit Trail
|
||||
|
||||
Create file: `{sprint_artifacts}/audit-super-dev-{story_id}-{date}.yaml`
|
||||
|
||||
```yaml
|
||||
---
|
||||
audit_version: "1.0"
|
||||
workflow: "super-dev-pipeline"
|
||||
workflow_version: "1.0.0"
|
||||
|
||||
# Story identification
|
||||
story_id: "{story_id}"
|
||||
story_file: "{story_file}"
|
||||
story_title: "{story_title}"
|
||||
|
||||
# Execution summary
|
||||
execution:
|
||||
started_at: "{started_at}"
|
||||
completed_at: "{completed_at}"
|
||||
total_duration: "{duration}"
|
||||
mode: "{mode}"
|
||||
status: "completed"
|
||||
|
||||
# Development analysis
|
||||
development:
|
||||
type: "{greenfield|brownfield|hybrid}"
|
||||
existing_files_modified: {count}
|
||||
new_files_created: {count}
|
||||
migrations_applied: {count}
|
||||
|
||||
# Step results
|
||||
steps:
|
||||
step-01-init:
|
||||
duration: "{duration}"
|
||||
status: "completed"
|
||||
|
||||
step-02-pre-gap-analysis:
|
||||
duration: "{duration}"
|
||||
tasks_analyzed: {count}
|
||||
tasks_refined: {count}
|
||||
tasks_added: {count}
|
||||
status: "completed"
|
||||
|
||||
step-03-implement:
|
||||
duration: "{duration}"
|
||||
tasks_completed: {count}
|
||||
files_created: {list}
|
||||
files_modified: {list}
|
||||
migrations: {list}
|
||||
tests_added: {count}
|
||||
status: "completed"
|
||||
|
||||
step-04-post-validation:
|
||||
duration: "{duration}"
|
||||
tasks_verified: {count}
|
||||
false_positives: {count}
|
||||
re_implementations: {count}
|
||||
status: "completed"
|
||||
|
||||
step-05-code-review:
|
||||
duration: "{duration}"
|
||||
issues_found: {count}
|
||||
issues_fixed: {count}
|
||||
categories: {list}
|
||||
status: "completed"
|
||||
|
||||
step-06-complete:
|
||||
duration: "{duration}"
|
||||
commit_hash: "{hash}"
|
||||
files_committed: {count}
|
||||
pushed: {true|false}
|
||||
status: "completed"
|
||||
|
||||
# Quality metrics
|
||||
quality:
|
||||
all_tests_passing: true
|
||||
lint_clean: true
|
||||
build_success: true
|
||||
no_vibe_coding: true
|
||||
followed_step_sequence: true
|
||||
|
||||
# Files affected
|
||||
files:
|
||||
created: {list}
|
||||
modified: {list}
|
||||
deleted: {list}
|
||||
|
||||
# Commit information
|
||||
commit:
|
||||
hash: "{hash}"
|
||||
message: "{message}"
|
||||
files_committed: {count}
|
||||
pushed_to_remote: {true|false}
|
||||
```
|
||||
|
||||
### 3. Display Final Summary
|
||||
|
||||
```
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
🎉 SUPER-DEV PIPELINE COMPLETE!
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Story: {story_title}
|
||||
Duration: {total_duration}
|
||||
|
||||
Development Type: {greenfield|brownfield|hybrid}
|
||||
|
||||
Results:
|
||||
✅ Tasks Completed: {completed_count}
|
||||
✅ Files Created: {created_count}
|
||||
✅ Files Modified: {modified_count}
|
||||
✅ Tests Added: {test_count}
|
||||
✅ Issues Found & Fixed: {issue_count}
|
||||
|
||||
Quality Gates Passed:
|
||||
✅ Pre-Gap Analysis
|
||||
✅ Implementation
|
||||
✅ Post-Validation (no false positives)
|
||||
✅ Code Review (3-10 issues)
|
||||
✅ All tests passing
|
||||
✅ Lint clean
|
||||
✅ Build success
|
||||
|
||||
Git:
|
||||
✅ Commit: {commit_hash}
|
||||
{if pushed}✅ Pushed to remote{endif}
|
||||
|
||||
Story Status: review (ready for human review)
|
||||
|
||||
Audit Trail: {audit_file}
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
✨ No vibe coding occurred! Disciplined execution maintained.
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
```
|
||||
|
||||
### 4. Clean Up State File
|
||||
|
||||
```bash
|
||||
rm {sprint_artifacts}/super-dev-state-{story_id}.yaml
|
||||
```
|
||||
|
||||
State is no longer needed - audit trail is the permanent record.
|
||||
|
||||
### 5. Final Message
|
||||
|
||||
```
|
||||
Super-Dev Pipeline Complete!
|
||||
|
||||
This story was developed with disciplined step-file execution.
|
||||
All quality gates passed. Ready for human review.
|
||||
|
||||
Next Steps:
|
||||
1. Review the commit: git show {commit_hash}
|
||||
2. Test manually if needed
|
||||
3. Merge when approved
|
||||
```
|
||||
|
||||
## PIPELINE COMPLETE
|
||||
|
||||
Pipeline execution is finished. No further steps.
|
||||
|
||||
---
|
||||
|
||||
## SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS
|
||||
- Audit trail generated
|
||||
- Summary accurate
|
||||
- State file cleaned up
|
||||
- Story marked "review"
|
||||
- All metrics captured
|
||||
|
||||
### ❌ FAILURE
|
||||
- Missing audit trail
|
||||
- Incomplete summary
|
||||
- State file not cleaned
|
||||
- Metrics inaccurate
|
||||
|
|
@ -1,292 +1,374 @@
|
|||
---
|
||||
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 - Multi-Agent Architecture
|
||||
|
||||
# Super-Dev Pipeline Workflow
|
||||
|
||||
**Goal:** Execute story development with disciplined step-file architecture that prevents "vibe coding" and works for both new features and existing codebase modifications.
|
||||
|
||||
**Your Role:** You are the **BMAD Pipeline Orchestrator**. You will follow each step file precisely, without deviation, optimization, or skipping ahead.
|
||||
|
||||
**Key Principle:** This workflow uses **step-file architecture** for disciplined execution that prevents Claude from veering off-course when token usage is high.
|
||||
**Architecture:** GSDMAD (GSD + BMAD)
|
||||
**Philosophy:** Trust but verify, separation of concerns
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
## Overview
|
||||
|
||||
This uses **step-file architecture** borrowed from story-pipeline:
|
||||
This workflow implements a story using **4 independent agents** with external validation at each phase.
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step is a self-contained instruction file (~150-300 lines)
|
||||
- **Just-In-Time Loading**: Only the current step file is in memory
|
||||
- **Mandatory Sequences**: Execute all numbered sections in order, never deviate
|
||||
- **State Tracking**: Pipeline state in `{sprint_artifacts}/super-dev-state-{story_id}.yaml`
|
||||
- **No Vibe Coding**: Explicit instructions prevent optimization/deviation
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||
3. **QUALITY GATES**: Complete gate criteria before proceeding to next step
|
||||
4. **WAIT FOR INPUT**: In interactive mode, halt at menus and wait for user selection
|
||||
5. **SAVE STATE**: Update pipeline state file after each step completion
|
||||
6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step
|
||||
|
||||
### Critical Rules (NO EXCEPTIONS)
|
||||
|
||||
- **NEVER** load multiple step files simultaneously
|
||||
- **ALWAYS** read entire step file before execution
|
||||
- **NEVER** skip steps or optimize the sequence
|
||||
- **ALWAYS** update pipeline state after completing each step
|
||||
- **ALWAYS** follow the exact instructions in the step file
|
||||
- **NEVER** create mental todo lists from future steps
|
||||
- **NEVER** look ahead to future step files
|
||||
- **NEVER** vibe code when token usage is high - follow the steps exactly!
|
||||
**Key Innovation:** Each agent has single responsibility and fresh context. No agent validates its own work.
|
||||
|
||||
---
|
||||
|
||||
## STEP FILE MAP
|
||||
## Execution Flow
|
||||
|
||||
| Step | File | Agent | Purpose |
|
||||
|------|------|-------|---------|
|
||||
| 1 | step-01-init.md | - | Load story, detect greenfield vs brownfield |
|
||||
| 2 | step-02-pre-gap-analysis.md | DEV | Validate tasks + **detect batchable patterns** |
|
||||
| 3 | step-03-implement.md | DEV | **Smart batching** + adaptive implementation |
|
||||
| 4 | step-04-post-validation.md | DEV | Verify completed tasks vs reality |
|
||||
| 5 | step-05-code-review.md | DEV | Find 3-10 specific issues |
|
||||
| 6 | step-06-complete.md | SM | Commit and push changes |
|
||||
| 7 | step-07-summary.md | - | Audit trail generation |
|
||||
|
||||
---
|
||||
|
||||
## KEY DIFFERENCES FROM story-pipeline
|
||||
|
||||
### What's REMOVED:
|
||||
- ❌ Step 2 (create-story) - assumes story already exists
|
||||
- ❌ Step 4 (ATDD) - not mandatory for brownfield
|
||||
|
||||
### What's ENHANCED:
|
||||
- ✅ Pre-gap analysis is MORE thorough (validates against existing code)
|
||||
- ✅ **Smart Batching** - detects and groups similar tasks automatically
|
||||
- ✅ Implementation is ADAPTIVE (TDD for new, refactor for existing)
|
||||
- ✅ Works for both greenfield and brownfield
|
||||
|
||||
### What's NEW:
|
||||
- ⚡ **Pattern Detection** - automatically identifies batchable tasks
|
||||
- ⚡ **Intelligent Grouping** - groups similar tasks for batch execution
|
||||
- ⚡ **Time Optimization** - 50-70% faster for repetitive work
|
||||
- ⚡ **Safety Preserved** - validation gates enforce discipline
|
||||
|
||||
---
|
||||
|
||||
## SMART BATCHING FEATURE
|
||||
|
||||
### What is Smart Batching?
|
||||
|
||||
**Smart batching** is an intelligent optimization that groups similar, low-risk tasks for batch execution while maintaining full validation discipline.
|
||||
|
||||
**NOT Vibe Coding:**
|
||||
- ✅ Pattern detection is systematic (not guesswork)
|
||||
- ✅ Batches are validated as a group (not skipped)
|
||||
- ✅ Failure triggers fallback to one-at-a-time
|
||||
- ✅ High-risk tasks always executed individually
|
||||
|
||||
**When It Helps:**
|
||||
- Large stories with repetitive tasks (100+ tasks)
|
||||
- Package migration work (installing multiple packages)
|
||||
- Module refactoring (same pattern across files)
|
||||
- Code cleanup (delete old implementations)
|
||||
|
||||
**Time Savings:**
|
||||
```
|
||||
Example: 100-task story
|
||||
- Without batching: 100 tasks × 2 min = 200 minutes (3.3 hours)
|
||||
- With batching: 6 batches × 10 min + 20 individual × 2 min = 100 minutes (1.7 hours)
|
||||
- Savings: 100 minutes (50% faster!)
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Main Orchestrator (Claude) │
|
||||
│ - Loads story │
|
||||
│ - Spawns agents sequentially │
|
||||
│ - Verifies each phase │
|
||||
│ - Final quality gate │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
├──> Phase 1: Builder (Steps 1-4)
|
||||
│ - Load story, analyze gaps
|
||||
│ - Write tests (TDD)
|
||||
│ - Implement code
|
||||
│ - Report what was built (NO VALIDATION)
|
||||
│
|
||||
├──> Phase 2: Inspector (Steps 5-6)
|
||||
│ - Fresh context, no Builder knowledge
|
||||
│ - Verify files exist
|
||||
│ - Run tests independently
|
||||
│ - Run quality checks
|
||||
│ - PASS or FAIL verdict
|
||||
│
|
||||
├──> Phase 3: Reviewer (Step 7)
|
||||
│ - Fresh context, adversarial stance
|
||||
│ - Find security vulnerabilities
|
||||
│ - Find performance problems
|
||||
│ - Find logic bugs
|
||||
│ - Report issues with severity
|
||||
│
|
||||
├──> Phase 4: Fixer (Steps 8-9)
|
||||
│ - Fix CRITICAL issues (all)
|
||||
│ - Fix HIGH issues (all)
|
||||
│ - Fix MEDIUM issues (if time)
|
||||
│ - Skip LOW issues (gold-plating)
|
||||
│ - Update story + sprint-status
|
||||
│ - Commit changes
|
||||
│
|
||||
└──> Final Verification (Main)
|
||||
- Check git commits exist
|
||||
- Check story checkboxes updated
|
||||
- Check sprint-status updated
|
||||
- Check tests passed
|
||||
- Mark COMPLETE or FAILED
|
||||
```
|
||||
|
||||
### Batchable Pattern Types
|
||||
---
|
||||
|
||||
| Pattern | Example Tasks | Risk | Validation |
|
||||
|---------|--------------|------|------------|
|
||||
| **Package Install** | Add dependencies | LOW | Build succeeds |
|
||||
| **Module Registration** | Import modules | LOW | TypeScript compiles |
|
||||
| **Code Deletion** | Remove old code | LOW | Tests pass |
|
||||
| **Import Updates** | Update import paths | LOW | Build succeeds |
|
||||
| **Config Changes** | Update settings | LOW | App starts |
|
||||
## Agent Spawning Instructions
|
||||
|
||||
### NON-Batchable (Individual Execution)
|
||||
### Phase 1: Spawn Builder
|
||||
|
||||
| Pattern | Example Tasks | Risk | Why Individual |
|
||||
|---------|--------------|------|----------------|
|
||||
| **Business Logic** | Circuit breaker fallbacks | MEDIUM-HIGH | Logic varies per case |
|
||||
| **Security Code** | Auth/authorization | HIGH | Mistakes are critical |
|
||||
| **Data Migrations** | Schema changes | HIGH | Irreversible |
|
||||
| **API Integration** | External service calls | MEDIUM | Error handling varies |
|
||||
| **Novel Patterns** | First-time implementation | MEDIUM | Unproven approach |
|
||||
```javascript
|
||||
Task({
|
||||
subagent_type: "general-purpose",
|
||||
description: "Implement story {{story_key}}",
|
||||
prompt: `
|
||||
You are the BUILDER agent for story {{story_key}}.
|
||||
|
||||
### How It Works
|
||||
Load and execute: {agents_path}/builder.md
|
||||
|
||||
**Step 2 (Pre-Gap Analysis):**
|
||||
1. Analyzes all tasks
|
||||
2. Detects repeating patterns
|
||||
3. Categorizes as batchable or individual
|
||||
4. Generates batching plan with time estimates
|
||||
5. Adds plan to story file
|
||||
Story file: {{story_file}}
|
||||
|
||||
**Step 3 (Implementation):**
|
||||
1. Loads batching plan
|
||||
2. Executes pattern batches first
|
||||
3. Validates each batch
|
||||
4. Fallback to individual if batch fails
|
||||
5. Executes individual tasks with full rigor
|
||||
Complete Steps 1-4:
|
||||
1. Init - Load story
|
||||
2. Pre-Gap - Analyze what exists
|
||||
3. Write Tests - TDD approach
|
||||
4. Implement - Write production code
|
||||
|
||||
**Safety Mechanisms:**
|
||||
- Pattern detection uses conservative rules (default to individual)
|
||||
- Each batch has explicit validation strategy
|
||||
- Failed batch triggers automatic fallback
|
||||
- High-risk tasks never batched
|
||||
- All validation gates still enforced
|
||||
DO NOT:
|
||||
- Validate your work
|
||||
- Review your code
|
||||
- Update checkboxes
|
||||
- Commit changes
|
||||
|
||||
Just build it and report what you created.
|
||||
`
|
||||
});
|
||||
```
|
||||
|
||||
**Wait for Builder to complete. Store agent_id in agent-history.json.**
|
||||
|
||||
### Phase 2: Spawn Inspector
|
||||
|
||||
```javascript
|
||||
Task({
|
||||
subagent_type: "general-purpose",
|
||||
description: "Validate story {{story_key}} implementation",
|
||||
prompt: `
|
||||
You are the INSPECTOR agent for story {{story_key}}.
|
||||
|
||||
Load and execute: {agents_path}/inspector.md
|
||||
|
||||
Story file: {{story_file}}
|
||||
|
||||
You have NO KNOWLEDGE of what the Builder did.
|
||||
|
||||
Complete Steps 5-6:
|
||||
5. Post-Validation - Verify files exist and have content
|
||||
6. Quality Checks - Run type-check, lint, build, tests
|
||||
|
||||
Run all checks yourself. Don't trust Builder claims.
|
||||
|
||||
Output: PASS or FAIL verdict with evidence.
|
||||
`
|
||||
});
|
||||
```
|
||||
|
||||
**Wait for Inspector to complete. If FAIL, halt pipeline.**
|
||||
|
||||
### Phase 3: Spawn Reviewer
|
||||
|
||||
```javascript
|
||||
Task({
|
||||
subagent_type: "bmad_bmm_multi-agent-review",
|
||||
description: "Adversarial review of story {{story_key}}",
|
||||
prompt: `
|
||||
You are the ADVERSARIAL REVIEWER for story {{story_key}}.
|
||||
|
||||
Load and execute: {agents_path}/reviewer.md
|
||||
|
||||
Story file: {{story_file}}
|
||||
Complexity: {{complexity_level}}
|
||||
|
||||
Your goal is to FIND PROBLEMS.
|
||||
|
||||
Complete Step 7:
|
||||
7. Code Review - Find security, performance, logic issues
|
||||
|
||||
Be critical. Look for flaws.
|
||||
|
||||
Output: List of issues with severity ratings.
|
||||
`
|
||||
});
|
||||
```
|
||||
|
||||
**Wait for Reviewer to complete. Parse issues by severity.**
|
||||
|
||||
### Phase 4: Spawn Fixer
|
||||
|
||||
```javascript
|
||||
Task({
|
||||
subagent_type: "general-purpose",
|
||||
description: "Fix issues in story {{story_key}}",
|
||||
prompt: `
|
||||
You are the FIXER agent for story {{story_key}}.
|
||||
|
||||
Load and execute: {agents_path}/fixer.md
|
||||
|
||||
Story file: {{story_file}}
|
||||
Review issues: {{review_findings}}
|
||||
|
||||
Complete Steps 8-9:
|
||||
8. Review Analysis - Categorize issues, filter gold-plating
|
||||
9. Fix Issues - Fix CRITICAL/HIGH, consider MEDIUM, skip LOW
|
||||
|
||||
After fixing:
|
||||
- Update story checkboxes
|
||||
- Update sprint-status.yaml
|
||||
- Commit with descriptive message
|
||||
|
||||
Output: Fix summary with git commit hash.
|
||||
`
|
||||
});
|
||||
```
|
||||
|
||||
**Wait for Fixer to complete.**
|
||||
|
||||
---
|
||||
|
||||
## EXECUTION MODES
|
||||
## Final Verification (Main Orchestrator)
|
||||
|
||||
**After all agents complete, verify:**
|
||||
|
||||
### Interactive Mode (Default)
|
||||
```bash
|
||||
bmad super-dev-pipeline
|
||||
# 1. Check git commits
|
||||
git log --oneline -3 | grep "{{story_key}}"
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "❌ FAILED: No commit found"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 2. Check story checkboxes
|
||||
before=$(git show HEAD~1:{{story_file}} | grep -c '^- \[x\]')
|
||||
after=$(grep -c '^- \[x\]' {{story_file}})
|
||||
if [ $after -le $before ]; then
|
||||
echo "❌ FAILED: Checkboxes not updated"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3. Check sprint-status
|
||||
git diff HEAD~1 {{sprint_status}} | grep "{{story_key}}: done"
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "❌ FAILED: Sprint status not updated"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 4. Check Inspector output for test evidence
|
||||
grep -E "PASS|tests.*passing" inspector_output.txt
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "❌ FAILED: No test evidence"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "✅ STORY COMPLETE - All verifications passed"
|
||||
```
|
||||
|
||||
Features:
|
||||
- Menu navigation between steps
|
||||
- User approval at quality gates
|
||||
- Can pause and resume
|
||||
---
|
||||
|
||||
### Batch Mode (For batch-super-dev)
|
||||
```bash
|
||||
bmad super-dev-pipeline --batch
|
||||
## Benefits Over Single-Agent
|
||||
|
||||
### Separation of Concerns
|
||||
- Builder doesn't validate own work
|
||||
- Inspector has no incentive to lie
|
||||
- Reviewer approaches with fresh eyes
|
||||
- Fixer can't skip issues
|
||||
|
||||
### Fresh Context Each Phase
|
||||
- Each agent starts at 0% context
|
||||
- No accumulated fatigue
|
||||
- No degraded quality
|
||||
- Honest reporting
|
||||
|
||||
### Adversarial Review
|
||||
- Reviewer WANTS to find issues
|
||||
- Not defensive about the code
|
||||
- More thorough than self-review
|
||||
|
||||
### Honest Verification
|
||||
- Inspector runs tests independently
|
||||
- Main orchestrator verifies everything
|
||||
- Can't fake completion
|
||||
|
||||
---
|
||||
|
||||
## Complexity Routing
|
||||
|
||||
**MICRO stories:**
|
||||
- Skip Reviewer (low risk)
|
||||
- 2 agents: Builder → Inspector → Fixer
|
||||
|
||||
**STANDARD stories:**
|
||||
- Full pipeline
|
||||
- 4 agents: Builder → Inspector → Reviewer → Fixer
|
||||
|
||||
**COMPLEX stories:**
|
||||
- Enhanced review (6 reviewers instead of 4)
|
||||
- Full pipeline + extra scrutiny
|
||||
- 4 agents: Builder → Inspector → Reviewer (enhanced) → Fixer
|
||||
|
||||
---
|
||||
|
||||
## Agent Tracking
|
||||
|
||||
Track all agents in `agent-history.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"version": "1.0",
|
||||
"max_entries": 50,
|
||||
"entries": [
|
||||
{
|
||||
"agent_id": "abc123",
|
||||
"story_key": "17-10",
|
||||
"phase": "builder",
|
||||
"steps": [1,2,3,4],
|
||||
"timestamp": "2026-01-25T21:00:00Z",
|
||||
"status": "completed",
|
||||
"completion_timestamp": "2026-01-25T21:15:00Z"
|
||||
},
|
||||
{
|
||||
"agent_id": "def456",
|
||||
"story_key": "17-10",
|
||||
"phase": "inspector",
|
||||
"steps": [5,6],
|
||||
"timestamp": "2026-01-25T21:16:00Z",
|
||||
"status": "completed",
|
||||
"completion_timestamp": "2026-01-25T21:20:00Z"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Features:
|
||||
- Auto-proceed through all steps
|
||||
- Fail-fast on errors
|
||||
- No vibe coding even at high token counts
|
||||
**Benefits:**
|
||||
- Resume interrupted sessions
|
||||
- Track agent performance
|
||||
- Debug failed pipelines
|
||||
- Audit trail
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION SEQUENCE
|
||||
## Error Handling
|
||||
|
||||
### 1. Configuration Loading
|
||||
**If Builder fails:**
|
||||
- Don't spawn Inspector
|
||||
- Report failure to user
|
||||
- Option to resume or retry
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
- `output_folder`, `sprint_artifacts`, `communication_language`
|
||||
**If Inspector fails:**
|
||||
- Don't spawn Reviewer
|
||||
- Report specific failures
|
||||
- Resume Builder to fix issues
|
||||
|
||||
### 2. Pipeline Parameters
|
||||
**If Reviewer finds CRITICAL issues:**
|
||||
- Must spawn Fixer (not optional)
|
||||
- Cannot mark story complete until fixed
|
||||
|
||||
Resolve from invocation:
|
||||
- `story_id`: Story identifier (e.g., "1-4")
|
||||
- `story_file`: Path to story file (must exist!)
|
||||
- `mode`: "interactive" or "batch"
|
||||
|
||||
### 3. Document Pre-loading
|
||||
|
||||
Load and cache these documents (read once, use across steps):
|
||||
- Story file: Required, must exist
|
||||
- Project context: `**/project-context.md`
|
||||
- Epic file: Optional, for context
|
||||
|
||||
### 4. First Step Execution
|
||||
|
||||
Load, read the full file and then execute:
|
||||
`{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline/steps/step-01-init.md`
|
||||
**If Fixer fails:**
|
||||
- Report unfixed issues
|
||||
- Cannot mark story complete
|
||||
- Manual intervention required
|
||||
|
||||
---
|
||||
|
||||
## QUALITY GATES
|
||||
## Comparison: v1.x vs v2.0
|
||||
|
||||
Each gate must pass before proceeding:
|
||||
|
||||
### Pre-Gap Analysis Gate (Step 2)
|
||||
- [ ] All tasks validated against codebase
|
||||
- [ ] Existing code analyzed
|
||||
- [ ] Tasks refined if needed
|
||||
- [ ] No missing context
|
||||
|
||||
### Implementation Gate (Step 3)
|
||||
- [ ] All tasks completed
|
||||
- [ ] Tests pass
|
||||
- [ ] Code follows project patterns
|
||||
- [ ] No TypeScript errors
|
||||
|
||||
### Post-Validation Gate (Step 4)
|
||||
- [ ] All completed tasks verified against codebase
|
||||
- [ ] Zero false positives (or re-implementation complete)
|
||||
- [ ] Files/functions/tests actually exist
|
||||
- [ ] Tests actually pass (not just claimed)
|
||||
|
||||
### Code Review Gate (Step 5)
|
||||
- [ ] 3-10 specific issues identified (not "looks good")
|
||||
- [ ] All issues resolved or documented
|
||||
- [ ] Security review complete
|
||||
| Aspect | v1.x (Single-Agent) | v2.0 (Multi-Agent) |
|
||||
|--------|--------------------|--------------------|
|
||||
| Agents | 1 | 4 |
|
||||
| Validation | Self (conflict of interest) | Independent (no conflict) |
|
||||
| Code Review | Self-review | Adversarial (fresh eyes) |
|
||||
| Honesty | Low (can lie) | High (verified) |
|
||||
| Context | Degrades over 11 steps | Fresh each phase |
|
||||
| Catches Issues | Low | High |
|
||||
| Completion Accuracy | ~60% (agents lie) | ~95% (verified) |
|
||||
|
||||
---
|
||||
|
||||
## ANTI-VIBE-CODING ENFORCEMENT
|
||||
## Migration from v1.x
|
||||
|
||||
This workflow **prevents vibe coding** through:
|
||||
**Backward Compatibility:**
|
||||
```yaml
|
||||
execution_mode: "single_agent" # Use v1.x
|
||||
execution_mode: "multi_agent" # Use v2.0 (new)
|
||||
```
|
||||
|
||||
1. **Mandatory Sequence**: Can't skip ahead or optimize
|
||||
2. **Micro-file Loading**: Only current step in memory
|
||||
3. **Quality Gates**: Must pass criteria to proceed
|
||||
4. **State Tracking**: Progress is recorded and verified
|
||||
5. **Explicit Instructions**: No interpretation required
|
||||
|
||||
**Even at 200K tokens**, Claude must:
|
||||
- ✅ Read entire step file
|
||||
- ✅ Follow numbered sequence
|
||||
- ✅ Complete quality gate
|
||||
- ✅ Update state
|
||||
- ✅ Load next step
|
||||
|
||||
**No shortcuts. No optimizations. No vibe coding.**
|
||||
**Gradual Rollout:**
|
||||
1. Week 1: Test v2.0 on 3-5 stories
|
||||
2. Week 2: Make v2.0 default for new stories
|
||||
3. Week 3: Migrate existing stories to v2.0
|
||||
4. Week 4: Deprecate v1.x
|
||||
|
||||
---
|
||||
|
||||
## SUCCESS METRICS
|
||||
## Hospital-Grade Standards
|
||||
|
||||
### ✅ SUCCESS
|
||||
- Pipeline completes all 7 steps
|
||||
- All quality gates passed
|
||||
- Story status updated
|
||||
- Git commit created
|
||||
- Audit trail generated
|
||||
- **No vibe coding occurred**
|
||||
⚕️ **Lives May Be at Stake**
|
||||
|
||||
### ❌ FAILURE
|
||||
- Step file instructions skipped or optimized
|
||||
- Quality gate bypassed without approval
|
||||
- State file not updated
|
||||
- Tests not verified
|
||||
- Code review accepts "looks good"
|
||||
- **Vibe coding detected**
|
||||
- Independent validation catches errors
|
||||
- Adversarial review finds security flaws
|
||||
- Multiple checkpoints prevent shortcuts
|
||||
- Final verification prevents false completion
|
||||
|
||||
**QUALITY >> SPEED**
|
||||
|
||||
---
|
||||
|
||||
## COMPARISON WITH OTHER WORKFLOWS
|
||||
|
||||
| Feature | super-dev-story | story-pipeline | super-dev-pipeline |
|
||||
|---------|----------------|----------------|-------------------|
|
||||
| Architecture | Orchestration | Step-files | Step-files |
|
||||
| Story creation | Separate workflow | Included | ❌ Not included |
|
||||
| ATDD mandatory | No | Yes | No (adaptive) |
|
||||
| Greenfield | ✅ | ✅ | ✅ |
|
||||
| Brownfield | ✅ | ❌ Limited | ✅ |
|
||||
| Token efficiency | ~100-150K | ~25-30K | ~40-60K |
|
||||
| Vibe-proof | ❌ | ✅ | ✅ |
|
||||
|
||||
---
|
||||
|
||||
**super-dev-pipeline is the best of both worlds for batch-super-dev!**
|
||||
**Key Takeaway:** Don't trust a single agent to build, validate, review, and commit its own work. Use independent agents with fresh context at each phase.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,10 @@
|
|||
name: super-dev-pipeline
|
||||
description: "Complete a-k workflow: test-first development, smart gap analysis, quality gates, intelligent multi-agent review, and mandatory status updates. Risk-based complexity routing with variable agent counts."
|
||||
author: "BMad"
|
||||
version: "1.5.0" # Complete a-k workflow with TDD, quality gates, multi-agent review, and mandatory sprint-status updates
|
||||
name: super-dev-pipeline-v2
|
||||
description: "Multi-agent pipeline with wave-based execution, independent validation, and adversarial code review (GSDMAD)"
|
||||
author: "BMAD Method + GSD"
|
||||
version: "2.0.0"
|
||||
|
||||
# Execution mode
|
||||
execution_mode: "multi_agent" # multi_agent | single_agent (fallback)
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
|
|
@ -11,259 +14,108 @@ communication_language: "{config_source}:communication_language"
|
|||
date: system-generated
|
||||
|
||||
# Workflow paths
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline-v2"
|
||||
agents_path: "{installed_path}/agents"
|
||||
steps_path: "{installed_path}/steps"
|
||||
templates_path: "{installed_path}/templates"
|
||||
checklists_path: "{installed_path}/checklists"
|
||||
|
||||
# Agent tracking (from GSD)
|
||||
agent_history: "{sprint_artifacts}/agent-history.json"
|
||||
current_agent_id: "{sprint_artifacts}/current-agent-id.txt"
|
||||
|
||||
# State management
|
||||
state_file: "{sprint_artifacts}/super-dev-state-{{story_id}}.yaml"
|
||||
audit_trail: "{sprint_artifacts}/audit-super-dev-{{story_id}}-{{date}}.yaml"
|
||||
|
||||
# Auto-create story settings (NEW v1.4.0)
|
||||
# When story is missing or lacks proper context, auto-invoke /create-story-with-gap-analysis
|
||||
auto_create_story:
|
||||
enabled: true # Set to false to revert to old HALT behavior
|
||||
create_story_workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story-with-gap-analysis"
|
||||
triggers:
|
||||
- story_not_found # Story file doesn't exist
|
||||
- no_tasks # Story exists but has no tasks
|
||||
- missing_sections # Story missing required sections (Tasks, Acceptance Criteria)
|
||||
# Multi-agent configuration
|
||||
agents:
|
||||
builder:
|
||||
description: "Implementation agent - writes code and tests"
|
||||
steps: [1, 2, 3, 4]
|
||||
subagent_type: "general-purpose"
|
||||
prompt_file: "{agents_path}/builder.md"
|
||||
trust_level: "low" # Assumes agent will cut corners
|
||||
timeout: 3600 # 1 hour
|
||||
|
||||
# Complexity level (passed from batch-super-dev or set manually)
|
||||
# Controls which pipeline steps to execute
|
||||
inspector:
|
||||
description: "Validation agent - independent verification"
|
||||
steps: [5, 6]
|
||||
subagent_type: "general-purpose"
|
||||
prompt_file: "{agents_path}/inspector.md"
|
||||
fresh_context: true # No knowledge of builder agent
|
||||
trust_level: "medium" # No conflict of interest
|
||||
timeout: 1800 # 30 minutes
|
||||
|
||||
reviewer:
|
||||
description: "Adversarial code review - finds problems"
|
||||
steps: [7]
|
||||
subagent_type: "multi-agent-review" # Spawns multiple reviewers
|
||||
prompt_file: "{agents_path}/reviewer.md"
|
||||
fresh_context: true
|
||||
adversarial: true # Goal: find issues
|
||||
trust_level: "high" # Wants to find problems
|
||||
timeout: 1800 # 30 minutes
|
||||
review_agent_count:
|
||||
micro: 2
|
||||
standard: 4
|
||||
complex: 6
|
||||
|
||||
fixer:
|
||||
description: "Issue resolution - fixes critical/high issues"
|
||||
steps: [8, 9]
|
||||
subagent_type: "general-purpose"
|
||||
prompt_file: "{agents_path}/fixer.md"
|
||||
trust_level: "medium" # Incentive to minimize work
|
||||
timeout: 2400 # 40 minutes
|
||||
|
||||
# Complexity level (determines which steps to execute)
|
||||
complexity_level: "standard" # micro | standard | complex
|
||||
|
||||
# Risk-based complexity routing (UPDATED v1.5.0)
|
||||
# Complexity determined by RISK level, not task count
|
||||
# Risk keywords: auth, security, payment, file handling, architecture changes
|
||||
# Complexity routing
|
||||
complexity_routing:
|
||||
micro:
|
||||
skip_steps: [3, 7, 8, 9] # Skip write-tests, code-review, review-analysis, fix-issues
|
||||
description: "Lightweight path for low-risk stories (UI tweaks, text, simple CRUD)"
|
||||
multi_agent_count: 2
|
||||
examples: ["UI tweaks", "text changes", "simple CRUD", "documentation"]
|
||||
skip_agents: ["reviewer"] # Skip code review for micro stories
|
||||
description: "Lightweight path for low-risk stories"
|
||||
examples: ["UI tweaks", "text changes", "simple CRUD"]
|
||||
|
||||
standard:
|
||||
skip_steps: [] # Full pipeline
|
||||
description: "Balanced path for medium-risk stories (APIs, business logic)"
|
||||
multi_agent_count: 4
|
||||
examples: ["API endpoints", "business logic", "data validation"]
|
||||
skip_agents: [] # Full pipeline
|
||||
description: "Balanced path for medium-risk stories"
|
||||
examples: ["API endpoints", "business logic"]
|
||||
|
||||
complex:
|
||||
skip_steps: [] # Full pipeline + comprehensive review
|
||||
description: "Comprehensive path for high-risk stories (auth, payments, security)"
|
||||
multi_agent_count: 6
|
||||
examples: ["auth/security", "payments", "file handling", "architecture changes"]
|
||||
warn_before_start: true
|
||||
suggest_split: true
|
||||
skip_agents: [] # Full pipeline + enhanced review
|
||||
description: "Enhanced validation for high-risk stories"
|
||||
examples: ["Auth", "payments", "security", "migrations"]
|
||||
review_focus: ["security", "performance", "architecture"]
|
||||
|
||||
# Workflow modes
|
||||
modes:
|
||||
interactive:
|
||||
description: "Human-in-the-loop with menu navigation between steps"
|
||||
checkpoint_on_failure: true
|
||||
requires_approval: true
|
||||
smart_batching: true # User can approve batching plan
|
||||
batch:
|
||||
description: "Unattended execution for batch-super-dev"
|
||||
checkpoint_on_failure: true
|
||||
requires_approval: false
|
||||
fail_fast: true
|
||||
smart_batching: true # Auto-enabled for efficiency
|
||||
|
||||
# Smart batching configuration
|
||||
smart_batching:
|
||||
# Final verification checklist (main orchestrator)
|
||||
final_verification:
|
||||
enabled: true
|
||||
detect_patterns: true
|
||||
default_to_safe: true # When uncertain, execute individually
|
||||
min_batch_size: 3 # Minimum tasks to form a batch
|
||||
fallback_on_failure: true # Revert to individual if batch fails
|
||||
checks:
|
||||
- name: "git_commits"
|
||||
command: "git log --oneline -3 | grep {{story_key}}"
|
||||
failure_message: "No commit found for {{story_key}}"
|
||||
|
||||
# Batchable pattern definitions
|
||||
batchable_patterns:
|
||||
- pattern: "package_installation"
|
||||
keywords: ["Add", "package.json", "npm install", "dependency"]
|
||||
risk_level: "low"
|
||||
validation: "npm install && npm run build"
|
||||
- name: "story_checkboxes"
|
||||
command: |
|
||||
before=$(git show HEAD~1:{{story_file}} | grep -c '^- \[x\]')
|
||||
after=$(grep -c '^- \[x\]' {{story_file}})
|
||||
[ $after -gt $before ]
|
||||
failure_message: "Story checkboxes not updated"
|
||||
|
||||
- pattern: "module_registration"
|
||||
keywords: ["Import", "Module", "app.module", "register"]
|
||||
risk_level: "low"
|
||||
validation: "tsc --noEmit"
|
||||
- name: "sprint_status"
|
||||
command: "git diff HEAD~1 {{sprint_status}} | grep '{{story_key}}'"
|
||||
failure_message: "Sprint status not updated"
|
||||
|
||||
- pattern: "code_deletion"
|
||||
keywords: ["Delete", "Remove", "rm ", "unlink"]
|
||||
risk_level: "low"
|
||||
validation: "npm test && npm run build"
|
||||
- name: "tests_passed"
|
||||
# Parse agent output for test evidence
|
||||
validation: "inspector_output must contain 'PASS' or test count"
|
||||
failure_message: "No test evidence in validation output"
|
||||
|
||||
- pattern: "import_update"
|
||||
keywords: ["Update import", "Change import", "import from"]
|
||||
risk_level: "low"
|
||||
validation: "npm run build"
|
||||
|
||||
# Non-batchable pattern definitions (always execute individually)
|
||||
individual_patterns:
|
||||
- pattern: "business_logic"
|
||||
keywords: ["circuit breaker", "fallback", "caching for", "strategy"]
|
||||
risk_level: "medium"
|
||||
|
||||
- pattern: "security"
|
||||
keywords: ["auth", "permission", "security", "encrypt"]
|
||||
risk_level: "high"
|
||||
|
||||
- pattern: "data_migration"
|
||||
keywords: ["migration", "schema", "ALTER TABLE", "database"]
|
||||
risk_level: "high"
|
||||
|
||||
# Agent role definitions (loaded once, switched as needed)
|
||||
agents:
|
||||
dev:
|
||||
name: "Developer"
|
||||
persona: "{project-root}/_bmad/bmm/agents/dev.md"
|
||||
description: "Gap analysis, write tests, implementation, validation, review, fixes"
|
||||
used_in_steps: [2, 3, 4, 5, 6, 7, 8, 9]
|
||||
sm:
|
||||
name: "Scrum Master"
|
||||
persona: "{project-root}/_bmad/bmm/agents/sm.md"
|
||||
description: "Story completion, status updates, sprint-status.yaml management"
|
||||
used_in_steps: [10]
|
||||
|
||||
# Step file definitions (NEW v1.5.0: 11-step a-k workflow)
|
||||
steps:
|
||||
- step: 1
|
||||
file: "{steps_path}/step-01-init.md"
|
||||
name: "Init + Validate Story"
|
||||
description: "Load, validate, auto-create if needed (a-c)"
|
||||
agent: null
|
||||
quality_gate: false
|
||||
auto_create_story: true
|
||||
|
||||
- step: 2
|
||||
file: "{steps_path}/step-02-smart-gap-analysis.md"
|
||||
name: "Smart Gap Analysis"
|
||||
description: "Gap analysis (skip if just created story) (d)"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
skip_if_story_just_created: true
|
||||
|
||||
- step: 3
|
||||
file: "{steps_path}/step-03-write-tests.md"
|
||||
name: "Write Tests (TDD)"
|
||||
description: "Write tests before implementation (e)"
|
||||
agent: dev
|
||||
quality_gate: false
|
||||
test_driven: true
|
||||
|
||||
- step: 4
|
||||
file: "{steps_path}/step-04-implement.md"
|
||||
name: "Implement"
|
||||
description: "Run dev-story implementation (f)"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
|
||||
- step: 5
|
||||
file: "{steps_path}/step-05-post-validation.md"
|
||||
name: "Post-Validation"
|
||||
description: "Verify work actually implemented (g)"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
iterative: true
|
||||
|
||||
- step: 6
|
||||
file: "{steps_path}/step-06-run-quality-checks.md"
|
||||
name: "Quality Checks"
|
||||
description: "Tests, type check, linter - fix all (h)"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
blocking: true
|
||||
required_checks:
|
||||
- tests_passing
|
||||
- type_check_passing
|
||||
- lint_passing
|
||||
- coverage_threshold
|
||||
|
||||
- step: 7
|
||||
file: "{steps_path}/step-07-code-review.md"
|
||||
name: "Code Review"
|
||||
description: "Multi-agent review with fresh context (i)"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
requires_fresh_context: true
|
||||
multi_agent_review: true
|
||||
variable_agent_count: true
|
||||
|
||||
- step: 8
|
||||
file: "{steps_path}/step-08-review-analysis.md"
|
||||
name: "Review Analysis"
|
||||
description: "Analyze findings - reject gold plating (j)"
|
||||
agent: dev
|
||||
quality_gate: false
|
||||
critical_thinking: true
|
||||
|
||||
- step: 9
|
||||
file: "{steps_path}/step-09-fix-issues.md"
|
||||
name: "Fix Issues"
|
||||
description: "Implement MUST FIX and SHOULD FIX items"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
|
||||
- step: 10
|
||||
file: "{steps_path}/step-10-complete.md"
|
||||
name: "Complete + Update Status"
|
||||
description: "Mark done, update sprint-status.yaml (k)"
|
||||
agent: sm
|
||||
quality_gate: true
|
||||
mandatory_sprint_status_update: true
|
||||
verify_status_update: true
|
||||
|
||||
- step: 11
|
||||
file: "{steps_path}/step-11-summary.md"
|
||||
name: "Summary"
|
||||
description: "Generate comprehensive audit trail"
|
||||
agent: null
|
||||
quality_gate: false
|
||||
|
||||
# Quality gates
|
||||
quality_gates:
|
||||
pre_gap_analysis:
|
||||
step: 2
|
||||
criteria:
|
||||
- "All tasks validated or refined"
|
||||
- "No missing context"
|
||||
- "Implementation path clear"
|
||||
|
||||
implementation:
|
||||
step: 3
|
||||
criteria:
|
||||
- "All tasks completed"
|
||||
- "Tests pass"
|
||||
- "Code follows project patterns"
|
||||
|
||||
post_validation:
|
||||
step: 4
|
||||
criteria:
|
||||
- "All completed tasks verified against codebase"
|
||||
- "Zero false positives remaining"
|
||||
- "Files/functions/tests actually exist"
|
||||
|
||||
code_review:
|
||||
step: 5
|
||||
criteria:
|
||||
- "3-10 specific issues identified"
|
||||
- "All issues resolved or documented"
|
||||
- "Security review complete"
|
||||
|
||||
# Document loading strategies
|
||||
input_file_patterns:
|
||||
story:
|
||||
description: "Story file being developed"
|
||||
pattern: "{sprint_artifacts}/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
|
||||
# Backward compatibility
|
||||
fallback_to_v1:
|
||||
enabled: true
|
||||
condition: "execution_mode == 'single_agent'"
|
||||
workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
|
||||
|
||||
standalone: true
|
||||
|
|
|
|||
|
|
@ -1,218 +0,0 @@
|
|||
name: super-dev-pipeline
|
||||
description: "Step-file architecture with complexity-based routing, smart batching, and auto-story-creation. Micro stories get lightweight path, standard/complex get full quality gates."
|
||||
author: "BMad"
|
||||
version: "1.4.0" # Added auto-create story via /create-story-with-gap-analysis when story missing or incomplete
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/bmm/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
sprint_artifacts: "{config_source}:sprint_artifacts"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
|
||||
# Workflow paths
|
||||
installed_path: "{project-root}/_bmad/bmm/workflows/4-implementation/super-dev-pipeline"
|
||||
steps_path: "{installed_path}/steps"
|
||||
templates_path: "{installed_path}/templates"
|
||||
checklists_path: "{installed_path}/checklists"
|
||||
|
||||
# State management
|
||||
state_file: "{sprint_artifacts}/super-dev-state-{{story_id}}.yaml"
|
||||
audit_trail: "{sprint_artifacts}/audit-super-dev-{{story_id}}-{{date}}.yaml"
|
||||
|
||||
# Auto-create story settings (NEW v1.4.0)
|
||||
# When story is missing or lacks proper context, auto-invoke /create-story-with-gap-analysis
|
||||
auto_create_story:
|
||||
enabled: true # Set to false to revert to old HALT behavior
|
||||
create_story_workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story-with-gap-analysis"
|
||||
triggers:
|
||||
- story_not_found # Story file doesn't exist
|
||||
- no_tasks # Story exists but has no tasks
|
||||
- missing_sections # Story missing required sections (Tasks, Acceptance Criteria)
|
||||
|
||||
# Complexity level (passed from batch-super-dev or set manually)
|
||||
# Controls which pipeline steps to execute
|
||||
complexity_level: "standard" # micro | standard | complex
|
||||
|
||||
# Complexity-based step skipping (NEW v1.2.0)
|
||||
complexity_routing:
|
||||
micro:
|
||||
skip_steps: [2, 5] # Skip pre-gap analysis and code review
|
||||
description: "Lightweight path for simple stories (≤3 tasks, low risk)"
|
||||
standard:
|
||||
skip_steps: [] # Full pipeline
|
||||
description: "Normal path with all quality gates"
|
||||
complex:
|
||||
skip_steps: [] # Full pipeline + warnings
|
||||
description: "Enhanced path for high-risk stories"
|
||||
warn_before_start: true
|
||||
suggest_split: true
|
||||
|
||||
# Workflow modes
|
||||
modes:
|
||||
interactive:
|
||||
description: "Human-in-the-loop with menu navigation between steps"
|
||||
checkpoint_on_failure: true
|
||||
requires_approval: true
|
||||
smart_batching: true # User can approve batching plan
|
||||
batch:
|
||||
description: "Unattended execution for batch-super-dev"
|
||||
checkpoint_on_failure: true
|
||||
requires_approval: false
|
||||
fail_fast: true
|
||||
smart_batching: true # Auto-enabled for efficiency
|
||||
|
||||
# Smart batching configuration
|
||||
smart_batching:
|
||||
enabled: true
|
||||
detect_patterns: true
|
||||
default_to_safe: true # When uncertain, execute individually
|
||||
min_batch_size: 3 # Minimum tasks to form a batch
|
||||
fallback_on_failure: true # Revert to individual if batch fails
|
||||
|
||||
# Batchable pattern definitions
|
||||
batchable_patterns:
|
||||
- pattern: "package_installation"
|
||||
keywords: ["Add", "package.json", "npm install", "dependency"]
|
||||
risk_level: "low"
|
||||
validation: "npm install && npm run build"
|
||||
|
||||
- pattern: "module_registration"
|
||||
keywords: ["Import", "Module", "app.module", "register"]
|
||||
risk_level: "low"
|
||||
validation: "tsc --noEmit"
|
||||
|
||||
- pattern: "code_deletion"
|
||||
keywords: ["Delete", "Remove", "rm ", "unlink"]
|
||||
risk_level: "low"
|
||||
validation: "npm test && npm run build"
|
||||
|
||||
- pattern: "import_update"
|
||||
keywords: ["Update import", "Change import", "import from"]
|
||||
risk_level: "low"
|
||||
validation: "npm run build"
|
||||
|
||||
# Non-batchable pattern definitions (always execute individually)
|
||||
individual_patterns:
|
||||
- pattern: "business_logic"
|
||||
keywords: ["circuit breaker", "fallback", "caching for", "strategy"]
|
||||
risk_level: "medium"
|
||||
|
||||
- pattern: "security"
|
||||
keywords: ["auth", "permission", "security", "encrypt"]
|
||||
risk_level: "high"
|
||||
|
||||
- pattern: "data_migration"
|
||||
keywords: ["migration", "schema", "ALTER TABLE", "database"]
|
||||
risk_level: "high"
|
||||
|
||||
# Agent role definitions (loaded once, switched as needed)
|
||||
agents:
|
||||
dev:
|
||||
name: "Developer"
|
||||
persona: "{project-root}/_bmad/bmm/agents/dev.md"
|
||||
description: "Pre-gap, implementation, post-validation, code review"
|
||||
used_in_steps: [2, 3, 4, 5]
|
||||
sm:
|
||||
name: "Scrum Master"
|
||||
persona: "{project-root}/_bmad/bmm/agents/sm.md"
|
||||
description: "Story completion and status"
|
||||
used_in_steps: [6]
|
||||
|
||||
# Step file definitions
|
||||
steps:
|
||||
- step: 1
|
||||
file: "{steps_path}/step-01-init.md"
|
||||
name: "Initialize"
|
||||
description: "Load story context and detect development mode"
|
||||
agent: null
|
||||
quality_gate: false
|
||||
|
||||
- step: 2
|
||||
file: "{steps_path}/step-02-pre-gap-analysis.md"
|
||||
name: "Pre-Gap Analysis"
|
||||
description: "Validate tasks against codebase (critical for brownfield)"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
|
||||
- step: 3
|
||||
file: "{steps_path}/step-03-implement.md"
|
||||
name: "Implement"
|
||||
description: "Adaptive implementation (TDD for new, refactor for existing)"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
|
||||
- step: 4
|
||||
file: "{steps_path}/step-04-post-validation.md"
|
||||
name: "Post-Validation"
|
||||
description: "Verify completed tasks against codebase reality"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
iterative: true # May re-invoke step 3 if gaps found
|
||||
|
||||
- step: 5
|
||||
file: "{steps_path}/step-05-code-review.md"
|
||||
name: "Code Review"
|
||||
description: "Adversarial code review finding 3-10 issues"
|
||||
agent: dev
|
||||
quality_gate: true
|
||||
|
||||
- step: 6
|
||||
file: "{steps_path}/step-06-complete.md"
|
||||
name: "Complete"
|
||||
description: "Commit and push changes"
|
||||
agent: sm
|
||||
quality_gate: false
|
||||
|
||||
- step: 7
|
||||
file: "{steps_path}/step-07-summary.md"
|
||||
name: "Summary"
|
||||
description: "Generate audit trail"
|
||||
agent: null
|
||||
quality_gate: false
|
||||
|
||||
# Quality gates
|
||||
quality_gates:
|
||||
pre_gap_analysis:
|
||||
step: 2
|
||||
criteria:
|
||||
- "All tasks validated or refined"
|
||||
- "No missing context"
|
||||
- "Implementation path clear"
|
||||
|
||||
implementation:
|
||||
step: 3
|
||||
criteria:
|
||||
- "All tasks completed"
|
||||
- "Tests pass"
|
||||
- "Code follows project patterns"
|
||||
|
||||
post_validation:
|
||||
step: 4
|
||||
criteria:
|
||||
- "All completed tasks verified against codebase"
|
||||
- "Zero false positives remaining"
|
||||
- "Files/functions/tests actually exist"
|
||||
|
||||
code_review:
|
||||
step: 5
|
||||
criteria:
|
||||
- "3-10 specific issues identified"
|
||||
- "All issues resolved or documented"
|
||||
- "Security review complete"
|
||||
|
||||
# Document loading strategies
|
||||
input_file_patterns:
|
||||
story:
|
||||
description: "Story file being developed"
|
||||
pattern: "{sprint_artifacts}/story-*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
cache: true
|
||||
|
||||
project_context:
|
||||
description: "Critical rules and patterns"
|
||||
pattern: "**/project-context.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
cache: true
|
||||
|
||||
standalone: true
|
||||
Loading…
Reference in New Issue