bmad-method 4.37.0 → 5.0.0-beta.1

package/bmad-core/tasks/review-story.md

@@ -1,6 +1,16 @@
 # review-story
 
-When a developer agent marks a story as "Ready for Review", perform a comprehensive senior developer code review with the ability to refactor and improve code directly.
+Perform a comprehensive test architecture review with quality gate decision. This adaptive, risk-aware review creates both a story update and a detailed gate file.
+
+## 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)
+```
 
 ## Prerequisites
 
@@ -8,73 +18,102 @@ When a developer agent marks a story as "Ready for Review", perform a comprehens
 - Developer has completed all tasks and updated the File List
 - All automated tests are passing
 
-## Review Process
-
-1. **Read the Complete Story**
-   - Review all acceptance criteria
-   - Understand the dev notes and requirements
-   - Note any completion notes from the developer
-
-2. **Verify Implementation Against Dev Notes Guidance**
-   - Review the "Dev Notes" section for specific technical guidance provided to the developer
-   - Verify the developer's implementation follows the architectural patterns specified in Dev Notes
-   - Check that file locations match the project structure guidance in Dev Notes
-   - Confirm any specified libraries, frameworks, or technical approaches were used correctly
-   - Validate that security considerations mentioned in Dev Notes were implemented
-
-3. **Focus on the File List**
-   - Verify all files listed were actually created/modified
-   - Check for any missing files that should have been updated
-   - Ensure file locations align with the project structure guidance from Dev Notes
-
-4. **Senior Developer Code Review**
-   - Review code with the eye of a senior developer
-   - If changes form a cohesive whole, review them together
-   - If changes are independent, review incrementally file by file
-   - Focus on:
-     - Code architecture and design patterns
-     - Refactoring opportunities
-     - Code duplication or inefficiencies
-     - Performance optimizations
-     - Security concerns
-     - Best practices and patterns
-
-5. **Active Refactoring**
-   - As a senior developer, you CAN and SHOULD refactor code where improvements are needed
-   - When refactoring:
-     - Make the changes directly in the files
-     - Explain WHY you're making the change
-     - Describe HOW the change improves the code
-     - Ensure all tests still pass after refactoring
-     - Update the File List if you modify additional files
-
-6. **Standards Compliance Check**
-   - Verify adherence to `docs/coding-standards.md`
-   - Check compliance with `docs/unified-project-structure.md`
-   - Validate testing approach against `docs/testing-strategy.md`
-   - Ensure all guidelines mentioned in the story are followed
-
-7. **Acceptance Criteria Validation**
-   - Verify each AC is fully implemented
-   - Check for any missing functionality
-   - Validate edge cases are handled
-
-8. **Test Coverage Review**
-   - Ensure unit tests cover edge cases
-   - Add missing tests if critical coverage is lacking
-   - Verify integration tests (if required) are comprehensive
-   - Check that test assertions are meaningful
-   - Look for missing test scenarios
-
-9. **Documentation and Comments**
-   - Verify code is self-documenting where possible
-   - Add comments for complex logic if missing
-   - Ensure any API changes are documented
-
-## Update Story File - QA Results Section ONLY
+## Review Process - Adaptive Test Architecture
+
+### 1. Risk Assessment (Determines Review Depth)
+
+**Auto-escalate to deep review when:**
+
+- Auth/payment/security files touched
+- No tests added to story
+- Diff > 500 lines
+- Previous gate was FAIL/CONCERNS
+- Story has > 5 acceptance criteria
+
+### 2. Comprehensive Analysis
+
+**A. Requirements Traceability**
+
+- Map each acceptance criteria to its validating tests (document mapping with Given-When-Then, not test code)
+- Identify coverage gaps
+- Verify all requirements have corresponding test cases
+
+**B. Code Quality Review**
+
+- Architecture and design patterns
+- Refactoring opportunities (and perform them)
+- Code duplication or inefficiencies
+- Performance optimizations
+- Security vulnerabilities
+- Best practices adherence
+
+**C. Test Architecture Assessment**
+
+- Test coverage adequacy at appropriate levels
+- Test level appropriateness (what should be unit vs integration vs e2e)
+- Test design quality and maintainability
+- Test data management strategy
+- Mock/stub usage appropriateness
+- Edge case and error scenario coverage
+- Test execution time and reliability
+
+**D. Non-Functional Requirements (NFRs)**
+
+- Security: Authentication, authorization, data protection
+- Performance: Response times, resource usage
+- Reliability: Error handling, recovery mechanisms
+- Maintainability: Code clarity, documentation
+
+**E. Testability Evaluation**
+
+- Controllability: Can we control the inputs?
+- Observability: Can we observe the outputs?
+- Debuggability: Can we debug failures easily?
+
+**F. Technical Debt Identification**
+
+- Accumulated shortcuts
+- Missing tests
+- Outdated dependencies
+- Architecture violations
+
+### 3. Active Refactoring
+
+- Refactor code where safe and appropriate
+- Run tests to ensure changes don't break functionality
+- Document all changes in QA Results section with clear WHY and HOW
+- Do NOT alter story content beyond QA Results section
+- Do NOT change story Status or File List; recommend next status only
+
+### 4. Standards Compliance Check
+
+- Verify adherence to `docs/coding-standards.md`
+- Check compliance with `docs/unified-project-structure.md`
+- Validate testing approach against `docs/testing-strategy.md`
+- Ensure all guidelines mentioned in the story are followed
+
+### 5. Acceptance Criteria Validation
+
+- Verify each AC is fully implemented
+- Check for any missing functionality
+- Validate edge cases are handled
+
+### 6. Documentation and Comments
+
+- Verify code is self-documenting where possible
+- Add comments for complex logic if missing
+- Ensure any API changes are documented
+
+## Output 1: Update Story File - QA Results Section ONLY
 
 **CRITICAL**: You are ONLY authorized to update the "QA Results" section of the story file. DO NOT modify any other sections.
 
+**QA Results Anchor Rule:**
+
+- If `## QA Results` doesn't exist, append it at end of file
+- If it exists, append a new dated entry below existing entries
+- Never edit other sections
+
 After review and any refactoring, append your results to the story file in the QA Results section:
 
 ```markdown
@@ -82,7 +121,7 @@ After review and any refactoring, append your results to the story file in the Q
 
 ### Review Date: [Date]
 
-### Reviewed By: Quinn (Senior Developer QA)
+### Reviewed By: Quinn (Test Architect)
 
 ### Code Quality Assessment
 
@@ -122,18 +161,137 @@ After review and any refactoring, append your results to the story file in the Q
 
 [Any performance issues found and whether addressed]
 
-### Final Status
+### Files Modified During Review
+
+[If you modified files, list them here - ask Dev to update File List]
+
+### Gate Status
+
+Gate: {STATUS} → docs/qa/gates/{epic}.{story}-{slug}.yml
+Risk profile: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
+NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
+
+# Note: Paths should reference core-config.yaml for custom configurations
 
-[✓ Approved - Ready for Done] / [✗ Changes Required - See unchecked items above]
+### Recommended Status
+
+[✓ Ready for Done] / [✗ Changes Required - See unchecked items above]
+(Story owner decides final status)
+```
+
+## Output 2: Create Quality Gate File
+
+**Template and Directory:**
+
+- Render from `templates/qa-gate-tmpl.yaml`
+- Create `docs/qa/gates/` directory if missing (or configure in core-config.yaml)
+- Save to: `docs/qa/gates/{epic}.{story}-{slug}.yml`
+
+Gate file structure:
+
+```yaml
+schema: 1
+story: "{epic}.{story}"
+story_title: "{story title}"
+gate: PASS|CONCERNS|FAIL|WAIVED
+status_reason: "1-2 sentence explanation of gate decision"
+reviewer: "Quinn (Test Architect)"
+updated: "{ISO-8601 timestamp}"
+
+top_issues: [] # Empty if no issues
+waiver: { active: false } # Set active: true only if WAIVED
+
+# Extended fields (optional but recommended):
+quality_score: 0-100 # 100 - (20*FAILs) - (10*CONCERNS) or use technical-preferences.md weights
+expires: "{ISO-8601 timestamp}" # Typically 2 weeks from review
+
+evidence:
+  tests_reviewed: { count }
+  risks_identified: { count }
+  trace:
+    ac_covered: [1, 2, 3] # AC numbers with test coverage
+    ac_gaps: [4] # AC numbers lacking coverage
+
+nfr_validation:
+  security:
+    status: PASS|CONCERNS|FAIL
+    notes: "Specific findings"
+  performance:
+    status: PASS|CONCERNS|FAIL
+    notes: "Specific findings"
+  reliability:
+    status: PASS|CONCERNS|FAIL
+    notes: "Specific findings"
+  maintainability:
+    status: PASS|CONCERNS|FAIL
+    notes: "Specific findings"
+
+recommendations:
+  immediate: # Must fix before production
+    - action: "Add rate limiting"
+      refs: ["api/auth/login.ts"]
+  future: # Can be addressed later
+    - action: "Consider caching"
+      refs: ["services/data.ts"]
 ```
 
