Replaced the old TEA brief with an indexed knowledge system: the agent now loads topic-specific

docs from knowledge/ via tea-index.csv, workflows reference those fragments, and risk/level/
  priority guidance lives in the new fragment files

src/core/tasks/adv-elicit.md

@@ -8,7 +8,7 @@
     <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 &lt;action&gt; within &lt;step&gt; is a REQUIRED action to complete that step</i>
+    <i>Each action xml tag within step xml 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>
 
@@ -44,7 +44,7 @@
       </smart-selection>
     </step>
 
-    <step n="2" title="Present Options &amp; Handle Responses">
+    <step n="2" title="Present Options and Handle Responses">
 
       <format>
         **Advanced Elicitation Options**

src/core/tasks/index-docs.md

@@ -8,7 +8,7 @@
     <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 &lt;action&gt; within &lt;step&gt; is a REQUIRED action to complete that step</i>
+    <i>Each action xml tag within step xml 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>
 

src/core/tasks/shard-doc.md

@@ -8,7 +8,7 @@
     <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 &lt;action&gt; within &lt;step&gt; is a REQUIRED action to complete that step</i>
+    <i>Each action xml tag within step xml 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>
 

src/core/workflows/bmad-init/workflow.yaml

@@ -11,14 +11,4 @@ date: system-generated
 template: false
 instructions: "{project-root}/src/core/workflows/bmad-init/instructions.md"
 
-# Sub-components
-party_update_instructions: "{project-root}/src/core/workflows/bmad-init/party-update/instructions.md"
-
-# No specific output file - this workflow performs various system actions
-default_output_file: null
-
-# Required tools for execution
-required_tools:
-  - file_operations
-  - llm_analysis
-  - xml_generation
+web_bundle: false

src/core/workflows/party-mode/workflow.yaml

@@ -22,3 +22,5 @@ exit_triggers:
   - "*exit"
   - "end party mode"
   - "stop party mode"
+
+web_bundle: false

src/modules/bmb/_module-installer/install-menu-config.yaml

@@ -9,8 +9,3 @@ prompt: "Happy Building - Build the Modules, Workflows and Agents of your dreams
 ## user_name
 ## communication_language
 ## output_folder
-
-src_impact:
-  prompt: "Are you installing this module to your local Forked BMad Core repository? (not a separate project which is normally the case)"
-  default: false
-  result: "{value}"

src/modules/bmb/workflows/convert-legacy/README.md

@@ -8,7 +8,7 @@ The Convert Legacy workflow is a comprehensive migration tool that converts BMAD
 
 - **Multi-Format Detection** - Automatically identifies v4 agents, workflows, tasks, templates, and modules
 - **Intelligent Conversion** - Smart mapping from v4 patterns to v5 equivalents with structural improvements
-- **Sub-Workflow Integration** - Leverages build-agent, build-workflow, and build-module workflows for quality output
+- **Sub-Workflow Integration** - Leverages create-agent, create-workflow, and create-module workflows for quality output
 - **Structure Modernization** - Converts YAML-based agents to XML, templates to workflows, tasks to structured workflows
 - **Path Normalization** - Updates all references to use proper v5 path conventions
 - **Validation System** - Comprehensive validation of converted items before finalization
@@ -60,7 +60,7 @@ convert-legacy/
 
 ### Phase 1: Legacy Analysis (Steps 1-3)
 
-**Item Identification & Loading**
+**Item Identification and Loading**
 
 - Accepts file path or directory from user
 - Loads complete file/folder structure for analysis
@@ -91,10 +91,10 @@ convert-legacy/
 **Strategy Selection Based on Item Type**
 
 - **Simple Agents**: Direct XML conversion with metadata mapping
-- **Complex Agents**: Workflow-assisted creation using build-agent
+- **Complex Agents**: Workflow-assisted creation using create-agent
 - **Templates**: Template-to-workflow conversion with proper structure
 - **Tasks**: Task-to-workflow conversion with step mapping
-- **Modules**: Full module creation using build-module workflow
+- **Modules**: Full module creation using create-module workflow
 
 **Workflow Type Determination**
 
@@ -118,9 +118,9 @@ convert-legacy/
 
 - Extracts key information from legacy items
 - Invokes appropriate sub-workflows:
-  - `build-agent` for complex agent creation
-  - `build-workflow` for template/task conversion
-  - `build-module` for full module migration
+  - `create-agent` for complex agent creation
+  - `create-workflow` for template/task conversion
+  - `create-module` for full module migration
 - Ensures proper v5 structure and conventions
 
 **Template-to-Workflow Conversion (5c)**
@@ -139,7 +139,7 @@ convert-legacy/
 - Maps 1-9 elicitation menus to v5 elicitation patterns
 - Preserves execution logic and critical notices
 
-### Phase 4: Validation & Finalization (Steps 6-8)
+### Phase 4: Validation and Finalization (Steps 6-8)
 
 **Comprehensive Validation**
 
@@ -155,7 +155,7 @@ convert-legacy/
 - Notes manual adjustments needed
 - Provides warnings and recommendations
 
-**Cleanup & Archival**
+**Cleanup and Archival**
 
 - Optional archival of original v4 files
 - Final location confirmation
@@ -182,7 +182,7 @@ Converted items follow v5 conventions:
 
 - **Legacy v4 Items** - Source files or directories to convert
 - **Target Module Access** - Write permissions to target module directories
-- **Sub-Workflow Availability** - build-agent, build-workflow, build-module workflows accessible
+- **Sub-Workflow Availability** - create-agent, create-workflow, create-module workflows accessible
 - **Conversion Mappings** (optional) - v4-to-v5 pattern mappings for complex conversions
 
 ## Best Practices
@@ -244,7 +244,7 @@ To customize this workflow:
 
 - **v1.0.0** - Initial release
   - Multi-format v4 item detection and conversion
-  - Integration with build-agent, build-workflow, build-module
+  - Integration with create-agent, create-workflow, create-module
   - Comprehensive path normalization
   - Migration reporting and validation
 
@@ -252,7 +252,7 @@ To customize this workflow:
 
 For issues or questions:
 
-- Review the workflow creation guide at `/bmad/bmb/workflows/build-workflow/workflow-creation-guide.md`
+- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
 - Check conversion mappings at `/bmad/bmb/data/v4-to-v5-mappings.yaml`
 - Validate output using `checklist.md`
 - Consult BMAD v5 documentation for proper conventions

src/modules/bmb/workflows/convert-legacy/instructions.md

@@ -9,10 +9,10 @@
 <action>Ask user for the path to the v4 item to convert (agent, workflow, or module)</action>
 <action>Load the complete file/folder structure</action>
 <action>Detect item type based on structure and content patterns:</action>
-  - Agent: Contains `<agent>` or `<prompt>` XML tags, single file
+  - Agent: Contains agent or prompt XML tags, single file
   - Workflow: Contains workflow YAML or instruction patterns, usually folder
   - Module: Contains multiple agents/workflows in organized structure
-  - Task: Contains `<task>` XML tags
+  - Task: Contains task XML tags
 <ask>Confirm detected type or allow user to correct: "Detected as [type]. Is this correct? (y/n)"</ask>
 </step>
 
@@ -164,7 +164,7 @@ For Modules:
 - Any special behaviors
 
 <invoke-workflow>
-  workflow: {project-root}/bmad/bmb/workflows/build-agent/workflow.yaml
+  workflow: {project-root}/bmad/bmb/workflows/create-agent/workflow.yaml
   inputs:
     - agent_name: {{extracted_name}}
     - agent_purpose: {{extracted_purpose}}
@@ -201,7 +201,7 @@ For Modules:
    - Processing flow → integrate into workflow steps
 
 <invoke-workflow>
-  workflow: {project-root}/bmad/bmb/workflows/build-workflow/workflow.yaml
+  workflow: {project-root}/bmad/bmb/workflows/create-workflow/workflow.yaml
   inputs:
     - workflow_name: {{template_name}}
     - workflow_type: document
@@ -217,7 +217,7 @@ For Modules:
 <action>Create module blueprint with all components</action>
 
 <invoke-workflow>
-  workflow: {project-root}/bmad/bmb/workflows/build-module/workflow.yaml
+  workflow: {project-root}/bmad/bmb/workflows/create-module/workflow.yaml
   inputs:
     - module_name: {{module_name}}
     - components: {{component_list}}
@@ -259,7 +259,7 @@ For Modules:
    - Critical notices → workflow.yaml comments
 
 <invoke-workflow>
-  workflow: {project-root}/bmad/bmb/workflows/build-workflow/workflow.yaml
+  workflow: {project-root}/bmad/bmb/workflows/create-workflow/workflow.yaml
   inputs:
     - workflow_name: {{task_name}}
     - workflow_type: {{confirmed_workflow_type}}

src/modules/bmb/workflows/convert-legacy/workflow.yaml

@@ -14,7 +14,6 @@ date: system-generated
 # Optional docs that can be provided as input
 recommended_inputs:
   - legacy_file: "Path to v4 agent, workflow, or module to convert"
-  - conversion_mappings: "{project-root}/bmad/bmb/data/v4-to-v5-mappings.yaml"
 
 # Module path and component files
 installed_path: "{project-root}/bmad/bmb/workflows/convert-legacy"
@@ -27,9 +26,8 @@ default_output_folder: "{project-root}/bmad/{{target_module}}/{{item_type}}/{{it
 
 # Sub-workflows that may be invoked for conversion
 sub_workflows:
-  - create_agent: "{project-root}/bmad/bmb/workflows/build-agent/workflow.yaml"
-  - create_workflow: "{project-root}/bmad/bmb/workflows/build-workflow/workflow.yaml"
-  - create_module: "{project-root}/bmad/bmb/workflows/build-module/workflow.yaml"
+  - create_agent: "{project-root}/bmad/bmb/workflows/create-agent/workflow.yaml"
+  - create_workflow: "{project-root}/bmad/bmb/workflows/create-workflow/workflow.yaml"
+  - create_module: "{project-root}/bmad/bmb/workflows/create-module/workflow.yaml"
 
-# No special tools required beyond standard BMAD capabilities
-required_tools: []
+web_bundle: false

src/modules/bmb/workflows/create-agent/README.md

@@ -19,7 +19,7 @@ The Build Agent workflow is an interactive agent builder that guides you through
 ### Basic Invocation
 
 ```bash
-workflow build-agent
+workflow create-agent
 ```
 
 ### Through BMad Builder Agent
@@ -49,7 +49,7 @@ The workflow includes an optional brainstorming phase (Step -1) that helps you e
 ### Files Included
 
 ```
-build-agent/
+create-agent/
 ├── workflow.yaml                  # Configuration
 ├── instructions.md                # Step-by-step guide
 ├── checklist.md                   # Validation criteria

src/modules/bmb/workflows/create-agent/agent-command-patterns.md

@@ -318,7 +318,7 @@ Logic embedded in agent persona (Simple agents)
 
   <!-- 2. Primary workflows -->
   <c cmd="*create-prd" run-workflow="...">Create PRD</c>
-  <c cmd="*build-module" run-workflow="...">Build module</c>
+  <c cmd="*create-module" run-workflow="...">Build module</c>
 
   <!-- 3. Secondary actions -->
   <c cmd="*validate" exec="...">Validate document</c>
@@ -490,8 +490,8 @@ The `data` attribute can be added to ANY command type to provide supplementary i
 ### BMB (Builder)
 
 ```xml
-<c cmd="*build-agent">Build Agent</c>
-<c cmd="*build-module">Build Module</c>
+<c cmd="*create-agent">Build Agent</c>
+<c cmd="*create-module">Build Module</c>
 <c cmd="*create-workflow">Create Workflow</c>
 <c cmd="*module-brief">Module Brief</c>
 ```
@@ -511,7 +511,7 @@ The `data` attribute can be added to ANY command type to provide supplementary i
 ```
 1. *help - Show numbered cmd list
 2. *create-prd - Create Product Requirements Document
-3. *build-agent - Build new BMAD agent
+3. *create-agent - Build new BMAD agent
 4. *validate - Validate document
 5. *exit - Exit with confirmation
 ```

src/modules/bmb/workflows/create-agent/brainstorm-context.md

@@ -20,28 +20,28 @@ An agent is an AI persona that embodies:
 
 Explore and define:
 
-### 1. Agent Identity & Personality
+### 1. Agent Identity and Personality
 
 - **Who are they?** (name, backstory, motivation)
 - **How do they talk?** (formal, casual, quirky, enthusiastic, wise)
 - **What's their vibe?** (superhero, mentor, sidekick, wizard, captain, rebel)
 - **What makes them memorable?** (catchphrases, quirks, style)
 
-### 2. Expertise & Capabilities
+### 2. Expertise and Capabilities
 
 - **What do they know deeply?** (domain expertise)
 - **What can they do?** (analyze, create, review, research, deploy)
 - **What problems do they solve?** (specific user pain points)
 - **What makes them unique?** (special skills or approaches)
 
-### 3. Commands & Actions
+### 3. Commands and Actions
 
 - **What commands?** (5-10 main actions users invoke)
 - **What workflows do they run?** (document creation, analysis, automation)
 - **What tasks do they perform?** (quick operations without full workflows)
 - **What's their killer command?** (the one thing they're known for)
 
-### 4. Agent Type & Context
+### 4. Agent Type and Context
 
 - **Simple Agent?** Self-contained, no dependencies, quick utility
 - **Expert Agent?** Domain-specific with sidecar data/memory files

src/modules/bmb/workflows/create-agent/communication-styles.md

@@ -6,7 +6,7 @@ Agents with distinct communication styles are more memorable, engaging, and fun
 
 ## Style Categories
 
-### 🎬 Cinema & TV Inspired
+### 🎬 Cinema and TV Inspired
 
 **Film Noir Detective**
 
@@ -32,7 +32,7 @@ Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous er
 Or to take arms against a sea of bugs, and by opposing, end them?
 ```
 
-### 🎮 Gaming & Pop Culture
+### 🎮 Gaming and Pop Culture
 
 **Dungeon Master**
 
@@ -118,7 +118,7 @@ Speaking of cache, let's clear yours and see if that fixes the issue.
 I promise my debugging skills are better than my jokes! ...I hope!
 ```
 
-### 🚀 Sci-Fi & Space
+### 🚀 Sci-Fi and Space
 
 **Star Trek Officer**
 

src/modules/bmb/workflows/create-agent/instructions.md

@@ -1,7 +1,7 @@
 # Build Agent - Interactive Agent Builder Instructions
 
 <critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.md</critical>
-<critical>You MUST have already loaded and processed: {project_root}/bmad/bmb/workflows/build-agent/workflow.yaml</critical>
+<critical>You MUST have already loaded and processed: {project_root}/bmad/bmb/workflows/create-agent/workflow.yaml</critical>
 <critical>Study agent examples in: {project_root}/bmad/bmm/agents/ for patterns</critical>
 
 <workflow>

src/modules/bmb/workflows/create-agent/workflow.yaml

@@ -1,5 +1,5 @@
 # Build Agent Workflow Configuration
-name: build-agent
+name: create-agent
 description: "Interactive workflow to build BMAD Core compliant agents (simple, expert, or module types) with optional brainstorming for agent ideas, proper persona development, activation rules, and command structure"
 author: "BMad"
 
@@ -23,7 +23,7 @@ recommended_inputs:
   - agent_activation_rules: "{project-root}/src/utility/models/agent-activation-ide.xml"
 
 # Module path and component files
-installed_path: "{project-root}/bmad/bmb/workflows/build-agent"
+installed_path: "{project-root}/bmad/bmb/workflows/create-agent"
 template: false # This is an interactive workflow - no template needed
 instructions: "{installed_path}/instructions.md"
 validation: "{installed_path}/checklist.md"
@@ -35,5 +35,14 @@ default_output_file: "{output_folder}/agents/{{agent_filename}}.md"
 src_output_file: "{project-root}/src/modules/{{target_module}}/agents/{{agent_filename}}.md"
 config_output_file: "{project-root}/bmad/_cfg/agents/{{agent_config_name}}.md"
 
-# No special tools required for agent building
-required_tools: []
+web_bundle:
+  name: "create-agent"
+  description: "Interactive workflow to build BMAD Core compliant agents (simple, expert, or module types) with optional brainstorming for agent ideas, proper persona development, activation rules, and command structure"
+  author: "BMad"
+  web_bundle_files:
+    - "bmad/bmb/workflows/create-agent/instructions.md"
+    - "bmad/bmb/workflows/create-agent/checklist.md"
+    - "bmad/bmb/workflows/create-agent/agent-types.md"
+    - "bmad/bmb/workflows/create-agent/agent-architecture.md"
+    - "bmad/bmb/workflows/create-agent/agent-command-patterns.md"
+    - "bmad/bmb/workflows/create-agent/communication-styles.md"

src/modules/bmb/workflows/create-module/README.md

@@ -8,24 +8,24 @@ The Build Module workflow is an interactive scaffolding system that creates comp
 
 - **Interactive Module Planning** - Collaborative session to define module concept, scope, and architecture
 - **Intelligent Scaffolding** - Automatic creation of proper directory structures and configuration files
-- **Component Integration** - Seamless integration with build-agent and build-workflow workflows
+- **Component Integration** - Seamless integration with create-agent and create-workflow workflows
 - **Installation Infrastructure** - Complete installer setup with configuration templates
 - **Module Brief Integration** - Can use existing module briefs as blueprints for accelerated development
-- **Validation & Documentation** - Built-in validation checks and comprehensive README generation
+- **Validation and Documentation** - Built-in validation checks and comprehensive README generation
 
 ## Usage
 
 ### Basic Invocation
 
 ```bash
-workflow build-module
+workflow create-module
 ```
 
 ### With Module Brief Input
 
 ```bash
 # If you have a module brief from the module-brief workflow
