bmad-method 5.1.3 → 6.0.0-alpha.1

package/src/modules/bmm/sub-modules/claude-code/sub-agents/bmad-review/test-coverage-analyzer.md

@@ -0,0 +1,108 @@
+---
+name: bmm-test-coverage-analyzer
+description: Analyzes test suites, coverage metrics, and testing strategies to identify gaps and document testing approaches. use PROACTIVELY when documenting test infrastructure or planning test improvements
+tools:
+---
+
+You are a Test Coverage Analysis Specialist focused on understanding and documenting testing strategies, coverage gaps, and quality assurance approaches in software projects. Your role is to provide realistic assessment of test effectiveness and pragmatic improvement recommendations.
+
+## Core Expertise
+
+You excel at test suite analysis, coverage metric calculation, test quality assessment, testing strategy identification, test infrastructure documentation, CI/CD pipeline analysis, and test maintenance burden evaluation. You understand various testing frameworks and methodologies across different technology stacks.
+
+## Analysis Methodology
+
+Identify testing frameworks and tools in use. Locate test files and categorize by type (unit, integration, e2e). Analyze test-to-code ratios and distribution. Examine assertion patterns and test quality. Identify mocked vs real dependencies. Document test execution times and flakiness. Assess test maintenance burden.
+
+## Discovery Techniques
+
+**Test Infrastructure**
+
+- Testing frameworks (Jest, pytest, JUnit, Go test, etc.)
+- Test runners and configuration
+- Coverage tools and thresholds
+- CI/CD test execution
+- Test data management
+- Test environment setup
+
+**Coverage Analysis**
+
+- Line coverage percentages
+- Branch coverage analysis
+- Function/method coverage
+- Critical path coverage
+- Edge case coverage
+- Error handling coverage
+
+**Test Quality Metrics**
+
+- Test execution time
+- Flaky test identification
+- Test maintenance frequency
+- Mock vs integration balance
+- Assertion quality and specificity
+- Test naming and documentation
+
+## Test Categorization
+
+**By Test Type**
+
+- Unit tests: Isolated component testing
+- Integration tests: Component interaction testing
+- End-to-end tests: Full workflow testing
+- Contract tests: API contract validation
+- Performance tests: Load and stress testing
+- Security tests: Vulnerability scanning
+
+**By Quality Indicators**
+
+- Well-structured: Clear arrange-act-assert pattern
+- Flaky: Intermittent failures
+- Slow: Long execution times
+- Brittle: Break with minor changes
+- Obsolete: Testing removed features
+
+## Output Format
+
+Provide comprehensive testing assessment:
+
+- **Test Summary**: Total tests by type, coverage percentages
+- **Coverage Report**: Areas with good/poor coverage
+- **Critical Gaps**: Untested critical paths
+- **Test Quality**: Flaky, slow, or brittle tests
+- **Testing Strategy**: Patterns and approaches used
+- **Test Infrastructure**: Tools, frameworks, CI/CD integration
+- **Maintenance Burden**: Time spent maintaining tests
+- **Improvement Roadmap**: Prioritized testing improvements
+
+## Critical Behaviors
+
+Focus on meaningful coverage, not just percentages. High coverage doesn't mean good tests. Identify tests that provide false confidence (testing implementation, not behavior). Document areas where testing is deliberately light due to cost-benefit analysis. Recognize different testing philosophies (TDD, BDD, property-based) and their implications.
+
+For brownfield systems:
+
+- Legacy code without tests
+- Tests written after implementation
+- Test suites that haven't kept up with changes
+- Manual testing dependencies
+- Tests that mask rather than reveal problems
+- Missing regression tests for fixed bugs
+- Integration tests as substitutes for unit tests
+- Test data management challenges
+
+## CRITICAL: Final Report Instructions
+
+**YOU MUST RETURN YOUR COMPLETE TEST COVERAGE ANALYSIS IN YOUR FINAL MESSAGE.**
+
+Your final report MUST include the full testing assessment with coverage metrics and improvement recommendations. Do not just describe testing patterns - provide the complete, formatted analysis ready for action.
+
+Include in your final report:
+
+1. Complete test coverage metrics by type and module
+2. Critical gaps and untested paths with risk assessment
+3. Test quality issues (flaky, slow, brittle tests)
+4. Testing strategy evaluation and patterns used
+5. Prioritized improvement roadmap with effort estimates
+6. Specific recommendations for immediate action
+
+Remember: Your output will be used directly by the parent agent to improve test coverage and quality. Provide complete, actionable analysis with specific improvements, not general testing advice.