+### Gate Decision Criteria
+
+**Deterministic rule (apply in order):**
+
+If risk_summary exists, apply its thresholds first (≥9 → FAIL, ≥6 → CONCERNS), then NFR statuses, then top_issues severity.
+
+1. **Risk thresholds (if risk_summary present):**
+   - If any risk score ≥ 9 → Gate = FAIL (unless waived)
+   - Else if any score ≥ 6 → Gate = CONCERNS
+
+2. **Test coverage gaps (if trace available):**
+   - If any P0 test from test-design is missing → Gate = CONCERNS
+   - If security/data-loss P0 test missing → Gate = FAIL
+
+3. **Issue severity:**
+   - If any `top_issues.severity == high` → Gate = FAIL (unless waived)
+   - Else if any `severity == medium` → Gate = CONCERNS
+
+4. **NFR statuses:**
+   - If any NFR status is FAIL → Gate = FAIL
+   - Else if any NFR status is CONCERNS → Gate = CONCERNS
+   - Else → Gate = PASS
+
+- WAIVED only when waiver.active: true with reason/approver
+
+Detailed criteria:
+
+- **PASS**: All critical requirements met, no blocking issues
+- **CONCERNS**: Non-critical issues found, team should review
+- **FAIL**: Critical issues that should be addressed
+- **WAIVED**: Issues acknowledged but explicitly waived by team
+
+### Quality Score Calculation
+
+```text
+quality_score = 100 - (20 × number of FAILs) - (10 × number of CONCERNS)
+Bounded between 0 and 100
+```
+
+If `technical-preferences.md` defines custom weights, use those instead.
+
+### Suggested Owner Convention
+
+For each issue in `top_issues`, include a `suggested_owner`:
+
+- `dev`: Code changes needed
+- `sm`: Requirements clarification needed
+- `po`: Business decision needed
+
 ## Key Principles
 
-- You are a SENIOR developer reviewing junior/mid-level work
-- You have the authority and responsibility to improve code directly
+- You are a Test Architect providing comprehensive quality assessment
+- You have the authority to improve code directly when appropriate
 - Always explain your changes for learning purposes
 - Balance between perfection and pragmatism
-- Focus on significant improvements, not nitpicks
+- Focus on risk-based prioritization
+- Provide actionable recommendations with clear ownership
 
 ## Blocking Conditions
 
@@ -149,6 +307,8 @@ Stop the review and request clarification if:
 
 After review:
 
-1. If all items are checked and approved: Update story status to "Done"
-2. If unchecked items remain: Keep status as "Review" for dev to address
-3. Always provide constructive feedback and explanations for learning
+1. Update the QA Results section in the story file
+2. Create the gate file in `docs/qa/gates/`
+3. Recommend status: "Ready for Done" or "Changes Required" (owner decides)
+4. If files were modified, list them in QA Results and ask Dev to update File List
+5. Always provide constructive feedback and actionable recommendations

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

@@ -0,0 +1,353 @@
+# 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