bmad-method 6.0.0-alpha.0 → 6.0.0-alpha.1

package/src/modules/bmm/testarch/test-levels-framework.md

@@ -1,148 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Test Levels Framework
-
-Comprehensive guide for determining appropriate test levels (unit, integration, E2E) for different scenarios.
-
-## Test Level Decision Matrix
-
-### Unit Tests
-
-**When to use:**
-
-- Testing pure functions and business logic
-- Algorithm correctness
-- Input validation and data transformation
-- Error handling in isolated components
-- Complex calculations or state machines
-
-**Characteristics:**
-
-- Fast execution (immediate feedback)
-- No external dependencies (DB, API, file system)
-- Highly maintainable and stable
-- Easy to debug failures
-
-**Example scenarios:**
-
-```yaml
-unit_test:
-  component: 'PriceCalculator'
-  scenario: 'Calculate discount with multiple rules'
-  justification: 'Complex business logic with multiple branches'
-  mock_requirements: 'None - pure function'
-```
-
-### Integration Tests
-
-**When to use:**
-
-- Component interaction verification
-- Database operations and transactions
-- API endpoint contracts
-- Service-to-service communication
-- Middleware and interceptor behavior
-
-**Characteristics:**
-
-- Moderate execution time
-- Tests component boundaries
-- May use test databases or containers
-- Validates system integration points
-
-**Example scenarios:**
-
-```yaml
-integration_test:
-  components: ['UserService', 'AuthRepository']
-  scenario: 'Create user with role assignment'
-  justification: 'Critical data flow between service and persistence'
-  test_environment: 'In-memory database'
-```
-
-### End-to-End Tests
-
-**When to use:**
-
-- Critical user journeys
-- Cross-system workflows
-- Visual regression testing
-- Compliance and regulatory requirements
-- Final validation before release
-
-**Characteristics:**
-
-- Slower execution
-- Tests complete workflows
-- Requires full environment setup
-- Most realistic but most brittle
-
-**Example scenarios:**
-
-```yaml
-e2e_test:
-  journey: 'Complete checkout process'
-  scenario: 'User purchases with saved payment method'
-  justification: 'Revenue-critical path requiring full validation'
-  environment: 'Staging with test payment gateway'
-```
-
-## Test Level Selection Rules
-
-### Favor Unit Tests When:
-
-- Logic can be isolated
-- No side effects involved
-- Fast feedback needed
-- High cyclomatic complexity
-
-### Favor Integration Tests When:
-
-- Testing persistence layer
-- Validating service contracts
-- Testing middleware/interceptors
-- Component boundaries critical
-
-### Favor E2E Tests When:
-
-- User-facing critical paths
-- Multi-system interactions
-- Regulatory compliance scenarios
-- Visual regression important
-
-## Anti-patterns to Avoid
-
-- E2E testing for business logic validation
-- Unit testing framework behavior
-- Integration testing third-party libraries
-- Duplicate coverage across levels
-
-## Duplicate Coverage Guard
-
-**Before adding any test, check:**
-
-1. Is this already tested at a lower level?
-2. Can a unit test cover this instead of integration?
-3. Can an integration test cover this instead of E2E?
-
-**Coverage overlap is only acceptable when:**
-
-- Testing different aspects (unit: logic, integration: interaction, e2e: user experience)
-- Critical paths requiring defense in depth
-- Regression prevention for previously broken functionality
-
-## Test Naming Conventions
-
-- Unit: `test_{component}_{scenario}`
-- Integration: `test_{flow}_{interaction}`
-- E2E: `test_{journey}_{outcome}`
-
-## Test ID Format
-
-`{EPIC}.{STORY}-{LEVEL}-{SEQ}`
-
-Examples:
-
-- `1.3-UNIT-001`
-- `1.3-INT-002`
-- `1.3-E2E-001`

package/src/modules/bmm/testarch/test-priorities-matrix.md

