bmad-method 5.1.3 → 6.0.0-Beta.1

package/bmad-core/tasks/risk-profile.md

@@ -1,353 +0,0 @@
-# risk-profile
-
-Generate a comprehensive risk assessment matrix for a story implementation using probability × impact analysis.
-
-## Inputs
-
-```yaml
-required:
-  - story_id: '{epic}.{story}' # e.g., "1.3"
-  - story_path: 'docs/stories/{epic}.{story}.*.md'
-  - story_title: '{title}' # If missing, derive from story file H1
-  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
-```
-
-## Purpose
-
-Identify, assess, and prioritize risks in the story implementation. Provide risk mitigation strategies and testing focus areas based on risk levels.
-
-## Risk Assessment Framework
-
-### Risk Categories
-
-**Category Prefixes:**
-
-- `TECH`: Technical Risks
-- `SEC`: Security Risks
-- `PERF`: Performance Risks
-- `DATA`: Data Risks
-- `BUS`: Business Risks
-- `OPS`: Operational Risks
-
-1. **Technical Risks (TECH)**
-   - Architecture complexity
-   - Integration challenges
-   - Technical debt
-   - Scalability concerns
-   - System dependencies
-
-2. **Security Risks (SEC)**
-   - Authentication/authorization flaws
-   - Data exposure vulnerabilities
-   - Injection attacks
-   - Session management issues
-   - Cryptographic weaknesses
-
-3. **Performance Risks (PERF)**
-   - Response time degradation
-   - Throughput bottlenecks
-   - Resource exhaustion
-   - Database query optimization
-   - Caching failures
-
-4. **Data Risks (DATA)**
-   - Data loss potential
-   - Data corruption
-   - Privacy violations
-   - Compliance issues
-   - Backup/recovery gaps
-
-5. **Business Risks (BUS)**
-   - Feature doesn't meet user needs
-   - Revenue impact
-   - Reputation damage
-   - Regulatory non-compliance
-   - Market timing
-
-6. **Operational Risks (OPS)**
-   - Deployment failures
-   - Monitoring gaps
-   - Incident response readiness
-   - Documentation inadequacy
-   - Knowledge transfer issues
-
-## Risk Analysis Process
-
-### 1. Risk Identification
-
-For each category, identify specific risks:
-
-```yaml
-risk:
-  id: 'SEC-001' # Use prefixes: SEC, PERF, DATA, BUS, OPS, TECH
-  category: security
-  title: 'Insufficient input validation on user forms'
-  description: 'Form inputs not properly sanitized could lead to XSS attacks'
-  affected_components:
-    - 'UserRegistrationForm'
-    - 'ProfileUpdateForm'
-  detection_method: 'Code review revealed missing validation'
-```
-
-### 2. Risk Assessment
-
-Evaluate each risk using probability × impact:
-
-**Probability Levels:**
-
-- `High (3)`: Likely to occur (>70% chance)
-- `Medium (2)`: Possible occurrence (30-70% chance)
-- `Low (1)`: Unlikely to occur (<30% chance)
-
-**Impact Levels:**
-
-- `High (3)`: Severe consequences (data breach, system down, major financial loss)
-- `Medium (2)`: Moderate consequences (degraded performance, minor data issues)
-- `Low (1)`: Minor consequences (cosmetic issues, slight inconvenience)
-
-**Risk Score = Probability × Impact**
-
-- 9: Critical Risk (Red)
-- 6: High Risk (Orange)
-- 4: Medium Risk (Yellow)
-- 2-3: Low Risk (Green)
-- 1: Minimal Risk (Blue)
-
-### 3. Risk Prioritization
-
-Create risk matrix:
-
-```markdown
-## Risk Matrix
-
-| Risk ID  | Description             | Probability | Impact     | Score | Priority |
-| -------- | ----------------------- | ----------- | ---------- | ----- | -------- |
-| SEC-001  | XSS vulnerability       | High (3)    | High (3)   | 9     | Critical |
-| PERF-001 | Slow query on dashboard | Medium (2)  | Medium (2) | 4     | Medium   |
-| DATA-001 | Backup failure          | Low (1)     | High (3)   | 3     | Low      |
-```
-
-### 4. Risk Mitigation Strategies
-
-For each identified risk, provide mitigation:
-
-```yaml
-mitigation:
-  risk_id: 'SEC-001'
-  strategy: 'preventive' # preventive|detective|corrective
-  actions:
-    - 'Implement input validation library (e.g., validator.js)'
-    - 'Add CSP headers to prevent XSS execution'
-    - 'Sanitize all user inputs before storage'
-    - 'Escape all outputs in templates'
-  testing_requirements:
-    - 'Security testing with OWASP ZAP'
-    - 'Manual penetration testing of forms'
-    - 'Unit tests for validation functions'
-  residual_risk: 'Low - Some zero-day vulnerabilities may remain'
-  owner: 'dev'
-  timeline: 'Before deployment'
-```
-
-## Outputs
-
-### Output 1: Gate YAML Block
-
-Generate for pasting into gate file under `risk_summary`:
-
-**Output rules:**
-
-- Only include assessed risks; do not emit placeholders
-- Sort risks by score (desc) when emitting highest and any tabular lists
-- If no risks: totals all zeros, omit highest, keep recommendations arrays empty
-
-```yaml
-# risk_summary (paste into gate file):
-risk_summary:
-  totals:
-    critical: X # score 9
-    high: Y # score 6
-    medium: Z # score 4
-    low: W # score 2-3
-  highest:
-    id: SEC-001
-    score: 9
-    title: 'XSS on profile form'
-  recommendations:
-    must_fix:
-      - 'Add input sanitization & CSP'
-    monitor:
-      - 'Add security alerts for auth endpoints'
-```
-
-### Output 2: Markdown Report
-
-**Save to:** `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`
-
-```markdown
-# Risk Profile: Story {epic}.{story}
-
-Date: {date}
-Reviewer: Quinn (Test Architect)
-
-## Executive Summary
-
-- Total Risks Identified: X
-- Critical Risks: Y
-- High Risks: Z
-- Risk Score: XX/100 (calculated)
-
-## Critical Risks Requiring Immediate Attention
-
-### 1. [ID]: Risk Title
-
-**Score: 9 (Critical)**
-**Probability**: High - Detailed reasoning
-**Impact**: High - Potential consequences
-**Mitigation**:
-
-- Immediate action required
-- Specific steps to take
-  **Testing Focus**: Specific test scenarios needed
-
-## Risk Distribution
-
-### By Category
-
-- Security: X risks (Y critical)
-- Performance: X risks (Y critical)
-- Data: X risks (Y critical)
-- Business: X risks (Y critical)
-- Operational: X risks (Y critical)
-
-### By Component
-
-- Frontend: X risks
-- Backend: X risks
-- Database: X risks
-- Infrastructure: X risks
-
-## Detailed Risk Register
-
-[Full table of all risks with scores and mitigations]
-
-## Risk-Based Testing Strategy
-
-### Priority 1: Critical Risk Tests
-
-- Test scenarios for critical risks
-- Required test types (security, load, chaos)
-- Test data requirements
-
-### Priority 2: High Risk Tests
-
-- Integration test scenarios
-- Edge case coverage
-
-### Priority 3: Medium/Low Risk Tests
-
-- Standard functional tests
-- Regression test suite
-
-## Risk Acceptance Criteria
-
-### Must Fix Before Production
-
-- All critical risks (score 9)
-- High risks affecting security/data
-
-### Can Deploy with Mitigation
-
-- Medium risks with compensating controls
-- Low risks with monitoring in place
-
-### Accepted Risks
-
-- Document any risks team accepts
-- Include sign-off from appropriate authority
-
-## Monitoring Requirements
-
-Post-deployment monitoring for:
-
-- Performance metrics for PERF risks
-- Security alerts for SEC risks
-- Error rates for operational risks
-- Business KPIs for business risks
-
-## Risk Review Triggers
-
-Review and update risk profile when:
-
-- Architecture changes significantly
-- New integrations added
-- Security vulnerabilities discovered
-- Performance issues reported
-- Regulatory requirements change
-```
-
-## Risk Scoring Algorithm
-
-Calculate overall story risk score:
-
-```
-Base Score = 100
-For each risk:
-  - Critical (9): Deduct 20 points
-  - High (6): Deduct 10 points
-  - Medium (4): Deduct 5 points
-  - Low (2-3): Deduct 2 points
-
-Minimum score = 0 (extremely risky)
-Maximum score = 100 (minimal risk)
-```
-
-## Risk-Based Recommendations
-
-Based on risk profile, recommend:
-
-1. **Testing Priority**
-   - Which tests to run first
-   - Additional test types needed
-   - Test environment requirements
-
-2. **Development Focus**
-   - Code review emphasis areas
-   - Additional validation needed
-   - Security controls to implement
-
-3. **Deployment Strategy**
-   - Phased rollout for high-risk changes
-   - Feature flags for risky features
-   - Rollback procedures
-
-4. **Monitoring Setup**
-   - Metrics to track
-   - Alerts to configure
-   - Dashboard requirements
-
-## Integration with Quality Gates
-
-**Deterministic gate mapping:**
-
-- Any risk with score ≥ 9 → Gate = FAIL (unless waived)
-- Else if any score ≥ 6 → Gate = CONCERNS
-- Else → Gate = PASS
-- Unmitigated risks → Document in gate
-
-### Output 3: Story Hook Line
-
-**Print this line for review task to quote:**
-
-```
-Risk profile: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
-```
-
-## Key Principles
-
-- Identify risks early and systematically
-- Use consistent probability × impact scoring
-- Provide actionable mitigation strategies
-- Link risks to specific test requirements
-- Track residual risk after mitigation
-- Update risk profile as story evolves