-workflow build-module --input module-brief-my-module-2024-09-26.md
+workflow create-module --input module-brief-my-module-2024-09-26.md
 ```
 
 ### Configuration
@@ -41,7 +41,7 @@ The workflow loads critical variables from the BMB configuration:
 ### Files Included
 
 ```
-build-module/
+create-module/
 ├── workflow.yaml           # Configuration and metadata
 ├── instructions.md         # Step-by-step execution guide
 ├── checklist.md           # Validation criteria
@@ -56,7 +56,7 @@ build-module/
 
 ### Phase 1: Concept Definition (Steps 1-2)
 
-**Module Vision & Identity**
+**Module Vision and Identity**
 
 - Define module concept, purpose, and target audience
 - Establish module code (kebab-case) and friendly name
@@ -87,8 +87,8 @@ build-module/
 
 **Interactive Component Building**
 
-- Optional creation of first agent using build-agent workflow
-- Optional creation of first workflow using build-workflow workflow
+- Optional creation of first agent using create-agent workflow
+- Optional creation of first workflow using create-workflow workflow
 - Creates placeholders for components to be built later
 
 **Workflow Integration**
@@ -97,7 +97,7 @@ build-module/
 - Ensures proper file placement and structure
 - Maintains module consistency across components
 
-### Phase 4: Installation & Documentation (Steps 7-9)
+### Phase 4: Installation and Documentation (Steps 7-9)
 
 **Installer Infrastructure**
 
@@ -111,7 +111,7 @@ build-module/
 - Creates development roadmap for remaining components
 - Provides quick commands for continued development
 
-### Phase 5: Validation & Finalization (Step 10)
+### Phase 5: Validation and Finalization (Step 10)
 
 **Quality Assurance**
 
@@ -144,7 +144,7 @@ The workflow creates a complete module ready for development:
 
 - **Module Brief** (optional but recommended) - Use module-brief workflow first for best results
 - **BMAD Core Configuration** - Properly configured BMB config.yaml
-- **Build Tools Access** - build-agent and build-workflow workflows must be available
+- **Build Tools Access** - create-agent and create-workflow workflows must be available
 
 ## Best Practices
 
@@ -158,7 +158,7 @@ The workflow creates a complete module ready for development:
 
 1. **Use Module Briefs** - Load existing briefs when prompted for accelerated development
 2. **Start Simple** - Create one core agent and workflow, then expand iteratively
-3. **Leverage Sub-workflows** - Use build-agent and build-workflow for quality components
+3. **Leverage Sub-workflows** - Use create-agent and create-workflow for quality components
 4. **Validate Early** - Review generated structure before proceeding to next phases
 
 ### After Completion
@@ -179,7 +179,7 @@ The workflow creates a complete module ready for development:
 
 **Issue**: Sub-workflow invocation fails
 
-- **Solution**: Ensure build-agent and build-workflow workflows are available
+- **Solution**: Ensure create-agent and create-workflow workflows are available
 - **Check**: Validate workflow paths in config.yaml
 
 **Issue**: Installation configuration invalid
@@ -200,7 +200,7 @@ To customize this workflow:
 
 - **v1.0.0** - Initial release
   - Interactive module scaffolding
-  - Component integration with build-agent and build-workflow
+  - Component integration with create-agent and create-workflow
   - Complete installation infrastructure
   - Module brief integration support
 
@@ -208,7 +208,7 @@ To customize this workflow:
 
 For issues or questions:
 
-- Review the workflow creation guide at `/bmad/bmb/workflows/build-workflow/workflow-creation-guide.md`
+- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
 - Study module structure patterns at `module-structure.md`
 - Validate output using `checklist.md`
 - Consult existing modules in `/bmad/` for examples

src/modules/bmb/workflows/create-module/brainstorm-context.md

@@ -20,7 +20,7 @@ A module is a cohesive package that provides:
 
 Explore and define:
 
-### 1. Domain & Purpose
+### 1. Domain and Purpose
 
 - **What domain/problem space?** (e.g., game development, marketing, personal productivity)
 - **Who is the target user?** (developers, writers, managers, hobbyists)

src/modules/bmb/workflows/create-module/checklist.md

@@ -1,6 +1,6 @@
 # Build Module Validation Checklist
 
-## Module Identity & Metadata
+## Module Identity and Metadata
 
 ### Basic Information
 
@@ -165,7 +165,7 @@
 - [ ] Component organization is logical
 - [ ] No hard-coded limits
 
-## Testing & Validation
+## Testing and Validation
 
 ### Structural Validation
 

src/modules/bmb/workflows/create-module/instructions.md

@@ -1,7 +1,7 @@
 # Build Module - Interactive Module Builder Instructions
 
 <critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.md</critical>
-<critical>You MUST have already loaded and processed: {project_root}/bmad/bmb/workflows/build-module/workflow.yaml</critical>
+<critical>You MUST have already loaded and processed: {project_root}/bmad/bmb/workflows/create-module/workflow.yaml</critical>
 <critical>Study existing modules in: {project_root}/bmad/ for patterns</critical>
 
 <workflow>
@@ -10,8 +10,8 @@
 <ask>Do you want to brainstorm module ideas first? [y/n]</ask>
 
 If yes:
-<action>Invoke brainstorming workflow: {project-root}/bmad/cis/workflows/brainstorming/workflow.yaml</action>
-<action>Pass context data: {installed_path}/brainstorm-context.md</action>
+<action>Invoke brainstorming workflow: {brainstorming-workflow}</action>
+<action>Pass context data: {brainstorming_context}</action>
 <action>Wait for brainstorming session completion</action>
 <action>Use brainstorming output to inform module concept, agent lineup, and workflow portfolio</action>
 
@@ -215,7 +215,7 @@ If no, create placeholder:
 ```md
 # {{primary_agent_name}} Agent
 
-<!-- TODO: Create using build-agent workflow -->
+<!-- TODO: Create using create-agent workflow -->
 <!-- Purpose: {{agent_purpose}} -->
 <!-- Type: {{agent_type}} -->
 ```
@@ -402,8 +402,8 @@ Key settings:
 
 To extend this module:
 
-1. Add new agents using `build-agent` workflow
-2. Add new workflows using `build-workflow` workflow
+1. Add new agents using `create-agent` workflow
+2. Add new workflows using `create-workflow` workflow
 3. Submit improvements via pull request
 
 ## Author
@@ -428,7 +428,7 @@ Create a development roadmap for remaining components:
 ## Phase 2: Enhanced Features
 {{phase2_tasks}}
 
-## Phase 3: Polish & Integration
+## Phase 3: Polish and Integration
 {{phase3_tasks}}
 
 ## Quick Commands
@@ -436,14 +436,14 @@ Create a development roadmap for remaining components:
 Create new agent:
 ````
 
-workflow build-agent
+workflow create-agent
 
 ```
 
 Create new workflow:
 ```
 
-workflow build-workflow
+workflow create-workflow
 
 ```
 

src/modules/bmb/workflows/create-module/workflow.yaml

@@ -1,5 +1,5 @@
 # Build Module Workflow Configuration
-name: build-module
+name: create-module
 description: "Interactive workflow to build complete BMAD modules with agents, workflows, tasks, and installation infrastructure"
 author: "BMad"
 
@@ -14,11 +14,12 @@ date: system-generated
 # Reference guides for module building
 module_structure_guide: "{installed_path}/module-structure.md"
 installer_templates: "{installed_path}/installer-templates/"
-example_modules: "{installed_path}/example-modules.md"
 
 # Use existing build workflows
-agent_builder: "{project-root}/bmad/bmb/workflows/build-agent/workflow.yaml"
-workflow_builder: "{project-root}/bmad/bmb/workflows/build-workflow/workflow.yaml"
+agent_builder: "{project-root}/bmad/bmb/workflows/create-agent/workflow.yaml"
+workflow_builder: "{project-root}/bmad/bmb/workflows/create-workflow/workflow.yaml"
+brainstorming_workflow: "{project-root}/bmad/cis/workflows/brainstorming/workflow.yaml"
+brainstorming_context: "{installed_path}/brainstorm-context.md"
 
 # Optional docs that help understand module patterns
 recommended_inputs:
@@ -30,7 +31,7 @@ recommended_inputs:
   - existing_workflows: "{project-root}/bmad/*/workflows/"
 
 # Module path and component files
-installed_path: "{project-root}/bmad/bmb/workflows/build-module"
+installed_path: "{project-root}/bmad/bmb/workflows/create-module"
 template: false # This is an interactive scaffolding workflow
 instructions: "{installed_path}/instructions.md"
 validation: "{installed_path}/checklist.md"
@@ -43,5 +44,16 @@ src_output_folder: "{project-root}/src/modules/{{module_code}}"
 installer_output_folder: "{output_folder}/{{module_code}}"
 src_installer_output_folder: "{project-root}/src/modules/{{module_code}}"
 
-# No special tools required for module building
-required_tools: []
+web_bundle:
+  name: "create-module"
+  description: "Interactive workflow to build complete BMAD modules with agents, workflows, tasks, and installation infrastructure"
+  author: "BMad"
+  web_bundle_files:
+    - "bmad/bmb/workflows/create-module/instructions.md"
+    - "bmad/bmb/workflows/create-module/checklist.md"
+    - "bmad/bmb/workflows/create-module/module-structure.md"
+    - "bmad/bmb/workflows/create-module/brainstorm-context.md"
+  existing_workflows:
+    - agent_builder: "bmad/bmb/workflows/create-agent/workflow.yaml"
+    - workflow_builder: "bmad/bmb/workflows/create-workflow/workflow.yaml"
+    - brainstorming_workflow: "bmad/cis/workflows/brainstorming/workflow.yaml"

src/modules/bmb/workflows/create-workflow/README.md

@@ -19,7 +19,7 @@ The Build Workflow is an interactive workflow builder that guides you through cr
 ### Basic Invocation
 
 ```bash
-workflow build-workflow
+workflow create-workflow
 ```
 
 ### Through BMad Builder Agent
@@ -42,7 +42,7 @@ workflow build-workflow
 ### Files Included
 
 ```
-build-workflow/
+create-workflow/
 ├── workflow.yaml                  # Configuration and metadata
 ├── instructions.md                # Step-by-step execution guide
 ├── checklist.md                   # Validation criteria
@@ -87,7 +87,7 @@ The brainstorming phase invokes the CIS brainstorming workflow to:
 - Generate validation checklist
 - Create supporting data files (optional)
 
-### Phase 3: Documentation & Validation (Steps 9-11)
+### Phase 3: Documentation and Validation (Steps 9-11)
 
 - Create comprehensive README.md (MANDATORY)
 - Test and validate workflow structure
@@ -142,7 +142,7 @@ For document workflows, the README documents:
 
 ### Creative Workflow Design
 
-The build-workflow now supports a **seamless transition from creative ideation to structured implementation**:
+The create-workflow now supports a **seamless transition from creative ideation to structured implementation**:
 
 - **"I need a workflow for something..."** → Start with brainstorming to explore possibilities
 - **Brainstorm** → Generate multiple approaches and clarify requirements
@@ -206,9 +206,9 @@ To modify this workflow:
 
 For issues or questions:
 
-- Review `/bmad/bmb/workflows/build-workflow/workflow-creation-guide.md`
+- Review `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
 - Check existing workflows in `/bmad/bmm/workflows/` for examples
-- Validate against `/bmad/bmb/workflows/build-workflow/checklist.md`
+- Validate against `/bmad/bmb/workflows/create-workflow/checklist.md`
 - Consult BMAD Method v6 documentation
 
 ---

src/modules/bmb/workflows/create-workflow/brainstorm-context.md

@@ -20,7 +20,7 @@ A workflow is a structured process that provides:
 
 Explore and define:
 
-### 1. Problem & Purpose
+### 1. Problem and Purpose
 
 - **What task needs structure?** (specific process users struggle with)
 - **Why is this hard manually?** (complexity, inconsistency, missing steps)
@@ -35,14 +35,14 @@ Explore and define:
 - **What's optional vs required?** (flexibility points)
 - **What checkpoints matter?** (validation, review, approval points)
 
-### 3. Inputs & Outputs
+### 3. Inputs and Outputs
 
 - **What inputs are needed?** (documents, data, user answers)
 - **What outputs are generated?** (documents, code, configurations)
 - **What format?** (markdown, XML, YAML, actions)
 - **What quality criteria?** (how to validate success)
 
-### 4. Workflow Type & Style
+### 4. Workflow Type and Style
 
 - **Document Workflow?** Creates structured documents (PRDs, specs, reports)
 - **Action Workflow?** Performs operations (refactoring, deployment, analysis)
@@ -78,7 +78,7 @@ A great BMAD workflow should be:
 4. **Checkpoints** (where to pause for approval)
 5. **Variables** (data passed between steps)
 
-### Quality & Validation
+### Quality and Validation
 
 1. **Success criteria** (what defines "done")
 2. **Validation checklist** (measurable quality checks)

src/modules/bmb/workflows/create-workflow/instructions.md

@@ -3,7 +3,7 @@
 <workflow>
 
 <critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.md</critical>
-<critical>You MUST have already loaded and processed: {project_root}/bmad/bmb/workflows/build-workflow/workflow.yaml</critical>
+<critical>You MUST have already loaded and processed: {project_root}/bmad/bmb/workflows/create-workflow/workflow.yaml</critical>
 <critical>You MUST fully understand the workflow creation guide at: {workflow_creation_guide}</critical>
 <critical>Study the guide thoroughly to follow ALL conventions for optimal human-AI collaboration</critical>
 

src/modules/bmb/workflows/create-workflow/workflow-creation-guide.md

@@ -8,7 +8,7 @@ Create structured, repeatable workflows for human-AI collaboration in BMAD v6.
 2. [Core Concepts](#core-concepts)
 3. [Workflow Structure](#workflow-structure)
 4. [Writing Instructions](#writing-instructions)
-5. [Templates & Variables](#templates--variables)
+5. [Templates and Variables](#templates--variables)
 6. [Flow Control](#flow-control)
 7. [Validation](#validation)
 8. [Examples](#examples)
@@ -192,7 +192,7 @@ Write 1-3 bullet points about project success:
 </step>
 ```
 
-## Templates & Variables
+## Templates and Variables
 
 ### Variable Syntax
 
@@ -257,7 +257,7 @@ _Generated on {{date}}_
 </step>
 ```
 
-### Branching & Goto
+### Branching and Goto
 
 ```xml
 <step n="7" goal="Validate">

src/modules/bmb/workflows/create-workflow/workflow.yaml

@@ -1,5 +1,5 @@
 # Build Workflow - Workflow Builder Configuration
-name: build-workflow
+name: create-workflow
 description: "Interactive workflow builder that guides creation of new BMAD workflows with proper structure and validation for optimal human-AI collaboration. Includes optional brainstorming phase for workflow ideas and design."
 author: "BMad Builder"
 
@@ -23,7 +23,7 @@ recommended_inputs:
   - bmm_workflows: "{project-root}/bmad/bmm/workflows/"
 
 # Module path and component files
-installed_path: "{project-root}/bmad/bmb/workflows/build-workflow"
+installed_path: "{project-root}/bmad/bmb/workflows/create-workflow"
 template: false # This is an action workflow - no template needed
 instructions: "{installed_path}/instructions.md"
 validation: "{installed_path}/checklist.md"
@@ -38,5 +38,15 @@ workflow_template_path: "{installed_path}/workflow-template"
 default_output_folder: "{output_folder}/workflows/{{workflow_name}}"
 src_output_folder: "{project-root}/src/modules/{{target_module}}/workflows/{{workflow_name}}"
 
-# No special tools required
-required_tools: []
+web_bundle:
+  name: "create-workflow"
+  description: "Interactive workflow builder that guides creation of new BMAD workflows with proper structure and validation for optimal human-AI collaboration. Includes optional brainstorming phase for workflow ideas and design."
+  author: "BMad Builder"
+  web_bundle_files:
+    - "bmad/bmb/workflows/create-workflow/instructions.md"
+    - "bmad/bmb/workflows/create-workflow/checklist.md"
+    - "bmad/bmb/workflows/create-workflow/workflow-creation-guide.md"
+    - "bmad/bmb/workflows/create-workflow/workflow-template/workflow.yaml"
+    - "bmad/bmb/workflows/create-workflow/workflow-template/instructions.md"
+    - "bmad/bmb/workflows/create-workflow/workflow-template/template.md"
+    - "bmad/bmb/workflows/create-workflow/workflow-template/checklist.md"

src/modules/bmb/workflows/edit-workflow/instructions.md

@@ -66,7 +66,7 @@ Based on the selected edit type, load appropriate reference materials:
 <action>Load example workflows from {project-root}/bmad/bmm/workflows/ for patterns</action>
 
 <check>If editing templates:</check>
-<action>Review the "Templates & Variables" section of the creation guide</action>
+<action>Review the "Templates and Variables" section of the creation guide</action>
 <action>Ensure variable naming conventions are followed</action>
 
 <check>If editing validation:</check>

src/modules/bmb/workflows/edit-workflow/workflow.yaml

@@ -12,7 +12,7 @@ user_name: "{config_source}:user_name"
 date: system-generated
 
 # Required Data Files - Critical for understanding workflow conventions
-workflow_creation_guide: "{project-root}/bmad/bmb/workflows/build-workflow/workflow-creation-guide.md"
+workflow_creation_guide: "{project-root}/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md"
 workflow_execution_engine: "{project-root}/bmad/core/tasks/workflow.md"
 
 # Optional docs that can be used to understand the target workflow
@@ -30,5 +30,10 @@ validation: "{installed_path}/checklist.md"
 # But we may generate a change log
 change_log_output: "{output_folder}/workflow-edit-log-{{date}}.md"
 
