feat: transform QA agent into Test Architect with advanced quality ca… (#433)

* feat: transform QA agent into Test Architect with advanced quality capabilities - Add 6 specialized quality assessment commands - Implement risk-based testing with scoring - Create quality gate system with deterministic decisions - Add comprehensive test design and NFR validation - Update documentation with stage-based workflow integration * feat: transform QA agent into Test Architect with advanced quality capabilities - Add 6 specialized quality assessment commands - Implement risk-based testing with scoring - Create quality gate system with deterministic decisions - Add comprehensive test design and NFR validation - Update documentation with stage-based workflow integration * docs: refined the docs for test architect * fix: addressed review comments from manjaroblack, round 1 * fix: addressed review comments from manjaroblack, round 1 --------- Co-authored-by: Murat Ozcan <murat@mac.lan> Co-authored-by: Brian <bmadcode@gmail.com>
2025-08-15 21:02:37 -05:00
parent 33269c888d
commit 0b61175d98
76 changed files with 9245 additions and 1442 deletions
--- a/docs/enhanced-ide-development-workflow.md
+++ b/docs/enhanced-ide-development-workflow.md
@@ -1,8 +1,8 @@
-# Enhanced Development Workflow
+# Enhanced IDE Development Workflow

-This is a simple step-by-step guide to help you efficiently manage your development workflow using the BMad Method. Refer to the **[<ins>User Guide</ins>](user-guide.md)** for any scenario that is not covered here.
+This is a simple step-by-step guide to help you efficiently manage your development workflow using the BMad Method. The workflow integrates the Test Architect (QA agent) throughout the development lifecycle to ensure quality, prevent regressions, and maintain high standards. Refer to the **[<ins>User Guide</ins>](user-guide.md)** for any scenario that is not covered here.

-## Create new Branch
+## Create New Branch

 1. **Start new branch**

@@ -21,23 +21,228 @@ This is a simple step-by-step guide to help you efficiently manage your developm
 3. **Execute**: `*develop-story {selected-story}` (runs execute-checklist task)
 4. **Review generated report** in `{selected-story}`

-## Story Review (Quality Assurance)
+## Test Architect Integration Throughout Workflow

-1. **Start new chat/conversation**
-2. **Load QA agent**
-3. **Execute**: `*review {selected-story}` (runs review-story task)
-4. **Review generated report** in `{selected-story}`
+The Test Architect (Quinn) provides comprehensive quality assurance throughout the development lifecycle. Here's how to leverage each capability at the right time.
+
+**Command Aliases:** Documentation uses short forms (`*risk`, `*design`, `*nfr`, `*trace`) for the full commands (`*risk-profile`, `*test-design`, `*nfr-assess`, `*trace-requirements`).
+
+### Quick Command Reference
+
+| **Stage** | **Command** | **Purpose** | **Output** | **Priority** |
+|-----------|------------|-------------|------------|--------------|
+| **After Story Approval** | `*risk` | Identify integration & regression risks | `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md` | High for complex/brownfield |
+| | `*design` | Create test strategy for dev | `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md` | High for new features |
+| **During Development** | `*trace` | Verify test coverage | `docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md` | Medium |
+| | `*nfr` | Validate quality attributes | `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md` | High for critical features |
+| **After Development** | `*review` | Comprehensive assessment | QA Results in story + `docs/qa/gates/{epic}.{story}-{slug}.yml` | **Required** |
+| **Post-Review** | `*gate` | Update quality decision | Updated `docs/qa/gates/{epic}.{story}-{slug}.yml` | As needed |
+
+### Stage 1: After Story Creation (Before Dev Starts)
+
+**RECOMMENDED - Set Developer Up for Success:**
+
+```bash
+# 1. RISK ASSESSMENT (Run FIRST for complex stories)
+@qa *risk {approved-story}
+# Identifies:
+#   - Technical debt impact
+#   - Integration complexity
+#   - Regression potential (1-9 scoring)
+#   - Mitigation strategies
+# Critical for: Brownfield, API changes, data migrations
+
+# 2. TEST DESIGN (Run SECOND to guide implementation)
+@qa *design {approved-story}
+# Provides:
+#   - Test scenarios per acceptance criterion
+#   - Test level recommendations (unit/integration/E2E)
+#   - Risk-based priorities (P0/P1/P2)
+#   - Test data requirements
+# Share with Dev: Include in story comments or attach to ticket
+```
+
+### Stage 2: During Development (Mid-Implementation Checkpoints)
+
+**Developer Self-Service Quality Checks:**
+
+```bash
+# 3. REQUIREMENTS TRACING (Verify coverage mid-development)
+@qa *trace {story-in-progress}
+# Validates:
+#   - All acceptance criteria have tests
+#   - No missing test scenarios
+#   - Appropriate test levels
+#   - Given-When-Then documentation clarity
+# Run when: After writing initial tests
+
+# 4. NFR VALIDATION (Check quality attributes)
+@qa *nfr {story-in-progress}
+# Assesses:
+#   - Security: Authentication, authorization, data protection
+#   - Performance: Response times, resource usage
+#   - Reliability: Error handling, recovery
+#   - Maintainability: Code quality, documentation
+# Run when: Before marking "Ready for Review"
+```
+
+### Stage 3: Story Review (Quality Gate Assessment)
+
+**REQUIRED - Comprehensive Test Architecture Review:**
+
+**Prerequisite:** All tests green locally; lint & type checks pass.
+
+```bash
+# 5. FULL REVIEW (Standard review process)
+@qa *review {completed-story}
+```
+
+**What Happens During Review:**
+
+1. **Deep Code Analysis**
+   - Architecture pattern compliance
+   - Code quality and maintainability
+   - Security vulnerability scanning
+   - Performance bottleneck detection
+
+2. **Active Refactoring**
+   - Improves code directly when safe
+   - Fixes obvious issues immediately
+   - Suggests complex refactoring for dev
+
+3. **Test Validation**
+   - Coverage at all levels (unit/integration/E2E)
+   - Test quality (no flaky tests, proper assertions)
+   - Regression test adequacy
+
+4. **Gate Decision**
+   - Creates: `docs/qa/gates/{epic}.{story}-{slug}.yml`
+   - Adds: QA Results section to story file
+   - Status: PASS/CONCERNS/FAIL/WAIVED
+
+### Stage 4: Post-Review (After Addressing Issues)
+
+**Update Gate Status After Fixes:**
+
+```bash
+# 6. GATE UPDATE (Document final decision)
+@qa *gate {reviewed-story}
+# Updates: Quality gate with new status
+# Use when: After addressing review feedback
+# Documents: What was fixed, what was waived
+```
+
+### Understanding Gate Decisions
+
+| **Status** | **Meaning** | **Action Required** | **Can Proceed?** |
+|------------|-------------|-------------------|------------------|
+| **PASS** | All critical requirements met | None | ✅ Yes |
+| **CONCERNS** | Non-critical issues found | Team review recommended | ⚠️ With caution |
+| **FAIL** | Critical issues (security, missing P0 tests) | Must fix | ❌ No |
+| **WAIVED** | Issues acknowledged and accepted | Document reasoning | ✅ With approval |
+
+### Risk-Based Testing Strategy
+
+The Test Architect uses risk scoring to prioritize testing:
+
+| **Risk Score** | **Calculation** | **Testing Priority** | **Gate Impact** |
+|---------------|----------------|-------------------|----------------|
+| **9** | High probability × High impact | P0 - Must test thoroughly | FAIL if untested |
+| **6** | Medium-high combinations | P1 - Should test well | CONCERNS if gaps |
+| **4** | Medium combinations | P1 - Should test | CONCERNS if notable gaps |
+| **2-3** | Low-medium combinations | P2 - Nice to have | Note in review |
+| **1** | Minimal risk | P2 - Minimal | Note in review |
+
+### Special Situations & Best Practices
+
+#### High-Risk or Brownfield Stories
+
+```bash
+# ALWAYS run this sequence:
+@qa *risk {story}    # First - identify dangers
+@qa *design {story}  # Second - plan defense
+# Then during dev:
+@qa *trace {story}   # Verify regression coverage
+@qa *nfr {story}     # Check performance impact
+# Finally:
+@qa *review {story}  # Deep integration analysis
+```
+
+#### Complex Integrations
+
+- Run `*trace` multiple times during development
+- Focus on integration test coverage
+- Use `*nfr` to validate cross-system performance
+- Review with extra attention to API contracts
+
+#### Performance-Critical Features
+
+- Run `*nfr` early and often (not just at review)
+- Establish performance baselines before changes
+- Document acceptable performance degradation
+- Consider load testing requirements in `*design`
+
+### Test Quality Standards Enforced
+
+Quinn ensures all tests meet these standards:
+
+- **No Flaky Tests**: Proper async handling, explicit waits
+- **No Hard Waits**: Dynamic strategies only (polling, events)
+- **Stateless**: Tests run independently and in parallel
+- **Self-Cleaning**: Tests manage their own test data
+- **Appropriate Levels**: Unit for logic, integration for interactions, E2E for journeys
+- **Clear Assertions**: Keep assertions in tests, not buried in helpers
+
+### Documentation & Audit Trail
+
+All Test Architect activities create permanent records:
+
+- **Assessment Reports**: Timestamped analysis in `docs/qa/assessments/`
+- **Gate Files**: Decision records in `docs/qa/gates/`
+- **Story Updates**: QA Results sections in story files
+- **Traceability**: Requirements to test mapping maintained

 ## Commit Changes and Push

 1. **Commit changes**
 2. **Push to remote**

-## Repeat Until Complete
+## Complete Development Cycle Flow

- **SM**: Create next story → Review → Approve
- **Dev**: Implement story → Complete → Mark Ready for Review
- **QA**: Review story → Mark done
- **Commit**: All changes
- **Push**: To remote
- **Continue**: Until all features implemented
+### The Full Workflow with Test Architect
+
+1. **SM**: Create next story → Review → Approve
+2. **QA (Optional)**: Risk assessment (`*risk`) → Test design (`*design`)
+3. **Dev**: Implement story → Write tests → Complete
+4. **QA (Optional)**: Mid-dev checks (`*trace`, `*nfr`)
+5. **Dev**: Mark Ready for Review
+6. **QA (Required)**: Review story (`*review`) → Gate decision
+7. **Dev (If needed)**: Address issues
+8. **QA (If needed)**: Update gate (`*gate`)
+9. **Commit**: All changes
+10. **Push**: To remote
+11. **Continue**: Until all features implemented
+
+### Quick Decision Guide
+
+**Should I run Test Architect commands?**
+
+| **Scenario** | **Before Dev** | **During Dev** | **After Dev** |
+|-------------|---------------|----------------|---------------|
+| **Simple bug fix** | Optional | Optional | Required `*review` |
+| **New feature** | Recommended `*risk`, `*design` | Optional `*trace` | Required `*review` |
+| **Brownfield change** | **Required** `*risk`, `*design` | Recommended `*trace`, `*nfr` | Required `*review` |
+| **API modification** | **Required** `*risk`, `*design` | **Required** `*trace` | Required `*review` |
+| **Performance-critical** | Recommended `*design` | **Required** `*nfr` | Required `*review` |
+| **Data migration** | **Required** `*risk`, `*design` | **Required** `*trace` | Required `*review` + `*gate` |
+
+### Success Metrics
+
+The Test Architect helps achieve:
+
+- **Zero regression defects** in production
+- **100% requirements coverage** with tests
+- **Clear quality gates** for go/no-go decisions
+- **Documented risk acceptance** for technical debt
+- **Consistent test quality** across the team
+- **Shift-left testing** with early risk identification
--- a/docs/user-guide.md
+++ b/docs/user-guide.md
@@ -1,6 +1,6 @@
-# BMad-Method BMAd Code User Guide
+# BMad Method — User Guide

-This guide will help you understand and effectively use the BMad Method for agile AI driven planning and development.
+This guide will help you understand and effectively use the BMad Method for agile AI-driven planning and development.

 ## The BMad Plan and Execute Workflow

@@ -8,7 +8,7 @@ First, here is the full standard Greenfield Planning + Execution Workflow. Brown

 If you are going to use the BMad Method with a Brownfield project (an existing project), review **[Working in the Brownfield](./working-in-the-brownfield.md)**.

-If you do not see the diagrams that following rendering, you can install Markdown All in One along with the Markdown Preview Mermaid Support plugins to VSCode (or one of the forked clones). With these plugin's, if you right click on the tab when open, there should be a Open Preview option, or check the IDE documentation.
+If the diagrams below don't render, install Markdown All in One along with the Markdown Preview Mermaid Support plugins to VSCode (or one of the forked clones). With these plugins, if you right click on the tab when open, there should be an Open Preview option, or check the IDE documentation.

 ### The Planning Workflow (Web UI or Powerful IDE Agents)

@@ -32,8 +32,11 @@ graph TD
    F2 -->|No| H["Architect: Create Architecture from PRD"]
    F3 --> F4["UX Expert: Generate UI Prompt for Lovable/V0 (Optional)"]
    F4 --> H2["Architect: Create Architecture from PRD + UX Spec"]
-    H --> I["PO: Run Master Checklist"]
-    H2 --> I
+    H --> Q{"Early Test Strategy? (Optional)"}
+    H2 --> Q
+    Q -->|Yes| R["QA: Early Test Architecture Input on High-Risk Areas"]
+    Q -->|No| I
+    R --> I["PO: Run Master Checklist"]
    I --> J{"Documents Aligned?"}
    J -->|Yes| K["Planning Complete"]
    J -->|No| L["PO: Update Epics & Stories"]
@@ -58,6 +61,8 @@ graph TD
    style G fill:#e3f2fd,color:#000
    style H fill:#f3e5f5,color:#000
    style H2 fill:#f3e5f5,color:#000
+    style Q fill:#e3f2fd,color:#000
+    style R fill:#ffd54f,color:#000
    style I fill:#f9ab00,color:#fff
    style J fill:#e3f2fd,color:#000
    style K fill:#34a853,color:#fff
@@ -77,6 +82,17 @@ graph TD
 3. **Document Sharding**: Use the PO agent to shard the PRD and then the Architecture
 4. **Begin Development**: Start the Core Development Cycle that follows

+#### Planning Artifacts (Standard Paths)
+
+```text
+PRD              → docs/prd.md
+Architecture     → docs/architecture.md
+Sharded Epics    → docs/epics/
+Sharded Stories  → docs/stories/
+QA Assessments   → docs/qa/assessments/
+QA Gates         → docs/qa/gates/
+```
+
 ### The Core Development Cycle (IDE)

 Once planning is complete and documents are sharded, BMad follows a structured development workflow:
@@ -85,35 +101,52 @@ Once planning is complete and documents are sharded, BMad follows a structured d
 graph TD
    A["Development Phase Start"] --> B["SM: Reviews Previous Story Dev/QA Notes"]
    B --> B2["SM: Drafts Next Story from Sharded Epic + Architecture"]
-    B2 --> B3{"PO: Validate Story Draft (Optional)"}
+    B2 --> S{"High-Risk Story? (Optional)"}
+    S -->|Yes| T["QA: *risk + *design on Draft Story"]
+    S -->|No| B3
+    T --> U["Test Strategy & Risk Profile Created"]
+    U --> B3{"PO: Validate Story Draft (Optional)"}
    B3 -->|Validation Requested| B4["PO: Validate Story Against Artifacts"]
    B3 -->|Skip Validation| C{"User Approval"}
    B4 --> C
    C -->|Approved| D["Dev: Sequential Task Execution"]
    C -->|Needs Changes| B2
    D --> E["Dev: Implement Tasks + Tests"]
-    E --> F["Dev: Run All Validations"]
+    E --> V{"Mid-Dev QA Check? (Optional)"}
+    V -->|Yes| W["QA: *trace or *nfr for Early Validation"]
+    V -->|No| F
+    W --> X["Dev: Address Coverage/NFR Gaps"]
+    X --> F["Dev: Run All Validations"]
    F --> G["Dev: Mark Ready for Review + Add Notes"]
    G --> H{"User Verification"}
-    H -->|Request QA Review| I["QA: Senior Dev Review + Active Refactoring"]
+    H -->|Request QA Review| I["QA: Test Architect Review + Quality Gate"]
    H -->|Approve Without QA| M["IMPORTANT: Verify All Regression Tests and Linting are Passing"]
-    I --> J["QA: Review, Refactor Code, Add Tests, Document Notes"]
+    I --> J["QA: Test Architecture Analysis + Active Refactoring"]
    J --> L{"QA Decision"}
    L -->|Needs Dev Work| D
    L -->|Approved| M
    H -->|Needs Fixes| D
    M --> N["IMPORTANT: COMMIT YOUR CHANGES BEFORE PROCEEDING!"]
-    N --> K["Mark Story as Done"]
+    N --> Y{"Gate Update Needed?"}
+    Y -->|Yes| Z["QA: *gate to Update Status"]
+    Y -->|No| K
+    Z --> K["Mark Story as Done"]
    K --> B

    style A fill:#f5f5f5,color:#000
    style B fill:#e8f5e9,color:#000
    style B2 fill:#e8f5e9,color:#000
+    style S fill:#e3f2fd,color:#000
+    style T fill:#ffd54f,color:#000
+    style U fill:#ffd54f,color:#000
    style B3 fill:#e3f2fd,color:#000
    style B4 fill:#fce4ec,color:#000
    style C fill:#e3f2fd,color:#000
    style D fill:#e3f2fd,color:#000
    style E fill:#e3f2fd,color:#000
+    style V fill:#e3f2fd,color:#000
+    style W fill:#ffd54f,color:#000
+    style X fill:#e3f2fd,color:#000
    style F fill:#e3f2fd,color:#000
    style G fill:#e3f2fd,color:#000
    style H fill:#e3f2fd,color:#000
@@ -123,13 +156,23 @@ graph TD
    style L fill:#e3f2fd,color:#000
    style M fill:#ff5722,color:#fff
    style N fill:#d32f2f,color:#fff
+    style Y fill:#e3f2fd,color:#000
+    style Z fill:#ffd54f,color:#000
 ```

+## Prerequisites
+
+Before installing BMad Method, ensure you have:
+
+- **Node.js** ≥ 18, **npm** ≥ 9
+- **Git** installed and configured
+- **(Optional)** VS Code with "Markdown All in One" + "Markdown Preview Mermaid Support" extensions
+
 ## Installation

 ### Optional

-If you want to do the planning in the Web with Claude (Sonnet 4 or Opus), Gemini Gem (2.5 Pro), or Custom GPT's:
+If you want to do the planning on the web with Claude (Sonnet 4 or Opus), Gemini Gem (2.5 Pro), or Custom GPTs:

 1. Navigate to `dist/teams/`
 2. Copy `team-fullstack.txt`
@@ -146,17 +189,17 @@ npx bmad-method install

 ## Special Agents

-There are two bmad agents - in the future they will be consolidated into the single bmad-master.
+There are two BMad agents — in the future they'll be consolidated into a single BMad-Master.

 ### BMad-Master

-This agent can do any task or command that all other agents can do, aside from actual story implementation. Additionally, this agent can help explain the BMad Method when in the web by accessing the knowledge base and explaining anything to you about the process.
+This agent can do any task or command that all other agents can do, aside from actual story implementation. Additionally, this agent can help explain the BMad Method when on the web by accessing the knowledge base and explaining anything to you about the process.

 If you don't want to bother switching between different agents aside from the dev, this is the agent for you. Just remember that as the context grows, the performance of the agent degrades, therefore it is important to instruct the agent to compact the conversation and start a new conversation with the compacted conversation as the initial message. Do this often, preferably after each story is implemented.

 ### BMad-Orchestrator

-This agent should NOT be used within the IDE, it is a heavy weight special purpose agent that utilizes a lot of context and can morph into any other agent. This exists solely to facilitate the team's within the web bundles. If you use a web bundle you will be greeted by the BMad Orchestrator.
+This agent should NOT be used within the IDE, it is a heavyweight, special-purpose agent that utilizes a lot of context and can morph into any other agent. This exists solely to facilitate the teams within the web bundles. If you use a web bundle you will be greeted by the BMad Orchestrator.

 ### How Agents Work

@@ -187,12 +230,12 @@ dependencies:
 **In IDE:**

 ```bash
-# Some Ide's, like Cursor or Windsurf for example, utilize manual rules so interaction is done with the '@' symbol
+# Some IDEs, like Cursor or Windsurf for example, utilize manual rules so interaction is done with the '@' symbol
@pm Create a PRD for a task management app
@architect Design the system architecture
@dev Implement the user authentication

-# Some, like Claude Code use slash commands instead
+# Some IDEs, like Claude Code, use slash commands instead
 /pm Create user stories
 /dev Fix the login bug
 ```
@@ -212,6 +255,216 @@ dependencies:
 - **File Organization**: Maintain clean project structure
 - **Commit Regularly**: Save your work frequently

+## The Test Architect (QA Agent)
+
+### Overview
+
+The QA agent in BMad is not just a "senior developer reviewer" - it's a **Test Architect** with deep expertise in test strategy, quality gates, and risk-based testing. Named Quinn, this agent provides advisory authority on quality matters while actively improving code when safe to do so.
+
+#### Quick Start (Essential Commands)
+
+```bash
+@qa *risk {story}       # Assess risks before development
+@qa *design {story}     # Create test strategy
+@qa *trace {story}      # Verify test coverage during dev
+@qa *nfr {story}        # Check quality attributes
+@qa *review {story}     # Full assessment → writes gate
+```
+
+#### Command Aliases (Test Architect)
+
+The documentation uses short forms for convenience. Both styles are valid:
+
+```text
+*risk    → *risk-profile
+*design  → *test-design  
+*nfr     → *nfr-assess
+*trace   → *trace-requirements (or just *trace)
+*review  → *review
+*gate    → *gate
+```
+
+### Core Capabilities
+
+#### 1. Risk Profiling (`*risk`)
+
+**When:** After story draft, before development begins (earliest intervention point)
+
+Identifies and assesses implementation risks:
+
+- **Categories**: Technical, Security, Performance, Data, Business, Operational
+- **Scoring**: Probability × Impact analysis (1-9 scale)
+- **Mitigation**: Specific strategies for each identified risk
+- **Gate Impact**: Risks ≥9 trigger FAIL, ≥6 trigger CONCERNS (see `tasks/risk-profile.md` for authoritative rules)
+
+#### 2. Test Design (`*design`)
+
+**When:** After story draft, before development begins (guides what tests to write)
+
+Creates comprehensive test strategies including:
+
+- Test scenarios for each acceptance criterion
+- Appropriate test level recommendations (unit vs integration vs E2E)
+- Risk-based prioritization (P0/P1/P2)
+- Test data requirements and mock strategies
+- Execution strategies for CI/CD integration
+
+**Example output:**
+
+```yaml
+test_summary:
+  total: 24
+  by_level:
+    unit: 15
+    integration: 7
+    e2e: 2
+  by_priority:
+    P0: 8 # Must have - linked to critical risks
+    P1: 10 # Should have - medium risks
+    P2: 6 # Nice to have - low risks
+```
+
+#### 3. Requirements Tracing (`*trace`)
+
+**When:** During development (mid-implementation checkpoint)
+
+Maps requirements to test coverage:
+
+- Documents which tests validate each acceptance criterion
+- Uses Given-When-Then for clarity (documentation only, not BDD code)
+- Identifies coverage gaps with severity ratings
+- Creates traceability matrix for audit purposes
+
+#### 4. NFR Assessment (`*nfr`)
+
+**When:** During development or early review (validate quality attributes)
+
+Validates non-functional requirements:
+
+- **Core Four**: Security, Performance, Reliability, Maintainability
+- **Evidence-Based**: Looks for actual implementation proof
+- **Gate Integration**: NFR failures directly impact quality gates
+
+#### 5. Comprehensive Test Architecture Review (`*review`)
+
+**When:** After development complete, story marked "Ready for Review"
+
+When you run `@qa *review {story}`, Quinn performs:
+
+- **Requirements Traceability**: Maps every acceptance criterion to its validating tests
+- **Test Level Analysis**: Ensures appropriate testing at unit, integration, and E2E levels
+- **Coverage Assessment**: Identifies gaps and redundant test coverage
+- **Active Refactoring**: Improves code quality directly when safe
+- **Quality Gate Decision**: Issues PASS/CONCERNS/FAIL status based on findings
+
+#### 6. Quality Gates (`*gate`)
+
+**When:** After review fixes or when gate status needs updating
+
+Manages quality gate decisions:
+
+- **Deterministic Rules**: Clear criteria for PASS/CONCERNS/FAIL
+- **Parallel Authority**: QA owns gate files in `docs/qa/gates/`
+- **Advisory Nature**: Provides recommendations, not blocks
+- **Waiver Support**: Documents accepted risks when needed
+
+**Note:** Gates are advisory; teams choose their quality bar. WAIVED requires reason, approver, and expiry date. See `templates/qa-gate-tmpl.yaml` for schema and `tasks/review-story.md` (gate rules) and `tasks/risk-profile.md` for scoring.
+
+### Working with the Test Architect
+
+#### Integration with BMad Workflow
+
+The Test Architect provides value throughout the entire development lifecycle. Here's when and how to leverage each capability:
+
+| **Stage** | **Command** | **When to Use** | **Value** | **Output** |
+|-----------|------------|-----------------|-----------|------------|
+| **Story Drafting** | `*risk` | After SM drafts story | Identify pitfalls early | `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md` |
+| | `*design` | After risk assessment | Guide dev on test strategy | `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md` |
+| **Development** | `*trace` | Mid-implementation | Verify test coverage | `docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md` |
+| | `*nfr` | While building features | Catch quality issues early | `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md` |
+| **Review** | `*review` | Story marked complete | Full quality assessment | QA Results in story + gate file |
+| **Post-Review** | `*gate` | After fixing issues | Update quality decision | Updated `docs/qa/gates/{epic}.{story}-{slug}.yml` |
+
+#### Example Commands
+
+```bash
+# Planning Stage - Run these BEFORE development starts
+@qa *risk {draft-story}     # What could go wrong?
+@qa *design {draft-story}   # What tests should we write?
+
+# Development Stage - Run these DURING coding
+@qa *trace {story}          # Are we testing everything?
+@qa *nfr {story}            # Are we meeting quality standards?
+
+# Review Stage - Run when development complete
+@qa *review {story}         # Comprehensive assessment + refactoring
+
+# Post-Review - Run after addressing issues
+@qa *gate {story}           # Update gate status
+```
+
+### Quality Standards Enforced
+
+Quinn enforces these test quality principles:
+
+- **No Flaky Tests**: Ensures reliability through proper async handling
+- **No Hard Waits**: Dynamic waiting strategies only
+- **Stateless & Parallel-Safe**: Tests run independently
+- **Self-Cleaning**: Tests manage their own test data
+- **Appropriate Test Levels**: Unit for logic, integration for interactions, E2E for journeys
+- **Explicit Assertions**: Keep assertions in tests, not helpers
+
+### Gate Status Meanings
+
+- **PASS**: All critical requirements met, no blocking issues
+- **CONCERNS**: Non-critical issues found, team should review
+- **FAIL**: Critical issues that should be addressed (security risks, missing P0 tests)
+- **WAIVED**: Issues acknowledged but explicitly accepted by team
+
+### Special Situations
+
+**High-Risk Stories:**
+
+- Always run `*risk` and `*design` before development starts
+- Consider mid-development `*trace` and `*nfr` checkpoints
+
+**Complex Integrations:**
+
+- Run `*trace` during development to ensure all integration points tested
+- Follow up with `*nfr` to validate performance across integrations
+
+**Performance-Critical:**
+
+- Run `*nfr` early and often during development
+- Don't wait until review to discover performance issues
+
+**Brownfield/Legacy Code:**
+
+- Start with `*risk` to identify regression dangers
+- Use `*review` with extra focus on backward compatibility
+
+### Best Practices
+
+- **Early Engagement**: Run `*design` and `*risk` during story drafting
+- **Risk-Based Focus**: Let risk scores drive test prioritization
+- **Iterative Improvement**: Use QA feedback to improve future stories
+- **Gate Transparency**: Share gate decisions with the team
+- **Continuous Learning**: QA documents patterns for team knowledge sharing
+- **Brownfield Care**: Pay extra attention to regression risks in existing systems
+
+### Output Paths Reference
+
+Quick reference for where Test Architect outputs are stored:
+
+```text
+*risk-profile  → docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
+*test-design   → docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
+*trace         → docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
+*nfr-assess    → docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
+*review        → QA Results section in story + gate file reference
+*gate          → docs/qa/gates/{epic}.{story}-{slug}.yml
+```
+
 ## Technical Preferences System

 BMad includes a personalization system through the `technical-preferences.md` file located in `.bmad-core/data/` - this can help bias the PM and Architect to recommend your preferences for design patterns, technology selection, or anything else you would like to put in here.
@@ -235,9 +488,9 @@ devLoadAlwaysFiles:
  - docs/architecture/project-structure.md
 ```

-You will want to verify from sharding your architecture that these documents exist, that they are as lean as possible, and contain exactly the information you want your dev agent to ALWAYS load into it's context. These are the rules the agent will follow.
+You will want to verify from sharding your architecture that these documents exist, that they are as lean as possible, and contain exactly the information you want your dev agent to ALWAYS load into its context. These are the rules the agent will follow.

-As your project grows and the code starts to build consistent patterns, coding standards should be reduced to include only the standards that the agent still makes with. The agent will look at surrounding code in files to infer the coding standards that are relevant to the current task.
+As your project grows and the code starts to build consistent patterns, coding standards should be reduced to include only the standards the agent still needs enforced. The agent will look at surrounding code in files to infer the coding standards that are relevant to the current task.

 ## Getting Help

--- a/docs/working-in-the-brownfield.md
+++ b/docs/working-in-the-brownfield.md
@@ -27,7 +27,7 @@ If you have just completed an MVP with BMad, and you want to continue with post-
 ## The Complete Brownfield Workflow

 1. **Follow the [<ins>User Guide - Installation</ins>](user-guide.md#installation) steps to setup your agent in the web.**
-2. **Generate a 'flattened' single file of your entire codebase** run: ```npx bmad-method flatten```
+2. **Generate a 'flattened' single file of your entire codebase** run: `npx bmad-method flatten`

 ### Choose Your Approach

@@ -76,7 +76,7 @@ The PM will:
 *document-project
 ```

-The analyst will:
+The architect will:

 - **Ask about your focus** if no PRD was provided
 - **Offer options**: Create PRD, provide requirements, or describe the enhancement
@@ -85,11 +85,11 @@ The analyst will:
 - **Skip unrelated areas** to keep docs lean
 - **Generate ONE architecture document** for all environments

-The analyst creates:
+The architect creates:

 - **One comprehensive architecture document** following fullstack-architecture template
 - **Covers all system aspects** in a single file
- **Easy to copy and save** as `docs/project-architecture.md`
+- **Easy to copy and save** as `docs/architecture.md`
 - **Can be sharded later** in IDE if desired

 For example, if you say "Add payment processing to user service":
@@ -108,10 +108,10 @@ For example, if you say "Add payment processing to user service":
 2. **Upload your project**:
   - **Option A**: Paste your GitHub repository URL directly
   - **Option B**: Upload your flattened-codebase.xml file
-3. **Load the analyst agent**: Upload `dist/agents/architect.txt`
+3. **Load the architect agent**: Upload `dist/agents/architect.txt`
 4. **Run documentation**: Type `*document-project`

-The analyst will generate comprehensive documentation of everything.
+The architect will generate comprehensive documentation of everything.

 #### Phase 2: Plan Your Enhancement

@@ -206,19 +206,20 @@ The PO ensures:
 ### Phase 4: Save and Shard Documents

 1. Save your PRD and Architecture as:
-   docs/brownfield-prd.md
-   docs/brownfield-architecture.md
+   docs/prd.md
+   docs/architecture.md
+   (Note: You can optionally prefix with 'brownfield-' if managing multiple versions)
 2. Shard your docs:
   In your IDE

   ```bash
   @po
-   shard docs/brownfield-prd.md
+   shard docs/prd.md
   ```

   ```bash
   @po
-   shard docs/brownfield-architecture.md
+   shard docs/architecture.md
   ```

 ### Phase 5: Transition to Development
@@ -255,12 +256,172 @@ Brownfield changes should:

 ### 4. Test Integration Thoroughly

-Focus testing on:
+#### Why the Test Architect is Critical for Brownfield

- Integration points
- Existing functionality (regression)
- Performance impact
- Data migrations
+In brownfield projects, the Test Architect (Quinn) becomes your safety net against breaking existing functionality. Unlike greenfield where you're building fresh, brownfield requires careful validation that new changes don't destabilize what already works.
+
+#### Brownfield-Specific Testing Challenges
+
+The Test Architect addresses unique brownfield complexities:
+
+| **Challenge**               | **How Test Architect Helps**                      | **Command**         |
+| --------------------------- | ------------------------------------------------- | ------------------- |
+| **Regression Risks**        | Identifies which existing features might break    | `*risk`             |
+| **Legacy Dependencies**     | Maps integration points and hidden dependencies   | `*trace`            |
+| **Performance Degradation** | Validates no slowdown in existing flows           | `*nfr`              |
+| **Coverage Gaps**           | Finds untested legacy code that new changes touch | `*design`           |
+| **Breaking Changes**        | Detects API/contract violations                   | `*review`           |
+| **Migration Safety**        | Validates data transformations and rollback plans | `*risk` + `*review` |
+
+#### Complete Test Architect Workflow for Brownfield
+
+##### Stage 1: Before Development (Risk & Strategy)
+
+**CRITICAL FOR BROWNFIELD - Run These First:**
+
+```bash
+# 1. RISK ASSESSMENT (Run IMMEDIATELY after story creation)
+@qa *risk {brownfield-story}
+# Identifies: Legacy dependencies, breaking changes, integration points
+# Output: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
+# Brownfield Focus:
+#   - Regression probability scoring
+#   - Affected downstream systems
+#   - Data migration risks
+#   - Rollback complexity
+
+# 2. TEST DESIGN (After risk assessment)
+@qa *design {brownfield-story}
+# Creates: Regression test strategy + new feature tests
+# Output: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
+# Brownfield Focus:
+#   - Existing functionality that needs regression tests
+#   - Integration test requirements
+#   - Performance benchmarks to maintain
+#   - Feature flag test scenarios
+```
+
+##### Stage 2: During Development (Continuous Validation)
+
+**Monitor Integration Health While Coding:**
+
+```bash
+# 3. REQUIREMENTS TRACING (Mid-development checkpoint)
+@qa *trace {brownfield-story}
+# Maps: New requirements + existing functionality preservation
+# Output: docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
+# Brownfield Focus:
+#   - Existing features that must still work
+#   - New/old feature interactions
+#   - API contract preservation
+#   - Missing regression test coverage
+
+# 4. NFR VALIDATION (Before considering "done")
+@qa *nfr {brownfield-story}
+# Validates: Performance, security, reliability unchanged
+# Output: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
+# Brownfield Focus:
+#   - Performance regression detection
+#   - Security implications of integrations
+#   - Backward compatibility validation
+#   - Load/stress on legacy components
+```
+
+##### Stage 3: Code Review (Deep Integration Analysis)
+
+**Comprehensive Brownfield Review:**
+
+```bash
+# 5. FULL REVIEW (When development complete)
+@qa *review {brownfield-story}
+# Performs: Deep analysis + active refactoring
+# Outputs:
+#   - QA Results in story file
+#   - Gate file: docs/qa/gates/{epic}.{story}-{slug}.yml
+```
+
+The review specifically analyzes:
+
+- **API Breaking Changes**: Validates all existing contracts maintained
+- **Data Migration Safety**: Checks transformation logic and rollback procedures
+- **Performance Regression**: Compares against baseline metrics
+- **Integration Points**: Validates all touchpoints with legacy code
+- **Feature Flag Logic**: Ensures proper toggle behavior
+- **Dependency Impacts**: Maps affected downstream systems
+
+##### Stage 4: Post-Review (Gate Updates)
+
+```bash
+# 6. GATE STATUS UPDATE (After addressing issues)
+@qa *gate {brownfield-story}
+# Updates: Quality gate decision after fixes
+# Output: docs/qa/gates/{epic}.{story}-{slug}.yml
+# Brownfield Considerations:
+#   - May WAIVE certain legacy code issues
+#   - Documents technical debt acceptance
+#   - Tracks migration progress
+```
+
+#### Brownfield-Specific Risk Scoring
+
+The Test Architect uses enhanced risk scoring for brownfield:
+
+| **Risk Category**      | **Brownfield Factors**                     | **Impact on Gate**  |
+| ---------------------- | ------------------------------------------ | ------------------- |
+| **Regression Risk**    | Number of integration points × Age of code | Score ≥9 = FAIL     |
+| **Data Risk**          | Migration complexity × Data volume         | Score ≥6 = CONCERNS |
+| **Performance Risk**   | Current load × Added complexity            | Score ≥6 = CONCERNS |
+| **Compatibility Risk** | API consumers × Contract changes           | Score ≥9 = FAIL     |
+
+#### Brownfield Testing Standards
+
+Quinn enforces additional standards for brownfield:
+
+- **Regression Test Coverage**: Every touched legacy module needs tests
+- **Performance Baselines**: Must maintain or improve current metrics
+- **Rollback Procedures**: Every change needs a rollback plan
+- **Feature Flags**: All risky changes behind toggles
+- **Integration Tests**: Cover all legacy touchpoints
+- **Contract Tests**: Validate API compatibility
+- **Data Validation**: Migration correctness checks
+
+#### Quick Reference: Brownfield Test Commands
+
+| **Scenario**                      | **Commands to Run**                                  | **Order**  | **Why Critical**              |
+| --------------------------------- | ---------------------------------------------------- | ---------- | ----------------------------- |
+| **Adding Feature to Legacy Code** | `*risk` → `*design` → `*trace` → `*review`           | Sequential | Map all dependencies first    |
+| **API Modification**              | `*risk` → `*design` → `*nfr` → `*review`             | Sequential | Prevent breaking consumers    |
+| **Performance-Critical Change**   | `*nfr` early and often → `*review`                   | Continuous | Catch degradation immediately |
+| **Data Migration**                | `*risk` → `*design` → `*trace` → `*review` → `*gate` | Full cycle | Ensure data integrity         |
+| **Bug Fix in Complex System**     | `*risk` → `*trace` → `*review`                       | Focused    | Prevent side effects          |
+
+#### Integration with Brownfield Scenarios
+
+**Scenario-Specific Guidance:**
+
+1. **Legacy Code Modernization**
+   - Start with `*risk` to map all dependencies
+   - Use `*design` to plan strangler fig approach
+   - Run `*trace` frequently to ensure nothing breaks
+   - `*review` with focus on gradual migration
+
+2. **Adding Features to Monolith**
+   - `*risk` identifies integration complexity
+   - `*design` plans isolation strategies
+   - `*nfr` monitors performance impact
+   - `*review` validates no monolith degradation
+
+3. **Microservice Extraction**
+   - `*risk` maps service boundaries
+   - `*trace` ensures functionality preservation
+   - `*nfr` validates network overhead acceptable
+   - `*gate` documents accepted trade-offs
+
+4. **Database Schema Changes**
+   - `*risk` assesses migration complexity
+   - `*design` plans backward-compatible approach
+   - `*trace` maps all affected queries
+   - `*review` validates migration safety

 ### 5. Communicate Changes

@@ -277,29 +438,63 @@ Document:

 1. Document existing system
 2. Create brownfield PRD focusing on integration
-3. Architecture emphasizes compatibility
-4. Stories include integration tasks
+3. **Test Architect Early Involvement**:
+   - Run `@qa *risk` on draft stories to identify integration risks
+   - Use `@qa *design` to plan regression test strategy
+4. Architecture emphasizes compatibility
+5. Stories include integration tasks with test requirements
+6. **During Development**:
+   - Developer runs `@qa *trace` to verify coverage
+   - Use `@qa *nfr` to monitor performance impact
+7. **Review Stage**: `@qa *review` validates integration safety

 ### Scenario 2: Modernizing Legacy Code

 1. Extensive documentation phase
 2. PRD includes migration strategy
-3. Architecture plans gradual transition
-4. Stories follow strangler fig pattern
+3. **Test Architect Strategy Planning**:
+   - `@qa *risk` assesses modernization complexity
+   - `@qa *design` plans parallel testing approach
+4. Architecture plans gradual transition (strangler fig pattern)
+5. Stories follow incremental modernization with:
+   - Regression tests for untouched legacy code
+   - Integration tests for new/old boundaries
+   - Performance benchmarks at each stage
+6. **Continuous Validation**: Run `@qa *trace` after each increment
+7. **Gate Management**: Use `@qa *gate` to track technical debt acceptance

 ### Scenario 3: Bug Fix in Complex System

 1. Document relevant subsystems
 2. Use `create-brownfield-story` for focused fix
-3. Include regression test requirements
-4. QA validates no side effects
+3. **Test Architect Risk Assessment**: Run `@qa *risk` to identify side effect potential
+4. Include regression test requirements from `@qa *design` output
+5. **During Fix**: Use `@qa *trace` to map affected functionality
+6. **Before Commit**: Run `@qa *review` for comprehensive validation
+7. Test Architect validates no side effects using:
+   - Risk profiling for side effect analysis (probability × impact scoring)
+   - Trace matrix to ensure fix doesn't break related features
+   - NFR assessment to verify performance/security unchanged
+   - Gate decision documents fix safety

 ### Scenario 4: API Integration

 1. Document existing API patterns
 2. PRD defines integration requirements
-3. Architecture ensures consistent patterns
-4. Stories include API documentation updates
+3. **Test Architect Contract Analysis**:
+   - `@qa *risk` identifies breaking change potential
+   - `@qa *design` creates contract test strategy
+4. Architecture ensures consistent patterns
+5. **API Testing Focus**:
+   - Contract tests for backward compatibility
+   - Integration tests for new endpoints
+   - Performance tests for added load
+6. Stories include API documentation updates
+7. **Validation Checkpoints**:
+   - `@qa *trace` maps all API consumers
+   - `@qa *nfr` validates response times
+   - `@qa *review` ensures no breaking changes
+8. **Gate Decision**: Document any accepted breaking changes with migration path

 ## Troubleshooting

@@ -325,19 +520,37 @@ Document:

 ```bash
 # Document existing project
-@architect → *document-project
+@architect *document-project

 # Create enhancement PRD
-@pm → *create-brownfield-prd
+@pm *create-brownfield-prd

 # Create architecture with integration focus
-@architect → *create-brownfield-architecture
+@architect *create-brownfield-architecture

 # Quick epic creation
-@pm → *create-brownfield-epic
+@pm *create-brownfield-epic

 # Single story creation
-@pm → *create-brownfield-story
+@pm *create-brownfield-story
+```
+
+### Test Architect Commands for Brownfield
+
+Note: Short forms shown below. Full commands: `*risk-profile`, `*test-design`, `*nfr-assess`, `*trace-requirements`
+
+```bash
+# BEFORE DEVELOPMENT (Planning)
+@qa *risk {story}     # Assess regression & integration risks
+@qa *design {story}   # Plan regression + new feature tests
+
+# DURING DEVELOPMENT (Validation)
+@qa *trace {story}    # Verify coverage of old + new
+@qa *nfr {story}      # Check performance degradation
+
+# AFTER DEVELOPMENT (Review)
+@qa *review {story}   # Deep integration analysis
+@qa *gate {story}     # Update quality decision
 ```

 ### Decision Tree
@@ -352,13 +565,33 @@ Do you have a large codebase or monorepo?

 Is this a major enhancement affecting multiple systems?
 ├─ Yes → Full Brownfield Workflow
+│   └─ ALWAYS run Test Architect *risk + *design first
 └─ No → Is this more than a simple bug fix?
-    ├─ Yes → brownfield-create-epic
-    └─ No → brownfield-create-story
+    ├─ Yes → *create-brownfield-epic
+    │   └─ Run Test Architect *risk for integration points
+    └─ No → *create-brownfield-story
+        └─ Still run *risk if touching critical paths
+
+Does the change touch legacy code?
+├─ Yes → Test Architect is MANDATORY
+│   ├─ *risk → Identify regression potential
+│   ├─ *design → Plan test coverage
+│   └─ *review → Validate no breakage
+└─ No → Test Architect is RECOMMENDED
+    └─ *review → Ensure quality standards
 ```

 ## Conclusion

-Brownfield development with BMad-Method provides structure and safety when modifying existing systems. The key is providing comprehensive context through documentation, using specialized templates that consider integration requirements, and following workflows that respect existing constraints while enabling progress.
+Brownfield development with BMad Method provides structure and safety when modifying existing systems. The Test Architect becomes your critical safety net, using risk assessment, regression testing, and continuous validation to ensure new changes don't destabilize existing functionality.

-Remember: **Document First, Plan Carefully, Integrate Safely**
+**The Brownfield Success Formula:**
+
+1. **Document First** - Understand what exists
+2. **Assess Risk Early** - Use Test Architect `*risk` before coding
+3. **Plan Test Strategy** - Design regression + new feature tests
+4. **Validate Continuously** - Check integration health during development
+5. **Review Comprehensively** - Deep analysis before committing
+6. **Gate Decisively** - Document quality decisions
+
+Remember: **In brownfield, the Test Architect isn't optional - it's your insurance policy against breaking production.**