@@ -1,174 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Test Priorities Matrix
-
-Guide for prioritizing test scenarios based on risk, criticality, and business impact.
-
-## Priority Levels
-
-### P0 - Critical (Must Test)
-
-**Criteria:**
-
-- Revenue-impacting functionality
-- Security-critical paths
-- Data integrity operations
-- Regulatory compliance requirements
-- Previously broken functionality (regression prevention)
-
-**Examples:**
-
-- Payment processing
-- Authentication/authorization
-- User data creation/deletion
-- Financial calculations
-- GDPR/privacy compliance
-
-**Testing Requirements:**
-
-- Comprehensive coverage at all levels
-- Both happy and unhappy paths
-- Edge cases and error scenarios
-- Performance under load
-
-### P1 - High (Should Test)
-
-**Criteria:**
-
-- Core user journeys
-- Frequently used features
-- Features with complex logic
-- Integration points between systems
-- Features affecting user experience
-
-**Examples:**
-
-- User registration flow
-- Search functionality
-- Data import/export
-- Notification systems
-- Dashboard displays
-
-**Testing Requirements:**
-
-- Primary happy paths required
-- Key error scenarios
-- Critical edge cases
-- Basic performance validation
-
-### P2 - Medium (Nice to Test)
-
-**Criteria:**
-
-- Secondary features
-- Admin functionality
-- Reporting features
-- Configuration options
-- UI polish and aesthetics
-
-**Examples:**
-
-- Admin settings panels
-- Report generation
-- Theme customization
-- Help documentation
-- Analytics tracking
-
-**Testing Requirements:**
-
-- Happy path coverage
-- Basic error handling
-- Can defer edge cases
-
-### P3 - Low (Test if Time Permits)
-
-**Criteria:**
-
-- Rarely used features
-- Nice-to-have functionality
-- Cosmetic issues
-- Non-critical optimizations
-
-**Examples:**
-
-- Advanced preferences
-- Legacy feature support
-- Experimental features
-- Debug utilities
-
-**Testing Requirements:**
-
-- Smoke tests only
-- Can rely on manual testing
-- Document known limitations
-
-## Risk-Based Priority Adjustments
-
-### Increase Priority When:
-
-- High user impact (affects >50% of users)
-- High financial impact (>$10K potential loss)
-- Security vulnerability potential
-- Compliance/legal requirements
-- Customer-reported issues
-- Complex implementation (>500 LOC)
-- Multiple system dependencies
-
-### Decrease Priority When:
-
-- Feature flag protected
-- Gradual rollout planned
-- Strong monitoring in place
-- Easy rollback capability
-- Low usage metrics
-- Simple implementation
-- Well-isolated component
-
-## Test Coverage by Priority
-
-| Priority | Unit Coverage | Integration Coverage | E2E Coverage       |
-| -------- | ------------- | -------------------- | ------------------ |
-| P0       | >90%          | >80%                 | All critical paths |
-| P1       | >80%          | >60%                 | Main happy paths   |
-| P2       | >60%          | >40%                 | Smoke tests        |
-| P3       | Best effort   | Best effort          | Manual only        |
-
-## Priority Assignment Rules
-
-1. **Start with business impact** - What happens if this fails?
-2. **Consider probability** - How likely is failure?
-3. **Factor in detectability** - Would we know if it failed?
-4. **Account for recoverability** - Can we fix it quickly?
-
-## Priority Decision Tree
-
-```
-Is it revenue-critical?
-├─ YES → P0
-└─ NO → Does it affect core user journey?
-    ├─ YES → Is it high-risk?
-    │   ├─ YES → P0
-    │   └─ NO → P1
-    └─ NO → Is it frequently used?
-        ├─ YES → P1
-        └─ NO → Is it customer-facing?
-            ├─ YES → P2
-            └─ NO → P3
-```
-
-## Test Execution Order
-
-1. Execute P0 tests first (fail fast on critical issues)
-2. Execute P1 tests second (core functionality)
-3. Execute P2 tests if time permits
-4. P3 tests only in full regression cycles
-
-## Continuous Adjustment
-
-Review and adjust priorities based on:
-
-- Production incident patterns
-- User feedback and complaints
-- Usage analytics
-- Test failure history
-- Business priority changes

package/src/modules/bmm/testarch/trace-requirements.md