-# No special tools required for editing workflows
-required_tools: []
+web_bundle:
+  name: "edit-workflow"
+  description: "Edit existing BMAD workflows while following all best practices and conventions"
+  author: "BMad"
+  web_bundle_files:
+    - "bmad/bmb/workflows/edit-workflow/instructions.md"
+    - "bmad/bmb/workflows/edit-workflow/checklist.md"

src/modules/bmb/workflows/module-brief/README.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-The Module Brief workflow creates comprehensive blueprints for building new BMAD modules using strategic analysis and creative vision. It serves as the essential planning phase that transforms initial ideas into detailed, actionable specifications ready for implementation with the build-module workflow.
+The Module Brief workflow creates comprehensive blueprints for building new BMAD modules using strategic analysis and creative vision. It serves as the essential planning phase that transforms initial ideas into detailed, actionable specifications ready for implementation with the create-module workflow.
 
 ## Key Features
 
@@ -61,9 +61,9 @@ module-brief/
 
 ## Workflow Process
 
-### Phase 1: Foundation & Context (Steps 1-3)
+### Phase 1: Foundation and Context (Steps 1-3)
 
-**Mode Selection & Input Gathering**
+**Mode Selection and Input Gathering**
 
 - Choose operational mode (Interactive, Express, YOLO)
 - Check for and optionally load existing brainstorming results
@@ -101,7 +101,7 @@ module-brief/
 - Define input-process-output flows for each workflow
 - Assess complexity levels and implementation priorities
 
-### Phase 3: Validation & User Experience (Steps 6-7)
+### Phase 3: Validation and User Experience (Steps 6-7)
 
 **User Journey Mapping**
 
@@ -110,7 +110,7 @@ module-brief/
 - Validate end-to-end functionality and value delivery
 - Identify potential friction points and optimization opportunities
 
-**Technical Planning & Requirements**
+**Technical Planning and Requirements**
 
 - Assess data requirements and storage needs
 - Map integration points with other modules and external systems
@@ -133,27 +133,27 @@ module-brief/
 - Prioritize features and capabilities by value and complexity
 - Create clear milestones and success checkpoints
 
-### Phase 5: Enhancement & Risk Management (Steps 10-12)
+### Phase 5: Enhancement and Risk Management (Steps 10-12)
 
-**Creative Features & Special Touches** (Optional)
+**Creative Features and Special Touches** (Optional)
 
 - Design easter eggs and delightful user interactions
 - Plan module lore and thematic consistency
 - Add personality quirks and creative responses
 - Develop backstories and universe building
 
-**Risk Assessment & Mitigation**
+**Risk Assessment and Mitigation**
 
 - Identify technical, usability, and scope risks
 - Develop mitigation strategies for each risk category
 - Plan contingency approaches for potential challenges
 - Document decision points and alternative paths
 
-**Final Review & Export Preparation**
+**Final Review and Export Preparation**
 
 - Comprehensive review of all brief sections
 - Validation against quality and completeness criteria
-- Preparation for seamless handoff to build-module workflow
+- Preparation for seamless handoff to create-module workflow
 - Export readiness confirmation with actionable specifications
 
 ## Output
@@ -161,7 +161,7 @@ module-brief/
 ### Generated Files
 
 - **Module Brief Document**: Comprehensive planning document at `{output_folder}/module-brief-{module_code}-{date}.md`
-- **Strategic Specifications**: Ready-to-implement blueprint for build-module workflow
+- **Strategic Specifications**: Ready-to-implement blueprint for create-module workflow
 
 ### Output Structure
 
@@ -178,7 +178,7 @@ The module brief contains detailed specifications across multiple sections:
 9. **Creative Features** - Special touches, easter eggs, module lore
 10. **Risk Assessment** - Technical, usability, scope risks with mitigation
 11. **Implementation Notes** - Priority order, design decisions, open questions
-12. **Resources & References** - Inspiration sources, similar modules, technical references
+12. **Resources and References** - Inspiration sources, similar modules, technical references
 
 ## Requirements
 
@@ -203,7 +203,7 @@ The module brief contains detailed specifications across multiple sections:
 
 ### After Completion
 
-1. **Use as Blueprint** - Feed the brief directly into build-module workflow for implementation
+1. **Use as Blueprint** - Feed the brief directly into create-module workflow for implementation
 2. **Review with Stakeholders** - Validate assumptions and gather feedback before building
 3. **Update as Needed** - Treat as living document that evolves with implementation learnings
 4. **Reference During Development** - Use as north star for design decisions and scope management
@@ -254,10 +254,10 @@ To customize this workflow:
 
 For issues or questions:
 
-- Review the workflow creation guide at `/bmad/bmb/workflows/build-workflow/workflow-creation-guide.md`
+- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
 - Study existing module examples in `/bmad/` for patterns and inspiration
 - Validate output using `checklist.md`
-- Consult module structure guide at `build-module/module-structure.md`
+- Consult module structure guide at `create-module/module-structure.md`
 
 ---
 

src/modules/bmb/workflows/module-brief/checklist.md

@@ -8,7 +8,7 @@
 - [ ] Target users are clearly defined
 - [ ] Unique value proposition is articulated
 
-## Vision & Concept
+## Vision and Concept
 
 - [ ] Problem being solved is clearly stated
 - [ ] Solution approach is explained
@@ -80,9 +80,9 @@
 
 ## Implementation Readiness
 
-- [ ] Brief provides enough detail for build-module workflow
-- [ ] Agent specifications sufficient for build-agent workflow
-- [ ] Workflow descriptions ready for build-workflow
+- [ ] Brief provides enough detail for create-module workflow
+- [ ] Agent specifications sufficient for create-agent workflow
+- [ ] Workflow descriptions ready for create-workflow
 - [ ] Resource requirements are clear
 - [ ] Success metrics are measurable
 

src/modules/bmb/workflows/module-brief/instructions.md

@@ -249,15 +249,15 @@ For each risk, note mitigation strategy.
 
 <step n="12" goal="Final review and export readiness">
 <action>Review all sections with user</action>
-<action>Ensure module brief is ready for build-module workflow</action>
+<action>Ensure module brief is ready for create-module workflow</action>
 
 Ask if they want to:
 
-1. Proceed directly to build-module workflow
+1. Proceed directly to create-module workflow
 2. Save and refine later
 3. Generate additional planning documents
 
-<action>Highlight that this brief can be fed directly into build-module workflow!</action>
+<action>Highlight that this brief can be fed directly into create-module workflow!</action>
 
 <template-output>final_brief</template-output>
 </step>

src/modules/bmb/workflows/module-brief/template.md

@@ -144,7 +144,7 @@ How we'll know the module is successful:
 **Deliverables:**
 {{phase2_deliverables}}
 
-### Phase 3: Polish & Optimization
+### Phase 3: Polish and Optimization
 
 **Timeline:** {{phase3_timeline}}
 
@@ -161,11 +161,11 @@ How we'll know the module is successful:
 
 {{creative_features}}
 
-### Easter Eggs & Delighters
+### Easter Eggs and Delighters
 
 {{easter_eggs}}
 
-### Module Lore & Theming
+### Module Lore and Theming
 
 {{module_lore}}
 
@@ -209,7 +209,7 @@ How we'll know the module is successful:
 
 ---
 
-## Resources & References
+## Resources and References
 
 ### Inspiration Sources
 
@@ -235,7 +235,7 @@ How we'll know the module is successful:
 
 {{detailed_workflow_specs}}
 
-### C. Data Structures & Schemas
+### C. Data Structures and Schemas
 
 {{data_schemas}}
 
@@ -248,14 +248,14 @@ How we'll know the module is successful:
 ## Next Steps
 
 1. **Review this brief** with stakeholders
-2. **Run build-module workflow** using this brief as input
-3. **Create first agent** using build-agent workflow
-4. **Develop initial workflows** using build-workflow
+2. **Run create-module workflow** using this brief as input
+3. **Create first agent** using create-agent workflow
+4. **Develop initial workflows** using create-workflow
 5. **Test MVP** with target users
 
 ---
 
-_This Module Brief is ready to be fed directly into the build-module workflow for scaffolding and implementation._
+_This Module Brief is ready to be fed directly into the create-module workflow for scaffolding and implementation._
 
 **Module Viability Score:** {{viability_score}}/10
 **Estimated Development Effort:** {{effort_estimate}}

src/modules/bmb/workflows/module-brief/workflow.yaml

@@ -15,7 +15,7 @@ date: system-generated
 recommended_inputs:
   - brainstorming_results: "{output_folder}/brainstorming-*.md"
   - existing_modules: "{project-root}/bmad/"
-  - module_examples: "{project-root}/bmad/bmb/workflows/build-module/module-structure.md"
+  - module_examples: "{project-root}/bmad/bmb/workflows/create-module/module-structure.md"
 
 # Module path and component files
 installed_path: "{project-root}/bmad/bmb/workflows/module-brief"
@@ -26,5 +26,11 @@ validation: "{installed_path}/checklist.md"
 # Output configuration
 default_output_file: "{output_folder}/module-brief-{{module_code}}-{{date}}.md"
 
-# No special tools required
-required_tools: []
+web_bundle:
+  name: "module-brief"
+  description: "Create a comprehensive Module Brief that serves as the blueprint for building new BMAD modules using strategic analysis and creative vision"
+  author: "BMad Builder"
+  web_bundle_files:
+    - "bmad/bmb/workflows/module-brief/instructions.md"
+    - "bmad/bmb/workflows/module-brief/template.md"
+    - "bmad/bmb/workflows/module-brief/checklist.md"

src/modules/bmb/workflows/redoc/checklist.md

@@ -1,6 +1,6 @@
 # ReDoc Workflow Validation Checklist
 
-## Initialization & Setup
+## Initialization and Setup
 
 - [ ] All BMAD convention documents loaded and understood
 - [ ] Target path validated and exists
@@ -66,7 +66,7 @@
 - [ ] Frontmatter syntax is correct and dates are current
 - [ ] No redundant explanation of standard BMAD patterns
 
-## Validation & Reporting
+## Validation and Reporting
 
 - [ ] All planned documentation items created/updated
 - [ ] Frontmatter dates verified as current across all files

src/modules/bmb/workflows/redoc/workflow.yaml

@@ -29,5 +29,10 @@ validation: "{installed_path}/checklist.md"
 # Configuration
 autonomous: true # Runs without user checkpoints unless clarification needed
 
-# Tool Requirements - Using built-in file system tools
-required_tools: []
+web_bundle:
+  name: "redoc"
+  description: "Autonomous documentation system that maintains module, workflow, and agent documentation using a reverse-tree approach (leaf folders first, then parents). Understands BMAD conventions and produces technical writer quality output."
+  author: "BMad"
+  web_bundle_files:
+    - "bmad/bmb/workflows/redoc/instructions.md"
+    - "bmad/bmb/workflows/redoc/checklist.md"

src/modules/bmm/agents/analyst.md

@@ -19,7 +19,7 @@
     <c cmd="*help">Show numbered cmd list</c>
     <c cmd="*brainstorm-project" run-workflow="{project-root}/bmad/bmm/workflows/1-analysis/brainstorm-project/workflow.yaml">Guide me through Brainstorming</c>
     <c cmd="*product-brief" run-workflow="{project-root}/bmad/bmm/workflows/1-analysis/product-brief/workflow.yaml">Produce Project Brief</c>
-    <c cmd="*research" run-workflow="{project-root}/bmad/cis/workflows/research/workflow.yaml">Guide me through Brainstorming</c>
+    <c cmd="*research" run-workflow="{project-root}/bmad/bmm/workflows/1-analysis/research/workflow.yaml">Guide me through Research</c>
     <c cmd="*exit">Goodbye+exit persona</c>
   </cmds>
 </agent>

src/modules/bmm/agents/game-designer.md

@@ -20,7 +20,7 @@
     <c cmd="*brainstorm-game" run-workflow="{project-root}/bmad/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml">Guide me through Game Brainstorming</c>
     <c cmd="*game-brief" run-workflow="{project-root}/bmad/bmm/workflows/1-analysis/game-brief/workflow.yaml">Create Game Brief</c>
     <c cmd="*plan-game" run-workflow="{project-root}/bmad/bmm/workflows/2-plan/workflow.yaml">Create Game Design Document (GDD)</c>
-    <c cmd="*research" run-workflow="{project-root}/bmad/cis/workflows/research/workflow.yaml">Conduct Game Market Research</c>
+    <c cmd="*research" run-workflow="{project-root}/bmad/bmm/workflows/1-analysis/research/workflow.yaml">Conduct Game Market Research</c>
     <c cmd="*exit">Goodbye+exit persona</c>
   </cmds>
 </agent>

src/modules/bmm/agents/game-dev.md

@@ -20,7 +20,6 @@
     <c cmd="*create-story" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/create-story/workflow.yaml">Create Development Story</c>
     <c cmd="*dev-story" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/dev-story/workflow.yaml">Implement Story with Context</c>
     <c cmd="*review-story" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/review-story/workflow.yaml">Review Story Implementation</c>
-    <c cmd="*standup" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/daily-standup/workflow.yaml">Daily Standup</c>
     <c cmd="*retro" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml">Sprint Retrospective</c>
     <c cmd="*exit">Goodbye+exit persona</c>
   </cmds>

src/modules/bmm/agents/sm.md

@@ -18,11 +18,11 @@
   </critical-actions>
   <cmds>
     <c cmd="*help">Show numbered cmd list</c>
-    <c cmd="*correct-course" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/correct-course.md">Execute correct-course task</c>
+    <c cmd="*correct-course" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml">Execute correct-course task</c>
     <c cmd="*create-story" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/create-story/workflow.yaml">Create a Draft Story with Context</c>
     <c cmd="*story-context"  run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/story-context/workflow.yaml">Assemble dynamic Story Context (XML) from latest docs and code</c>
     <c cmd="*validate-story-context"  validate-workflow="{project-root}/bmad/bmm/workflows/4-implementation/story-context/workflow.yaml">Validate latest Story Context XML against checklist</c>
-    <c cmd="*retrospective" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/retrospective.md" data="{project-root}/bmad/_cfg/agent-party.xml">Facilitate team retrospective after epic/sprint</c>
+    <c cmd="*retrospective" run-workflow="{project-root}/bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml" data="{project-root}/bmad/_cfg/agent-party.xml">Facilitate team retrospective after epic/sprint</c>
     <c cmd="*exit">Goodbye+exit persona</c>
   </cmds>
   </agent>

src/modules/bmm/agents/tea.md

@@ -8,23 +8,26 @@
     <role>Master Test Architect</role>
     <identity>Expert test architect and CI specialist with comprehensive expertise across all software engineering disciplines, with primary focus on test discipline. Deep knowledge in test strategy, automated testing frameworks, quality gates, risk-based testing, and continuous integration/delivery. Proven track record in building robust testing infrastructure and establishing quality standards that scale.</identity>
     <communication_style>Educational and advisory approach. Strong opinions, weakly held. Explains quality concerns with clear rationale. Balances thoroughness with pragmatism. Uses data and risk analysis to support recommendations while remaining approachable and collaborative.</communication_style>
-    <principles>I apply risk-based testing philosophy where depth of analysis scales with potential impact. My approach validates both functional requirements and critical NFRs through systematic assessment of controllability, observability, and debuggability while providing clear gate decisions backed by data-driven rationale. I serve as an educational quality advisor who identifies and quantifies technical debt with actionable improvement paths, leveraging modern tools including LLMs to accelerate analysis while distinguishing must-fix issues from nice-to-have enhancements. Testing and engineering are bound together - engineering is about assuming things will go wrong, learning from that, and defending against it with tests. One failing test proves software isn't good enough. The more tests resemble actual usage, the more confidence they give. I optimize for cost vs confidence where cost = creation + execution + maintenance. What you can avoid testing is more important than what you test. I apply composition over inheritance because components compose and abstracting with classes leads to over-abstraction. Quality is a whole team responsibility that we cannot abdicate. Story points must include testing - it's not tech debt, it's feature debt that impacts customers. In the AI era, E2E tests reign supreme as the ultimate acceptance criteria. I follow ATDD: write acceptance criteria as tests first, let AI propose implementation, validate with E2E suite. Simplicity is the ultimate sophistication.</principles>
+    <principles>I apply risk-based testing philosophy where depth of analysis scales with potential impact. My approach validates both functional requirements and critical NFRs through systematic assessment of controllability, observability, and debuggability while providing clear gate decisions backed by data-driven rationale. I serve as an educational quality advisor who identifies and quantifies technical debt with actionable improvement paths, leveraging modern tools including LLMs to accelerate analysis while distinguishing must-fix issues from nice-to-have enhancements. Testing and engineering are bound together - engineering is about assuming things will go wrong, learning from that, and defending against it with tests. One failing test proves software isn't good enough. The more tests resemble actual usage, the more confidence they give. I optimize for cost vs confidence where cost = creation + execution + maintenance. What you can avoid testing is more important than what you test. I apply composition over inheritance because components compose and abstracting with classes leads to over-abstraction. Quality is a whole team responsibility that we cannot abdicate. Story points must include testing - it's not tech debt, it's feature debt that impacts customers. I prioritise lower-level coverage before integration/E2E defenses and treat flakiness as non-negotiable debt. In the AI era, E2E tests serve as the living acceptance criteria. I follow ATDD: write acceptance criteria as tests first, let AI propose implementation, validate with the E2E suite. Simplicity is the ultimate sophistication.</principles>
   </persona>
   <critical-actions>
     <i>Load into memory {project-root}/bmad/bmm/config.yaml and set variable project_name, output_folder, user_name, communication_language</i>
