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

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/1-analysis/brainstorm-game/instructions.md

@@ -1,47 +0,0 @@
-# Brainstorm Game - Workflow Instructions
-
-```xml
-<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.md</critical>
-<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>This is a meta-workflow that orchestrates the CIS brainstorming workflow with game-specific context and additional game design techniques</critical>
-
-<workflow>
-
-  <step n="1" goal="Load game brainstorming context and techniques">
-    <action>Read the game context document from: {game_context}</action>
-    <action>This context provides game-specific guidance including:
-      - Focus areas for game ideation (mechanics, narrative, experience, etc.)
-      - Key considerations for game design
-      - Recommended techniques for game brainstorming
-      - Output structure guidance
-    </action>
-    <action>Load game-specific brain techniques from: {game_brain_methods}</action>
-    <action>These additional techniques supplement the standard CIS brainstorming methods with game design-focused approaches like:
-      - MDA Framework exploration
-      - Core loop brainstorming
-      - Player fantasy mining
-      - Genre mashup
-      - And other game-specific ideation methods
-    </action>
-  </step>
-
-  <step n="2" goal="Invoke CIS brainstorming with game context">
-    <action>Execute the CIS brainstorming workflow with game context and additional techniques</action>
-    <invoke-workflow path="{cis_brainstorming}" data="{game_context}" techniques="{game_brain_methods}">
-      The CIS brainstorming workflow will:
-      - Merge game-specific techniques with standard techniques
-      - Present interactive brainstorming techniques menu
-      - Guide the user through selected ideation methods
-      - Generate and capture brainstorming session results
-      - Save output to: {output_folder}/brainstorming-session-results-{{date}}.md
-    </invoke-workflow>
-  </step>
-
-  <step n="3" goal="Completion">
-    <action>Confirm brainstorming session completed successfully</action>
-    <action>Brainstorming results saved by CIS workflow</action>
-    <action>Report workflow completion</action>
-  </step>
-
-</workflow>
-```

package/src/modules/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml

@@ -1,22 +0,0 @@
-# Brainstorm Game Workflow Configuration
-name: "brainstorm-game"
-description: "Facilitate game brainstorming sessions by orchestrating the CIS brainstorming workflow with game-specific context, guidance, and additional game design techniques."
-author: "BMad"
-
-# Critical variables load from config_source
-config_source: "{project-root}/bmad/bmm/config.yaml"
-output_folder: "{config_source}:output_folder"
-user_name: "{config_source}:user_name"
-date: system-generated
-
-# Module path and component files
-installed_path: "{project-root}/bmad/bmm/workflows/1-analysis/brainstorm-game"
-template: false
-instructions: "{installed_path}/instructions.md"
-
-# Context and techniques for game brainstorming
-game_context: "{installed_path}/game-context.md"
-game_brain_methods: "{installed_path}/game-brain-methods.csv"
-
-# CIS brainstorming workflow to invoke
-cis_brainstorming: "{project-root}/bmad/cis/workflows/brainstorming/workflow.yaml"

package/src/modules/bmm/workflows/1-analysis/game-brief/README.md