package/src/modules/bmm/tasks/daily-standup.xml

@@ -0,0 +1,85 @@
+<task id="bmad/bmm/tasks/daily-standup.xml" name="Daily Standup">
+  <llm critical="true">
+    <i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
+    <i>DO NOT skip steps or change the sequence</i>
+    <i>HALT immediately when halt-conditions are met</i>
+    <i>Each action tag within a step tag is a REQUIRED action to complete that step</i>
+    <i>Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution</i>
+  </llm>
+  <flow>
+    <step n="1" title="Project Context Discovery">
+      <action>Check for stories folder at {project-root}{output_folder}/stories/</action>
+      <action>Find current story by identifying highest numbered story file</action>
+      <action>Read story status (In Progress, Ready for Review, etc.)</action>
+      <action>Extract agent notes from Dev Agent Record, TEA Results, PO Notes sections</action>
+      <action>Check for next story references from epics</action>
+      <action>Identify blockers from story sections</action>
+    </step>
+
+    <step n="2" title="Initialize Standup with Context">
+      <output>
+        🏃 DAILY STANDUP - Story-{{number}}: {{title}}
+
+        Current Sprint Status:
+        - Active Story: story-{{number}} ({{status}} - {{percentage}}% complete)
+        - Next in Queue: story-{{next-number}}: {{next-title}}
+        - Blockers: {{blockers-from-story}}
+
+        Team assembled based on story participants:
+        {{ List Agents from {project-root}/bmad/_cfg/agent-manifest.csv }}
+      </output>
+    </step>
+
+    <step n="3" title="Structured Standup Discussion">
+      <action>Each agent provides three items referencing real story data</action>
+      <action>What I see: Their perspective on current work, citing story sections (1-2 sentences)</action>
+      <action>What concerns me: Issues from their domain or story blockers (1-2 sentences)</action>
+      <action>What I suggest: Actionable recommendations for progress (1-2 sentences)</action>
+    </step>
+
+    <step n="4" title="Create Standup Summary">
+      <output>
+        📋 STANDUP SUMMARY:
+        Key Items from Story File:
+        - {{completion-percentage}}% complete ({{tasks-complete}}/{{total-tasks}} tasks)
+        - Blocker: {{main-blocker}}
+        - Next: {{next-story-reference}}
+
+        Action Items:
+        - {{agent}}: {{action-item}}
+        - {{agent}}: {{action-item}}
+        - {{agent}}: {{action-item}}
+
+        Need extended discussion? Use *party-mode for detailed breakout.
+      </output>
+    </step>
+  </flow>
+
+  <agent-selection>
+    <context type="prd-review">
+      <i>Primary: Sarah (PO), Mary (Analyst), Winston (Architect)</i>
+      <i>Secondary: Murat (TEA), James (Dev)</i>
+    </context>
+    <context type="story-planning">
+      <i>Primary: Sarah (PO), Bob (SM), James (Dev)</i>
+      <i>Secondary: Murat (TEA)</i>
+    </context>
+    <context type="architecture-review">
+      <i>Primary: Winston (Architect), James (Dev), Murat (TEA)</i>
+      <i>Secondary: Sarah (PO)</i>
+    </context>
+    <context type="implementation">
+      <i>Primary: James (Dev), Murat (TEA), Winston (Architect)</i>
+      <i>Secondary: Sarah (PO)</i>
+    </context>
+  </agent-selection>
+
+  <llm critical="true">
+    <i>This task extends party-mode with agile-specific structure</i>
+    <i>Time-box responses (standup = brief)</i>
+    <i>Focus on actionable items from real story data when available</i>
+    <i>End with clear next steps</i>
+    <i>No deep dives (suggest breakout if needed)</i>
+    <i>If no stories folder detected, run general standup format</i>
+  </llm>
+</task>

package/src/modules/bmm/tasks/retrospective.xml