+    <i>Consult {project-root}/bmad/bmm/testarch/tea-index.csv to select knowledge fragments under `knowledge/` and load only the files needed for the current task</i>
+    <i>Load the referenced fragment(s) from `{project-root}/bmad/bmm/testarch/knowledge/` before giving recommendations</i>
+    <i>Cross-check recommendations with the current official Playwright, Cypress, Pact, and CI platform documentation; fall back to {project-root}/bmad/bmm/testarch/test-resources-for-ai-flat.txt only when deeper sourcing is required</i>
     <i>Remember the users name is {user_name}</i>
     <i>ALWAYS communicate in {communication_language}</i>
   </critical-actions>
   <cmds>
     <c cmd="*help">Show numbered cmd list</c>
-    <c cmd="*framework" exec="{project-root}/bmad/bmm/testarch/framework.md">Initialize production-ready test framework architecture</c>
-    <c cmd="*atdd" exec="{project-root}/bmad/bmm/testarch/atdd.md">Generate E2E tests first, before starting implementation</c>
-    <c cmd="*automate" exec="{project-root}/bmad/bmm/testarch/automate.md">Generate comprehensive test automation</c>
-    <c cmd="*test-design" exec="{project-root}/bmad/bmm/testarch/test-design.md">Create comprehensive test scenarios</c>
-    <c cmd="*trace" exec="{project-root}/bmad/bmm/testarch/trace-requirements.md">Map requirements to tests Given-When-Then BDD format</c>
-    <c cmd="*nfr-assess" exec="{project-root}/bmad/bmm/testarch/nfr-assess.md">Validate non-functional requirements</c>
-    <c cmd="*ci" exec="{project-root}/bmad/bmm/testarch/ci.md">Scaffold CI/CD quality pipeline</c>
-    <c cmd="*gate" exec="{project-root}/bmad/bmm/testarch/gate.md">Write/update quality gate decision assessment</c>
+    <c cmd="*framework" run-workflow="{project-root}/bmad/bmm/workflows/testarch/framework/workflow.yaml">Initialize production-ready test framework architecture</c>
+    <c cmd="*atdd" run-workflow="{project-root}/bmad/bmm/workflows/testarch/atdd/workflow.yaml">Generate E2E tests first, before starting implementation</c>
+    <c cmd="*automate" run-workflow="{project-root}/bmad/bmm/workflows/testarch/automate/workflow.yaml">Generate comprehensive test automation</c>
+    <c cmd="*test-design" run-workflow="{project-root}/bmad/bmm/workflows/testarch/test-design/workflow.yaml">Create comprehensive test scenarios</c>
+    <c cmd="*trace" run-workflow="{project-root}/bmad/bmm/workflows/testarch/trace/workflow.yaml">Map requirements to tests Given-When-Then BDD format</c>
+    <c cmd="*nfr-assess" run-workflow="{project-root}/bmad/bmm/workflows/testarch/nfr-assess/workflow.yaml">Validate non-functional requirements</c>
+    <c cmd="*ci" run-workflow="{project-root}/bmad/bmm/workflows/testarch/ci/workflow.yaml">Scaffold CI/CD quality pipeline</c>
+    <c cmd="*gate" run-workflow="{project-root}/bmad/bmm/workflows/testarch/gate/workflow.yaml">Write/update quality gate decision assessment</c>
     <c cmd="*exit">Goodbye+exit persona</c>
   </cmds>
 </agent>

src/modules/bmm/sub-modules/claude-code/readme.md

@@ -30,7 +30,7 @@ When Claude Code is selected during BMAD installation:
 | **epic-optimizer**       | Story breakdown and sizing               | PM Agent   | Epic details, story sequencing                |
 | **document-reviewer**    | Quality checks and validation            | PM/Analyst | Final document review before delivery         |
 
-### Architecture & Documentation Subagents
+### Architecture and Documentation Subagents
 
 | Subagent                   | Purpose                                   | Used By   | Recommended For                                |
 | -------------------------- | ----------------------------------------- | --------- | ---------------------------------------------- |

src/modules/bmm/sub-modules/claude-code/sub-agents/codebase-analyzer.md

@@ -48,7 +48,7 @@ Provide structured analysis with:
 - **Key Components**: Entry points, core modules, critical services
 - **Dependencies**: External libraries, internal module relationships
 - **Configuration**: Environment setup, deployment configurations
-- **Build & Deploy**: Build process, test execution, deployment pipeline
+- **Build and Deploy**: Build process, test execution, deployment pipeline
 
 ## Critical Behaviors
 

src/modules/bmm/sub-modules/claude-code/sub-agents/technical-decisions-curator.md

@@ -8,8 +8,8 @@ Specialized sub-agent for maintaining and organizing the technical-decisions.md
 
 ### Primary Functions
 
-1. **Capture & Append**: Add new technical decisions with proper context
-2. **Organize & Categorize**: Structure decisions into logical sections
+1. **Capture and Append**: Add new technical decisions with proper context
+2. **Organize and Categorize**: Structure decisions into logical sections
 3. **Deduplicate**: Identify and merge duplicate or conflicting entries
 4. **Validate**: Ensure decisions align and don't contradict
 5. **Prioritize**: Mark decisions as confirmed vs. preferences vs. constraints

src/modules/bmm/tasks/daily-standup.md

@@ -8,7 +8,7 @@
     <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 &lt;action&gt; within &lt;step&gt; is a REQUIRED action to complete that step</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>

src/modules/bmm/tasks/retrospective.md

@@ -8,7 +8,7 @@
     <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 &lt;action&gt; within &lt;step&gt; is a REQUIRED action to complete that step</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>

src/modules/bmm/testarch/README.md

@@ -6,22 +6,20 @@ last-redoc-date: 2025-09-30
 
 ## Overview
 
-- **Persona:** Murat, Master Test Architect & Quality Advisor focused on risk-based testing, fixture architecture, ATDD, and CI/CD governance.
+- **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.
 
-## Prerequisites & Setup
+## Prerequisites and Setup
 
 1. Run the core planning workflows first:
    - Analyst `*product-brief`
    - Product Manager `*plan-project`
    - Architect `*solution-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, schedule `*framework` before development.
-4. Skim supporting references under `./testarch/`:
-   - `tea-knowledge.md`
-   - `test-levels-framework.md`
-   - `test-priorities-matrix.md`
+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
 
@@ -30,7 +28,7 @@ last-redoc-date: 2025-09-30
 | Phase              | Test Architect                                                            | Dev / Team                                                                       | Outputs                                                                               |
 | ------------------ | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
 | Setup              | -                                                                         | Analyst `*product-brief`, PM `*plan-project`, Architect `*solution-architecture` | `{output_folder}/product-brief*.md`, `PRD.md`, `epics.md`, `solution-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 & coverage strategy                                  |
+| 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`, re-run `*trace`                                      | Address recommendations, update code/tests                                       | Regression specs, refreshed coverage matrix                                           |
@@ -53,7 +51,7 @@ last-redoc-date: 2025-09-30
 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 `*assess-project-ready`.
 4. **Implementation:** TEA optionally runs `*atdd`; Dev implements with guidance from failing tests and the plan.
-5. **Post-Dev & Release:** TEA runs `*automate`, re-runs `*trace`, and finishes with `*gate` to document the decision.
+5. **Post-Dev and Release:** TEA runs `*automate`, re-runs `*trace`, and finishes with `*gate` to document the decision.
 
 </details>
 
@@ -85,7 +83,7 @@ last-redoc-date: 2025-09-30
 
 1. **Context Refresh:** Analyst reruns `*product-brief`; PM executes `*plan-project` to update PRD, analysis, and `epics.md`; Architect triggers `*solution-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 & Design:** `*test-design` flags settlement edge cases, plans mitigations, and allocates new API/E2E scenarios with P0 priorities.
+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.
@@ -125,31 +123,40 @@ last-redoc-date: 2025-09-30
 
 ## Command Catalog
 
-| Command        | Task File                        | Primary Outputs                                                      | Notes                                            |
-| -------------- | -------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------ |
-| `*framework`   | `testarch/framework.md`          | Playwright/Cypress scaffold, `.env.example`, `.nvmrc`, sample specs  | Use when no production-ready harness exists      |
-| `*atdd`        | `testarch/atdd.md`               | Failing Acceptance-Test Driven Development, implementation checklist | Requires approved story + harness                |
-| `*automate`    | `testarch/automate.md`           | Prioritized specs, fixtures, README/script updates, DoD summary      | Avoid duplicate coverage (see priority matrix)   |
-| `*ci`          | `testarch/ci.md`                 | CI workflow, selective test scripts, secrets checklist               | Platform-aware (GitHub Actions default)          |
-| `*test-design` | `testarch/test-design.md`        | Combined risk assessment, mitigation plan, and coverage strategy     | Handles risk scoring and test design in one pass |
-| `*trace`       | `testarch/trace-requirements.md` | Coverage matrix, recommendations, gate snippet                       | Requires access to story/tests repositories      |
-| `*nfr-assess`  | `testarch/nfr-assess.md`         | NFR assessment report with actions                                   | Focus on security/performance/reliability        |
-| `*gate`        | `testarch/gate.md`               | Gate YAML + summary (PASS/CONCERNS/FAIL/WAIVED)                      | Deterministic decision rules + rationale         |
+| Command        | Task File                                        | Primary Outputs                                                     | Notes                                            |
+| -------------- | ------------------------------------------------ | ------------------------------------------------------------------- | ------------------------------------------------ |
+| `*framework`   | `workflows/testarch/framework/instructions.md`   | Playwright/Cypress scaffold, `.env.example`, `.nvmrc`, sample specs | Use when no production-ready harness exists      |
+| `*atdd`        | `workflows/testarch/atdd/instructions.md`        | Failing acceptance tests + implementation checklist                 | Requires approved story + harness                |
+| `*automate`    | `workflows/testarch/automate/instructions.md`    | Prioritized specs, fixtures, README/script updates, DoD summary     | Avoid duplicate coverage (see priority matrix)   |
+| `*ci`          | `workflows/testarch/ci/instructions.md`          | CI workflow, selective test scripts, secrets checklist              | Platform-aware (GitHub Actions default)          |
+| `*test-design` | `workflows/testarch/test-design/instructions.md` | Combined risk assessment, mitigation plan, and coverage strategy    | Handles risk scoring and test design in one pass |
+| `*trace`       | `workflows/testarch/trace/instructions.md`       | Coverage matrix, recommendations, gate snippet                      | Requires access to story/tests repositories      |
+| `*nfr-assess`  | `workflows/testarch/nfr-assess/instructions.md`  | NFR assessment report with actions                                  | Focus on security/performance/reliability        |
+| `*gate`        | `workflows/testarch/gate/instructions.md`        | Gate YAML + summary (PASS/CONCERNS/FAIL/WAIVED)                     | Deterministic decision rules + rationale         |
 
 <details>
-<summary>Command Guidance & Context Loading</summary>
+<summary>Command Guidance and Context Loading</summary>
 
-- Each task reads one row from `tea-commands.csv` via `command_key`, expanding pipe-delimited (`|`) values into checklists.
-- Keep CSV rows lightweight; place in-depth heuristics in `tea-knowledge.md` and reference via `knowledge_tags`.
-- If the CSV grows substantially, consider splitting into scoped registries (e.g., planning vs execution) or upgrading to Markdown tables for humans.
-- `tea-knowledge.md` encapsulates Murat’s philosophy—update both CSV and knowledge file together to avoid drift.
+- Each task now carries its own preflight/flow/deliverable guidance inline.
+- `tea-index.csv` maps workflow needs to knowledge fragments; keep tags accurate as you add guidance.
+- Consider future modularization into orchestrated workflows if additional automation is needed.
+- Update the fragment markdown files alongside workflow edits so guidance and outputs stay in sync.
 
 </details>
 
+## Workflow Placement
+
+The TEA stack has three tightly-linked layers:
+
+1. **Agent spec (`agents/tea.md`)** – declares the persona, critical actions, and the `run-workflow` entries for every TEA command. Critical actions instruct the agent to load `tea-index.csv` and then fetch only the fragments it needs from `knowledge/` before giving guidance.
+2. **Knowledge index (`tea-index.csv`)** – catalogues each fragment with tags and file paths. Workflows call out the IDs they need (e.g., `risk-governance`, `fixture-architecture`) so the agent loads targeted guidance instead of a monolithic brief.
+3. **Workflows (`workflows/testarch/*`)** – contain the task flows and reference `tea-index.csv` in their `<flow>`/`<notes>` sections to request specific fragments. Keeping all workflows in this directory ensures consistent discovery during planning (`*framework`), implementation (`*atdd`, `*automate`, `*trace`), and release (`*nfr-assess`, `*gate`).
+
+This separation lets us expand the knowledge base without touching agent wiring and keeps every command remote-controllable via the standard BMAD workflow runner. As navigation improves, we can add lightweight entrypoints or tags in the index without changing where workflows live.
+
 ## Appendix
 
 - **Supporting Knowledge:**
-  - `tea-knowledge.md` – Murat’s testing philosophy, heuristics, and risk scales.
-  - `test-levels-framework.md` – Decision matrix for unit/integration/E2E selection.
-  - `test-priorities-matrix.md` – Priority (P0–P3) criteria and target coverage percentages.
-    s
+  - `tea-index.csv` – Catalog of knowledge fragments with tags and file paths under `knowledge/` for task-specific loading.
+  - `knowledge/*.md` – Focused summaries (fixtures, network, CI, levels, priorities, etc.) distilled from Murat’s external resources.
+  - `test-resources-for-ai-flat.txt` – Raw 347 KB archive retained for manual deep dives when a fragment needs source validation.

src/modules/bmm/testarch/atdd.md

@@ -1,40 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Acceptance TDD v2.0 (Slim)
-
-```xml
-<task id="bmad/bmm/testarch/tdd" name="Acceptance Test Driven Development">
-  <llm critical="true">
-    <i>Set command_key="*tdd"</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the row where command equals command_key</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md into context</i>
-    <i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags to guide execution</i>
-    <i>Split pipe-delimited fields into individual checklist items</i>
-    <i>Map knowledge_tags to sections in the knowledge brief and apply them while writing tests</i>
-    <i>Keep responses concise and focused on generating the failing acceptance tests plus the implementation checklist</i>
-  </llm>
-  <flow>
-    <step n="1" title="Preflight">
-      <action>Verify each preflight requirement; gather missing info from user when needed</action>
-      <action>Abort if halt_rules are triggered</action>
-    </step>
-    <step n="2" title="Execute TDD Flow">
-      <action>Walk through flow_cues sequentially, adapting to story context</action>
-      <action>Use knowledge brief heuristics to enforce Murat's patterns (one test = one concern, explicit assertions, etc.)</action>
-    </step>
-    <step n="3" title="Deliverables">
-      <action>Produce artifacts described in deliverables</action>
-      <action>Summarize failing tests and checklist items for the developer</action>
-    </step>
-  </flow>
-  <halt>
-    <i>Apply halt_rules from the CSV row exactly</i>
-  </halt>
-  <notes>
-    <i>Use the notes column for additional constraints or reminders</i>
-  </notes>
-  <output>
-    <i>Failing acceptance test files + implementation checklist summary</i>
-  </output>
-</task>
-```

src/modules/bmm/testarch/automate.md

@@ -1,38 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Automation Expansion v2.0 (Slim)
-
-```xml
-<task id="bmad/bmm/testarch/automate" name="Automation Expansion">
-  <llm critical="true">
-    <i>Set command_key="*automate"</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and read the row where command equals command_key</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md for heuristics</i>
-    <i>Follow CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags</i>
-    <i>Convert pipe-delimited values into actionable checklists</i>
-    <i>Apply Murat's opinions from the knowledge brief when filling gaps or refactoring tests</i>
-  </llm>
-  <flow>
-    <step n="1" title="Preflight">
-      <action>Confirm prerequisites; stop if halt_rules are triggered</action>
-    </step>
-    <step n="2" title="Execute Automation Flow">
-      <action>Walk through flow_cues to analyse existing coverage and add only necessary specs</action>
-      <action>Use knowledge heuristics (composable helpers, deterministic waits, network boundary) while generating code</action>
-    </step>
-    <step n="3" title="Deliverables">
-      <action>Create or update artifacts listed in deliverables</action>
-      <action>Summarize coverage deltas and remaining recommendations</action>
-    </step>
-  </flow>
-  <halt>
-    <i>Apply halt_rules from the CSV row as written</i>
-  </halt>
-  <notes>
-    <i>Reference notes column for additional guardrails</i>
-  </notes>
-  <output>
-    <i>Updated spec files and concise summary of automation changes</i>
-  </output>
-</task>
-```

src/modules/bmm/testarch/ci.md

@@ -1,39 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# CI/CD Enablement v2.0 (Slim)
-
-```xml
-<task id="bmad/bmm/testarch/ci" name="CI/CD Enablement">
-  <llm critical="true">
-    <i>Set command_key="*ci"</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and read the row where command equals command_key</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md to recall CI heuristics</i>
-    <i>Follow CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags</i>
-    <i>Split pipe-delimited values into actionable lists</i>
-    <i>Keep output focused on workflow YAML, scripts, and guidance explicitly requested in deliverables</i>
-  </llm>
-  <flow>
-    <step n="1" title="Preflight">
-      <action>Confirm prerequisites and required permissions</action>
-      <action>Stop if halt_rules trigger</action>
-    </step>
-    <step n="2" title="Execute CI Flow">
-      <action>Apply flow_cues to design the pipeline stages</action>
-      <action>Leverage knowledge brief guidance (cost vs confidence, sharding, artifacts) when making trade-offs</action>
-    </step>
-    <step n="3" title="Deliverables">
-      <action>Create artifacts listed in deliverables (workflow files, scripts, documentation)</action>
-      <action>Summarize the pipeline, selective testing strategy, and required secrets</action>
-    </step>
-  </flow>
-  <halt>
-    <i>Use halt_rules from the CSV row verbatim</i>
-  </halt>
-  <notes>
-    <i>Reference notes column for optimization reminders</i>
-  </notes>
-  <output>
-    <i>CI workflow + concise explanation ready for team adoption</i>
-  </output>
-</task>
-```