@@ -1,38 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Requirements Traceability v2.0 (Slim)
-
-```xml
-<task id="bmad/bmm/testarch/trace" name="Requirements Traceability">
-  <llm critical="true">
-    <i>Set command_key="*trace"</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and read the matching row</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md emphasising assertions guidance</i>
-    <i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags</i>
-    <i>Split pipe-delimited values into actionable lists</i>
-    <i>Focus on mapping reality: reference actual files, describe coverage gaps, recommend next steps</i>
-  </llm>
-  <flow>
-    <step n="1" title="Preflight">
-      <action>Validate prerequisites; halt per halt_rules if unmet</action>
-    </step>
-    <step n="2" title="Traceability Analysis">
-      <action>Follow flow_cues to map acceptance criteria to implemented tests</action>
-      <action>Leverage knowledge heuristics to highlight assertion quality and duplication risks</action>
-    </step>
-    <step n="3" title="Deliverables">
-      <action>Create traceability report described in deliverables</action>
-      <action>Summarize critical gaps and recommendations</action>
-    </step>
-  </flow>
-  <halt>
-    <i>Apply halt_rules from the CSV row</i>
-  </halt>
-  <notes>
-    <i>Reference notes column for additional emphasis</i>
-  </notes>
-  <output>
-    <i>Coverage matrix and narrative summary</i>
-  </output>
-</task>
-```

package/src/modules/bmm/workflows/2-plan/README.md