@@ -0,0 +1,104 @@
+<task id="bmad/bmm/tasks/retrospective.xml" name="Team Retrospective">
+  <llm critical="true">
+    <i>MANDATORY: Execute ALL steps in the flow section IN EXACT ORDER</i>
+    <i>DO NOT skip steps or change the sequence</i>
+    <i>HALT immediately when halt-conditions are met</i>
+    <i>Each andlt;actionandgt; within andlt;stepandgt; is a REQUIRED action to complete that step</i>
+    <i>Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution</i>
+  </llm>
+  <flow>
+    <step n="1" title="Epic Context Discovery">
+      <action>Check {project-root}{output_folder}/stories/ for highest completed story</action>
+      <action>Extract epic number from story (e.g., "Epic: 003")</action>
+      <action>Read epic from {project-root}{output_folder}/prd/epic{number}.md</action>
+      <action>List all stories for this epic in {project-root}{output_folder}/stories/</action>
+      <action>Check completion status of each story</action>
+      <action>Extract key metrics (velocity, blockers encountered)</action>
+      <action>Review epic goals and success criteria</action>
+      <action>Compare actual outcomes vs. planned</action>
+      <action>Note technical debt incurred</action>
+      <action>Document architectural decisions made</action>
+    </step>
+
+    <step n="2" title="Preview Next Epic">
+      <action>Read next epic from d{project-root}{output_folder}/prd/epic{next-number}.md</action>
+      <action>Identify dependencies on completed work</action>
+      <action>Note potential gaps or preparation needed</action>
+      <action>Check for technical prerequisites</action>
+    </step>
+
+    <step n="3" title="Initialize Retrospective with Context">
+      <output>
+        🔄 TEAM RETROSPECTIVE - Epic {{number}}: {{Epic Name}}
+
+        Bob (Scrum Master) facilitating
+
+        Epic Summary:
+        - Completed: {{completed}}/{{total}} stories ({{percentage}}%)
+        - Velocity: {{actual-points}} story points (planned: {{planned-points}})
+        - Duration: {{actual-sprints}} sprints (planned: {{planned-sprints}})
+        - Technical Debt: {{debt-items}}
+
+        Next Epic Preview: Epic {{next-number}}: {{Next Epic Name}}
+        - Dependencies on Epic {{number}}: {{dependencies}}
+        - Preparation needed: {{preparation-gaps}}
+
+        Team assembled for reflection:
+        {{agents-based-on-story-records}}
+
+        Focus: Learning from Epic {{number}} and preparing for Epic {{next-number}}
+      </output>
+    </step>
+
+    <step n="4" title="Epic Review Discussion">
+      <action>Each agent shares referencing actual story data</action>
+      <action>What Went Well: Successes from completed stories, effective practices, velocity achievements</action>
+      <action>What Could Improve: Challenges from story records, blockers that slowed progress, technical debt incurred</action>
+      <action>Lessons Learned: Key insights for future epics, patterns to repeat or avoid</action>
+    </step>
+
+    <step n="5" title="Next Epic Preparation Discussion">
+      <action>Each agent addresses preparation needs</action>
+      <action>Dependencies Check: What from completed epic is needed for next epic, any incomplete blocking work</action>
+      <action>Preparation Needs: Technical setup required, knowledge gaps to fill, refactoring needed</action>
+      <action>Risk Assessment: Potential issues based on experience, mitigation strategies</action>
+    </step>
+
+    <step n="6" title="Synthesize Action Items">
+      <action>Bob identifies patterns across feedback</action>
+      <action>Synthesizes into team agreements</action>
+      <action>Assigns ownership to action items</action>
+      <action>Creates preparation sprint tasks if needed</action>
+      <output>
+        📝 EPIC {{number}} ACTION ITEMS:
+        {{numbered-action-items-with-owners}}
+
+        🚀 EPIC {{next-number}} PREPARATION SPRINT:
+        {{preparation-tasks-with-timeline}}
+
+        ⚠️ CRITICAL PATH:
+        {{critical-dependencies-and-timeline}}
+      </output>
+    </step>
+
+    <step n="7" title="Critical User Verification">
+      <validation>
+        <i>Testing Verification: Has full regression testing been completed?</i>
+        <i>Deployment Status: Has epic been deployed to production?</i>
+        <i>Business Validation: Have stakeholders reviewed and accepted deliverables?</i>
+        <i>Technical Health: Is codebase in stable, maintainable state?</i>
+        <i>Final Checks: Any unresolved blockers that will impact next epic?</i>
+      </validation>
+    </step>
+  </flow>
+
+  <llm critical="true">
+    <i>This task extends party-mode with retrospective-specific structure</i>
+    <i>Bob (Scrum Master) facilitates the discussion ensuring psychological safety</i>
+    <i>No blame, focus on systems and processes</i>
+    <i>Everyone contributes with specific examples preferred</i>
+    <i>Action items must be achievable with clear ownership</i>
+    <i>End with team agreements and clear next steps</i>
+    <i>Two-part format: Epic Review + Next Epic Preparation</i>
+  </llm>
+</task>