src/modules/bmm/testarch/framework.md

@@ -1,41 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Test Framework Setup v2.0 (Slim)
-
-```xml
-<task id="bmad/bmm/testarch/framework" name="Test Framework Setup">
-  <llm critical="true">
-    <i>Set command_key="*framework"</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the row where command equals command_key</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md to internal memory</i>
-    <i>Use the CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags to guide behaviour</i>
-    <i>Split pipe-delimited values (|) into individual checklist items</i>
-    <i>Map knowledge_tags to matching sections in the knowledge brief and apply those heuristics throughout execution</i>
-    <i>DO NOT expand beyond the guidance unless the user supplies extra context; keep instructions lean and adaptive</i>
-  </llm>
-  <flow>
-    <step n="1" title="Run Preflight Checks">
-      <action>Evaluate each item in preflight; confirm or collect missing information</action>
-      <action>If any preflight requirement fails, follow halt_rules and stop</action>
-    </step>
-    <step n="2" title="Execute Framework Flow">
-      <action>Follow flow_cues sequence, adapting to the project's stack</action>
-      <action>When deciding frameworks or patterns, apply relevant heuristics from tea-knowledge.md via knowledge_tags</action>
-      <action>Keep generated assets minimal—only what the CSV specifies</action>
-    </step>
-    <step n="3" title="Finalize Deliverables">
-      <action>Create artifacts listed in deliverables</action>
-      <action>Capture a concise summary for the user explaining what was scaffolded</action>
-    </step>
-  </flow>
-  <halt>
-    <i>Follow halt_rules from the CSV row verbatim</i>
-  </halt>
-  <notes>
-    <i>Use notes column for additional guardrails while executing</i>
-  </notes>
-  <output>
-    <i>Deliverables and summary specified in the CSV row</i>
-  </output>
-</task>
-```

src/modules/bmm/testarch/gate.md

@@ -1,38 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Quality Gate v2.0 (Slim)
-
-```xml
-<task id="bmad/bmm/testarch/tea-gate" name="Quality Gate">
-  <llm critical="true">
-    <i>Set command_key="*gate"</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and read the matching row</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md to reinforce risk-model heuristics</i>
-    <i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags</i>
-    <i>Split pipe-delimited values into actionable items</i>
-    <i>Apply deterministic rules for PASS/CONCERNS/FAIL/WAIVED; capture rationale and approvals</i>
-  </llm>
-  <flow>
-    <step n="1" title="Preflight">
-      <action>Gather latest assessments and confirm prerequisites; halt per halt_rules if missing</action>
-    </step>
-    <step n="2" title="Set Gate Decision">
-      <action>Follow flow_cues to determine status, residual risk, follow-ups</action>
-      <action>Use knowledge heuristics to balance cost vs confidence when negotiating waivers</action>
-    </step>
-    <step n="3" title="Deliverables">
-      <action>Update gate YAML specified in deliverables</action>
-      <action>Summarize decision, rationale, owners, and deadlines</action>
-    </step>
-  </flow>
-  <halt>
-    <i>Apply halt_rules from the CSV row</i>
-  </halt>
-  <notes>
-    <i>Use notes column for quality bar reminders</i>
-  </notes>
-  <output>
-    <i>Updated gate file with documented decision</i>
-  </output>
-</task>
-```

src/modules/bmm/testarch/knowledge/ci-burn-in.md

@@ -0,0 +1,9 @@
+# CI Pipeline and Burn-In Strategy
+
+- Stage jobs: install/caching once, run `test-changed` for quick feedback, then shard full suites with `fail-fast: false` so evidence isn’t lost.
+- Re-run changed specs 5–10x (burn-in) before merging to flush flakes; fail the pipeline on the first inconsistent run.
+- Upload artifacts on failure (videos, traces, HAR) and keep retry counts explicit—hidden retries hide instability.
+- Use `wait-on` for app startup, enforce time budgets (<10 min per job), and document required secrets alongside workflows.
+- Mirror CI scripts locally (`npm run test:ci`, `scripts/burn-in-changed.sh`) so devs reproduce pipeline behaviour exactly.
+
+_Source: Murat CI/CD strategy blog, Playwright/Cypress workflow examples._

src/modules/bmm/testarch/knowledge/component-tdd.md

@@ -0,0 +1,9 @@
+# Component Test-Driven Development Loop
+
+- Start every UI change with a failing component spec (`cy.mount` or RTL `render`); ship only after red → green → refactor passes.
+- Recreate providers/stores per spec to prevent state bleed and keep parallel runs deterministic.
+- Use factories to exercise prop/state permutations; cover accessibility by asserting against roles, labels, and keyboard flows.
+- Keep component specs under ~100 lines: split by intent (rendering, state transitions, error messaging) to preserve clarity.
+- Pair component tests with visual debugging (Cypress runner, Storybook, Playwright trace viewer) to accelerate diagnosis.
+
+_Source: CCTDD repository, Murat component testing talks._

src/modules/bmm/testarch/knowledge/contract-testing.md

@@ -0,0 +1,9 @@
+# Contract Testing Essentials (Pact)
+
+- Store consumer contracts beside the integration specs that generate them; version contracts semantically and publish on every CI run.
+- Require provider verification before merge; failed verification blocks release and surfaces breaking changes immediately.
+- Capture fallback behaviour inside interactions (timeouts, retries, error payloads) so resilience guarantees remain explicit.
+- Automate broker housekeeping: tag releases, archive superseded contracts, and expire unused pacts to reduce noise.
+- Pair contract suites with API smoke or component tests to validate data mapping and UI rendering in tandem.
+
+_Source: Pact consumer/provider sample repos, Murat contract testing blog._

src/modules/bmm/testarch/knowledge/data-factories.md

@@ -0,0 +1,9 @@
+# Data Factories and API-First Setup
+
+- Prefer factory functions that accept overrides and return complete objects (`createUser(overrides)`)—never rely on static fixtures.
+- Seed state through APIs, tasks, or direct DB helpers before visiting the UI; UI-based setup is for validation only.
+- Ensure factories generate parallel-safe identifiers (UUIDs, timestamps) and perform cleanup after each test.
+- Centralize factory exports to avoid duplication; version them alongside schema changes to catch drift in reviews.
+- When working with shared environments, layer feature toggles or targeted cleanup so factories do not clobber concurrent runs.
+
+_Source: Murat Testing Philosophy, blog posts on functional helpers and API-first testing._

src/modules/bmm/testarch/knowledge/email-auth.md

@@ -0,0 +1,9 @@
+# Email-Based Authentication Testing
+
+- Use services like Mailosaur or in-house SMTP capture; extract magic links via regex or HTML parsing helpers.
+- Preserve browser storage (local/session) when processing links—restore state before visiting the authenticated page.
+- Cache email payloads with `cypress-data-session` or equivalent so retries don’t exhaust inbox quotas.
+- Cover negative cases: expired links, reused links, and multiple requests in rapid succession.
+- Ensure the workflow logs the email ID and link for troubleshooting, but scrub PII before committing artifacts.
+
+_Source: Email authentication blog, Murat testing toolkit._

src/modules/bmm/testarch/knowledge/error-handling.md

@@ -0,0 +1,9 @@
+# Error Handling and Resilience Checks
+
+- Treat expected failures explicitly: intercept network errors and assert UI fallbacks (`error-message` visible, retries triggered).
+- In Cypress, use scoped `Cypress.on('uncaught:exception')` to ignore known errors; rethrow anything else so regressions fail.
+- In Playwright, hook `page.on('pageerror')` and only swallow the specific, documented error messages.
+- Test retry/backoff logic by forcing sequential failures (e.g., 500, timeout, success) and asserting telemetry gets recorded.
+- Log captured errors with context (request payload, user/session) but redact secrets to keep artifacts safe for sharing.
+
+_Source: Murat error-handling patterns, Pact resilience guidance._

src/modules/bmm/testarch/knowledge/feature-flags.md

@@ -0,0 +1,9 @@
+# Feature Flag Governance
+
+- Centralize flag definitions in a frozen enum; expose helpers to set, clear, and target specific audiences.
+- Test both enabled and disabled states in CI; clean up targeting after each spec to keep shared environments stable.
+- For LaunchDarkly-style systems, script API helpers to seed variations instead of mutating via UI.
+- Maintain a checklist for new flags: default state, owners, expiry date, telemetry, rollback plan.
+- Document flag dependencies in story/PR templates so QA and release reviews know which toggles must flip before launch.
+
+_Source: LaunchDarkly strategy blog, Murat test architecture notes._

src/modules/bmm/testarch/knowledge/fixture-architecture.md

@@ -0,0 +1,9 @@
+# Fixture Architecture Playbook
+
+- Build helpers as pure functions first, then expose them via Playwright `extend` or Cypress commands so logic stays testable in isolation.
+- Compose capabilities with `mergeTests` (Playwright) or layered Cypress commands instead of inheritance; each fixture should solve one concern (auth, api, logs, network).
+- Keep HTTP helpers framework agnostic—accept all required params explicitly and return results so unit tests and runtime fixtures can share them.
+- Export fixtures through package subpaths (`"./api-request"`, `"./api-request/fixtures"`) to make reuse trivial across suites and projects.
+- Treat fixture files as infrastructure: document dependencies, enforce deterministic timeouts, and ban hidden retries that mask flakiness.
+
+_Source: Murat Testing Philosophy, cy-vs-pw comparison, SEON production patterns._

src/modules/bmm/testarch/knowledge/network-first.md

@@ -0,0 +1,9 @@
+# Network-First Safeguards
+
+- Register interceptions before any navigation or user action; store the promise and await it immediately after the triggering step.
+- Assert on structured responses (status, body schema, headers) instead of generic waits so failures surface with actionable context.
+- Capture HAR files or Playwright traces on successful runs—reuse them for deterministic CI playback when upstream services flake.
+- Prefer edge mocking: stub at service boundaries, never deep within the stack unless risk analysis demands it.
+- Replace implicit waits with deterministic signals like `waitForResponse`, disappearance of spinners, or event hooks.
+
+_Source: Murat Testing Philosophy, Playwright patterns book, blog on network interception._

src/modules/bmm/testarch/knowledge/nfr-criteria.md

@@ -0,0 +1,21 @@
+# Non-Functional Review Criteria
+
+- **Security**
+  - PASS: auth/authz, secret handling, and threat mitigations in place.
+  - CONCERNS: minor gaps with clear owners.
+  - FAIL: critical exposure or missing controls.
+- **Performance**
+  - PASS: metrics meet targets with profiling evidence.
+  - CONCERNS: trending toward limits or missing baselines.
+  - FAIL: breaches SLO/SLA or introduces resource leaks.
+- **Reliability**
+  - PASS: error handling, retries, health checks verified.
+  - CONCERNS: partial coverage or missing telemetry.
+  - FAIL: no recovery path or crash scenarios unresolved.
+- **Maintainability**
+  - PASS: clean code, tests, and documentation shipped together.
+  - CONCERNS: duplication, low coverage, or unclear ownership.
+  - FAIL: absent tests, tangled implementations, or no observability.
+- Default to CONCERNS when targets or evidence are undefined—force the team to clarify before sign-off.
+
+_Source: Murat NFR assessment guidance._

src/modules/bmm/testarch/knowledge/playwright-config.md

@@ -0,0 +1,9 @@
+# Playwright Configuration Guardrails
+
+- Load environment configs via a central map (`envConfigMap`) and fail fast when `TEST_ENV` is missing or unsupported.
+- Standardize timeouts: action 15s, navigation 30s, expect 10s, test 60s; expose overrides through fixtures rather than inline literals.
+- Emit HTML + JUnit reporters, disable auto-open, and store artifacts under `test-results/` for CI upload.
+- Keep `.env.example`, `.nvmrc`, and browser dependencies versioned so local and CI runs stay aligned.
+- Use global setup for shared auth tokens or seeding, but prefer per-test fixtures for anything mutable to avoid cross-test leakage.
+
+_Source: Playwright book repo, SEON configuration example._

src/modules/bmm/testarch/knowledge/probability-impact.md

@@ -0,0 +1,17 @@
+# Probability and Impact Scale
+
+- **Probability**
+  - 1 – Unlikely: standard implementation, low uncertainty.
+  - 2 – Possible: edge cases or partial unknowns worth investigation.
+  - 3 – Likely: known issues, new integrations, or high ambiguity.
+- **Impact**
+  - 1 – Minor: cosmetic issues or easy workarounds.
+  - 2 – Degraded: partial feature loss or manual workaround required.
+  - 3 – Critical: blockers, data/security/regulatory exposure.
+- Multiply probability × impact to derive the risk score.
+  - 1–3: document for awareness.
+  - 4–5: monitor closely, plan mitigations.
+  - 6–8: CONCERNS at the gate until mitigations are implemented.
+  - 9: automatic gate FAIL until resolved or formally waived.
+
+_Source: Murat risk model summary._

src/modules/bmm/testarch/knowledge/risk-governance.md

@@ -0,0 +1,14 @@
+# Risk Governance and Gatekeeping
+
+- Score risk as probability (1–3) × impact (1–3); totals ≥6 demand mitigation before approval, 9 mandates a gate failure.
+- Classify risks across TECH, SEC, PERF, DATA, BUS, OPS. Document owners, mitigation plans, and deadlines for any score above 4.
+- Trace every acceptance criterion to implemented tests; missing coverage must be resolved or explicitly waived before release.
+- Gate decisions:
+  - **PASS** – no critical issues remain and evidence is current.
+  - **CONCERNS** – residual risk exists but has owners, actions, and timelines.
+  - **FAIL** – critical issues unresolved or evidence missing.
+  - **WAIVED** – risk accepted with documented approver, rationale, and expiry.
+- Maintain a gate history log capturing updates so auditors can follow the decision trail.
+- Use the probability/impact scale fragment for shared definitions when scoring teams run the matrix.
+
+_Source: Murat risk governance notes, gate schema guidance._

src/modules/bmm/testarch/knowledge/selective-testing.md

@@ -0,0 +1,9 @@
+# Selective and Targeted Test Execution
+
+- Use tags/grep (`--grep "@smoke"`, `--grep "@critical"`) to slice suites by risk, not directory.
+- Filter by spec patterns (`--spec "**/*checkout*"`) or git diff (`npm run test:changed`) to focus on impacted areas.
+- Combine priority metadata (P0–P3) with change detection to decide which levels to run pre-commit vs. in CI.
+- Record burn-in history for newly added specs; promote to main suite only after consistent green runs.
+- Document the selection strategy in README/CI so the team understands when full regression is mandatory.
+
+_Source: 32+ selective testing strategies blog, Murat testing philosophy._

src/modules/bmm/testarch/knowledge/test-quality.md

@@ -0,0 +1,10 @@
+# Test Quality Definition of Done
+
+- No hard waits (`waitForTimeout`, `cy.wait(ms)`); rely on deterministic waits or event hooks.
+- Each spec <300 lines and executes in ≤1.5 minutes.
+- Tests are isolated, parallel-safe, and self-cleaning (seed via API/tasks, teardown after run).
+- Assertions stay visible in test bodies; avoid conditional logic controlling test flow.
+- Suites must pass locally and in CI with the same commands.
+- Promote new tests only after they have failed for the intended reason at least once.
+
+_Source: Murat quality checklist._

src/modules/bmm/testarch/knowledge/visual-debugging.md

@@ -0,0 +1,9 @@
+# Visual Debugging and Developer Ergonomics
+
+- Keep Playwright trace viewer, Cypress runner, and Storybook accessible in CI artifacts to speed up reproduction.
+- Record short screen captures only-on-failure; pair them with HAR or console logs to avoid guesswork.
+- Document common trace navigation steps (network tab, action timeline) so new contributors diagnose issues quickly.
+- Encourage live-debug sessions with component harnesses to validate behaviour before writing full E2E specs.
+- Integrate accessibility tooling (axe, Playwright audits) into the same debug workflow to catch regressions early.
+
+_Source: Murat DX blog posts, Playwright book appendix on debugging._

src/modules/bmm/testarch/nfr-assess.md

@@ -1,38 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# NFR Assessment v2.0 (Slim)
-
-```xml
-<task id="bmad/bmm/testarch/nfr-assess" name="NFR Assessment">
-  <llm critical="true">
-    <i>Set command_key="*nfr-assess"</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the matching row</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md focusing on NFR guidance</i>
-    <i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags</i>
-    <i>Split pipe-delimited values into actionable lists</i>
-    <i>Demand evidence for each non-functional claim (tests, telemetry, logs)</i>
-  </llm>
-  <flow>
-    <step n="1" title="Preflight">
-      <action>Confirm prerequisites; halt per halt_rules if unmet</action>
-    </step>
-    <step n="2" title="Assess NFRs">
-      <action>Follow flow_cues to evaluate Security, Performance, Reliability, Maintainability</action>
-      <action>Use knowledge heuristics to suggest monitoring and fail-fast patterns</action>
-    </step>
-    <step n="3" title="Deliverables">
-      <action>Produce assessment document and recommendations defined in deliverables</action>
-      <action>Summarize status, gaps, and actions</action>
-    </step>
-  </flow>
-  <halt>
-    <i>Apply halt_rules from the CSV row</i>
-  </halt>
-  <notes>
-    <i>Reference notes column for negotiation framing (cost vs confidence)</i>
-  </notes>
-  <output>
-    <i>NFR assessment markdown with clear next steps</i>
-  </output>
-</task>
-```

src/modules/bmm/testarch/tea-commands.csv

