External/BMAD-METHOD
1
0
Fork 0
mirror of https://github.com/bmadcode/BMAD-METHOD.git synced 2025-12-17 17:55:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

refactor: update TEA documentation to align with BMad 4-phase methodology (#870)

Browse Source 
* refactor: update TEA documentation to align with BMad 4-phase methodology

* reafactor: address review comments

---------

Co-authored-by: Murat Ozcan <murat@mac.lan>
This commit is contained in:
Murat K Ozcan 2025-11-05 13:37:51 -06:00 committed by GitHub
parent 6fa6ebab12
commit c20ead1acb
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 269 additions and 175 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored
View File

@ -34,7 +34,7 @@ Thumbs.db
.bmad*/.cursor/
# AI assistant files
CLAUDE.md
# CLAUDE.md # we need this for Claude Code reviews
.ai/*
cursor
.gemini

29
bmad/bmm/workflows/workflow-status/paths/enterprise-brownfield.yaml
View File

@ -77,26 +77,33 @@ phases:
output: "Integration architecture with enterprise considerations"
note: "Distills brownfield context + adds security/scalability/compliance design"
- id: "framework"
optional: true
agent: "tea"
command: "framework"
output: "Test framework scaffold (Playwright/Cypress)"
note: "Modernize test framework AFTER architecture defines integration approach"
- id: "ci"
optional: true
agent: "tea"
command: "ci"
output: "CI/CD test pipeline configuration"
note: "Configure CI pipeline AFTER architecture and framework decisions"
- id: "create-security-architecture"
required: true
optional: true
agent: "architect"
command: "create-security-architecture"
output: "Security architecture for brownfield integration"
note: "Future workflow - threat model, auth integration, audit requirements"
note: "Future workflow - optional extended enterprise workflow for threat model, auth integration, audit requirements"
- id: "create-devops-strategy"
required: true
optional: true
agent: "architect"
command: "create-devops-strategy"
output: "DevOps strategy for brownfield deployment"
note: "Future workflow - CI/CD integration, deployment strategy, monitoring"
- id: "create-test-strategy"
required: true
agent: "tea"
command: "create-test-strategy"
output: "Test strategy including regression testing"
note: "Future workflow - critical for brownfield to prevent breaking existing functionality"
note: "Future workflow - optional extended enterprise workflow for CI/CD integration, deployment strategy, monitoring"
- id: "validate-architecture"
optional: true

29
bmad/bmm/workflows/workflow-status/paths/enterprise-greenfield.yaml
View File

@ -65,26 +65,33 @@ phases:
output: "Enterprise-grade system architecture"
note: "Includes scalability, multi-tenancy, integration architecture"
- id: "framework"
optional: true
agent: "tea"
command: "framework"
output: "Test framework scaffold (Playwright/Cypress)"
note: "Initialize test framework AFTER architecture defines technology stack"
- id: "ci"
optional: true
agent: "tea"
command: "ci"
output: "CI/CD test pipeline configuration"
note: "Configure CI pipeline AFTER architecture and framework choices are made"
- id: "create-security-architecture"
required: true
optional: true
agent: "architect"
command: "create-security-architecture"
output: "Security architecture and threat model"
note: "Future workflow - security design, auth, compliance"
note: "Future workflow - optional extended enterprise workflow for security design, auth, compliance"
- id: "create-devops-strategy"
required: true
optional: true
agent: "architect"
command: "create-devops-strategy"
output: "DevOps pipeline and infrastructure plan"
note: "Future workflow - CI/CD, deployment, monitoring"
- id: "create-test-strategy"
required: true
agent: "tea"
command: "create-test-strategy"
output: "Comprehensive test strategy"
note: "Future workflow - test approach, automation, quality gates"
note: "Future workflow - optional extended enterprise workflow for CI/CD, deployment, monitoring"
- id: "validate-architecture"
optional: true

303
src/modules/bmm/docs/test-architecture.md
View File

@ -1,5 +1,5 @@
---
last-redoc-date: 2025-10-14
last-redoc-date: 2025-11-05
---
# Test Architect (TEA) Agent Guide
@ -7,29 +7,37 @@ last-redoc-date: 2025-10-14
## 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.
- **Mission:** Deliver actionable quality strategies, automation coverage, and gate decisions that scale with project complexity and compliance demands.
- **Use When:** BMad Method or Enterprise track projects, integration risk is non-trivial, brownfield regression risk exists, or compliance/NFR evidence is required. (Quick Flow projects typically don't require TEA)
## TEA Workflow Lifecycle
TEA integrates across the entire BMad development lifecycle, providing quality assurance at every phase:
TEA integrates into the BMad development lifecycle during Solutioning (Phase 3) and Implementation (Phase 4):
```mermaid
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#fff','primaryTextColor':'#000','primaryBorderColor':'#000','lineColor':'#000','secondaryColor':'#fff','tertiaryColor':'#fff','fontSize':'16px','fontFamily':'arial'}}}%%
graph TB
subgraph Phase2["<b>Phase 2: PLANNING</b>"]
PM["<b>PM: *prd</b>"]
Framework["<b>TEA: *framework</b>"]
CI["<b>TEA: *ci</b>"]
TestDesign["<b>TEA: *test-design</b>"]
PM --> Framework
Framework --> CI
CI --> TestDesign
SetupNote["<b>Setup once per project</b>"]
TestDesign -.-> SetupNote
PM["<b>PM: *prd (creates PRD + epics)</b>"]
PlanNote["<b>Business requirements phase</b>"]
PM -.-> PlanNote
end
subgraph Phase4["<b>Phase 4: IMPLEMENTATION - Per Story Cycle</b>"]
subgraph Phase3["<b>Phase 3: SOLUTIONING</b>"]
Architecture["<b>Architect: *architecture</b>"]
Framework["<b>TEA: *framework</b>"]
CI["<b>TEA: *ci</b>"]
GateCheck["<b>Architect: *solutioning-gate-check</b>"]
Architecture --> Framework
Framework --> CI
CI --> GateCheck
Phase3Note["<b>Test infrastructure AFTER architecture</b><br/>defines technology stack"]
Framework -.-> Phase3Note
end
subgraph Phase4["<b>Phase 4: IMPLEMENTATION - Per Epic Cycle</b>"]
SprintPlan["<b>SM: *sprint-planning</b>"]
TestDesign["<b>TEA: *test-design (per epic)</b>"]
CreateStory["<b>SM: *create-story</b>"]
ATDD["<b>TEA: *atdd (optional, before dev)</b>"]
DevImpl["<b>DEV: implements story</b>"]
@ -37,12 +45,16 @@ graph TB
TestReview1["<b>TEA: *test-review (optional)</b>"]
Trace1["<b>TEA: *trace (refresh coverage)</b>"]
SprintPlan --> TestDesign
TestDesign --> CreateStory
CreateStory --> ATDD
ATDD --> DevImpl
DevImpl --> Automate
Automate --> TestReview1
TestReview1 --> Trace1
Trace1 -.->|next story| CreateStory
TestDesignNote["<b>Test design: 'How do I test THIS epic?'</b><br/>Creates test-design-epic-N.md per epic"]
TestDesign -.-> TestDesignNote
end
subgraph Gate["<b>EPIC/RELEASE GATE</b>"]
@ -60,10 +72,12 @@ graph TB
GateDecision -->|WAIVED| Waived["<b>WAIVED ⏭️</b>"]
end
Phase2 --> Phase4
Phase2 --> Phase3
Phase3 --> Phase4
Phase4 --> Gate
style Phase2 fill:#bbdefb,stroke:#0d47a1,stroke-width:3px,color:#000
style Phase3 fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px,color:#000
style Phase4 fill:#e1bee7,stroke:#4a148c,stroke-width:3px,color:#000
style Gate fill:#ffe082,stroke:#f57c00,stroke-width:3px,color:#000
style Pass fill:#4caf50,stroke:#1b5e20,stroke-width:3px,color:#000
@ -72,82 +86,129 @@ graph TB
style Waived fill:#9c27b0,stroke:#4a148c,stroke-width:3px,color:#000
```
### TEA Integration with BMad v6 Workflow
**Phase Numbering Note:** BMad uses a 4-phase methodology with optional Phase 0/1:
TEA operates **across all four BMad phases**, unlike other agents that are phase-specific:
- **Phase 0** (Optional): Documentation (brownfield prerequisite - `*document-project`)
- **Phase 1** (Optional): Discovery/Analysis (`*brainstorm`, `*research`, `*product-brief`)
- **Phase 2** (Required): Planning (`*prd` creates PRD + epics)
- **Phase 3** (Track-dependent): Solutioning (`*architecture` → TEA: `*framework`, `*ci` → `*solutioning-gate-check`)
- **Phase 4** (Required): Implementation (`*sprint-planning` → per-epic: `*test-design` → per-story: dev workflows)
**TEA workflows:** `*framework` and `*ci` run once in Phase 3 after architecture. `*test-design` runs per-epic in Phase 4. Output: `test-design-epic-N.md`.
Quick Flow track skips Phases 0, 1, and 3. BMad Method and Enterprise use all phases based on project needs.
### Why TEA is Different from Other BMM Agents
TEA is the only BMM agent that operates in **multiple phases** (Phase 3 and Phase 4) and has its own **knowledge base architecture**.
<details>
<summary><strong>Cross-Phase Integration & Workflow Complexity</strong></summary>
<summary><strong>Cross-Phase Operation & Unique Architecture</strong></summary>
### Phase-Specific Agents (Standard Pattern)
Most BMM agents work in a single phase:
- **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: Multi-Phase Quality Agent (Unique Pattern)
TEA is **the only agent that spans all phases**:
TEA is **the only agent that operates in multiple phases**:
```
Phase 1 (Analysis) → [TEA not typically used]
↓
Phase 2 (Planning) → TEA: *framework, *ci, *test-design (setup)
Phase 2 (Planning) → [PM defines requirements - TEA not active]
↓
Phase 3 (Solutioning) → [TEA validates architecture testability]
Phase 3 (Solutioning) → TEA: *framework, *ci (test infrastructure AFTER architecture)
↓
Phase 4 (Implementation) → TEA: *atdd, *automate, *test-review, *trace (per story)
Phase 4 (Implementation) → TEA: *test-design (per epic: "how do I test THIS feature?")
→ TEA: *atdd, *automate, *test-review, *trace (per story)
↓
Epic/Release Gate → TEA: *nfr-assess, *trace Phase 2 (release decision)
```
### Why TEA Needs 8 Workflows
### TEA's 8 Workflows Across Phases
**Standard agents**: 1-3 workflows per phase
**TEA**: 8 workflows across 3+ phases
**TEA**: 8 workflows across Phase 3, Phase 4, and Release Gate
| 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 |
| ----------- | ----------------------------------------------------- | ---------------- | ---------------------------------------------- |
| **Phase 2** | (none) | - | Planning phase - PM defines requirements |
| **Phase 3** | *framework, *ci | Once per project | Setup test infrastructure AFTER architecture |
| **Phase 4** | *test-design, *atdd, *automate, *test-review, \*trace | Per epic/story | Test planning per epic, then per-story testing |
| **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).
### Unique Directory Architecture
TEA is the only BMM agent with its own top-level module directory (`bmm/testarch/`):
```
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 covering test patterns, CI/CD, fixtures, quality practices, healing strategies
- **Centralized reference system**: `tea-index.csv` for on-demand fragment loading during workflow execution
- **Cross-cutting concerns**: Domain-specific testing patterns (vs project-specific artifacts like PRDs/stories)
- **Optional MCP integration**: Healing, exploratory, and verification modes for enhanced testing capabilities
This architecture enables TEA to maintain consistent, production-ready testing patterns across all BMad projects while operating across multiple development phases.
</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)
These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks** across the **4-Phase Methodology** (Phase 1: Analysis, Phase 2: Planning, Phase 3: Solutioning, Phase 4: Implementation).
| 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) |
**Note:** Quick Flow projects typically don't require TEA (covered in Overview). These cheat sheets focus on BMad Method and Enterprise tracks where TEA adds value.
**Legend for Track Deltas:**
- ➕ = New workflow or phase added (doesn't exist in baseline)
- 🔄 = Modified focus (same workflow, different emphasis or purpose)
- 📦 = Additional output or archival requirement
### Greenfield - BMad Method (Simple/Standard Work)
**Planning Track:** BMad Method (PRD + Architecture)
**Use Case:** New projects with standard complexity
| Workflow Stage | Test Architect | Dev / Team | Outputs |
| -------------------------- | ----------------------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------- |
| **Phase 1**: Discovery | - | Analyst `*product-brief` (optional) | `product-brief.md` |
| **Phase 2**: Planning | - | PM `*prd` (creates PRD + epics) | PRD, epics |
| **Phase 3**: Solutioning | Run `*framework`, `*ci` AFTER architecture | Architect `*architecture`, `*solutioning-gate-check` | Architecture, test scaffold, CI pipeline |
| **Phase 4**: Sprint Start | - | SM `*sprint-planning` | Sprint status file with all epics and stories |
| **Phase 4**: Epic Planning | Run `*test-design` for THIS epic (per-epic test plan) | Review epic scope | `test-design-epic-N.md` with risk assessment and test plan |
| **Phase 4**: Story Dev | (Optional) `*atdd` before dev, then `*automate` after | SM `*create-story`, DEV implements | Tests, story implementation |
| **Phase 4**: Story Review | Execute `*test-review` (optional), re-run `*trace` | Address recommendations, update code/tests | Quality report, refreshed coverage matrix |
| **Phase 4**: Release Gate | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2) | Confirm Definition of Done, share release notes | Quality audit, Gate YAML + release summary |
<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.
- **Phase 3 (Solutioning)**: After architecture is complete, run `*framework` and `*ci` to setup test infrastructure based on architectural decisions.
- **Phase 4 starts**: After solutioning is complete, sprint planning loads all epics.
- **`*test-design` runs per-epic**: At the beginning of working on each epic, run `*test-design` to create a test plan for THAT specific epic/feature. Output: `test-design-epic-N.md`.
- 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.
@ -157,79 +218,110 @@ This complexity **requires specialized documentation** (this guide), **extensive
<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.
1. **Planning (Phase 2):** Analyst runs `*product-brief`; PM executes `*prd` to produce PRD and epics.
2. **Solutioning (Phase 3):** Architect completes `*architecture` for the new module; TEA sets up test infrastructure via `*framework` and `*ci` based on architectural decisions; gate check validates planning completeness.
3. **Sprint Start (Phase 4):** Scrum Master runs `*sprint-planning` to load all epics into sprint status.
4. **Epic 1 Planning (Phase 4):** TEA runs `*test-design` to create test plan for Epic 1, producing `test-design-epic-1.md` with risk assessment.
5. **Story Implementation (Phase 4):** For each story in Epic 1, SM generates story via `*create-story`; TEA optionally runs `*atdd`; Dev implements with guidance from failing tests.
6. **Post-Dev (Phase 4):** TEA runs `*automate`, optionally `*test-review` to audit test quality, re-runs `*trace` to refresh coverage.
7. **Release Gate:** TEA runs `*trace` with Phase 2 enabled to generate gate decision.
</details>
### Brownfield Feature Enhancement (Level 3–4)
### Brownfield - BMad Method or Enterprise (Simple or Complex)
| 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 |
**Planning Tracks:** BMad Method or Enterprise Method
**Use Case:** Existing codebases - simple additions (BMad Method) or complex enterprise requirements (Enterprise Method)
**🔄 Brownfield Deltas from Greenfield:**
- ➕ Phase 0 (Documentation) - Document existing codebase if undocumented
- ➕ Phase 2: `*trace` - Baseline existing test coverage before planning
- 🔄 Phase 4: `*test-design` - Focus on regression hotspots and brownfield risks
- 🔄 Phase 4: Story Review - May include `*nfr-assess` if not done earlier
| Workflow Stage | Test Architect | Dev / Team | Outputs |
| ----------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------- |
| **Phase 0**: Documentation ➕ | - | Analyst `*document-project` (if undocumented) | Comprehensive project documentation |
| **Phase 1**: Discovery | - | Analyst/PM/Architect rerun planning workflows | Updated planning artifacts in `{output_folder}` |
| **Phase 2**: Planning | Run ➕ `*trace` (baseline coverage) | PM `*prd` (creates PRD + epics) | PRD, epics, ➕ coverage baseline |
| **Phase 3**: Solutioning | Run `*framework`, `*ci` AFTER architecture | Architect `*architecture`, `*solutioning-gate-check` | Architecture, test framework, CI pipeline |
| **Phase 4**: Sprint Start | - | SM `*sprint-planning` | Sprint status file with all epics and stories |
| **Phase 4**: Epic Planning | Run `*test-design` for THIS epic 🔄 (regression hotspots) | Review epic scope and brownfield risks | `test-design-epic-N.md` with brownfield risk assessment and mitigation |
| **Phase 4**: Story Dev | (Optional) `*atdd` before dev, then `*automate` after | SM `*create-story`, DEV implements | Tests, story implementation |
| **Phase 4**: Story Review | Apply `*test-review` (optional), re-run `*trace`, ➕ `*nfr-assess` if needed | Resolve gaps, update docs/tests | Quality report, refreshed coverage matrix, NFR report |
| **Phase 4**: Release Gate | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2) | Capture sign-offs, 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.
- Lead with `*trace` during Planning (Phase 2) to baseline existing test coverage before architecture work begins.
- **Phase 3 (Solutioning)**: After architecture is complete, run `*framework` and `*ci` to modernize test infrastructure. For brownfield, framework may need to integrate with or replace existing test setup.
- **Phase 4 starts**: After solutioning is complete and sprint planning loads all epics.
- **`*test-design` runs per-epic**: At the beginning of working on each epic, run `*test-design` to identify regression hotspots, integration risks, and mitigation strategies for THAT specific epic/feature. Output: `test-design-epic-N.md`.
- 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.
1. **Planning (Phase 2):** PM executes `*prd` to update PRD and `epics.md` (Epic 1: Payment Processing); TEA runs `*trace` to baseline existing coverage.
2. **Solutioning (Phase 3):** Architect triggers `*architecture` capturing legacy payment flows and integration architecture; TEA sets up `*framework` and `*ci` based on architectural decisions; gate check validates planning.
3. **Sprint Start (Phase 4):** Scrum Master runs `*sprint-planning` to load Epic 1 into sprint status.
4. **Epic 1 Planning (Phase 4):** TEA runs `*test-design` for Epic 1 (Payment Processing), producing `test-design-epic-1.md` that flags settlement edge cases, regression hotspots, and mitigation plans.
5. **Story Implementation (Phase 4):** For each story in Epic 1, SM generates story via `*create-story`; TEA runs `*atdd` producing failing Playwright specs; Dev implements with guidance from tests and checklist.
6. **Post-Dev (Phase 4):** TEA applies `*automate`, optionally `*test-review` to audit test quality, re-runs `*trace` to refresh coverage.
7. **Release Gate:** TEA performs `*nfr-assess` to validate SLAs, runs `*trace` with Phase 2 enabled to generate gate decision (PASS/CONCERNS/FAIL).
</details>
### Enterprise / Compliance Program (Level 4)
### Greenfield - Enterprise Method (Enterprise/Compliance Work)
| 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 |
**Planning Track:** Enterprise Method (BMad Method + extended security/devops/test strategies)
**Use Case:** New enterprise projects with compliance, security, or complex regulatory requirements
**🏢 Enterprise Deltas from BMad Method:**
- ➕ Phase 1: `*research` - Domain and compliance research (recommended)
- ➕ Phase 2: `*nfr-assess` - Capture NFR requirements early (security/performance/reliability)
- 🔄 Phase 4: `*test-design` - Enterprise focus (compliance, security architecture alignment)
- 📦 Release Gate - Archive artifacts and compliance evidence for audits
| Workflow Stage | Test Architect | Dev / Team | Outputs |
| -------------------------- | ------------------------------------------------------------------------ | ---------------------------------------------------- | ------------------------------------------------------------------ |
| **Phase 1**: Discovery | - | Analyst ➕ `*research`, `*product-brief` | Domain research, compliance analysis, product brief |
| **Phase 2**: Planning | Run ➕ `*nfr-assess` | PM `*prd` (creates PRD + epics), UX `*create-design` | Enterprise PRD, epics, UX design, ➕ NFR documentation |
| **Phase 3**: Solutioning | Run `*framework`, `*ci` AFTER architecture | Architect `*architecture`, `*solutioning-gate-check` | Architecture, test framework, CI pipeline |
| **Phase 4**: Sprint Start | - | SM `*sprint-planning` | Sprint plan with all epics |
| **Phase 4**: Epic Planning | Run `*test-design` for THIS epic 🔄 (compliance focus) | Review epic scope and compliance requirements | `test-design-epic-N.md` with security/performance/compliance focus |
| **Phase 4**: Story Dev | (Optional) `*atdd`, `*automate`, `*test-review`, `*trace` per story | SM `*create-story`, DEV implements | Tests, fixtures, quality reports, coverage matrices |
| **Phase 4**: Release Gate | Final `*test-review` audit, Run `*trace` (Phase 2), 📦 archive artifacts | Capture sign-offs, 📦 compliance evidence | 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.
- `*nfr-assess` runs early in Planning (Phase 2) to capture compliance, security, and performance requirements upfront.
- **Phase 3 (Solutioning)**: After architecture is complete, run `*framework` and `*ci` with enterprise-grade configurations (selective testing, burn-in jobs, caching, notifications).
- **Phase 4 starts**: After solutioning is complete and sprint planning loads all epics.
- **`*test-design` runs per-epic**: At the beginning of working on each epic, run `*test-design` to create an enterprise-focused test plan for THAT specific epic, ensuring alignment with security architecture, performance targets, and compliance requirements. Output: `test-design-epic-N.md`.
- Use `*atdd` for stories when feasible so acceptance tests can lead implementation.
- Use `*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); archive artifacts for compliance audits.
</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.
1. **Planning (Phase 2):** Analyst runs `*research` and `*product-brief`; PM completes `*prd` creating PRD and epics; TEA runs `*nfr-assess` to establish NFR targets.
2. **Solutioning (Phase 3):** Architect completes `*architecture` with enterprise considerations; TEA sets up `*framework` and `*ci` with enterprise-grade configurations based on architectural decisions; gate check validates planning completeness.
3. **Sprint Start (Phase 4):** Scrum Master runs `*sprint-planning` to load all epics into sprint status.
4. **Per-Epic (Phase 4):** For each epic, TEA runs `*test-design` to create epic-specific test plan (e.g., `test-design-epic-1.md`, `test-design-epic-2.md`) with compliance-focused risk assessment.
5. **Per-Story (Phase 4):** For each story, TEA uses `*atdd`, `*automate`, `*test-review`, and `*trace`; Dev teams iterate on the findings.
6. **Release Gate:** 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>
@ -300,30 +392,3 @@ MCP provides additional capabilities on top of TEA's default AI-based approach:
| `*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>

17
src/modules/bmm/docs/workflows-solutioning.md
View File

@ -32,9 +32,8 @@ graph TB
subgraph Optional["<b>ENTERPRISE ADDITIONS (Optional)</b>"]
direction LR
TestArch["<b>TEA: test-architecture</b><br/>(Future)"]
SecArch["<b>Architect: security-architecture</b>"]
DevOps["<b>Architect: devops-strategy</b>"]
SecArch["<b>Architect: security-architecture</b><br/>(Future)"]
DevOps["<b>Architect: devops-strategy</b><br/>(Future)"]
end
GateCheck["<b>Architect: solutioning-gate-check</b><br/>Validation before Phase 4"]
@ -69,7 +68,6 @@ graph TB
style SkipArch fill:#aed581,stroke:#1b5e20,stroke-width:2px,color:#000
style Architecture fill:#42a5f5,stroke:#0d47a1,stroke-width:2px,color:#000
style TestArch fill:#ef9a9a,stroke:#c62828,stroke-width:2px,color:#000
style SecArch fill:#ef9a9a,stroke:#c62828,stroke-width:2px,color:#000
style DevOps fill:#ef9a9a,stroke:#c62828,stroke-width:2px,color:#000
style GateCheck fill:#42a5f5,stroke:#0d47a1,stroke-width:2px,color:#000
@ -352,13 +350,14 @@ Planning (prd by PM)
```
Planning (prd by PM - same as BMad Method)
→ architecture (Architect)
→ Optional: test-architecture (TEA, future)
→ Optional: security-architecture (Architect)
→ Optional: devops-strategy (Architect)
→ Optional: security-architecture (Architect, future)
→ Optional: devops-strategy (Architect, future)
→ solutioning-gate-check (Architect)
→ Phase 4 (Implementation)
```
**Note on TEA (Test Architect):** TEA is fully operational with 8 workflows across all phases. TEA validates architecture testability during Phase 3 reviews but does not have a dedicated solutioning workflow. TEA's primary setup occurs in Phase 2 (`*framework`, `*ci`, `*test-design`) and testing execution in Phase 4 (`*atdd`, `*automate`, `*test-review`, `*trace`, `*nfr-assess`).
**Note:** Enterprise uses the same planning and architecture as BMad Method. The only difference is optional extended workflows added AFTER architecture but BEFORE gate check.
### Solutioning → Implementation Handoff
@ -422,11 +421,13 @@ Architecture documents are living. Update them as you learn during implementatio
### Enterprise
- **Planning:** prd (PM) - same as BMad Method
- **Solutioning:** architecture (Architect) → Optional extended workflows (test-architecture, security-architecture, devops-strategy) → solutioning-gate-check (Architect)
- **Solutioning:** architecture (Architect) → Optional extended workflows (security-architecture, devops-strategy) → solutioning-gate-check (Architect)
- **Implementation:** sprint-planning → epic-tech-context → dev-story
**Key Difference:** Enterprise adds optional extended workflows AFTER architecture but BEFORE gate check. Everything else is identical to BMad Method.
**Note:** TEA (Test Architect) operates across all phases and validates architecture testability but is not a Phase 3-specific workflow. See [Test Architecture Guide](./test-architecture.md) for TEA's full lifecycle integration.
---
## Common Anti-Patterns

29
src/modules/bmm/workflows/workflow-status/paths/enterprise-brownfield.yaml
View File

@ -66,6 +66,20 @@ phases:
command: "create-design"
note: "Recommended - must integrate with existing UX patterns"
- id: "framework"
optional: true
agent: "tea"
command: "framework"
output: "Test framework scaffold (Playwright/Cypress)"
note: "Initialize or modernize test framework - critical if brownfield lacks proper test infrastructure"
- id: "ci"
optional: true
agent: "tea"
command: "ci"
output: "CI/CD test pipeline configuration"
note: "Establish or enhance CI pipeline with regression testing strategy"
- phase: 2
name: "Solutioning"
required: true
@ -78,25 +92,18 @@ phases:
note: "Distills brownfield context + adds security/scalability/compliance design"
- id: "create-security-architecture"
required: true
optional: true
agent: "architect"
command: "create-security-architecture"
output: "Security architecture for brownfield integration"
note: "Future workflow - threat model, auth integration, audit requirements"
note: "Future workflow - optional extended enterprise workflow for threat model, auth integration, audit requirements"
- id: "create-devops-strategy"
required: true
optional: true
agent: "architect"
command: "create-devops-strategy"
output: "DevOps strategy for brownfield deployment"
note: "Future workflow - CI/CD integration, deployment strategy, monitoring"
- id: "create-test-strategy"
required: true
agent: "tea"
command: "create-test-strategy"
output: "Test strategy including regression testing"
note: "Future workflow - critical for brownfield to prevent breaking existing functionality"
note: "Future workflow - optional extended enterprise workflow for CI/CD integration, deployment strategy, monitoring"
- id: "validate-architecture"
optional: true

29
src/modules/bmm/workflows/workflow-status/paths/enterprise-greenfield.yaml
View File

@ -54,6 +54,20 @@ phases:
command: "create-design"
note: "Highly recommended for enterprise - design system and patterns"
- id: "framework"
optional: true
agent: "tea"
command: "framework"
output: "Test framework scaffold (Playwright/Cypress)"
note: "Initialize production-ready test framework - run once per project"
- id: "ci"
optional: true
agent: "tea"
command: "ci"
output: "CI/CD test pipeline configuration"
note: "Scaffold CI workflow with selective testing, burn-in, caching"
- phase: 2
name: "Solutioning"
required: true
@ -66,25 +80,18 @@ phases:
note: "Includes scalability, multi-tenancy, integration architecture"
- id: "create-security-architecture"
required: true
optional: true
agent: "architect"
command: "create-security-architecture"
output: "Security architecture and threat model"
note: "Future workflow - security design, auth, compliance"
note: "Future workflow - optional extended enterprise workflow for security design, auth, compliance"
- id: "create-devops-strategy"
required: true
optional: true
agent: "architect"
command: "create-devops-strategy"
output: "DevOps pipeline and infrastructure plan"
note: "Future workflow - CI/CD, deployment, monitoring"
- id: "create-test-strategy"
required: true
agent: "tea"
command: "create-test-strategy"
output: "Comprehensive test strategy"
note: "Future workflow - test approach, automation, quality gates"
note: "Future workflow - optional extended enterprise workflow for CI/CD, deployment, monitoring"
- id: "validate-architecture"
optional: true