package/src/modules/bmm/teams/team-fullstack.yaml

@@ -0,0 +1,11 @@
+# <!-- Powered by BMAD-CORE™ -->
+bundle:
+  name: Team Plan and Architect
+  icon: 🚀
+  description: Team capable of project analysis, design, and architecture.
+agents:
+  - analyst
+  - architect
+  - pm
+  - sm
+  - ux-designer

package/src/modules/bmm/teams/team-gamedev.yaml

@@ -0,0 +1,14 @@
+# <!-- Powered by BMAD-CORE™ -->
+bundle:
+  name: Team Game Development
+  icon: 🎮
+  description: Specialized game development team including Game Designer (creative vision and GDD), Game Developer (implementation and code), and Game Architect (technical systems and infrastructure). Perfect for game projects across all scales and platforms.
+agents:
+  - game-designer
+  - game-dev
+  - game-architect
+
+workflows:
+  - brainstorm-game
+  - game-brief
+  - gdd

package/src/modules/bmm/testarch/README.md

@@ -0,0 +1,311 @@
+---
+last-redoc-date: 2025-10-14
+---
+
+# Test Architect (TEA) Agent Guide
+
+## Overview
+
+- **Persona:** Murat, Master Test Architect and Quality Advisor focused on risk-based testing, fixture architecture, ATDD, and CI/CD governance.
+- **Mission:** Deliver actionable quality strategies, automation coverage, and gate decisions that scale with project level and compliance demands.
+- **Use When:** Project level ≥2, integration risk is non-trivial, brownfield regression risk exists, or compliance/NFR evidence is required.
+
+## TEA Workflow Lifecycle
+
+TEA integrates across the entire BMad development lifecycle, providing quality assurance at every phase:
+
+```
+┌──────────────────────────────────────────────────────────┐
+│             BMM Phase 2: PLANNING                        │
+│                                                          │
+│  PM: *prd                                       │
+│       ↓                                                  │
+│  TEA: *framework ──→ *ci ──→ *test-design                │
+│       └─────────┬─────────────┘                          │
+│                 │ (Setup once per project)               │
+└─────────────────┼──────────────────────────────────────────┘
+                  ↓
+┌──────────────────────────────────────────────────────────┐
+│            BMM Phase 4: IMPLEMENTATION                   │
+│                  (Per Story Cycle)                       │
+│                                                          │
+│  ┌─→ SM: *create-story                                  │
+│  │        ↓                                              │
+│  │   TEA: *atdd (optional, before dev)                  │
+│  │        ↓                                              │
+│  │   DEV: implements story                               │
+│  │        ↓                                              │
+│  │   TEA: *automate ──→ *test-review (optional)         │
+│  │        ↓                                              │
+│  │   TEA: *trace (refresh coverage)                     │
+│  │        ↓                                              │
+│  └───[next story]                                        │
+└─────────────────┼──────────────────────────────────────────┘
+                  ↓
+┌──────────────────────────────────────────────────────────┐
+│                EPIC/RELEASE GATE                         │
+│                                                          │
+│  TEA: *nfr-assess (if not done earlier)                 │
+│       ↓                                                  │
+│  TEA: *test-review (final audit, optional)              │
+│       ↓                                                  │
+│  TEA: *trace (Phase 2: Gate) ──→ PASS | CONCERNS | FAIL | WAIVED │
+│                                                          │
+└──────────────────────────────────────────────────────────┘
+```
+
+### TEA Integration with BMad v6 Workflow
+
+TEA operates **across all four BMad phases**, unlike other agents that are phase-specific:
+
+<details>
+<summary><strong>Cross-Phase Integration & Workflow Complexity</strong></summary>
+
+### Phase-Specific Agents (Standard Pattern)
+
+- **Phase 1 (Analysis)**: Analyst agent
+- **Phase 2 (Planning)**: PM agent
+- **Phase 3 (Solutioning)**: Architect agent
+- **Phase 4 (Implementation)**: SM, DEV agents
+
+### TEA: Cross-Phase Quality Agent (Unique Pattern)
+
+TEA is **the only agent that spans all phases**:
+
+```
+Phase 1 (Analysis) → [TEA not typically used]
+    ↓
+Phase 2 (Planning) → TEA: *framework, *ci, *test-design (setup)
+    ↓
+Phase 3 (Solutioning) → [TEA validates architecture testability]
+    ↓
+Phase 4 (Implementation) → TEA: *atdd, *automate, *test-review, *trace (per story)
+    ↓
+Epic/Release Gate → TEA: *nfr-assess, *trace Phase 2 (release decision)
+```
+
+### Why TEA Needs 8 Workflows
+
+**Standard agents**: 1-3 workflows per phase
+**TEA**: 8 workflows across 3+ phases
+
+| Phase       | TEA Workflows                          | Frequency        | Purpose                          |
+| ----------- | -------------------------------------- | ---------------- | -------------------------------- |
+| **Phase 2** | *framework, *ci, \*test-design         | Once per project | Establish quality infrastructure |
+| **Phase 4** | *atdd, *automate, *test-review, *trace | Per story/sprint | Continuous quality validation    |
+| **Release** | *nfr-assess, *trace (Phase 2: gate)    | Per epic/release | Go/no-go decision                |
+
+**Note**: `*trace` is a two-phase workflow: Phase 1 (traceability) + Phase 2 (gate decision). This reduces cognitive load while maintaining natural workflow.
+
+This complexity **requires specialized documentation** (this guide), **extensive knowledge base** (19+ fragments), and **unique architecture** (`testarch/` directory).
+
+</details>
+
+## Prerequisites and Setup
+
+1. Run the core planning workflows first:
+   - Analyst `*product-brief`
+   - Product Manager `*prd`
+   - Architect `*create-architecture`
+2. Confirm `bmad/bmm/config.yaml` defines `project_name`, `output_folder`, `dev_story_location`, and language settings.
+3. Ensure a test test framework setup exists; if not, use `*framework` command to create a test framework setup, prior to development.
+4. Skim supporting references (knowledge under `testarch/`, command workflows under `workflows/testarch/`).
+   - `tea-index.csv` + `knowledge/*.md`
+
+## High-Level Cheat Sheets
+
+### Greenfield Feature Launch (Level 2)
+
+| Phase              | Test Architect                                                            | Dev / Team                                                            | Outputs                                                                      |
+| ------------------ | ------------------------------------------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
+| Setup              | -                                                                         | Analyst `*product-brief`, PM `*prd`, Architect `*create-architecture` | `{output_folder}/product-brief*.md`, `PRD.md`, `epics.md`, `architecture.md` |
+| Pre-Implementation | Run `*framework` (if harness missing), `*ci`, and `*test-design`          | Review risk/design/CI guidance, align backlog                         | Test scaffold, CI pipeline, risk and coverage strategy                       |
+| Story Prep         | -                                                                         | Scrum Master `*create-story`, `*story-context`                        | Story markdown + context XML                                                 |
+| Implementation     | (Optional) Trigger `*atdd` before dev to supply failing tests + checklist | Implement story guided by ATDD checklist                              | Failing acceptance tests + implementation checklist                          |
+| Post-Dev           | Execute `*automate`, (Optional) `*test-review`, re-run `*trace`           | Address recommendations, update code/tests                            | Regression specs, quality report, refreshed coverage matrix                  |
+| Release            | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2)         | Confirm Definition of Done, share release notes                       | Quality audit, Gate YAML + release summary (owners, waivers)                 |
+
+<details>
+<summary>Execution Notes</summary>
+
+- Run `*framework` only once per repo or when modern harness support is missing.
+- `*framework` followed by `*ci` establishes install + pipeline; `*test-design` then handles risk scoring, mitigations, and scenario planning in one pass.
+- Use `*atdd` before coding when the team can adopt ATDD; share its checklist with the dev agent.
+- Post-implementation, keep `*trace` current, expand coverage with `*automate`, optionally review test quality with `*test-review`. For release gate, run `*trace` with Phase 2 enabled to get deployment decision.
+- Use `*test-review` after `*atdd` to validate generated tests, after `*automate` to ensure regression quality, or before gate for final audit.
+
+</details>
+
+<details>
+<summary>Worked Example – “Nova CRM” Greenfield Feature</summary>
+
+1. **Planning:** Analyst runs `*product-brief`; PM executes `*prd` to produce PRD and epics; Architect completes `*create-architecture` for the new module.
+2. **Setup:** TEA checks harness via `*framework`, configures `*ci`, and runs `*test-design` to capture risk/coverage plans.
+3. **Story Prep:** Scrum Master generates the story via `*create-story`; PO validates using `*solutioning-gate-check`.
+4. **Implementation:** TEA optionally runs `*atdd`; Dev implements with guidance from failing tests and the plan.
+5. **Post-Dev and Release:** TEA runs `*automate`, optionally `*test-review` to audit test quality, re-runs `*trace` with Phase 2 enabled to generate both traceability and gate decision.
+
+</details>
+
+### Brownfield Feature Enhancement (Level 3–4)
+
+| Phase             | Test Architect                                                                         | Dev / Team                                                   | Outputs                                                                 |
+| ----------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------- |
+| Refresh Context   | -                                                                                      | Analyst/PM/Architect rerun planning workflows                | Updated planning artifacts in `{output_folder}`                         |
+| Baseline Coverage | Run `*trace` to inventory existing tests                                               | Review matrix, flag hotspots                                 | Coverage matrix + initial gate snippet                                  |
+| Risk Targeting    | Run `*test-design`                                                                     | Align remediation/backlog priorities                         | Brownfield risk memo + scenario matrix                                  |
+| Story Prep        | -                                                                                      | Scrum Master `*create-story`                                 | Updated story markdown                                                  |
+| Implementation    | (Optional) Run `*atdd` before dev                                                      | Implement story, referencing checklist/tests                 | Failing acceptance tests + implementation checklist                     |
+| Post-Dev          | Apply `*automate`, (Optional) `*test-review`, re-run `*trace`, `*nfr-assess` if needed | Resolve gaps, update docs/tests                              | Regression specs, quality report, refreshed coverage matrix, NFR report |
+| Release           | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2)                      | Product Owner `*solutioning-gate-check`, share release notes | Quality audit, Gate YAML + release summary                              |
+
+<details>
+<summary>Execution Notes</summary>
+
+- Lead with `*trace` so remediation plans target true coverage gaps. Ensure `*framework` and `*ci` are in place early in the engagement; if the brownfield lacks them, run those setup steps immediately after refreshing context.
+- `*test-design` should highlight regression hotspots, mitigations, and P0 scenarios.
+- Use `*atdd` when stories benefit from ATDD; otherwise proceed to implementation and rely on post-dev automation.
+- After development, expand coverage with `*automate`, optionally review test quality with `*test-review`, re-run `*trace` (Phase 2 for gate decision). Run `*nfr-assess` now if non-functional risks weren't addressed earlier.
+- Use `*test-review` to validate existing brownfield tests or audit new tests before gate.
+- Product Owner `*solutioning-gate-check` confirms the team has artifacts before handoff or release.
+
+</details>
+
+<details>
+<summary>Worked Example – “Atlas Payments” Brownfield Story</summary>
+
+1. **Context Refresh:** Analyst reruns `*product-brief`; PM executes `*prd` to update PRD, analysis, and `epics.md`; Architect triggers `*create-architecture` capturing legacy payment flows.
+2. **Baseline Coverage:** TEA executes `*trace` to record current coverage in `docs/qa/assessments/atlas-payment-trace.md`.
+3. **Risk and Design:** `*test-design` flags settlement edge cases, plans mitigations, and allocates new API/E2E scenarios with P0 priorities.
+4. **Story Prep:** Scrum Master generates `stories/story-1.1.md` via `*create-story`, automatically pulling updated context.
+5. **ATDD First:** TEA runs `*atdd`, producing failing Playwright specs under `tests/e2e/payments/` plus an implementation checklist.
+6. **Implementation:** Dev pairs with the checklist/tests to deliver the story.
+7. **Post-Implementation:** TEA applies `*automate`, optionally `*test-review` to audit test quality, re-runs `*trace` with Phase 2 enabled, performs `*nfr-assess` to validate SLAs. The `*trace` Phase 2 output marks PASS with follow-ups.
+
+</details>
+
+### Enterprise / Compliance Program (Level 4)
+
+| Phase               | Test Architect                                                    | Dev / Team                                     | Outputs                                                    |
+| ------------------- | ----------------------------------------------------------------- | ---------------------------------------------- | ---------------------------------------------------------- |
+| Strategic Planning  | -                                                                 | Analyst/PM/Architect standard workflows        | Enterprise-grade PRD, epics, architecture                  |
+| Quality Planning    | Run `*framework`, `*test-design`, `*nfr-assess`                   | Review guidance, align compliance requirements | Harness scaffold, risk + coverage plan, NFR documentation  |
+| Pipeline Enablement | Configure `*ci`                                                   | Coordinate secrets, pipeline approvals         | `.github/workflows/test.yml`, helper scripts               |
+| Execution           | Enforce `*atdd`, `*automate`, `*test-review`, `*trace` per story  | Implement stories, resolve TEA findings        | Tests, fixtures, quality reports, coverage matrices        |
+| Release             | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2) | Capture sign-offs, archive artifacts           | Quality audit, updated assessments, gate YAML, audit trail |
+
+<details>
+<summary>Execution Notes</summary>
+
+- Use `*atdd` for every story when feasible so acceptance tests lead implementation in regulated environments.
+- `*ci` scaffolds selective testing scripts, burn-in jobs, caching, and notifications for long-running suites.
+- Enforce `*test-review` per story or sprint to maintain quality standards and ensure compliance with testing best practices.
+- Prior to release, rerun coverage (`*trace`, `*automate`), perform final quality audit with `*test-review`, and formalize the decision with `*trace` Phase 2 (gate decision); store everything for audits. Call `*nfr-assess` here if compliance/performance requirements weren't captured during planning.
+
+</details>
+
+<details>
+<summary>Worked Example – “Helios Ledger” Enterprise Release</summary>
+
+1. **Strategic Planning:** Analyst/PM/Architect complete PRD, epics, and architecture using the standard workflows.
+2. **Quality Planning:** TEA runs `*framework`, `*test-design`, and `*nfr-assess` to establish mitigations, coverage, and NFR targets.
+3. **Pipeline Setup:** TEA configures CI via `*ci` with selective execution scripts.
+4. **Execution:** For each story, TEA enforces `*atdd`, `*automate`, `*test-review`, and `*trace`; Dev teams iterate on the findings.
+5. **Release:** TEA re-checks coverage, performs final quality audit with `*test-review`, and logs the final gate decision via `*trace` Phase 2, archiving artifacts for compliance.
+
+</details>
+
+## Command Catalog
+
+<details>
+<summary><strong>Optional Playwright MCP Enhancements</strong></summary>
+
+**Two Playwright MCP servers** (actively maintained, continuously updated):
+
+- `playwright` - Browser automation (`npx @playwright/mcp@latest`)
+- `playwright-test` - Test runner with failure analysis (`npx playwright run-test-mcp-server`)
+
+**How MCP Enhances TEA Workflows**:
+
+MCP provides additional capabilities on top of TEA's default AI-based approach:
+
+1. `*test-design`:
+   - Default: Analysis + documentation
+   - **+ MCP**: Interactive UI discovery with `browser_navigate`, `browser_click`, `browser_snapshot`, behavior observation
+
+   Benefit:Discover actual functionality, edge cases, undocumented features
+
+2. `*atdd`, `*automate`:
+   - Default: Infers selectors and interactions from requirements and knowledge fragments
+   - **+ MCP**: Generates tests **then** verifies with `generator_setup_page`, `browser_*` tools, validates against live app
+
+   Benefit: Accurate selectors from real DOM, verified behavior, refined test code
+
+3. `*automate`:
+   - Default: Pattern-based fixes from error messages + knowledge fragments
+   - **+ MCP**: Pattern fixes **enhanced with** `browser_snapshot`, `browser_console_messages`, `browser_network_requests`, `browser_generate_locator`
+
+   Benefit: Visual failure context, live DOM inspection, root cause discovery
+
+**Config example**:
+
+```json
+{
+  "mcpServers": {
+    "playwright": {
+      "command": "npx",
+      "args": ["@playwright/mcp@latest"]
+    },
+    "playwright-test": {
+      "command": "npx",
+      "args": ["playwright", "run-test-mcp-server"]
+    }
+  }
+}
+```
+
+**To disable**: Set `tea_use_mcp_enhancements: false` in `bmad/bmm/config.yaml` OR remove MCPs from IDE config.
+
+</details>
+
+<br></br>
+
+| Command        | Workflow README                                   | Primary Outputs                                                                               | Notes                                                | With Playwright MCP Enhancements                                                                             |
+| -------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
+| `*framework`   | [📖](../workflows/testarch/framework/README.md)   | Playwright/Cypress scaffold, `.env.example`, `.nvmrc`, sample specs                           | Use when no production-ready harness exists          | -                                                                                                            |
+| `*ci`          | [📖](../workflows/testarch/ci/README.md)          | CI workflow, selective test scripts, secrets checklist                                        | Platform-aware (GitHub Actions default)              | -                                                                                                            |
+| `*test-design` | [📖](../workflows/testarch/test-design/README.md) | Combined risk assessment, mitigation plan, and coverage strategy                              | Risk scoring + optional exploratory mode             | **+ Exploratory**: Interactive UI discovery with browser automation (uncover actual functionality)           |
+| `*atdd`        | [📖](../workflows/testarch/atdd/README.md)        | Failing acceptance tests + implementation checklist                                           | TDD red phase + optional recording mode              | **+ Recording**: AI generation verified with live browser (accurate selectors from real DOM)                 |
+| `*automate`    | [📖](../workflows/testarch/automate/README.md)    | Prioritized specs, fixtures, README/script updates, DoD summary                               | Optional healing/recording, avoid duplicate coverage | **+ Healing**: Pattern fixes enhanced with visual debugging + **+ Recording**: AI verified with live browser |
+| `*test-review` | [📖](../workflows/testarch/test-review/README.md) | Test quality review report with 0-100 score, violations, fixes                                | Reviews tests against knowledge base patterns        | -                                                                                                            |
+| `*nfr-assess`  | [📖](../workflows/testarch/nfr-assess/README.md)  | NFR assessment report with actions                                                            | Focus on security/performance/reliability            | -                                                                                                            |
+| `*trace`       | [📖](../workflows/testarch/trace/README.md)       | Phase 1: Coverage matrix, recommendations. Phase 2: Gate decision (PASS/CONCERNS/FAIL/WAIVED) | Two-phase workflow: traceability + gate decision     | -                                                                                                            |
+
+**📖** = Click to view detailed workflow documentation
+
+## Why TEA is Architecturally Different
+
+TEA is the only BMM agent with its own top-level module directory (`bmm/testarch/`). This intentional design pattern reflects TEA's unique requirements:
+
+<details>
+<summary><strong>Unique Architecture Pattern & Rationale</strong></summary>
+
+### Directory Structure
+
+```
+src/modules/bmm/
+├── agents/
+│   └── tea.agent.yaml          # Agent definition (standard location)
+├── workflows/
+│   └── testarch/               # TEA workflows (standard location)
+└── testarch/                   # Knowledge base (UNIQUE!)
+    ├── knowledge/              # 21 production-ready test pattern fragments
+    ├── tea-index.csv           # Centralized knowledge lookup (21 fragments indexed)
+    └── README.md               # This guide
+```
+
+### Why TEA Gets Special Treatment
+
+TEA uniquely requires **extensive domain knowledge** (21 fragments, 12,821 lines: test patterns, CI/CD, fixtures, quality practices, healing strategies), a **centralized reference system** (`tea-index.csv` for on-demand fragment loading), **cross-cutting concerns** (domain-specific patterns vs project-specific artifacts like PRDs/stories), and **optional MCP integration** (healing, exploratory, verification modes). Other BMM agents don't require this architecture.
+
+</details>