@@ -1,9 +0,0 @@
-command,title,when_to_use,preflight,flow_cues,deliverables,halt_rules,notes,knowledge_tags
-*automate,Automation expansion,After implementation or when reforging coverage,all acceptance criteria satisfied|code builds locally|framework configured,"Review story source/diff to confirm automation target; ensure fixture architecture exists (mergeTests for Playwright, commands for Cypress) and implement apiRequest/network/auth/log fixtures if missing; map acceptance criteria with test-levels-framework.md guidance and avoid duplicate coverage; assign priorities using test-priorities-matrix.md; generate unit/integration/E2E specs with naming convention feature-name.spec.ts, covering happy, negative, and edge paths; enforce deterministic waits, self-cleaning factories, and <=1.5 minute execution per test; run suite and capture Definition of Done results; update package.json scripts and README instructions",New or enhanced spec files grouped by level; fixture modules under support/; data factory utilities; updated package.json scripts and README notes; DoD summary with remaining gaps; gate-ready coverage summary,"If automation target unclear or framework missing, halt and request clarification",Never create page objects; keep tests <300 lines and stateless; forbid hard waits and conditional flow in tests; co-locate tests near source; flag flaky patterns immediately,philosophy/core|patterns/helpers|patterns/waits|patterns/dod
-*ci,CI/CD quality pipeline,Once automation suite exists or needs optimization,git repository initialized|tests pass locally|team agrees on target environments|access to CI platform settings,"Detect CI platform (default GitHub Actions, ask if GitLab/CircleCI/etc); scaffold workflow (.github/workflows/test.yml or platform equivalent) with triggers; set Node.js version from .nvmrc and cache node_modules + browsers; stage jobs: lint -> unit -> component -> e2e with matrix parallelization (shard by file not test); add selective execution script for affected tests; create burn-in job that reruns changed specs 3x to catch flakiness; attach artifacts on failure (traces/videos/HAR); configure retries/backoff and concurrency controls; document required secrets and environment variables; add Slack/email notifications and local script mirroring CI",.github/workflows/test.yml (or platform equivalent); scripts/test-changed.sh; scripts/burn-in-changed.sh; updated README/ci.md instructions; secrets checklist; dashboard or badge configuration,"If git repo absent, test framework missing, or CI platform unspecified, halt and request setup",Target 20x speedups via parallel shards + caching; shard by file; keep jobs under 10 minutes; wait-on-timeout 120s for app startup; ensure npm test locally matches CI run; mention alternative platform paths when not on GitHub,philosophy/core|ci-strategy
-*framework,Initialize test architecture,Run once per repo or when no production-ready harness exists,package.json present|no existing E2E framework detected|architectural context available,"Identify stack from package.json (React/Vue/Angular/Next.js); detect bundler (Vite/Webpack/Rollup/esbuild); match test language to source (JS/TS frontend -> JS/TS tests); choose Playwright for large or performance-critical repos, Cypress for small DX-first teams; create {framework}/tests/ and {framework}/support/fixtures/ and {framework}/support/helpers/; configure config files with timeouts (action 15s, navigation 30s, test 60s) and reporters (HTML + JUnit); create .env.example with TEST_ENV, BASE_URL, API_URL; implement pure function->fixture->mergeTests pattern and faker-based data factories; enable failure-only screenshots/videos and ensure .nvmrc recorded",playwright/ or cypress/ folder with config + support tree; .env.example; .nvmrc; example tests; README with setup instructions,"If package.json missing OR framework already configured, halt and instruct manual review","Playwright: worker parallelism, trace viewer, multi-language support; Cypress: avoid if many dependent API calls; Component testing: Vitest (large) or Cypress CT (small); Contract testing: Pact for microservices; always use data-cy/data-testid selectors",philosophy/core|patterns/fixtures|patterns/selectors
-*gate,Quality gate decision,After review or mitigation updates,latest assessments gathered|team consensus on fixes,"Assemble story metadata (id, title); choose gate status using deterministic rules (PASS all critical issues resolved, CONCERNS minor residual risk, FAIL critical blockers, WAIVED approved by business); update YAML schema with sections: metadata, waiver status, top_issues, risk_summary totals, recommendations (must_fix, monitor), nfr_validation statuses, history; capture rationale, owners, due dates, and summary comment back to story","docs/qa/gates/{story}.yml updated with schema fields (schema, story, story_title, gate, status_reason, reviewer, updated, waiver, top_issues, risk_summary, recommendations, nfr_validation, history); summary message for team","If review incomplete or risk data outdated, halt and request rerun","FAIL whenever unresolved P0 risks/tests or security holes remain; CONCERNS when mitigations planned but residual risk exists; WAIVED requires reason, approver, and expiry; maintain audit trail in history",philosophy/core|risk-model
-*nfr-assess,NFR validation,Late development or pre-review for critical stories,implementation deployed locally|non-functional goals defined or discoverable,"Ask which NFRs to assess; default to core four (security, performance, reliability, maintainability); gather thresholds from story/architecture/technical-preferences and mark unknown targets; inspect evidence (tests, telemetry, logs) for each NFR; classify status using deterministic pass/concerns/fail rules and list quick wins; produce gate block and assessment doc with recommended actions",NFR assessment markdown with findings; gate YAML block capturing statuses and notes; checklist of evidence gaps and follow-up owners,"If NFR targets undefined and no guidance available, request definition and halt","Unknown thresholds -> CONCERNS, never guess; ensure each NFR has evidence or call it out; suggest monitoring hooks and fail-fast mechanisms when gaps exist",philosophy/core|nfr
-*tdd,Acceptance Test Driven Development,Before implementation when team commits to TDD,story approved with acceptance criteria|dev sandbox ready|framework scaffolding in place,Clarify acceptance criteria and affected systems; pick appropriate test level (E2E/API/Component); write failing acceptance tests using Given-When-Then with network interception first then navigation; create data factories and fixture stubs for required entities; outline mocks/fixtures infrastructure the dev team must supply; generate component tests for critical UI logic; compile implementation checklist mapping each test to source work; share failing tests with dev agent and maintain red -> green -> refactor loop,Failing acceptance test files; component test stubs; fixture/mocks skeleton; implementation checklist with test-to-code mapping; documented data-testid requirements,"If criteria ambiguous or framework missing, halt for clarification",Start red; one assertion per test; use beforeEach for visible setup (no shared state); remind devs to run tests before writing production code; update checklist as each test goes green,philosophy/core|patterns/test-structure
-*test-design,Risk and test design planning,"After story approval, before development",story markdown present|acceptance criteria clear|architecture/PRD accessible,"Filter requirements so only genuine risks remain; review PRD/architecture/story for unresolved gaps; classify risks across TECH, SEC, PERF, DATA, BUS, OPS using category definitions; request clarification when evidence missing; score probability (1 unlikely, 2 possible, 3 likely) and impact (1 minor, 2 degraded, 3 critical) then compute totals; highlight risks >=6 and plan mitigations with owners and timelines; break acceptance criteria into atomic scenarios mapped to mitigations; reference test-levels-framework.md to pick unit/integration/E2E/component levels; avoid duplicate coverage, prefer lower levels when possible; assign priorities using test-priorities-matrix.md; outline data/tooling prerequisites and execution order",Risk assessment markdown in docs/qa/assessments; table of category/probability/impact/score; mitigation matrix with owners and due dates; coverage matrix with requirement/level/priority/mitigation; gate YAML snippet summarizing risk totals and scenario counts; recommended execution order,"If story missing or criteria unclear, halt for clarification","Category definitions: TECH=architecture flaws; SEC=missing controls/vulnerabilities; PERF=SLA risk; DATA=loss/corruption; BUS=user/business harm; OPS=deployment/run failures; rely on evidence, not speculation; tie scenarios back to risk mitigations; keep scenarios independent and maintainable",philosophy/core|risk-model|patterns/test-structure
-*trace,Requirements traceability,Mid-development checkpoint or before review,tests exist for story|access to source + specs,"Gather acceptance criteria and implemented tests; map each criterion to concrete tests (file + describe/it) using Given-When-Then narrative; classify coverage status as FULL, PARTIAL, NONE, UNIT-ONLY, INTEGRATION-ONLY; flag severity based on priority (P0 gaps critical); recommend additional tests or refactors; generate gate YAML coverage summary",Traceability report saved under docs/qa/assessments; coverage matrix with status per criterion; gate YAML snippet for coverage totals and gaps,"If story lacks implemented tests, pause and advise running *tdd or writing tests","Definitions: FULL=all scenarios validated, PARTIAL=some coverage exists, NONE=no validation, UNIT-ONLY=missing higher level, INTEGRATION-ONLY=lacks lower confidence; ensure assertions explicit and avoid duplicate coverage",philosophy/core|patterns/assertions

src/modules/bmm/testarch/tea-index.csv

@@ -0,0 +1,19 @@
+id,name,description,tags,fragment_file
+fixture-architecture,Fixture Architecture,"Composable fixture patterns (pure function → fixture → merge) and reuse rules","fixtures,architecture,playwright,cypress",knowledge/fixture-architecture.md
+network-first,Network-First Safeguards,"Intercept-before-navigate workflow, HAR capture, deterministic waits, edge mocking","network,stability,playwright,cypress",knowledge/network-first.md
+data-factories,Data Factories and API Setup,"Factories with overrides, API seeding, cleanup discipline","data,factories,setup,api",knowledge/data-factories.md
+component-tdd,Component TDD Loop,"Red→green→refactor workflow, provider isolation, accessibility assertions","component-testing,tdd,ui",knowledge/component-tdd.md
+playwright-config,Playwright Config Guardrails,"Environment switching, timeout standards, artifact outputs","playwright,config,env",knowledge/playwright-config.md
+ci-burn-in,CI and Burn-In Strategy,"Staged jobs, shard orchestration, burn-in loops, artifact policy","ci,automation,flakiness",knowledge/ci-burn-in.md
+selective-testing,Selective Test Execution,"Tag/grep usage, spec filters, diff-based runs, promotion rules","risk-based,selection,strategy",knowledge/selective-testing.md
+feature-flags,Feature Flag Governance,"Enum management, targeting helpers, cleanup, release checklists","feature-flags,governance,launchdarkly",knowledge/feature-flags.md
+contract-testing,Contract Testing Essentials,"Pact publishing, provider verification, resilience coverage","contract-testing,pact,api",knowledge/contract-testing.md
+email-auth,Email Authentication Testing,"Magic link extraction, state preservation, caching, negative flows","email-authentication,security,workflow",knowledge/email-auth.md
+error-handling,Error Handling Checks,"Scoped exception handling, retry validation, telemetry logging","resilience,error-handling,stability",knowledge/error-handling.md
+visual-debugging,Visual Debugging Toolkit,"Trace viewer usage, artifact expectations, accessibility integration","debugging,dx,tooling",knowledge/visual-debugging.md
+risk-governance,Risk Governance,"Scoring matrix, category ownership, gate decision rules","risk,governance,gates",knowledge/risk-governance.md
+probability-impact,Probability and Impact Scale,"Shared definitions for scoring matrix and gate thresholds","risk,scoring,scale",knowledge/probability-impact.md
+test-quality,Test Quality Definition of Done,"Execution limits, isolation rules, green criteria","quality,definition-of-done,tests",knowledge/test-quality.md
+nfr-criteria,NFR Review Criteria,"Security, performance, reliability, maintainability status definitions","nfr,assessment,quality",knowledge/nfr-criteria.md
+test-levels,Test Levels Framework,"Guidelines for choosing unit, integration, or end-to-end coverage","testing,levels,selection",knowledge/test-levels-framework.md
+test-priorities,Test Priorities Matrix,"P0–P3 criteria, coverage targets, execution ordering","testing,prioritization,risk",knowledge/test-priorities-matrix.md

src/modules/bmm/testarch/tea-knowledge.md