@@ -1,203 +0,0 @@
-# Project Planning Workflow
-
-## Overview
-
-Scale-adaptive project planning workflow that automatically adjusts outputs based on project scope - from single atomic changes (Level 0: tech-spec only) to enterprise platforms (Level 4: full PRD + epics). Generates appropriate planning artifacts for each level with intelligent routing and continuation support.
-
-## Key Features
-
-- **Scale-adaptive planning** - Automatically determines output based on project complexity
-- **Intelligent routing** - Uses router system to load appropriate instruction sets
-- **Continuation support** - Can resume from previous sessions and handle incremental work
-- **Multi-level outputs** - Supports 5 project levels (0-4) with appropriate artifacts
-- **Input integration** - Leverages product briefs and market research when available
-- **Template-driven** - Uses validated templates for consistent output structure
-
-## Usage
-
-### Basic Invocation
-
-```bash
-workflow plan-project
-```
-
-### With Input Documents
-
-```bash
-# With product brief as input
-workflow plan-project --input /path/to/product-brief.md
-
-# With multiple inputs
-workflow plan-project --input product-brief.md --input market-research.md
-```
-
-### Configuration
-
-The workflow adapts automatically based on project assessment, but key configuration options include:
-
-- **scale_parameters**: Defines story/epic counts for each project level
-- **output_folder**: Where all generated documents are stored
-- **project_name**: Used in document names and templates
-
-## Workflow Structure
-
-### Files Included
-
-```
-plan-project/
-├── workflow.yaml              # Configuration and metadata
-├── instructions-router.md     # Initial assessment and routing logic
-├── instructions-sm.md         # Level 0 instructions (tech-spec only)
-├── instructions-med.md        # Level 1-2 instructions (PRD + tech-spec)
-├── instructions-lg.md         # Level 3-4 instructions (full PRD + epics)
-├── analysis-template.md       # Project assessment template
-├── prd-template.md           # Product Requirements Document template
-├── tech-spec-template.md     # Technical Specification template
-├── epics-template.md         # Epic breakdown template
-├── checklist.md              # Validation criteria
-└── README.md                 # This file
-```
-
-## Workflow Process
-
-### Phase 1: Assessment and Routing (Steps 1-5)
-
-- **Project Analysis**: Determines project type (greenfield/brownfield/legacy)
-- **Scope Assessment**: Classifies into 5 levels based on complexity
-- **Document Discovery**: Identifies existing inputs and documentation
-- **Workflow Routing**: Loads appropriate instruction set based on level
-- **Continuation Handling**: Resumes from previous work when applicable
-
-### Phase 2: Level-Specific Planning (Steps vary by level)
-
-**Level 0 (Single Atomic Change)**:
-
-- Creates technical specification only
-- Focuses on implementation details for small changes
-
-**Level 1-2 (Features and Small Systems)**:
-
-- Generates minimal PRD with core sections
-- Creates comprehensive tech-spec
-- Includes basic epic breakdown
-
-**Level 3-4 (Full Products and Platforms)**:
-
-- Produces complete PRD with all sections
-- Generates detailed epic breakdown
-- Includes architect handoff materials
-- Creates traceability mapping
-
-### Phase 3: Validation and Handoff (Final steps)
-
-- **Document Review**: Validates outputs against checklists
-- **Architect Preparation**: For Level 3-4, prepares handoff materials
-- **Next Steps**: Provides guidance for development phase
-
-## Output
-
-### Generated Files
-
-- **Primary output**: PRD.md (except Level 0), tech-spec.md, project-workflow-analysis.md
-- **Supporting files**: epics.md (Level 3-4), PRD-validation-report.md (if validation run)
-
-### Output Structure by Level
-
-**Level 0 - Tech Spec Only**:
-
-1. **Technical Overview** - Implementation approach
-2. **Detailed Design** - Code-level specifications
-3. **Testing Strategy** - Validation approach
-
-**Level 1-2 - Minimal PRD + Tech Spec**:
-
-1. **Problem Statement** - Core issue definition
-2. **Solution Overview** - High-level approach
-3. **Requirements** - Functional and non-functional
-4. **Technical Specification** - Implementation details
-5. **Success Criteria** - Acceptance criteria
-
-**Level 3-4 - Full PRD + Epics**:
-
-1. **Executive Summary** - Project overview
-2. **Problem Definition** - Detailed problem analysis
-3. **Solution Architecture** - Comprehensive solution design
-4. **User Experience** - Journey mapping and wireframes
-5. **Requirements** - Complete functional/non-functional specs
-6. **Epic Breakdown** - Development phases and stories
-7. **Technical Handoff** - Architecture and implementation guidance
-
-## Requirements
-
-- **Input Documents**: Product brief and/or market research (recommended but not required)
-- **Project Configuration**: Valid config.yaml with project_name and output_folder
-- **Assessment Readiness**: Clear understanding of project scope and objectives
-
-## Best Practices
-
-### Before Starting
-
-1. **Gather Context**: Collect any existing product briefs, market research, or requirements
-2. **Define Scope**: Have a clear sense of project boundaries and complexity
-3. **Prepare Stakeholders**: Ensure key stakeholders are available for input if needed
-
-### During Execution
-
-1. **Be Honest About Scope**: Accurate assessment ensures appropriate planning depth
-2. **Leverage Existing Work**: Reference previous documents and avoid duplication
-3. **Think Incrementally**: Remember that planning can evolve - start with what you know
-
-### After Completion
-
-1. **Validate Against Checklist**: Use included validation criteria to ensure completeness
-2. **Share with Stakeholders**: Distribute appropriate documents to relevant team members
-3. **Prepare for Architecture**: For Level 3-4 projects, ensure architect has complete context
-
-## Troubleshooting
-
-### Common Issues
-
-**Issue**: Workflow creates wrong level of documentation
-
-- **Solution**: Review project assessment and restart with correct scope classification
-- **Check**: Verify the project-workflow-analysis.md reflects actual project complexity
-
-**Issue**: Missing input documents cause incomplete planning
-
-- **Solution**: Gather recommended inputs or proceed with manual context gathering
-- **Check**: Ensure critical business context is captured even without formal documents
-
-**Issue**: Continuation from previous session fails
-
-- **Solution**: Check for existing project-workflow-analysis.md and ensure output folder is correct
-- **Check**: Verify previous session completed at a valid checkpoint
-
-## Customization
-
-To customize this workflow:
-
-1. **Modify Assessment Logic**: Update instructions-router.md to adjust level classification
-2. **Adjust Templates**: Customize PRD, tech-spec, or epic templates for organizational needs
-3. **Add Validation**: Extend checklist.md with organization-specific quality criteria
-4. **Configure Outputs**: Modify workflow.yaml to change file naming or structure
-
-## Version History
-
-- **v6.0.0** - Scale-adaptive architecture with intelligent routing
-  - Multi-level project support (0-4)
-  - Continuation and resumption capabilities
-  - Template-driven output generation
-  - Input document integration
-
-## Support
-
-For issues or questions:
-
-- Review the workflow creation guide at `/bmad/bmb/workflows/build-workflow/workflow-creation-guide.md`
-- Validate output using `checklist.md`
-- Consult project assessment in `project-workflow-analysis.md`
-- Check continuation status in existing output documents
-
----
-
-_Part of the BMad Method v6 - BMM (Method) Module_