package/bmad-core/tasks/shard-doc.md

@@ -1,185 +0,0 @@
-# Document Sharding Task
-
-## Purpose
-
-- Split a large document into multiple smaller documents based on level 2 sections
-- Create a folder structure to organize the sharded documents
-- Maintain all content integrity including code blocks, diagrams, and markdown formatting
-
-## Primary Method: Automatic with markdown-tree
-
-[[LLM: First, check if markdownExploder is set to true in {root}/core-config.yaml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
-
-If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
-
-If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
-
-1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
-2. Or set markdownExploder to false in {root}/core-config.yaml
-
-**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
-
-If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
-
-1. Set markdownExploder to true in {root}/core-config.yaml
-2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
-
-I will now proceed with the manual sharding process."
-
-Then proceed with the manual method below ONLY if markdownExploder is false.]]
-
-### Installation and Usage
-
-1. **Install globally**:
-
-   ```bash
-   npm install -g @kayvan/markdown-tree-parser
-   ```
-
-2. **Use the explode command**:
-
-   ```bash
-   # For PRD
-   md-tree explode docs/prd.md docs/prd
-
-   # For Architecture
-   md-tree explode docs/architecture.md docs/architecture
-
-   # For any document
-   md-tree explode [source-document] [destination-folder]
-   ```
-
-3. **What it does**:
-   - Automatically splits the document by level 2 sections
-   - Creates properly named files
-   - Adjusts heading levels appropriately
-   - Handles all edge cases with code blocks and special markdown
-
-If the user has @kayvan/markdown-tree-parser installed, use it and skip the manual process below.
-
----
-
-## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
-
-### Task Instructions
-
-1. Identify Document and Target Location
-
-- Determine which document to shard (user-provided path)
-- Create a new folder under `docs/` with the same name as the document (without extension)
-- Example: `docs/prd.md` → create folder `docs/prd/`
-
-2. Parse and Extract Sections
-
-CRITICAL AEGNT SHARDING RULES:
-
-1. Read the entire document content
-2. Identify all level 2 sections (## headings)
-3. For each level 2 section:
-   - Extract the section heading and ALL content until the next level 2 section
-   - Include all subsections, code blocks, diagrams, lists, tables, etc.
-   - Be extremely careful with:
-     - Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
-     - Mermaid diagrams - preserve the complete diagram syntax
-     - Nested markdown elements
-     - Multi-line content that might contain ## inside code blocks
-
-CRITICAL: Use proper parsing that understands markdown context. A ## inside a code block is NOT a section header.]]
-
-### 3. Create Individual Files
-
-For each extracted section:
-
-1. **Generate filename**: Convert the section heading to lowercase-dash-case
-   - Remove special characters
-   - Replace spaces with dashes
-   - Example: "## Tech Stack" → `tech-stack.md`
-
-2. **Adjust heading levels**:
-   - The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
-   - All subsection levels decrease by 1:
-
-   ```txt
-     - ### → ##
-     - #### → ###
-     - ##### → ####
-     - etc.
-   ```
-
-3. **Write content**: Save the adjusted content to the new file
-
-### 4. Create Index File
-
-Create an `index.md` file in the sharded folder that:
-
-1. Contains the original level 1 heading and any content before the first level 2 section
-2. Lists all the sharded files with links:
-
-```markdown
-# Original Document Title
-
-[Original introduction content if any]
-
-## Sections
-
-- [Section Name 1](./section-name-1.md)
-- [Section Name 2](./section-name-2.md)
-- [Section Name 3](./section-name-3.md)
-  ...
-```
-
-### 5. Preserve Special Content
-
-1. **Code blocks**: Must capture complete blocks including:
-
-   ```language
-   content
-   ```
-
-2. **Mermaid diagrams**: Preserve complete syntax:
-
-   ```mermaid
-   graph TD
-   ...
-   ```
-
-3. **Tables**: Maintain proper markdown table formatting
-
-4. **Lists**: Preserve indentation and nesting
-
-5. **Inline code**: Preserve backticks
-
-6. **Links and references**: Keep all markdown links intact
-
-7. **Template markup**: If documents contain {{placeholders}} ,preserve exactly
-
-### 6. Validation
-
-After sharding:
-
-1. Verify all sections were extracted
-2. Check that no content was lost
-3. Ensure heading levels were properly adjusted
-4. Confirm all files were created successfully
-
-### 7. Report Results
-
-Provide a summary:
-
-```text
-Document sharded successfully:
-- Source: [original document path]
-- Destination: docs/[folder-name]/
-- Files created: [count]
-- Sections:
-  - section-name-1.md: "Section Title 1"
-  - section-name-2.md: "Section Title 2"
-  ...
-```
-
-## Important Notes
-
-- Never modify the actual content, only adjust heading levels
-- Preserve ALL formatting, including whitespace where significant
-- Handle edge cases like sections with code blocks containing ## symbols
-- Ensure the sharding is reversible (could reconstruct the original from shards)

package/bmad-core/tasks/test-design.md

@@ -1,174 +0,0 @@
-# test-design
-
-Create comprehensive test scenarios with appropriate test level recommendations for story implementation.
-
-## Inputs
-
-```yaml
-required:
-  - story_id: '{epic}.{story}' # e.g., "1.3"
-  - story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
-  - story_title: '{title}' # If missing, derive from story file H1
-  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
-```
-
-## Purpose
-
-Design a complete test strategy that identifies what to test, at which level (unit/integration/e2e), and why. This ensures efficient test coverage without redundancy while maintaining appropriate test boundaries.
-
-## Dependencies
-
-```yaml
-data:
-  - test-levels-framework.md # Unit/Integration/E2E decision criteria
-  - test-priorities-matrix.md # P0/P1/P2/P3 classification system
-```
-
-## Process
-
-### 1. Analyze Story Requirements
-
-Break down each acceptance criterion into testable scenarios. For each AC:
-
-- Identify the core functionality to test
-- Determine data variations needed
-- Consider error conditions
-- Note edge cases
-
-### 2. Apply Test Level Framework
-
-**Reference:** Load `test-levels-framework.md` for detailed criteria
-
-Quick rules:
-
-- **Unit**: Pure logic, algorithms, calculations
-- **Integration**: Component interactions, DB operations
-- **E2E**: Critical user journeys, compliance
-
-### 3. Assign Priorities
-
-**Reference:** Load `test-priorities-matrix.md` for classification
-
-Quick priority assignment:
-
-- **P0**: Revenue-critical, security, compliance
-- **P1**: Core user journeys, frequently used
-- **P2**: Secondary features, admin functions
-- **P3**: Nice-to-have, rarely used
-
-### 4. Design Test Scenarios
-
-For each identified test need, create:
-
-```yaml
-test_scenario:
-  id: '{epic}.{story}-{LEVEL}-{SEQ}'
-  requirement: 'AC reference'
-  priority: P0|P1|P2|P3
-  level: unit|integration|e2e
-  description: 'What is being tested'
-  justification: 'Why this level was chosen'
-  mitigates_risks: ['RISK-001'] # If risk profile exists
-```
-
-### 5. Validate Coverage
-
-Ensure:
-
-- Every AC has at least one test
-- No duplicate coverage across levels
-- Critical paths have multiple levels
-- Risk mitigations are addressed
-
-## Outputs
-
-### Output 1: Test Design Document
-
-**Save to:** `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`
-
-```markdown
-# Test Design: Story {epic}.{story}
-
-Date: {date}
-Designer: Quinn (Test Architect)
-
-## Test Strategy Overview
-
-- Total test scenarios: X
-- Unit tests: Y (A%)
-- Integration tests: Z (B%)
-- E2E tests: W (C%)
-- Priority distribution: P0: X, P1: Y, P2: Z
-
-## Test Scenarios by Acceptance Criteria
-
-### AC1: {description}
-
-#### Scenarios
-
-| ID           | Level       | Priority | Test                      | Justification            |
-| ------------ | ----------- | -------- | ------------------------- | ------------------------ |
-| 1.3-UNIT-001 | Unit        | P0       | Validate input format     | Pure validation logic    |
-| 1.3-INT-001  | Integration | P0       | Service processes request | Multi-component flow     |
-| 1.3-E2E-001  | E2E         | P1       | User completes journey    | Critical path validation |
-
-[Continue for all ACs...]
-
-## Risk Coverage
-
-[Map test scenarios to identified risks if risk profile exists]
-
-## Recommended Execution Order
-
-1. P0 Unit tests (fail fast)
-2. P0 Integration tests
-3. P0 E2E tests
-4. P1 tests in order
-5. P2+ as time permits
-```
-
-### Output 2: Gate YAML Block
-
-Generate for inclusion in quality gate:
-
-```yaml
-test_design:
-  scenarios_total: X
-  by_level:
-    unit: Y
-    integration: Z
-    e2e: W
-  by_priority:
-    p0: A
-    p1: B
-    p2: C
-  coverage_gaps: [] # List any ACs without tests
-```
-
-### Output 3: Trace References
-
-Print for use by trace-requirements task:
-
-```text
-Test design matrix: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
-P0 tests identified: {count}
-```
-
-## Quality Checklist
-
-Before finalizing, verify:
-
-- [ ] Every AC has test coverage
-- [ ] Test levels are appropriate (not over-testing)
-- [ ] No duplicate coverage across levels
-- [ ] Priorities align with business risk
-- [ ] Test IDs follow naming convention
-- [ ] Scenarios are atomic and independent
-
-## Key Principles
-
-- **Shift left**: Prefer unit over integration, integration over E2E
-- **Risk-based**: Focus on what could go wrong
-- **Efficient coverage**: Test once at the right level
-- **Maintainability**: Consider long-term test maintenance
-- **Fast feedback**: Quick tests run first