@@ -1,275 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Murat Test Architecture Foundations (Slim Brief)
-
-This brief distills Murat Ozcan's testing philosophy used by the Test Architect agent. Use it as the north star after loading `tea-commands.csv`.
-
-## Core Principles
-
-- Cost vs confidence: cost = creation + execution + maintenance. Push confidence where impact is highest and skip redundant checks.
-- Engineering assumes failure: predict what breaks, defend with tests, learn from every failure. A single failing test means the software is not ready.
-- Quality is team work. Story estimates include testing, documentation, and deployment work required to ship safely.
-- Missing test coverage is feature debt (hurts customers), not mere tech debt—treat it with the same urgency as functionality gaps.
-- Shared mutable state is the source of all evil: design fixtures and helpers so each test owns its data.
-- Composition over inheritance: prefer functional helpers and fixtures that compose behaviour; page objects and deep class trees hide duplication.
-- Setup via API, assert via UI. Keep tests user-centric while priming state through fast interfaces.
-- One test = one concern. Explicit assertions live in the test body, not buried in helpers.
-
-## Patterns & Heuristics
-
-- Selector order: `data-cy` / `data-testid` -> ARIA -> text. Avoid brittle CSS, IDs, or index based locators.
-- Network boundary is the mock boundary. Stub at the edge, never mid-service unless risk demands.
-- **Network-first pattern**: ALWAYS intercept before navigation: `const call = interceptNetwork(); await page.goto(); await call;`
-- Deterministic waits only: await specific network responses, elements disappearing, or event hooks. Ban fixed sleeps.
-- **Fixture architecture (The Murat Way)**:
-  ```typescript
-  // 1. Pure function first (testable independently)
-  export async function apiRequest({ request, method, url, data }) {
-    /* implementation */
-  }
-  // 2. Fixture wrapper
-  export const apiRequestFixture = base.extend({
-    apiRequest: async ({ request }, use) => {
-      await use((params) => apiRequest({ request, ...params }));
-    },
-  });
-  // 3. Compose via mergeTests
-  export const test = mergeTests(base, apiRequestFixture, authFixture, networkFixture);
-  ```
-- **Data factories pattern**:
-  ```typescript
-  export const createUser = (overrides = {}) => ({
-    id: faker.string.uuid(),
-    email: faker.internet.email(),
-    ...overrides,
-  });
-  ```
-- Visual debugging: keep component/test runner UIs available (Playwright trace viewer, Cypress runner) to accelerate feedback.
-
-## Risk & Coverage
-
-- Risk score = probability (1-3) × impact (1-3). Score 9 => gate FAIL, ≥6 => CONCERNS. Most stories have 0-1 high risks.
-- Test level ratio: heavy unit/component coverage, but always include E2E for critical journeys and integration seams.
-- Traceability looks for reality: map each acceptance criterion to concrete tests and flag missing coverage or duplicate value.
-- NFR focus areas: Security, Performance, Reliability, Maintainability. Demand evidence (tests, telemetry, alerts) before approving.
-
-## Test Configuration
-
-- **Timeouts**: actionTimeout 15s, navigationTimeout 30s, testTimeout 60s, expectTimeout 10s
-- **Reporters**: HTML (never auto-open) + JUnit XML for CI integration
-- **Media**: screenshot only-on-failure, video retain-on-failure
-- **Language Matching**: Tests should match source code language (JS/TS frontend -> JS/TS tests)
-
-## Automation & CI
-
-- Prefer Playwright for multi-language teams, worker parallelism, rich debugging; Cypress suits smaller DX-first repos or component-heavy spikes.
-- **Framework Selection**: Large repo + performance = Playwright, Small repo + DX = Cypress
-- **Component Testing**: Large repos = Vitest (has UI, easy RTL conversion), Small repos = Cypress CT
-- CI pipelines run lint -> unit -> component -> e2e, with selective reruns for flakes and artifacts (videos, traces) on failure.
-- Shard suites to keep feedback tight; treat CI as shared safety net, not a bottleneck.
-- Test selection ideas (32+ strategies): filter by tags/grep (`npm run test -- --grep "@smoke"`), file patterns (`--spec "**/*checkout*"`), changed files (`npm run test:changed`), or test level (`npm run test:unit` / `npm run test:e2e`).
-- Burn-in testing: run new or changed specs multiple times (e.g., 3-10x) to flush flakes before they land in main.
-- Keep helper scripts handy (`scripts/test-changed.sh`, `scripts/burn-in-changed.sh`) so CI and local workflows stay in sync.
-
-## Project Structure & Config
-
-- **Directory structure**:
-  ```
-  project/
-  ├── playwright.config.ts     # Environment-based config loading
-  ├── playwright/
-  │   ├── tests/               # All specs (group by domain: auth/, network/, feature-flags/…)
-  │   ├── support/             # Frequently touched helpers (global-setup, merged-fixtures, ui helpers, factories)
-  │   ├── config/              # Environment configs (base, local, staging, production)
-  │   └── scripts/             # Expert utilities (burn-in, record/playback, maintenance)
-  ```
-- **Environment config pattern**:
-  ```javascript
-  const configs = {
-    local: require('./config/local.config'),
-    staging: require('./config/staging.config'),
-    prod: require('./config/prod.config'),
-  };
-  export default configs[process.env.TEST_ENV || 'local'];
-  ```
-
-## Test Hygiene & Independence
-
-- Tests must be independent and stateless; never rely on execution order.
-- Cleanup all data created during tests (afterEach or API cleanup).
-- Ensure idempotency: same results every run.
-- No shared mutable state; prefer factory functions per test.
-- Tests must run in parallel safely; never commit `.only`.
-- Prefer co-location: component tests next to components, integration in `tests/integration`, etc.
-- Feature flags: centralise enum definitions (e.g., `export const FLAGS = Object.freeze({ NEW_FEATURE: 'new-feature' })`), provide helpers to set/clear targeting, and write dedicated flag tests that clean up targeting after each run.
-
-## CCTDD (Component Test-Driven Development)
-
-- Start with failing component test -> implement minimal component -> refactor.
-- Component tests catch ~70% of bugs before integration.
-- Use `cy.mount()` or `render()` to test components in isolation; focus on user interactions.
-
-## CI Optimization Strategies
-
-- **Parallel execution**: Split by test file, not test case.
-- **Smart selection**: Run only tests affected by changes (dependency graphs, git diff).
-- **Burn-in testing**: Run new/modified tests 3x to catch flakiness early.
-- **HAR recording**: Record network traffic for offline playback in CI.
-- **Selective reruns**: Only rerun failed specs, not entire suite.
-- **Network recording**: capture HAR files during stable runs so CI can replay network traffic when external systems are flaky.
-
-## Package Scripts
-
-- **Essential npm scripts**:
-  ```json
-  "test:e2e": "playwright test",
-  "test:unit": "vitest run",
-  "test:component": "cypress run --component",
-  "test:contract": "jest --testMatch='**/pact/*.spec.ts'",
-  "test:debug": "playwright test --headed",
-  "test:ci": "npm run test:unit && npm run test:e2e",
-  "contract:publish": "pact-broker publish"
-  ```
-
-## Contract Testing (Pact)
-
-- Use for microservices with integration points.
-- Consumer generates contracts, provider verifies.
-- Structure: `pact/` directory at root, `pact/config.ts` for broker settings.
-- Reference repos: pact-js-example-consumer, pact-js-example-provider, pact-js-example-react-consumer.
-
-## Online Resources & Examples
-
-- Fixture architecture: https://github.com/muratkeremozcan/cy-vs-pw-murats-version
-- Playwright patterns: https://github.com/muratkeremozcan/pw-book
-- Component testing (CCTDD): https://github.com/muratkeremozcan/cctdd
-- Contract testing: https://github.com/muratkeremozcan/pact-js-example-consumer
-- Full app example: https://github.com/muratkeremozcan/tour-of-heroes-react-vite-cypress-ts
-- Blog posts: https://dev.to/muratkeremozcan
-
-## Risk Model Details
-
-- TECH: Unmitigated architecture flaws, experimental patterns without fallbacks.
-- SEC: Missing security controls, potential vulnerabilities, unsafe data handling.
-- PERF: SLA-breaking slowdowns, resource exhaustion, lack of caching.
-- DATA: Loss or corruption scenarios, migrations without rollback, inconsistent schemas.
-- BUS: Business or user harm, revenue-impacting failures, compliance gaps.
-- OPS: Deployment, infrastructure, or observability gaps that block releases.
-
-## Probability & Impact Scale
-
-- Probability 1 = Unlikely (standard implementation, low risk).
-- Probability 2 = Possible (edge cases, needs attention).
-- Probability 3 = Likely (known issues, high uncertainty).
-- Impact 1 = Minor (cosmetic, easy workaround).
-- Impact 2 = Degraded (partial feature loss, manual workaround needed).
-- Impact 3 = Critical (blocker, data/security/regulatory impact).
-- Scores: 9 => FAIL, 6-8 => CONCERNS, 4 => monitor, 1-3 => note only.
-
-## Test Design Frameworks
-
-- Use `docs/docs-v6/v6-bmm/test-levels-framework.md` for level selection and anti-patterns.
-- Use `docs/docs-v6/v6-bmm/test-priorities-matrix.md` for P0-P3 priority criteria.
-- Naming convention: `{epic}.{story}-{LEVEL}-{sequence}` (e.g., `2.4-E2E-01`).
-- Tie each scenario to risk mitigations or acceptance criteria.
-
-## Test Quality Definition of Done
-
-- No hard waits (`page.waitForTimeout`, `cy.wait(ms)`)—use deterministic waits.
-- Each test < 300 lines and executes in <= 1.5 minutes.
-- Tests are stateless, parallel-safe, and self-cleaning.
-- No conditional logic in tests (`if/else`, `try/catch` controlling flow).
-- Explicit assertions live in tests, not hidden in helpers.
-- Tests must run green locally and in CI with identical commands.
-- A test delivers value only when it has failed at least once—design suites so they regularly catch regressions during development.
-
-## NFR Status Criteria
-
-- **Security**: PASS (auth, authz, secrets handled), CONCERNS (minor gaps), FAIL (critical exposure).
-- **Performance**: PASS (meets targets, profiling evidence), CONCERNS (approaching limits), FAIL (breaches limits, leaks).
-- **Reliability**: PASS (error handling, retries, health checks), CONCERNS (partial coverage), FAIL (no recovery, crashes).
-- **Maintainability**: PASS (tests + docs + clean code), CONCERNS (duplication, low coverage), FAIL (no tests, tangled code).
-- Unknown targets => CONCERNS until defined.
-
-## Quality Gate Schema
-
-```yaml
-schema: 1
-story: '{epic}.{story}'
-story_title: '{title}'
-gate: PASS|CONCERNS|FAIL|WAIVED
-status_reason: 'Single sentence summary'
-reviewer: 'Murat (Master Test Architect)'
-updated: '2024-09-20T12:34:56Z'
-waiver:
-  active: false
-  reason: ''
-  approved_by: ''
-  expires: ''
-top_issues:
-  - id: SEC-001
-    severity: high
-    finding: 'Issue description'
-    suggested_action: 'Action to resolve'
-risk_summary:
-  totals:
-    critical: 0
-    high: 0
-    medium: 0
-    low: 0
-recommendations:
-  must_fix: []
-  monitor: []
-nfr_validation:
-  security: { status: PASS, notes: '' }
-  performance: { status: CONCERNS, notes: 'Add caching' }
-  reliability: { status: PASS, notes: '' }
-  maintainability: { status: PASS, notes: '' }
-history:
-  - at: '2024-09-20T12:34:56Z'
-    gate: CONCERNS
-    note: 'Initial review'
-```
-
-- Optional sections: `quality_score` block for extended metrics, and `evidence` block (tests_reviewed, risks_identified, trace.ac_covered/ac_gaps) when teams track them.
-
-## Collaborative TDD Loop
-
-- Share failing acceptance tests with the developer or AI agent.
-- Track red -> green -> refactor progress alongside the implementation checklist.
-- Update checklist items as each test passes; add new tests for discovered edge cases.
-- Keep conversation focused on observable behavior, not implementation detail.
-
-## Traceability Coverage Definitions
-
-- FULL: All scenarios for the criterion validated across appropriate levels.
-- PARTIAL: Some coverage exists but gaps remain.
-- NONE: No tests currently validate the criterion.
-- UNIT-ONLY: Only low-level tests exist; add integration/E2E.
-- INTEGRATION-ONLY: Missing unit/component coverage for fast feedback.
-- Avoid naive UI E2E until service-level confidence exists; use API or contract tests to harden backends first, then add minimal UI coverage to fill the gaps.
-
-## CI Platform Guidance
-
-- Default to GitHub Actions if no preference is given; otherwise ask for GitLab, CircleCI, etc.
-- Ensure local script mirrors CI pipeline (npm test vs CI workflow).
-- Use concurrency controls to prevent duplicate runs (`concurrency` block in GitHub Actions).
-- Keep job runtime under 10 minutes; split further if necessary.
-
-## Testing Tool Preferences
-
-- Component testing: Large repositories prioritize Vitest with UI (fast, component-native). Smaller DX-first teams with existing Cypress stacks can keep Cypress Component Testing for consistency.
-- E2E testing: Favor Playwright for large or performance-sensitive repos; reserve Cypress for smaller DX-first teams where developer experience outweighs scale.
-- API testing: Prefer Playwright's API testing or contract suites over ad-hoc REST clients.
-- Contract testing: Pact.js for consumer-driven contracts; keep `pact/` config in repo.
-- Visual testing: Percy, Chromatic, or Playwright snapshots when UX must be audited.
-
-## Naming Conventions
-
-- File names: `ComponentName.cy.tsx` for Cypress component tests, `component-name.spec.ts` for Playwright, `ComponentName.test.tsx` for unit/RTL.
-- Describe blocks: `describe('Feature/Component Name', () => { context('when condition', ...) })`.
-- Data attributes: always kebab-case (`data-cy="submit-button"`, `data-testid="user-email"`).
-
-## Reference Materials
-
-If deeper context is needed, consult Murat's testing philosophy notes, blog posts, and sample repositories in https://github.com/muratkeremozcan/test-resources-for-ai/blob/main/gitingest-full-repo-text-version.txt.

src/modules/bmm/testarch/test-design.md

@@ -1,43 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Risk & Test Design v3.0 (Slim)
-
-```xml
-<task id="bmad/bmm/testarch/test-design" name="Risk & Test Design">
-  <llm critical="true">
-    <i>Set command_key="*test-design"</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the matching row</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md for risk-model and coverage heuristics</i>
-    <i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags as the execution blueprint</i>
-    <i>Split pipe-delimited values into actionable checklists</i>
-    <i>Stay evidence-based—link risks and scenarios directly to PRD/architecture/story artifacts</i>
-  </llm>
-  <flow>
-    <step n="1" title="Preflight">
-      <action>Confirm story markdown, acceptance criteria, and architecture/PRD access.</action>
-      <action>Stop immediately if halt_rules trigger (missing inputs or unclear requirements).</action>
-    </step>
-    <step n="2" title="Assess Risks">
-      <action>Follow flow_cues to filter genuine risks, classify them (TECH/SEC/PERF/DATA/BUS/OPS), and score probability × impact.</action>
-      <action>Document mitigations with owners, timelines, and residual risk expectations.</action>
-    </step>
-    <step n="3" title="Design Coverage">
-      <action>Break acceptance criteria into atomic scenarios mapped to mitigations.</action>
-      <action>Choose test levels using test-levels-framework.md, assign priorities via test-priorities-matrix.md, and note tooling/data prerequisites.</action>
-    </step>
-    <step n="4" title="Deliverables">
-      <action>Generate the combined risk report and test design artifacts described in deliverables.</action>
-      <action>Summarize key risks, mitigations, coverage plan, and recommended execution order.</action>
-    </step>
-  </flow>
-  <halt>
-    <i>Apply halt_rules from the CSV row verbatim.</i>
-  </halt>
-  <notes>
-    <i>Use notes column for calibration reminders and coverage heuristics.</i>
-  </notes>
-  <output>
-    <i>Unified risk assessment plus coverage strategy ready for implementation.</i>
-  </output>
-</task>
-```

src/modules/bmm/testarch/trace-requirements.md

@@ -1,38 +0,0 @@
-<!-- Powered by BMAD-CORE™ -->
-
-# Requirements Traceability v2.0 (Slim)
-
-```xml
-<task id="bmad/bmm/testarch/trace" name="Requirements Traceability">
-  <llm critical="true">
-    <i>Set command_key="*trace"</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and read the matching row</i>
-    <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md emphasising assertions guidance</i>
-    <i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags</i>
-    <i>Split pipe-delimited values into actionable lists</i>
-    <i>Focus on mapping reality: reference actual files, describe coverage gaps, recommend next steps</i>
-  </llm>
-  <flow>
-    <step n="1" title="Preflight">
-      <action>Validate prerequisites; halt per halt_rules if unmet</action>
-    </step>
-    <step n="2" title="Traceability Analysis">
-      <action>Follow flow_cues to map acceptance criteria to implemented tests</action>
-      <action>Leverage knowledge heuristics to highlight assertion quality and duplication risks</action>
-    </step>
-    <step n="3" title="Deliverables">
-      <action>Create traceability report described in deliverables</action>
-      <action>Summarize critical gaps and recommendations</action>
-    </step>
-  </flow>
-  <halt>
-    <i>Apply halt_rules from the CSV row</i>
-  </halt>
-  <notes>
-    <i>Reference notes column for additional emphasis</i>
-  </notes>
-  <output>
-    <i>Coverage matrix and narrative summary</i>
-  </output>
-</task>
-```

src/modules/bmm/workflows/1-analysis/brainstorm-game/game-context.md

@@ -12,10 +12,10 @@ When brainstorming for games, consider exploring:
 - **Game Dynamics** - Emergent behaviors from mechanic interactions
 - **Aesthetic Experience** - Emotional responses and feelings evoked
 - **Progression Systems** - How players grow and unlock content
-- **Challenge & Difficulty** - How to create engaging difficulty curves
+- **Challenge and Difficulty** - How to create engaging difficulty curves
 - **Social/Multiplayer Features** - How players interact with each other
-- **Narrative & World** - Story, setting, and environmental storytelling
-- **Art Direction & Feel** - Visual style and game feel
+- **Narrative and World** - Story, setting, and environmental storytelling
+- **Art Direction and Feel** - Visual style and game feel
 - **Monetization** - Business model and revenue approach (if applicable)
 
 ## Game Design Frameworks

src/modules/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml

@@ -20,3 +20,18 @@ game_brain_methods: "{installed_path}/game-brain-methods.csv"
 
 # CIS brainstorming workflow to invoke
 cis_brainstorming: "{project-root}/bmad/cis/workflows/brainstorming/workflow.yaml"
+
+web_bundle:
+  name: "brainstorm-game"
+  description: "Facilitate game brainstorming sessions by orchestrating the CIS brainstorming workflow with game-specific context, guidance, and additional game design techniques."
+  author: "BMad"
+  instructions: "bmad/bmm/workflows/1-analysis/brainstorm-game/instructions.md"
+  template: false
+  use_advanced_elicitation: true
+  web_bundle_files:
+    - "bmad/bmm/workflows/1-analysis/brainstorm-game/instructions.md"
+    - "bmad/bmm/workflows/1-analysis/brainstorm-game/game-context.md"
+    - "bmad/bmm/workflows/1-analysis/brainstorm-game/game-brain-methods.csv"
+    - "bmad/cis/workflows/brainstorming/workflow.yaml"
+  existing_workflows:
+    - cis_brainstorming: "bmad/cis/workflows/brainstorming/workflow.yaml"

src/modules/bmm/workflows/1-analysis/brainstorm-project/project-context.md

@@ -6,13 +6,13 @@ This context guide provides project-specific considerations for brainstorming se
 
 When brainstorming for projects, consider exploring:
 
-- **User Problems & Pain Points** - What challenges do users face?
-- **Feature Ideas & Capabilities** - What could the product do?
+- **User Problems and Pain Points** - What challenges do users face?
+- **Feature Ideas and Capabilities** - What could the product do?
 - **Technical Approaches** - How might we build it?
 - **User Experience** - How will users interact with it?
-- **Business Model & Value** - How does it create value?
+- **Business Model and Value** - How does it create value?
 - **Market Differentiation** - What makes it unique?
-- **Technical Risks & Challenges** - What could go wrong?
+- **Technical Risks and Challenges** - What could go wrong?
 - **Success Metrics** - How will we measure success?
 
 ## Integration with Project Workflow

src/modules/bmm/workflows/1-analysis/brainstorm-project/workflow.yaml

@@ -19,3 +19,17 @@ project_context: "{installed_path}/project-context.md"
 
 # CIS brainstorming workflow to invoke
 cis_brainstorming: "{project-root}/bmad/cis/workflows/brainstorming/workflow.yaml"
+
+web_bundle:
+  name: "brainstorm-project"
+  description: "Facilitate project brainstorming sessions by orchestrating the CIS brainstorming workflow with project-specific context and guidance."
+  author: "BMad"
+  instructions: "bmad/bmm/workflows/1-analysis/brainstorm-project/instructions.md"
+  template: false
+  use_advanced_elicitation: true
+  web_bundle_files:
+    - "bmad/bmm/workflows/1-analysis/brainstorm-project/instructions.md"
+    - "bmad/bmm/workflows/1-analysis/brainstorm-project/project-context.md"
+    - "bmad/cis/workflows/brainstorming/workflow.yaml"
+  existing_workflows:
+    - cis_brainstorming: "bmad/cis/workflows/brainstorming/workflow.yaml"

src/modules/bmm/workflows/1-analysis/game-brief/README.md

@@ -48,7 +48,7 @@ Work through each section collaboratively:
 4. Scope and Constraints (platforms, timeline, budget, team)
 5. Reference Framework (inspiration, competitors, differentiators)
 6. Content Framework (world, narrative, volume)
-7. Art & Audio Direction (visual and audio style)
+7. Art and Audio Direction (visual and audio style)
 8. Risk Assessment (risks, challenges, mitigation)
 9. Success Criteria (MVP, metrics, launch goals)
 10. Next Steps (immediate actions, research, questions)

src/modules/bmm/workflows/1-analysis/game-brief/checklist.md

@@ -45,13 +45,13 @@ Use this checklist to ensure your game brief is complete and ready for GDD creat
 
 ## Content Framework ✓
 
-- [ ] **World & Setting** is defined
+- [ ] **World and Setting** is defined
 - [ ] **Narrative Approach** matches game type
 - [ ] **Content Volume** is estimated (rough order of magnitude)
 - [ ] Playtime expectations are set
 - [ ] Replayability approach is clear
 
-## Art & Audio Direction ✓
+## Art and Audio Direction ✓
 
 - [ ] **Visual Style** is described with references
 - [ ] 2D vs. 3D is decided

src/modules/bmm/workflows/1-analysis/game-brief/instructions.md

@@ -225,7 +225,7 @@ What makes your game unique?
 <step n="8" goal="Define content framework" if="collaboration_mode == 'interactive'">
 <ask>Let's scope your content needs.
 
-**World & Setting:**
+**World and Setting:**
 
 - Where/when does your game take place?
 - How much world-building is needed?
@@ -459,7 +459,7 @@ What are you still uncertain about?
 4. Scope and Constraints
 5. Reference Framework
 6. Content Framework
-7. Art & Audio Direction
+7. Art and Audio Direction
 8. Risk Assessment
 9. Success Criteria
 10. Next Steps

src/modules/bmm/workflows/1-analysis/game-brief/template.md

@@ -102,7 +102,7 @@
 
 ## Content Framework
 
-### World & Setting
+### World and Setting
 
 {{world_setting}}
 
@@ -116,7 +116,7 @@
 
 ---
 
-## Art & Audio Direction
+## Art and Audio Direction
 
 ### Visual Style
 