@@ -1,221 +0,0 @@
-# Game Brief Workflow
-
-## Overview
-
-The Game Brief workflow is the starting point for game projects in the BMad Method. It's a lightweight, interactive brainstorming and planning session that captures your game vision before diving into detailed Game Design Documents (GDD).
-
-## Purpose
-
-**Game Brief answers:**
-
-- What game are you making?
-- Who is it for?
-- What makes it unique?
-- Is it feasible?
-
-**This is NOT:**
-
-- A full Game Design Document
-- A technical specification
-- A production plan
-- A detailed content outline
-
-## When to Use This Workflow
-
-Use the game-brief workflow when:
-
-- Starting a new game project from scratch
-- Exploring a game idea before committing
-- Pitching a concept to team/stakeholders
-- Validating market fit and feasibility
-- Preparing input for the GDD workflow
-
-Skip if:
-
-- You already have a complete GDD
-- Continuing an existing project
-- Prototyping without planning needs
-
-## Workflow Structure
-
-### Interactive Mode (Recommended)
-
-Work through each section collaboratively:
-
-1. Game Vision (concept, pitch, vision statement)
-2. Target Market (audience, competition, positioning)
-3. Game Fundamentals (pillars, mechanics, experience goals)
-4. Scope and Constraints (platforms, timeline, budget, team)
-5. Reference Framework (inspiration, competitors, differentiators)
-6. Content Framework (world, narrative, volume)
-7. Art & Audio Direction (visual and audio style)
-8. Risk Assessment (risks, challenges, mitigation)
-9. Success Criteria (MVP, metrics, launch goals)
-10. Next Steps (immediate actions, research, questions)
-
-### YOLO Mode
-
-AI generates complete draft, then you refine sections iteratively.
-
-## Key Features
-
-### Optional Inputs
-
-The workflow can incorporate:
-
-- Market research
-- Brainstorming results
-- Competitive analysis
-- Design notes
-- Reference game lists
-
-### Realistic Scoping
-
-The workflow actively helps you:
-
-- Identify scope vs. resource mismatches
-- Assess technical feasibility
-- Recognize market risks
-- Plan mitigation strategies
-
-### Clear Handoff
-
-Output is designed to feed directly into:
-
-- GDD workflow (2-plan phase)
-- Prototyping decisions
-- Team discussions
-- Stakeholder presentations
-
-## Output
-
-**game-brief-{game_name}-{date}.md** containing:
-
-- Executive summary
-- Complete game vision
-- Target market analysis
-- Core gameplay definition
-- Scope and constraints
-- Reference framework
-- Art/audio direction
-- Risk assessment
-- Success criteria
-- Next steps
-
-## Integration with BMad Method
-
-```
-1-analysis/game-brief     (You are here)
-    ↓
-2-plan/gdd               (Game Design Document)
-    ↓
-2-plan/narrative         (Optional: Story-heavy games)
-    ↓
-3-solutioning            (Technical architecture, engine selection)
-    ↓
-4-dev-stories            (Implementation stories)
-```
-
-## Comparison: Game Brief vs. GDD
-
-| Aspect              | Game Brief                  | GDD                       |
-| ------------------- | --------------------------- | ------------------------- |
-| **Purpose**         | Validate concept            | Design for implementation |
-| **Detail Level**    | High-level vision           | Detailed specifications   |
-| **Time Investment** | 1-2 hours                   | 4-10 hours                |
-| **Audience**        | Self, team, stakeholders    | Development team          |
-| **Scope**           | Concept validation          | Implementation roadmap    |
-| **Format**          | Conversational, exploratory | Structured, comprehensive |
-| **Output**          | 3-5 pages                   | 10-30+ pages              |
-
-## Comparison: Game Brief vs. Product Brief
-
-| Aspect            | Game Brief                   | Product Brief                     |
-| ----------------- | ---------------------------- | --------------------------------- |
-| **Focus**         | Player experience, fun, feel | User problems, features, value    |
-| **Metrics**       | Engagement, retention, fun   | Revenue, conversion, satisfaction |
-| **Core Elements** | Gameplay pillars, mechanics  | Problem/solution, user segments   |
-| **References**    | Other games                  | Competitors, market               |
-| **Vision**        | Emotional experience         | Business outcomes                 |
-
-## Example Use Case
-
-### Scenario: Indie Roguelike Card Game
-
-**Starting Point:**
-"I want to make a roguelike card game with a twist"
-
-**After Game Brief:**
-
-- **Core Concept:** "A roguelike card battler where you play as emotions battling inner demons"
-- **Target Audience:** Core gamers who love Slay the Spire, interested in mental health themes
-- **Differentiator:** Emotional narrative system where deck composition affects story
-- **MVP Scope:** 3 characters, 80 cards, 30 enemy types, 3 bosses, 6-hour first run
-- **Platform:** PC (Steam) first, mobile later
-- **Timeline:** 12 months with 2-person team
-- **Key Risk:** Emotional theme might alienate hardcore roguelike fans
-- **Mitigation:** Prototype early, test with target audience, offer "mechanical-only" mode
-
-**Next Steps:**
-
-1. Build card combat prototype (2 weeks)
-2. Test emotional resonance with players
-3. Proceed to GDD workflow if prototype validates
-
-## Tips for Success
-
-### Be Honest About Scope
-
-The most common game dev failure is scope mismatch. Use this workflow to reality-check:
-
-- Can your team actually build this?
-- Is the timeline realistic?
-- Do you have budget for assets?
-
-### Focus on Player Experience
-
-Don't think about code or implementation. Think about:
-
-- What will players DO?
-- How will they FEEL?
-- Why will they CARE?
-
-### Validate Early
-
-The brief identifies assumptions and risks. Don't skip to GDD without:
-
-- Prototyping risky mechanics
-- Testing with target audience
-- Validating market interest
-
-### Use References Wisely
-
-"Like X but with Y" is a starting point, not a differentiator. Push beyond:
-
-- What specifically from reference games?
-- What are you explicitly NOT doing?
-- What's genuinely new?
-
-## FAQ
-
-**Q: Is this required before GDD?**
-A: No, but highly recommended for new projects. You can start directly with GDD if you have a clear vision.
-
-**Q: Can I use this for game jams?**
-A: Yes, but use YOLO mode for speed. Focus on vision, mechanics, and MVP scope.
-
-**Q: What if my game concept changes?**
-A: Revisit and update the brief. It's a living document during early development.
-
-**Q: How detailed should content volume estimates be?**
-A: Rough orders of magnitude are fine. "~50 enemies" not "47 enemies with 3 variants each."
-
-**Q: Should I complete this alone or with my team?**
-A: Involve your team! Collaborative briefs catch blind spots and build shared vision.
-
-## Related Workflows
-
-- **Product Brief** (`1-analysis/product-brief`): For software products, not games
-- **GDD** (`2-plan/gdd`): Next step after game brief
-- **Narrative Design** (`2-plan/narrative`): For story-heavy games after GDD
-- **Solutioning** (`3-solutioning`): Technical architecture after planning