src/modules/bmm/workflows/1-analysis/game-brief/workflow.yaml

@@ -26,9 +26,19 @@ validation: "{installed_path}/checklist.md"
 # Output configuration
 default_output_file: "{output_folder}/game-brief-{{game_name}}-{{date}}.md"
 
-# Required tools
-required_tools: []
-
 # Workflow settings
 autonomous: false # This is an interactive workflow requiring user collaboration
 brief_format: "comprehensive" # Options: "comprehensive" (full detail) or "executive" (3-page limit)
+
+web_bundle:
+  name: "game-brief"
+  description: "Interactive game brief creation workflow that guides users through defining their game vision with multiple input sources and conversational collaboration"
+  author: "BMad"
+  instructions: "bmad/bmm/workflows/1-analysis/product-brief/instructions.md"
+  validation: "bmad/bmm/workflows/1-analysis/product-brief/checklist.md"
+  template: "bmad/bmm/workflows/1-analysis/game-brief/template.md"
+  use_advanced_elicitation: true
+  web_bundle_files:
+    - "bmad/bmm/workflows/1-analysis/game-brief/template.md"
+    - "bmad/bmm/workflows/1-analysis/game-brief/instructions.md"
+    - "bmad/bmm/workflows/1-analysis/game-brief/checklist.md"

src/modules/bmm/workflows/1-analysis/product-brief/README.md

@@ -95,14 +95,14 @@ product-brief/
 2. **Problem Statement** - Detailed problem analysis with evidence
 3. **Proposed Solution** - Core approach and key differentiators
 4. **Target Users** - Primary and secondary user segments with personas
-5. **Goals & Success Metrics** - Business objectives and measurable KPIs
+5. **Goals and Success Metrics** - Business objectives and measurable KPIs
 6. **MVP Scope** - Must-have features and out-of-scope items
 7. **Post-MVP Vision** - Phase 2 features and long-term roadmap
 8. **Financial Impact** - Investment requirements and ROI projections
 9. **Strategic Alignment** - Connection to company OKRs and initiatives
 10. **Technical Considerations** - Platform requirements and preferences
-11. **Constraints & Assumptions** - Resource limits and key assumptions
-12. **Risks & Open Questions** - Risk assessment and research needs
+11. **Constraints and Assumptions** - Resource limits and key assumptions
+12. **Risks and Open Questions** - Risk assessment and research needs
 13. **Supporting Materials** - Research summaries and references
 
 ## Requirements
@@ -170,7 +170,7 @@ To customize this workflow:
 
 For issues or questions:
 
-- Review the workflow creation guide at `/bmad/bmb/workflows/build-workflow/workflow-creation-guide.md`
+- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
 - Validate output using `checklist.md`
 - Consider running market research workflow first if lacking business context
 - Consult BMAD documentation for product planning methodology

src/modules/bmm/workflows/1-analysis/product-brief/checklist.md

@@ -41,7 +41,7 @@
 - [ ] Secondary segment (if applicable) is equally detailed
 - [ ] Avoids generic personas like "busy professionals"
 
-## Goals & Metrics
+## Goals and Metrics
 
 - [ ] Business objectives include measurable outcomes with targets
 - [ ] User success metrics focus on behaviors, not features
@@ -67,7 +67,7 @@
 - [ ] Technology preferences are marked as preferences, not decisions
 - [ ] Integration requirements with existing systems are identified
 
-## Constraints & Assumptions
+## Constraints and Assumptions
 
 - [ ] Budget constraints are documented if known
 - [ ] Timeline or deadline pressures are specified

src/modules/bmm/workflows/1-analysis/product-brief/instructions.md

@@ -299,13 +299,13 @@ Being honest about unknowns helps us prepare.</ask>
 1. Problem Statement
 2. Proposed Solution
 3. Target Users
-4. Goals & Metrics
+4. Goals and Metrics
 5. MVP Scope
 6. Post-MVP Vision
-7. Financial Impact & Strategic Alignment
+7. Financial Impact and Strategic Alignment
 8. Technical Considerations
-9. Constraints & Assumptions
-10. Risks & Questions
+9. Constraints and Assumptions
+10. Risks and Questions
 11. Save and continue</ask>
 
 <action>Work with user to refine selected section</action>

src/modules/bmm/workflows/1-analysis/product-brief/template.md

@@ -36,7 +36,7 @@
 
 ---
 
-## Goals & Success Metrics
+## Goals and Success Metrics
 
 ### Business Objectives
 
@@ -52,7 +52,7 @@
 
 ---
 
-## Strategic Alignment & Financial Impact
+## Strategic Alignment and Financial Impact
 
 ### Financial Impact
 
@@ -116,7 +116,7 @@
 
 ---
 
-## Constraints & Assumptions
+## Constraints and Assumptions
 
 ### Constraints
 
@@ -128,7 +128,7 @@
 
 ---
 
-## Risks & Open Questions
+## Risks and Open Questions
 
 ### Key Risks
 

src/modules/bmm/workflows/1-analysis/product-brief/workflow.yaml

@@ -25,9 +25,19 @@ validation: "{installed_path}/checklist.md"
 # Output configuration
 default_output_file: "{output_folder}/product-brief-{{project_name}}-{{date}}.md"
 
-# Required tools
-required_tools: []
-
 # Workflow settings
 autonomous: false # This is an interactive workflow requiring user collaboration
 brief_format: "comprehensive" # Options: "comprehensive" (full detail) or "executive" (3-page limit)
+
+web_bundle:
+  name: "product-brief"
+  description: "Interactive product brief creation workflow that guides users through defining their product vision with multiple input sources and conversational collaboration"
+  author: "BMad"
+  instructions: "bmad/bmm/workflows/1-analysis/product-brief/instructions.md"
+  validation: "bmad/bmm/workflows/1-analysis/product-brief/checklist.md"
+  template: "bmad/bmm/workflows/1-analysis/product-brief/template.md"
+  use_advanced_elicitation: true
+  web_bundle_files:
+    - "bmad/bmm/workflows/1-analysis/product-brief/template.md"
+    - "bmad/bmm/workflows/1-analysis/product-brief/instructions.md"
+    - "bmad/bmm/workflows/1-analysis/product-brief/checklist.md"

src/modules/bmm/workflows/1-analysis/research/README.md

@@ -146,7 +146,7 @@ research/
 
 ## Workflow Process
 
-### Phase 1: Research Type Selection & Setup
+### Phase 1: Research Type Selection and Setup
 
 1. Router presents research type menu
 2. User selects research type (market, deep_prompt, technical, competitive, user, domain)
@@ -196,7 +196,7 @@ research/
 - Adapts questions and frameworks to research type
 - Customizes output format for target audience
 
-### Phase 3: Validation & Delivery
+### Phase 3: Validation and Delivery
 
 1. Review outputs against checklist
 2. Validate completeness and quality
@@ -428,7 +428,7 @@ Add to `workflow.yaml` `frameworks` section under appropriate research type.
 
 For issues or questions:
 
-- Review workflow creation guide at `/bmad/bmb/workflows/build-workflow/workflow-creation-guide.md`
+- Review workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
 - Check validation against `checklist.md`
 - Examine router logic in `instructions-router.md`
 - Review research type-specific instructions

src/modules/bmm/workflows/1-analysis/research/claude-code/sub-agents/bmm-competitor-analyzer.md

@@ -207,7 +207,7 @@ Competitive Threat:
 ### Innovation Pipeline Assessment
 
 - Patent filing analysis
-- R&D investment signals
+- RandD investment signals
 - Acquisition patterns
 - Partnership strategies
 - Beta/preview features

src/modules/bmm/workflows/1-analysis/research/claude-code/sub-agents/bmm-market-researcher.md

@@ -77,7 +77,7 @@ You are a specialized Market Research Expert with deep expertise in gathering, a
 - Market share estimates
 - Business model analysis
 - Competitive dynamics
-- M&A activity
+- MandA activity
 
 **Customer Research**
 
@@ -87,7 +87,7 @@ You are a specialized Market Research Expert with deep expertise in gathering, a
 - Decision criteria
 - Price sensitivity
 
-### Phase 3: Synthesis & Insights
+### Phase 3: Synthesis and Insights
 
 **Pattern Recognition**
 

src/modules/bmm/workflows/1-analysis/research/claude-code/sub-agents/bmm-trend-spotter.md

@@ -58,9 +58,9 @@ When analyzing trends:
 
 For each identified trend, provide:
 
-- **Trend Name & Description**
+- **Trend Name and Description**
 - **Current Stage** (Emerging/Growing/Mainstream/Declining)
-- **Evidence & Signals** (3-5 specific indicators)
+- **Evidence and Signals** (3-5 specific indicators)
 - **Timeline** (When mainstream adoption expected)
 - **Impact Assessment** (Market size, disruption potential)
 - **Opportunities** (How to capitalize)

src/modules/bmm/workflows/1-analysis/research/template-deep-prompt.md

@@ -62,7 +62,7 @@
 
 ---
 
-## Complete Research Prompt (Copy & Paste)
+## Complete Research Prompt (Copy and Paste)
 
 ```
 {{deep_research_prompt}}

src/modules/bmm/workflows/1-analysis/research/template-market.md

@@ -22,7 +22,7 @@
 
 ---
 
-## 1. Research Objectives & Methodology
+## 1. Research Objectives and Methodology
 
 ### Research Objectives
 

src/modules/bmm/workflows/1-analysis/research/workflow.yaml

@@ -147,3 +147,99 @@ data_sources:
   - "Social media and communities"
   - "Patent databases"
   - "Benchmarking studies"
+
+web_bundle:
+  name: "research"
+  description: "Adaptive research workflow supporting multiple research types: market research, deep research prompt generation, technical/architecture evaluation, competitive intelligence, user research, and domain analysis"
+  author: "BMad"
+  instructions: "bmad/bmm/workflows/1-analysis/research/instructions-router.md" # Router loads specific instruction sets
+  validation: "bmad/bmm/workflows/1-analysis/research/checklist.md"
+  use_advanced_elicitation: true
+  web_bundle_files:
+    - "bmad/bmm/workflows/1-analysis/research/instructions-router.md"
+    - "bmad/bmm/workflows/1-analysis/research/instructions-market.md"
+    - "bmad/bmm/workflows/1-analysis/research/instructions-deep-prompt.md"
+    - "bmad/bmm/workflows/1-analysis/research/instructions-technical.md"
+    - "bmad/bmm/workflows/1-analysis/research/template-market.md"
+    - "bmad/bmm/workflows/1-analysis/research/template-deep-prompt.md"
+    - "bmad/bmm/workflows/1-analysis/research/template-technical.md"
+    - "bmad/bmm/workflows/1-analysis/research/checklist.md"
+  # Workflow configuration
+  interactive: true # User checkpoints throughout
+  autonomous: false # Requires user input
+  allow_parallel: true # Can run research tasks in parallel
+
+  # Research frameworks available (context dependent)
+  frameworks:
+    market:
+      - "TAM/SAM/SOM Analysis"
+      - "Porter's Five Forces"
+      - "Jobs-to-be-Done"
+      - "Technology Adoption Lifecycle"
+      - "SWOT Analysis"
+      - "Value Chain Analysis"
+    technical:
+      - "Trade-off Analysis"
+      - "Architecture Decision Records (ADR)"
+      - "Technology Radar"
+      - "Comparison Matrix"
+      - "Cost-Benefit Analysis"
+    deep_prompt:
+      - "ChatGPT Deep Research Best Practices"
+      - "Gemini Deep Research Framework"
+      - "Grok DeepSearch Optimization"
+      - "Claude Projects Methodology"
+      - "Iterative Prompt Refinement"
+
+  # Data sources (for web research)
+  data_sources:
+    - "Industry reports and publications"
+    - "Government statistics and databases"
+    - "Financial reports and SEC filings"
+    - "News articles and press releases"
+    - "Academic research papers"
+    - "Technical documentation and RFCs"
+    - "GitHub repositories and discussions"
+    - "Stack Overflow and developer forums"
+    - "Market research firm reports"
+    - "Social media and communities"
+    - "Patent databases"
+    - "Benchmarking studies"
+  # Research types supported
+  research_types:
+    market:
+      name: "Market Research"
+      description: "Comprehensive market analysis with TAM/SAM/SOM"
+      instructions: "bmad/bmm/workflows/1-analysis/research/instructions-market.md"
+      template: "bmad/bmm/workflows/1-analysis/research/template-market.md"
+      output: "{market_output}"
+    deep_prompt:
+      name: "Deep Research Prompt Generator"
+      description: "Generate optimized prompts for AI research platforms"
+      instructions: "bmad/bmm/workflows/1-analysis/research/instructions-deep-prompt.md"
+      template: "bmad/bmm/workflows/1-analysis/research/template-deep-prompt.md"
+      output: "{deep_prompt_output}"
+    technical:
+      name: "Technical/Architecture Research"
+      description: "Technology evaluation and architecture pattern research"
+      instructions: "bmad/bmm/workflows/1-analysis/research/instructions-technical.md"
+      template: "bmad/bmm/workflows/1-analysis/research/template-technical.md"
+      output: "{technical_output}"
+    competitive:
+      name: "Competitive Intelligence"
+      description: "Deep competitor analysis"
+      instructions: "bmad/bmm/workflows/1-analysis/research/instructions-market.md" # Uses market with competitive focus
+      template: "bmad/bmm/workflows/1-analysis/research/template-market.md"
+      output: "{output_folder}/competitive-intelligence-{{date}}.md"
+    user:
+      name: "User Research"
+      description: "Customer insights and persona development"
+      instructions: "bmad/bmm/workflows/1-analysis/research/instructions-market.md" # Uses market with user focus
+      template: "bmad/bmm/workflows/1-analysis/research/template-market.md"
+      output: "{output_folder}/user-research-{{date}}.md"
+    domain:
+      name: "Domain/Industry Research"
+      description: "Industry and domain deep dives"
+      instructions: "bmad/bmm/workflows/1-analysis/research/instructions-market.md" # Uses market with domain focus
+      template: "bmad/bmm/workflows/1-analysis/research/template-market.md"
+      output: "{output_folder}/domain-research-{{date}}.md"

src/modules/bmm/workflows/2-plan/README.md

@@ -193,7 +193,7 @@ To customize this workflow:
 
 For issues or questions:
 
-- Review the workflow creation guide at `/bmad/bmb/workflows/build-workflow/workflow-creation-guide.md`
+- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
 - Validate output using `checklist.md`
 - Consult project assessment in `project-workflow-analysis.md`
 - Check continuation status in existing output documents

src/modules/bmm/workflows/2-plan/gdd/README.md

@@ -20,12 +20,12 @@ The GDD workflow creates a comprehensive Game Design Document that captures:
 `gdd-template.md` contains sections common to ALL game types:
 
 - Executive Summary
-- Goals & Context
+- Goals and Context
 - Core Gameplay
 - Win/Loss Conditions
-- Progression & Balance
+- Progression and Balance
 - Level Design Framework
-- Art & Audio Direction
+- Art and Audio Direction
 - Technical Specs
 - Development Epics
 - Success Metrics
@@ -53,15 +53,15 @@ Located in `game-types/` folder, these markdown files contain sections specific
 - Movement System (jump mechanics, air control, special moves)
 - Combat System (attack types, combos, enemy AI)
 - Level Design Patterns (platforming challenges, combat arenas)
-- Player Abilities & Unlocks
+- Player Abilities and Unlocks
 
 **rpg.md**:
 
 - Character System (stats, classes, leveling)
-- Inventory & Equipment
+- Inventory and Equipment
 - Quest System
-- World & Exploration
-- NPC & Dialogue
+- World and Exploration
+- NPC and Dialogue
 - Combat System
 
 **puzzle.md**:
@@ -76,8 +76,8 @@ Located in `game-types/` folder, these markdown files contain sections specific
 
 - Run Structure
 - Procedural Generation
-- Permadeath & Progression
-- Item & Upgrade System
+- Permadeath and Progression
+- Item and Upgrade System
 - Character Selection
 - Difficulty Modifiers
 
@@ -98,15 +98,15 @@ Located in `game-types/` folder, these markdown files contain sections specific
    - Stores `game_type` for injection
 
 3. **Universal GDD Sections** (Steps 2-5, 7-13):
-   - Platform & target audience
-   - Goals & context
+   - Platform and target audience
+   - Goals and context
    - Core gameplay (pillars, loop, win/loss)
-   - Mechanics & controls
-   - Progression & balance
+   - Mechanics and controls
+   - Progression and balance
    - Level design
-   - Art & audio
+   - Art and audio
    - Technical specs
-   - Epics & metrics
+   - Epics and metrics
 
 4. **Game-Type Injection** (Step 6):
    - Loads fragment from `game-types/{game_type}.md`

src/modules/bmm/workflows/2-plan/gdd/game-types/action-platformer.md

@@ -33,7 +33,7 @@
 - Checkpoint placement
 - Difficulty spikes and pacing
 
-### Player Abilities & Unlocks
+### Player Abilities and Unlocks
 
 {{player_abilities}}
 

src/modules/bmm/workflows/2-plan/gdd/game-types/adventure.md

@@ -59,7 +59,7 @@ This game type is **narrative-heavy**. Consider running the Narrative Design wor
 - Companion mechanics (if applicable)
 - Memorable character moments
 
-### Inventory & Items
+### Inventory and Items
 
 {{inventory_items}}
 

src/modules/bmm/workflows/2-plan/gdd/game-types/card-game.md

@@ -1,6 +1,6 @@
 ## Card Game Specific Elements
 
-### Card Types & Effects
+### Card Types and Effects
 
 {{card_types}}
 
@@ -50,7 +50,7 @@
 - Time limits per turn
 - Match length targets
 
-### Card Collection & Progression
+### Card Collection and Progression
 
 {{collection_progression}}