bmad-method 5.0.0-beta.2 → 5.0.1

package/dist/teams/team-all.txt

@@ -46,7 +46,7 @@ bundle:
   description: Includes every core system agent.
 agents:
   - bmad-orchestrator
-  - '*'
+  - "*"
 workflows:
   - brownfield-fullstack.yaml
   - brownfield-service.yaml
@@ -1261,7 +1261,7 @@ You are the "Vibe CEO" - thinking like a CEO with unlimited resources and a sing
 
 - **Claude Code**: `/agent-name` (e.g., `/bmad-master`)
 - **Cursor**: `@agent-name` (e.g., `@bmad-master`)
-- **Windsurf**: `@agent-name` (e.g., `@bmad-master`)
+- **Windsurf**: `/agent-name` (e.g., `/bmad-master`)
 - **Trae**: `@agent-name` (e.g., `@bmad-master`)
 - **Roo Code**: Select mode from mode selector (e.g., `bmad-master`)
 - **GitHub Copilot**: Open the Chat view (`⌃⌘I` on Mac, `Ctrl+Alt+I` on Windows/Linux) and select **Agent** from the chat mode selector.
@@ -2001,7 +2001,7 @@ Agents should be workflow-aware: know active workflow, their role, access artifa
 ==================== START: .bmad-core/tasks/facilitate-brainstorming-session.md ====================
 ---
 docOutputLocation: docs/brainstorming-session-results.md
-template: ".bmad-core/templates/brainstorming-output-tmpl.yaml"
+template: '.bmad-core/templates/brainstorming-output-tmpl.yaml'
 ---
 
 # Facilitate Brainstorming Session Task
@@ -2795,12 +2795,12 @@ sections:
   - id: introduction
     instruction: |
       This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development.
-      
+
       Start by asking the user which mode they prefer:
-      
+
       1. **Interactive Mode** - Work through each section collaboratively
       2. **YOLO Mode** - Generate complete draft for review and refinement
-      
+
       Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context.
 
   - id: executive-summary
@@ -3121,7 +3121,7 @@ sections:
         instruction: Map the end-to-end customer experience for primary segments
         template: |
           For primary customer segment:
-          
+
           1. **Awareness:** {{discovery_process}}
           2. **Consideration:** {{evaluation_criteria}}
           3. **Purchase:** {{decision_triggers}}
@@ -3322,7 +3322,7 @@ sections:
         title: Competitor Prioritization Matrix
         instruction: |
           Help categorize competitors by market share and strategic threat level
-          
+
           Create a 2x2 matrix:
           - Priority 1 (Core Competitors): High Market Share + High Threat
           - Priority 2 (Emerging Threats): Low Market Share + High Threat
@@ -3387,7 +3387,14 @@ sections:
         title: Feature Comparison Matrix
         instruction: Create a detailed comparison table of key features across competitors
         type: table
-        columns: ["Feature Category", "{{your_company}}", "{{competitor_1}}", "{{competitor_2}}", "{{competitor_3}}"]
+        columns:
+          [
+            "Feature Category",
+            "{{your_company}}",
+            "{{competitor_1}}",
+            "{{competitor_2}}",
+            "{{competitor_3}}",
+          ]
         rows:
           - category: "Core Functionality"
             items:
@@ -3399,7 +3406,13 @@ sections:
               - ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
           - category: "Integration & Ecosystem"
             items:
-              - ["API Availability", "{{availability}}", "{{availability}}", "{{availability}}", "{{availability}}"]
+              - [
+                  "API Availability",
+                  "{{availability}}",
+                  "{{availability}}",
+                  "{{availability}}",
+                  "{{availability}}",
+                ]
               - ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
           - category: "Pricing & Plans"
             items:
@@ -3426,7 +3439,7 @@ sections:
         title: Positioning Map
         instruction: |
           Describe competitor positions on key dimensions
-          
+
           Create a positioning description using 2 key dimensions relevant to the market, such as:
           - Price vs. Features
           - Ease of Use vs. Power
@@ -3461,7 +3474,7 @@ sections:
         title: Blue Ocean Opportunities
         instruction: |
           Identify uncontested market spaces
-          
+
           List opportunities to create new market space:
           - Underserved segments
           - Unaddressed use cases
@@ -3565,11 +3578,11 @@ sections:
       - id: summary-details
         template: |
           **Topic:** {{session_topic}}
-          
+
           **Session Goals:** {{stated_goals}}
-          
+
           **Techniques Used:** {{techniques_list}}
-          
+
           **Total Ideas Generated:** {{total_ideas}}
       - id: key-themes
         title: "Key Themes Identified:"
@@ -3694,7 +3707,7 @@ sections:
   - id: footer
     content: |
       ---
-      
+
       *Session facilitated using the BMAD-METHOD brainstorming framework*
 ==================== END: .bmad-core/templates/brainstorming-output-tmpl.yaml ====================
 
@@ -3849,20 +3862,20 @@ sections:
       - id: intro-content
         content: |
           This document outlines the overall project architecture for {{project_name}}, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies.
-          
+
           **Relationship to Frontend Architecture:**
           If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components.
       - id: starter-template
         title: Starter Template or Existing Project
         instruction: |
           Before proceeding further with architecture design, check if the project is based on a starter template or existing codebase:
-          
+
           1. Review the PRD and brainstorming brief for any mentions of:
           - Starter templates (e.g., Create React App, Next.js, Vue CLI, Angular CLI, etc.)
           - Existing projects or codebases being used as a foundation
           - Boilerplate projects or scaffolding tools
           - Previous projects to be cloned or adapted
-          
+
           2. If a starter template or existing project is mentioned:
           - Ask the user to provide access via one of these methods:
             - Link to the starter template documentation
@@ -3875,16 +3888,16 @@ sections:
             - Existing architectural patterns and conventions
             - Any limitations or constraints imposed by the starter
           - Use this analysis to inform and align your architecture decisions
-          
+
           3. If no starter template is mentioned but this is a greenfield project:
           - Suggest appropriate starter templates based on the tech stack preferences
           - Explain the benefits (faster setup, best practices, community support)
           - Let the user decide whether to use one
-          
+
           4. If the user confirms no starter template will be used:
           - Proceed with architecture design from scratch
           - Note that manual setup will be required for all tooling and configuration
-          
+
           Document the decision here before proceeding with the architecture design. If none, just say N/A
         elicit: true
       - id: changelog
@@ -3912,7 +3925,7 @@ sections:
         title: High Level Overview
         instruction: |
           Based on the PRD's Technical Assumptions section, describe:
-          
+
           1. The main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven)
           2. Repository structure decision from PRD (Monorepo/Polyrepo)
           3. Service architecture decision from PRD
@@ -3929,17 +3942,17 @@ sections:
           - Data flow directions
           - External integrations
           - User entry points
-          
+
       - id: architectural-patterns
         title: Architectural and Design Patterns
         instruction: |
           List the key high-level patterns that will guide the architecture. For each pattern:
-          
+
           1. Present 2-3 viable options if multiple exist
           2. Provide your recommendation with clear rationale
           3. Get user confirmation before finalizing
           4. These patterns should align with the PRD's technical assumptions and project goals
-          
+
           Common patterns to consider:
           - Architectural style patterns (Serverless, Event-Driven, Microservices, CQRS, Hexagonal)
           - Code organization patterns (Dependency Injection, Repository, Module, Factory)
@@ -3955,23 +3968,23 @@ sections:
     title: Tech Stack
     instruction: |
       This is the DEFINITIVE technology selection section. Work with the user to make specific choices:
-      
+
       1. Review PRD technical assumptions and any preferences from .bmad-core/data/technical-preferences.yaml or an attached technical-preferences
       2. For each category, present 2-3 viable options with pros/cons
       3. Make a clear recommendation based on project needs
       4. Get explicit user approval for each selection
       5. Document exact versions (avoid "latest" - pin specific versions)
       6. This table is the single source of truth - all other docs must reference these choices
-      
+
       Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about - let the user know if they are not sure on any that you can also provide suggestions with rationale:
-      
+
       - Starter templates (if any)
       - Languages and runtimes with exact versions
       - Frameworks and libraries / packages
       - Cloud provider and key services choices
       - Database and storage solutions - if unclear suggest sql or nosql or other types depending on the project and depending on cloud provider offer a suggestion
       - Development tools
-      
+
       Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback - this statement and the options should be rendered and then prompt right all before allowing user input.
     elicit: true
     sections:
@@ -3995,13 +4008,13 @@ sections:
     title: Data Models
     instruction: |
       Define the core data models/entities:
-      
+
       1. Review PRD requirements and identify key business entities
       2. For each model, explain its purpose and relationships
       3. Include key attributes and data types
       4. Show relationships between models
       5. Discuss design decisions with user
-      
+
       Create a clear conceptual model before moving to database schema.
     elicit: true
     repeatable: true
@@ -4010,11 +4023,11 @@ sections:
         title: "{{model_name}}"
         template: |
           **Purpose:** {{model_purpose}}
-          
+
           **Key Attributes:**
           - {{attribute_1}}: {{type_1}} - {{description_1}}
           - {{attribute_2}}: {{type_2}} - {{description_2}}
-          
+
           **Relationships:**
           - {{relationship_1}}
           - {{relationship_2}}
@@ -4023,7 +4036,7 @@ sections:
     title: Components
     instruction: |
       Based on the architectural patterns, tech stack, and data models from above:
-      
+
       1. Identify major logical components/services and their responsibilities
       2. Consider the repository structure (monorepo/polyrepo) from PRD
       3. Define clear boundaries and interfaces between components
@@ -4032,7 +4045,7 @@ sections:
       - Key interfaces/APIs exposed
       - Dependencies on other components
       - Technology specifics based on tech stack choices
-      
+
       5. Create component diagrams where helpful
     elicit: true
     sections:
@@ -4041,13 +4054,13 @@ sections:
         title: "{{component_name}}"
         template: |
           **Responsibility:** {{component_description}}
-          
+
           **Key Interfaces:**
           - {{interface_1}}
           - {{interface_2}}
-          
+
           **Dependencies:** {{dependencies}}
-          
+
           **Technology Stack:** {{component_tech_details}}
       - id: component-diagrams
         title: Component Diagrams
@@ -4064,13 +4077,13 @@ sections:
     condition: Project requires external API integrations
     instruction: |
       For each external service integration:
-      
+
       1. Identify APIs needed based on PRD requirements and component design
       2. If documentation URLs are unknown, ask user for specifics
       3. Document authentication methods and security considerations
       4. List specific endpoints that will be used
       5. Note any rate limits or usage constraints
-      
+
       If no external APIs are needed, state this explicitly and skip to next section.
     elicit: true
     repeatable: true
@@ -4083,10 +4096,10 @@ sections:
           - **Base URL(s):** {{api_base_url}}
           - **Authentication:** {{auth_method}}
           - **Rate Limits:** {{rate_limits}}
-          
+
           **Key Endpoints Used:**
           - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
-          
+
           **Integration Notes:** {{integration_considerations}}
 
   - id: core-workflows
@@ -4095,13 +4108,13 @@ sections:
     mermaid_type: sequence
     instruction: |
       Illustrate key system workflows using sequence diagrams:
-      
+
       1. Identify critical user journeys from PRD
       2. Show component interactions including external APIs
       3. Include error handling paths
       4. Document async operations
       5. Create both high-level and detailed diagrams as needed
-      
+
       Focus on workflows that clarify architecture decisions or complex interactions.
     elicit: true
 
@@ -4112,13 +4125,13 @@ sections:
     language: yaml
     instruction: |
       If the project includes a REST API:
-      
+
       1. Create an OpenAPI 3.0 specification
       2. Include all endpoints from epics/stories
       3. Define request/response schemas based on data models
       4. Document authentication requirements
       5. Include example requests/responses
-      
+
       Use YAML format for better readability. If no REST API, skip this section.
     elicit: true
     template: |
@@ -4135,13 +4148,13 @@ sections:
     title: Database Schema
     instruction: |
       Transform the conceptual data models into concrete database schemas:
-      
+
       1. Use the database type(s) selected in Tech Stack
       2. Create schema definitions using appropriate notation
       3. Include indexes, constraints, and relationships
       4. Consider performance and scalability
       5. For NoSQL, show document structures
-      
+
       Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
     elicit: true
 
@@ -4151,14 +4164,14 @@ sections:
     language: plaintext
     instruction: |
       Create a project folder structure that reflects:
-      
+
       1. The chosen repository structure (monorepo/polyrepo)
       2. The service architecture (monolith/microservices/serverless)
       3. The selected tech stack and languages
       4. Component organization from above
       5. Best practices for the chosen frameworks
       6. Clear separation of concerns
-      
+
       Adapt the structure based on project needs. For monorepos, show service separation. For serverless, show function organization. Include language-specific conventions.
     elicit: true
     examples:
@@ -4176,13 +4189,13 @@ sections:
     title: Infrastructure and Deployment
     instruction: |
       Define the deployment architecture and practices:
-      
+
       1. Use IaC tool selected in Tech Stack
       2. Choose deployment strategy appropriate for the architecture
       3. Define environments and promotion flow
       4. Establish rollback procedures
       5. Consider security, monitoring, and cost optimization
-      
+
       Get user input on deployment preferences and CI/CD tool choices.
     elicit: true
     sections:
@@ -4218,13 +4231,13 @@ sections:
     title: Error Handling Strategy
     instruction: |
       Define comprehensive error handling approach:
-      
+
       1. Choose appropriate patterns for the language/framework from Tech Stack
       2. Define logging standards and tools
       3. Establish error categories and handling rules
       4. Consider observability and debugging needs
       5. Ensure security (no sensitive data in logs)
-      
+
       This section guides both AI and human developers in consistent error handling.
     elicit: true
     sections:
@@ -4271,13 +4284,13 @@ sections:
     title: Coding Standards
     instruction: |
       These standards are MANDATORY for AI agents. Work with user to define ONLY the critical rules needed to prevent bad code. Explain that:
-      
+
       1. This section directly controls AI developer behavior
       2. Keep it minimal - assume AI knows general best practices
       3. Focus on project-specific conventions and gotchas
       4. Overly detailed standards bloat context and slow development
       5. Standards will be extracted to separate file for dev agent use
-      
+
       For each standard, get explicit user confirmation it's necessary.
     elicit: true
     sections:
@@ -4299,7 +4312,7 @@ sections:
           - "Never use console.log in production code - use logger"
           - "All API responses must use ApiResponse wrapper type"
           - "Database queries must use repository pattern, never direct ORM"
-          
+
           Avoid obvious rules like "use SOLID principles" or "write clean code"
         repeatable: true
         template: "- **{{rule_name}}:** {{rule_description}}"
@@ -4317,14 +4330,14 @@ sections:
     title: Test Strategy and Standards
     instruction: |
       Work with user to define comprehensive test strategy:
-      
+
       1. Use test frameworks from Tech Stack
       2. Decide on TDD vs test-after approach
       3. Define test organization and naming
       4. Establish coverage goals
       5. Determine integration test infrastructure
       6. Plan for test data and external dependencies
-      
+
       Note: Basic info goes in Coding Standards for dev agent. This detailed section is for QA agent and team reference.
     elicit: true
     sections:
@@ -4345,7 +4358,7 @@ sections:
               - **Location:** {{unit_test_location}}
               - **Mocking Library:** {{mocking_library}}
               - **Coverage Requirement:** {{unit_coverage}}
-              
+
               **AI Agent Requirements:**
               - Generate tests for all public methods
               - Cover edge cases and error conditions
@@ -4387,7 +4400,7 @@ sections:
     title: Security
     instruction: |
       Define MANDATORY security requirements for AI and human developers:
-      
+
       1. Focus on implementation-specific rules
       2. Reference security tools from Tech Stack
       3. Define clear patterns for common scenarios
@@ -4456,16 +4469,16 @@ sections:
     title: Next Steps
     instruction: |
       After completing the architecture:
-      
+
       1. If project has UI components:
       - Use "Frontend Architecture Mode"
       - Provide this document as input
-      
+
       2. For all projects:
       - Review with Product Owner
       - Begin story implementation with Dev agent
       - Set up infrastructure with DevOps agent
-      
+
       3. Include specific prompts for next agents if needed
     sections:
       - id: architect-prompt
@@ -4498,16 +4511,16 @@ sections:
     title: Template and Framework Selection
     instruction: |
       Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided.
-      
+
       Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase:
-      
+
       1. Review the PRD, main architecture document, and brainstorming brief for mentions of:
          - Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.)
          - UI kit or component library starters
          - Existing frontend projects being used as a foundation
          - Admin dashboard templates or other specialized starters
          - Design system implementations
-      
+
       2. If a frontend starter template or existing project is mentioned:
          - Ask the user to provide access via one of these methods:
            - Link to the starter template documentation
@@ -4523,7 +4536,7 @@ sections:
            - Testing setup and patterns
            - Build and development scripts
          - Use this analysis to ensure your frontend architecture aligns with the starter's patterns
-      
+
       3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is:
          - Based on the framework choice, suggest appropriate starters:
            - React: Create React App, Next.js, Vite + React
@@ -4531,11 +4544,11 @@ sections:
            - Angular: Angular CLI
            - Or suggest popular UI templates if applicable
          - Explain benefits specific to frontend development
-      
+
       4. If the user confirms no starter template will be used:
          - Note that all tooling, bundling, and configuration will need manual setup
          - Proceed with frontend architecture from scratch
-      
+
       Document the starter template decision and any constraints it imposes before proceeding.
     sections:
       - id: changelog
@@ -4557,12 +4570,24 @@ sections:
         rows:
           - ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - ["UI Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["State Management", "{{state_management}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - [
+              "State Management",
+              "{{state_management}}",
+              "{{version}}",
+              "{{purpose}}",
+              "{{why_chosen}}",
+            ]
           - ["Routing", "{{routing_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - ["Styling", "{{styling_solution}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - ["Testing", "{{test_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Component Library", "{{component_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - [
+              "Component Library",
+              "{{component_lib}}",
+              "{{version}}",
+              "{{purpose}}",
+              "{{why_chosen}}",
+            ]
           - ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
@@ -4710,33 +4735,33 @@ sections:
     elicit: true
     content: |
       This document outlines the complete fullstack architecture for {{project_name}}, including backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack.
-      
+
       This unified approach combines what would traditionally be separate backend and frontend architecture documents, streamlining the development process for modern fullstack applications where these concerns are increasingly intertwined.
     sections:
       - id: starter-template
         title: Starter Template or Existing Project
         instruction: |
           Before proceeding with architecture design, check if the project is based on any starter templates or existing codebases:
-          
+
           1. Review the PRD and other documents for mentions of:
           - Fullstack starter templates (e.g., T3 Stack, MEAN/MERN starters, Django + React templates)
           - Monorepo templates (e.g., Nx, Turborepo starters)
           - Platform-specific starters (e.g., Vercel templates, AWS Amplify starters)
           - Existing projects being extended or cloned
-          
+
           2. If starter templates or existing projects are mentioned:
           - Ask the user to provide access (links, repos, or files)
           - Analyze to understand pre-configured choices and constraints
           - Note any architectural decisions already made
           - Identify what can be modified vs what must be retained
-          
+
           3. If no starter is mentioned but this is greenfield:
           - Suggest appropriate fullstack starters based on tech preferences
           - Consider platform-specific options (Vercel, AWS, etc.)
           - Let user decide whether to use one
-          
+
           4. Document the decision and any constraints it imposes
-          
+
           If none, state "N/A - Greenfield project"
       - id: changelog
         title: Change Log
@@ -4762,17 +4787,17 @@ sections:
         title: Platform and Infrastructure Choice
         instruction: |
           Based on PRD requirements and technical assumptions, make a platform recommendation:
-          
+
           1. Consider common patterns (not an exhaustive list, use your own best judgement and search the web as needed for emerging trends):
           - **Vercel + Supabase**: For rapid development with Next.js, built-in auth/storage
           - **AWS Full Stack**: For enterprise scale with Lambda, API Gateway, S3, Cognito
           - **Azure**: For .NET ecosystems or enterprise Microsoft environments
           - **Google Cloud**: For ML/AI heavy applications or Google ecosystem integration
-          
+
           2. Present 2-3 viable options with clear pros/cons
           3. Make a recommendation with rationale
           4. Get explicit user confirmation
-          
+
           Document the choice and key services that will be used.
         template: |
           **Platform:** {{selected_platform}}
@@ -4782,7 +4807,7 @@ sections:
         title: Repository Structure
         instruction: |
           Define the repository approach based on PRD requirements and platform choice, explain your rationale or ask questions to the user if unsure:
-          
+
           1. For modern fullstack apps, monorepo is often preferred
           2. Consider tooling (Nx, Turborepo, Lerna, npm workspaces)
           3. Define package/app boundaries
@@ -4804,7 +4829,7 @@ sections:
           - Databases and storage
           - External integrations
           - CDN and caching layers
-          
+
           Use appropriate diagram type for clarity.
       - id: architectural-patterns
         title: Architectural Patterns
@@ -4814,7 +4839,7 @@ sections:
           - Frontend patterns (e.g., Component-based, State management)
           - Backend patterns (e.g., Repository, CQRS, Event-driven)
           - Integration patterns (e.g., BFF, API Gateway)
-          
+
           For each pattern, provide recommendation and rationale.
         repeatable: true
         template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}"
@@ -4828,7 +4853,7 @@ sections:
     title: Tech Stack
     instruction: |
       This is the DEFINITIVE technology selection for the entire project. Work with user to finalize all choices. This table is the single source of truth - all development must use these exact versions.
-      
+
       Key areas to cover:
       - Frontend and backend languages/frameworks
       - Databases and caching
@@ -4837,7 +4862,7 @@ sections:
       - Testing tools for both frontend and backend
       - Build and deployment tools
       - Monitoring and logging
-      
+
       Upon render, elicit feedback immediately.
     elicit: true
     sections:
@@ -4847,11 +4872,29 @@ sections:
         columns: [Category, Technology, Version, Purpose, Rationale]
         rows:
           - ["Frontend Language", "{{fe_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Frontend Framework", "{{fe_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["UI Component Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - [
+              "Frontend Framework",
+              "{{fe_framework}}",
+              "{{version}}",
+              "{{purpose}}",
+              "{{why_chosen}}",
+            ]
+          - [
+              "UI Component Library",
+              "{{ui_library}}",
+              "{{version}}",
+              "{{purpose}}",
+              "{{why_chosen}}",
+            ]
           - ["State Management", "{{state_mgmt}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - ["Backend Language", "{{be_language}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Backend Framework", "{{be_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - [
+              "Backend Framework",
+              "{{be_framework}}",
+              "{{version}}",
+              "{{purpose}}",
+              "{{why_chosen}}",
+            ]
           - ["API Style", "{{api_style}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - ["Database", "{{database}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - ["Cache", "{{cache}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
@@ -4872,14 +4915,14 @@ sections:
     title: Data Models
     instruction: |
       Define the core data models/entities that will be shared between frontend and backend:
-      
+
       1. Review PRD requirements and identify key business entities
       2. For each model, explain its purpose and relationships
       3. Include key attributes and data types
       4. Show relationships between models
       5. Create TypeScript interfaces that can be shared
       6. Discuss design decisions with user
-      
+
       Create a clear conceptual model before moving to database schema.
     elicit: true
     repeatable: true
@@ -4888,7 +4931,7 @@ sections:
         title: "{{model_name}}"
         template: |
           **Purpose:** {{model_purpose}}
-          
+
           **Key Attributes:**
           - {{attribute_1}}: {{type_1}} - {{description_1}}
           - {{attribute_2}}: {{type_2}} - {{description_2}}
@@ -4907,7 +4950,7 @@ sections:
     title: API Specification
     instruction: |
       Based on the chosen API style from Tech Stack:
-      
+
       1. If REST API, create an OpenAPI 3.0 specification
       2. If GraphQL, provide the GraphQL schema
       3. If tRPC, show router definitions
@@ -4915,7 +4958,7 @@ sections:
       5. Define request/response schemas based on data models
       6. Document authentication requirements
       7. Include example requests/responses
-      
+
       Use appropriate format for the chosen API style. If no API (e.g., static site), skip this section.
     elicit: true
     sections:
@@ -4950,7 +4993,7 @@ sections:
     title: Components
     instruction: |
       Based on the architectural patterns, tech stack, and data models from above:
-      
+
       1. Identify major logical components/services across the fullstack
       2. Consider both frontend and backend components
       3. Define clear boundaries and interfaces between components
@@ -4959,7 +5002,7 @@ sections:
       - Key interfaces/APIs exposed
       - Dependencies on other components
       - Technology specifics based on tech stack choices
-      
+
       5. Create component diagrams where helpful
     elicit: true
     sections:
@@ -4968,13 +5011,13 @@ sections:
         title: "{{component_name}}"
         template: |
           **Responsibility:** {{component_description}}
-          
+
           **Key Interfaces:**
           - {{interface_1}}
           - {{interface_2}}
-          
+
           **Dependencies:** {{dependencies}}
-          
+
           **Technology Stack:** {{component_tech_details}}
       - id: component-diagrams
         title: Component Diagrams
@@ -4991,13 +5034,13 @@ sections:
     condition: Project requires external API integrations
     instruction: |
       For each external service integration:
-      
+
       1. Identify APIs needed based on PRD requirements and component design
       2. If documentation URLs are unknown, ask user for specifics
       3. Document authentication methods and security considerations
       4. List specific endpoints that will be used
       5. Note any rate limits or usage constraints
-      
+
       If no external APIs are needed, state this explicitly and skip to next section.
     elicit: true
     repeatable: true
@@ -5010,10 +5053,10 @@ sections:
           - **Base URL(s):** {{api_base_url}}
           - **Authentication:** {{auth_method}}
           - **Rate Limits:** {{rate_limits}}
-          
+
           **Key Endpoints Used:**
           - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
-          
+
           **Integration Notes:** {{integration_considerations}}
 
   - id: core-workflows
@@ -5022,14 +5065,14 @@ sections:
     mermaid_type: sequence
     instruction: |
       Illustrate key system workflows using sequence diagrams:
-      
+
       1. Identify critical user journeys from PRD
       2. Show component interactions including external APIs
       3. Include both frontend and backend flows
       4. Include error handling paths
       5. Document async operations
       6. Create both high-level and detailed diagrams as needed
-      
+
       Focus on workflows that clarify architecture decisions or complex interactions.
     elicit: true
 
@@ -5037,13 +5080,13 @@ sections:
     title: Database Schema
     instruction: |
       Transform the conceptual data models into concrete database schemas:
-      
+
       1. Use the database type(s) selected in Tech Stack
       2. Create schema definitions using appropriate notation
       3. Include indexes, constraints, and relationships
       4. Consider performance and scalability
       5. For NoSQL, show document structures
-      
+
       Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
     elicit: true
 
@@ -5179,60 +5222,60 @@ sections:
     type: code
     language: plaintext
     examples:
-    - |
-      {{project-name}}/
-      ├── .github/                    # CI/CD workflows
-      │   └── workflows/
-      │       ├── ci.yaml
-      │       └── deploy.yaml
-      ├── apps/                       # Application packages
-      │   ├── web/                    # Frontend application
-      │   │   ├── src/
-      │   │   │   ├── components/     # UI components
-      │   │   │   ├── pages/          # Page components/routes
-      │   │   │   ├── hooks/          # Custom React hooks
-      │   │   │   ├── services/       # API client services
-      │   │   │   ├── stores/         # State management
-      │   │   │   ├── styles/         # Global styles/themes
-      │   │   │   └── utils/          # Frontend utilities
-      │   │   ├── public/             # Static assets
-      │   │   ├── tests/              # Frontend tests
-      │   │   └── package.json
-      │   └── api/                    # Backend application
-      │       ├── src/
-      │       │   ├── routes/         # API routes/controllers
-      │       │   ├── services/       # Business logic
-      │       │   ├── models/         # Data models
-      │       │   ├── middleware/     # Express/API middleware
-      │       │   ├── utils/          # Backend utilities
-      │       │   └── {{serverless_or_server_entry}}
-      │       ├── tests/              # Backend tests
-      │       └── package.json
-      ├── packages/                   # Shared packages
-      │   ├── shared/                 # Shared types/utilities
-      │   │   ├── src/
-      │   │   │   ├── types/          # TypeScript interfaces
-      │   │   │   ├── constants/      # Shared constants
-      │   │   │   └── utils/          # Shared utilities
-      │   │   └── package.json
-      │   ├── ui/                     # Shared UI components
-      │   │   ├── src/
-      │   │   └── package.json
-      │   └── config/                 # Shared configuration
-      │       ├── eslint/
-      │       ├── typescript/
-      │       └── jest/
-      ├── infrastructure/             # IaC definitions
-      │   └── {{iac_structure}}
-      ├── scripts/                    # Build/deploy scripts
-      ├── docs/                       # Documentation
-      │   ├── prd.md
-      │   ├── front-end-spec.md
-      │   └── fullstack-architecture.md
-      ├── .env.example                # Environment template
-      ├── package.json                # Root package.json
-      ├── {{monorepo_config}}         # Monorepo configuration
-      └── README.md
+      - |
+        {{project-name}}/
+        ├── .github/                    # CI/CD workflows
+        │   └── workflows/
+        │       ├── ci.yaml
+        │       └── deploy.yaml
+        ├── apps/                       # Application packages
+        │   ├── web/                    # Frontend application
+        │   │   ├── src/
+        │   │   │   ├── components/     # UI components
+        │   │   │   ├── pages/          # Page components/routes
+        │   │   │   ├── hooks/          # Custom React hooks
+        │   │   │   ├── services/       # API client services
+        │   │   │   ├── stores/         # State management
+        │   │   │   ├── styles/         # Global styles/themes
+        │   │   │   └── utils/          # Frontend utilities
+        │   │   ├── public/             # Static assets
+        │   │   ├── tests/              # Frontend tests
+        │   │   └── package.json
+        │   └── api/                    # Backend application
+        │       ├── src/
+        │       │   ├── routes/         # API routes/controllers
+        │       │   ├── services/       # Business logic
+        │       │   ├── models/         # Data models
+        │       │   ├── middleware/     # Express/API middleware
+        │       │   ├── utils/          # Backend utilities
+        │       │   └── {{serverless_or_server_entry}}
+        │       ├── tests/              # Backend tests
+        │       └── package.json
+        ├── packages/                   # Shared packages
+        │   ├── shared/                 # Shared types/utilities
+        │   │   ├── src/
+        │   │   │   ├── types/          # TypeScript interfaces
+        │   │   │   ├── constants/      # Shared constants
+        │   │   │   └── utils/          # Shared utilities
+        │   │   └── package.json
+        │   ├── ui/                     # Shared UI components
+        │   │   ├── src/
+        │   │   └── package.json
+        │   └── config/                 # Shared configuration
+        │       ├── eslint/
+        │       ├── typescript/
+        │       └── jest/
+        ├── infrastructure/             # IaC definitions
+        │   └── {{iac_structure}}
+        ├── scripts/                    # Build/deploy scripts
+        ├── docs/                       # Documentation
+        │   ├── prd.md
+        │   ├── front-end-spec.md
+        │   └── fullstack-architecture.md
+        ├── .env.example                # Environment template
+        ├── package.json                # Root package.json
+        ├── {{monorepo_config}}         # Monorepo configuration
+        └── README.md
 
   - id: development-workflow
     title: Development Workflow
@@ -5259,13 +5302,13 @@ sections:
             template: |
               # Start all services
               {{start_all_command}}
-              
+
               # Start frontend only
               {{start_frontend_command}}
-              
+
               # Start backend only
               {{start_backend_command}}
-              
+
               # Run tests
               {{test_commands}}
       - id: environment-config
@@ -5278,10 +5321,10 @@ sections:
             template: |
               # Frontend (.env.local)
               {{frontend_env_vars}}
-              
+
               # Backend (.env)
               {{backend_env_vars}}
-              
+
               # Shared
               {{shared_env_vars}}
 
@@ -5298,7 +5341,7 @@ sections:
           - **Build Command:** {{frontend_build_command}}
           - **Output Directory:** {{frontend_output_dir}}
           - **CDN/Edge:** {{cdn_strategy}}
-          
+
           **Backend Deployment:**
           - **Platform:** {{backend_deploy_platform}}
           - **Build Command:** {{backend_build_command}}
@@ -5329,12 +5372,12 @@ sections:
           - CSP Headers: {{csp_policy}}
           - XSS Prevention: {{xss_strategy}}
           - Secure Storage: {{storage_strategy}}
-          
+
           **Backend Security:**
           - Input Validation: {{validation_approach}}
           - Rate Limiting: {{rate_limit_config}}
           - CORS Policy: {{cors_config}}
-          
+
           **Authentication Security:**
           - Token Storage: {{token_strategy}}
           - Session Management: {{session_approach}}
@@ -5346,7 +5389,7 @@ sections:
           - Bundle Size Target: {{bundle_size}}
           - Loading Strategy: {{loading_approach}}
           - Caching Strategy: {{fe_cache_strategy}}
-          
+
           **Backend Performance:**
           - Response Time Target: {{response_target}}
           - Database Optimization: {{db_optimization}}
@@ -5362,10 +5405,10 @@ sections:
         type: code
         language: text
         template: |
-                  E2E Tests
-                 /        \
-            Integration Tests
-               /            \
+          E2E Tests
+          /        \
+          Integration Tests
+          /            \
           Frontend Unit  Backend Unit
       - id: test-organization
         title: Test Organization
@@ -5484,7 +5527,7 @@ sections:
           - JavaScript errors
           - API response times
           - User interactions
-          
+
           **Backend Metrics:**
           - Request rate
           - Error rate
@@ -5515,40 +5558,40 @@ sections:
     title: Introduction
     instruction: |
       IMPORTANT - SCOPE AND ASSESSMENT REQUIRED:
-      
+
       This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding:
-      
+
       1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead."
-      
+
       2. **REQUIRED INPUTS**:
          - Completed brownfield-prd.md
          - Existing project technical documentation (from docs folder or user-provided)
          - Access to existing project structure (IDE or uploaded files)
-      
+
       3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions.
-      
+
       4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?"
-      
+
       If any required inputs are missing, request them before proceeding.
     elicit: true
     sections:
       - id: intro-content
         content: |
           This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system.
-          
+
           **Relationship to Existing Architecture:**
           This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements.
       - id: existing-project-analysis
         title: Existing Project Analysis
         instruction: |
           Analyze the existing project structure and architecture:
-          
+
           1. Review existing documentation in docs folder
           2. Examine current technology stack and versions
           3. Identify existing architectural patterns and conventions
           4. Note current deployment and infrastructure setup
           5. Document any constraints or limitations
-          
+
           CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations."
         elicit: true
         sections:
@@ -5577,12 +5620,12 @@ sections:
     title: Enhancement Scope and Integration Strategy
     instruction: |
       Define how the enhancement will integrate with the existing system:
-      
+
       1. Review the brownfield PRD enhancement scope
       2. Identify integration points with existing code
       3. Define boundaries between new and existing functionality
       4. Establish compatibility requirements
-      
+
       VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?"
     elicit: true
     sections:
@@ -5611,7 +5654,7 @@ sections:
     title: Tech Stack Alignment
     instruction: |
       Ensure new components align with existing technology choices:
-      
+
       1. Use existing technology stack as the foundation
       2. Only introduce new technologies if absolutely necessary
       3. Justify any new additions with clear rationale
@@ -5634,7 +5677,7 @@ sections:
     title: Data Models and Schema Changes
     instruction: |
       Define new data models and how they integrate with existing schema:
-      
+
       1. Identify new entities required for the enhancement
       2. Define relationships with existing data models
       3. Plan database schema changes (additions, modifications)
@@ -5650,11 +5693,11 @@ sections:
             template: |
               **Purpose:** {{model_purpose}}
               **Integration:** {{integration_with_existing}}
-              
+
               **Key Attributes:**
               - {{attribute_1}}: {{type_1}} - {{description_1}}
               - {{attribute_2}}: {{type_2}} - {{description_2}}
-              
+
               **Relationships:**
               - **With Existing:** {{existing_relationships}}
               - **With New:** {{new_relationships}}
@@ -5666,7 +5709,7 @@ sections:
           - **Modified Tables:** {{modified_tables_list}}
           - **New Indexes:** {{new_indexes_list}}
           - **Migration Strategy:** {{migration_approach}}
-          
+
           **Backward Compatibility:**
           - {{compatibility_measure_1}}
           - {{compatibility_measure_2}}
@@ -5675,12 +5718,12 @@ sections:
     title: Component Architecture
     instruction: |
       Define new components and their integration with existing architecture:
-      
+
       1. Identify new components required for the enhancement
       2. Define interfaces with existing components
       3. Establish clear boundaries and responsibilities
       4. Plan integration points and data flow
-      
+
       MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?"
     elicit: true
     sections:
@@ -5693,15 +5736,15 @@ sections:
             template: |
               **Responsibility:** {{component_description}}
               **Integration Points:** {{integration_points}}
-              
+
               **Key Interfaces:**
               - {{interface_1}}
               - {{interface_2}}
-              
+
               **Dependencies:**
               - **Existing Components:** {{existing_dependencies}}
               - **New Components:** {{new_dependencies}}
-              
+
               **Technology Stack:** {{component_tech_details}}
       - id: interaction-diagram
         title: Component Interaction Diagram
@@ -5714,7 +5757,7 @@ sections:
     condition: Enhancement requires API changes
     instruction: |
       Define new API endpoints and integration with existing APIs:
-      
+
       1. Plan new API endpoints required for the enhancement
       2. Ensure consistency with existing API patterns
       3. Define authentication and authorization integration
@@ -5764,17 +5807,17 @@ sections:
           - **Base URL:** {{api_base_url}}
           - **Authentication:** {{auth_method}}
           - **Integration Method:** {{integration_approach}}
-          
+
           **Key Endpoints Used:**
           - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
-          
+
           **Error Handling:** {{error_handling_strategy}}
 
   - id: source-tree-integration
     title: Source Tree Integration
     instruction: |
       Define how new code will integrate with existing project structure:
-      
+
       1. Follow existing project organization patterns
       2. Identify where new files/folders will be placed
       3. Ensure consistency with existing naming conventions
@@ -5813,7 +5856,7 @@ sections:
     title: Infrastructure and Deployment Integration
     instruction: |
       Define how the enhancement will be deployed alongside existing infrastructure:
-      
+
       1. Use existing deployment pipeline and infrastructure
       2. Identify any infrastructure changes needed
       3. Plan deployment strategy to minimize risk
@@ -5843,7 +5886,7 @@ sections:
     title: Coding Standards and Conventions
     instruction: |
       Ensure new code follows existing project conventions:
-      
+
       1. Document existing coding standards from project analysis
       2. Identify any enhancement-specific requirements
       3. Ensure consistency with existing codebase patterns
@@ -5874,7 +5917,7 @@ sections:
     title: Testing Strategy
     instruction: |
       Define testing approach for the enhancement:
-      
+
       1. Integrate with existing test suite
       2. Ensure existing functionality remains intact
       3. Plan for testing new features
@@ -5914,7 +5957,7 @@ sections:
     title: Security Integration
     instruction: |
       Ensure security consistency with existing system:
-      
+
       1. Follow existing security patterns and tools
       2. Ensure new features don't introduce vulnerabilities
       3. Maintain existing security posture
@@ -5949,7 +5992,7 @@ sections:
     title: Next Steps
     instruction: |
       After completing the brownfield architecture:
-      
+
       1. Review integration points with existing system
       2. Begin story implementation with Dev agent
       3. Set up deployment pipeline integration
@@ -7289,7 +7332,7 @@ sections:
     condition: PRD has UX/UI requirements
     instruction: |
       Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps:
-      
+
       1. Pre-fill all subsections with educated guesses based on project context
       2. Present the complete rendered section to user
       3. Clearly let the user know where assumptions were made
@@ -7331,7 +7374,7 @@ sections:
     title: Technical Assumptions
     instruction: |
       Gather technical decisions that will guide the Architect. Steps:
-      
+
       1. Check if .bmad-core/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices
       2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
       3. For unknowns, offer guidance based on project goals and MVP scope
@@ -7359,9 +7402,9 @@ sections:
     title: Epic List
     instruction: |
       Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
-      
+
       CRITICAL: Epics MUST be logically sequential following agile best practices:
-      
+
       - Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
       - Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic!
       - Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
@@ -7380,11 +7423,11 @@ sections:
     repeatable: true
     instruction: |
       After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
-      
+
       For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
-      
+
       CRITICAL STORY SEQUENCING REQUIREMENTS:
-      
+
       - Stories within each epic MUST be logically sequential
       - Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation
       - No story should depend on work from a later story or epic
@@ -7412,7 +7455,7 @@ sections:
             repeatable: true
             instruction: |
               Define clear, comprehensive, and testable acceptance criteria that:
-              
+
               - Precisely define what "done" means from a functional perspective
               - Are unambiguous and serve as basis for verification
               - Include any critical non-functional requirements from the PRD
@@ -7454,19 +7497,19 @@ sections:
     title: Intro Project Analysis and Context
     instruction: |
       IMPORTANT - SCOPE ASSESSMENT REQUIRED:
-      
+
       This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
-      
+
       1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories."
-      
+
       2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first.
-      
+
       3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions.
-      
+
       Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
-      
+
       CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?"
-      
+
       Do not proceed with any recommendations until the user has validated your understanding of the existing system.
     sections:
       - id: existing-project-overview
@@ -7492,7 +7535,7 @@ sections:
           - Note: "Document-project analysis available - using existing technical documentation"
           - List key documents created by document-project
           - Skip the missing documentation check below
-          
+
           Otherwise, check for existing documentation:
         sections:
           - id: available-docs
@@ -7616,7 +7659,7 @@ sections:
           If document-project output available:
           - Extract from "Actual Tech Stack" table in High Level Architecture section
           - Include version numbers and any noted constraints
-          
+
           Otherwise, document the current technology stack:
         template: |
           **Languages**: {{languages}}
@@ -7655,7 +7698,7 @@ sections:
           - Reference "Technical Debt and Known Issues" section
           - Include "Workarounds and Gotchas" that might impact enhancement
           - Note any identified constraints from "Critical Technical Debt"
-          
+
           Build risk assessment incorporating existing known issues:
         template: |
           **Technical Risks**: {{technical_risks}}
@@ -7678,7 +7721,7 @@ sections:
     title: "Epic 1: {{enhancement_title}}"
     instruction: |
       Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
-      
+
       CRITICAL STORY SEQUENCING FOR BROWNFIELD:
       - Stories must ensure existing functionality remains intact
       - Each story should include verification that existing features still work
@@ -7691,7 +7734,7 @@ sections:
       - Each story must deliver value while maintaining system integrity
     template: |
       **Epic Goal**: {{epic_goal}}
-      
+
       **Integration Requirements**: {{integration_requirements}}
     sections:
       - id: story
@@ -8291,7 +8334,7 @@ workflow:
   elicitation: advanced-elicitation
 
 agent_config:
-  editable_sections: 
+  editable_sections:
     - Status
     - Story
     - Acceptance Criteria
@@ -8308,7 +8351,7 @@ sections:
     instruction: Select the current status of the story
     owner: scrum-master
     editors: [scrum-master, dev-agent]
-    
+
   - id: story
     title: Story
     type: template-text
@@ -8320,7 +8363,7 @@ sections:
     elicit: true
     owner: scrum-master
     editors: [scrum-master]
-    
+
   - id: acceptance-criteria
     title: Acceptance Criteria
     type: numbered-list
@@ -8328,7 +8371,7 @@ sections:
     elicit: true
     owner: scrum-master
     editors: [scrum-master]
-    
+
   - id: tasks-subtasks
     title: Tasks / Subtasks
     type: bullet-list
@@ -8345,7 +8388,7 @@ sections:
     elicit: true
     owner: scrum-master
     editors: [scrum-master, dev-agent]
-    
+
   - id: dev-notes
     title: Dev Notes
     instruction: |
@@ -8369,7 +8412,7 @@ sections:
         elicit: true
         owner: scrum-master
         editors: [scrum-master]
-        
+
   - id: change-log
     title: Change Log
     type: table
@@ -8377,7 +8420,7 @@ sections:
     instruction: Track changes made to this story document
     owner: scrum-master
     editors: [scrum-master, dev-agent, qa-agent]
-    
+
   - id: dev-agent-record
     title: Dev Agent Record
     instruction: This section is populated by the development agent during implementation
@@ -8390,25 +8433,25 @@ sections:
         instruction: Record the specific AI agent model and version used for development
         owner: dev-agent
         editors: [dev-agent]
-        
+
       - id: debug-log-references
         title: Debug Log References
         instruction: Reference any debug logs or traces generated during development
         owner: dev-agent
         editors: [dev-agent]
-        
+
       - id: completion-notes
         title: Completion Notes List
         instruction: Notes about the completion of tasks and any issues encountered
         owner: dev-agent
         editors: [dev-agent]
-        
+
       - id: file-list
         title: File List
         instruction: List all files created, modified, or affected during story implementation
         owner: dev-agent
         editors: [dev-agent]
-        
+
   - id: qa-results
     title: QA Results
     instruction: Results from QA Agent QA review of the completed story implementation
@@ -8860,10 +8903,10 @@ Perform a comprehensive test architecture review with quality gate decision. Thi
 
 ```yaml
 required:
-  - story_id: "{epic}.{story}" # e.g., "1.3"
-  - story_path: "docs/stories/{epic}.{story}.*.md"
-  - story_title: "{title}" # If missing, derive from story file H1
-  - story_slug: "{slug}" # If missing, derive from title (lowercase, hyphenated)
+  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
+  - story_title: '{title}' # If missing, derive from story file H1
+  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
 ```
 
 ## Prerequisites
@@ -9025,6 +9068,8 @@ Gate: {STATUS} → docs/qa/gates/{epic}.{story}-{slug}.yml
 Risk profile: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
 NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
 
+# Note: Paths should reference core-config.yaml for custom configurations
+
 ### Recommended Status
 
 [✓ Ready for Done] / [✗ Changes Required - See unchecked items above]
@@ -9036,26 +9081,26 @@ NFR assessment: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
 **Template and Directory:**
 
 - Render from `templates/qa-gate-tmpl.yaml`
-- Create `docs/qa/gates/` directory if missing
+- Create `docs/qa/gates/` directory if missing (or configure in core-config.yaml)
 - Save to: `docs/qa/gates/{epic}.{story}-{slug}.yml`
 
 Gate file structure:
 
 ```yaml
 schema: 1
-story: "{epic}.{story}"
-story_title: "{story title}"
+story: '{epic}.{story}'
+story_title: '{story title}'
 gate: PASS|CONCERNS|FAIL|WAIVED
-status_reason: "1-2 sentence explanation of gate decision"
-reviewer: "Quinn (Test Architect)"
-updated: "{ISO-8601 timestamp}"
+status_reason: '1-2 sentence explanation of gate decision'
+reviewer: 'Quinn (Test Architect)'
+updated: '{ISO-8601 timestamp}'
 
 top_issues: [] # Empty if no issues
 waiver: { active: false } # Set active: true only if WAIVED
 
 # Extended fields (optional but recommended):
 quality_score: 0-100 # 100 - (20*FAILs) - (10*CONCERNS) or use technical-preferences.md weights
-expires: "{ISO-8601 timestamp}" # Typically 2 weeks from review
+expires: '{ISO-8601 timestamp}' # Typically 2 weeks from review
 
 evidence:
   tests_reviewed: { count }
@@ -9067,24 +9112,24 @@ evidence:
 nfr_validation:
   security:
     status: PASS|CONCERNS|FAIL
-    notes: "Specific findings"
+    notes: 'Specific findings'
   performance:
     status: PASS|CONCERNS|FAIL
-    notes: "Specific findings"
+    notes: 'Specific findings'
   reliability:
     status: PASS|CONCERNS|FAIL
-    notes: "Specific findings"
+    notes: 'Specific findings'
   maintainability:
     status: PASS|CONCERNS|FAIL
-    notes: "Specific findings"
+    notes: 'Specific findings'
 
 recommendations:
   immediate: # Must fix before production
-    - action: "Add rate limiting"
-      refs: ["api/auth/login.ts"]
+    - action: 'Add rate limiting'
+      refs: ['api/auth/login.ts']
   future: # Can be addressed later
-    - action: "Consider caching"
-      refs: ["services/data.ts"]
+    - action: 'Consider caching'
+      refs: ['services/data.ts']
 ```
 
 ### Gate Decision Criteria
@@ -9196,11 +9241,11 @@ Slug rules:
 
 ```yaml
 schema: 1
-story: "{epic}.{story}"
+story: '{epic}.{story}'
 gate: PASS|CONCERNS|FAIL|WAIVED
-status_reason: "1-2 sentence explanation of gate decision"
-reviewer: "Quinn"
-updated: "{ISO-8601 timestamp}"
+status_reason: '1-2 sentence explanation of gate decision'
+reviewer: 'Quinn'
+updated: '{ISO-8601 timestamp}'
 top_issues: [] # Empty array if no issues
 waiver: { active: false } # Only set active: true if WAIVED
 ```
@@ -9209,20 +9254,20 @@ waiver: { active: false } # Only set active: true if WAIVED
 
 ```yaml
 schema: 1
-story: "1.3"
+story: '1.3'
 gate: CONCERNS
-status_reason: "Missing rate limiting on auth endpoints poses security risk."
-reviewer: "Quinn"
-updated: "2025-01-12T10:15:00Z"
+status_reason: 'Missing rate limiting on auth endpoints poses security risk.'
+reviewer: 'Quinn'
+updated: '2025-01-12T10:15:00Z'
 top_issues:
-  - id: "SEC-001"
+  - id: 'SEC-001'
     severity: high # ONLY: low|medium|high
-    finding: "No rate limiting on login endpoint"
-    suggested_action: "Add rate limiting middleware before production"
-  - id: "TEST-001"
+    finding: 'No rate limiting on login endpoint'
+    suggested_action: 'Add rate limiting middleware before production'
+  - id: 'TEST-001'
     severity: medium
-    finding: "No integration tests for auth flow"
-    suggested_action: "Add integration test coverage"
+    finding: 'No integration tests for auth flow'
+    suggested_action: 'Add integration test coverage'
 waiver: { active: false }
 ```
 
@@ -9230,20 +9275,20 @@ waiver: { active: false }
 
 ```yaml
 schema: 1
-story: "1.3"
+story: '1.3'
 gate: WAIVED
-status_reason: "Known issues accepted for MVP release."
-reviewer: "Quinn"
-updated: "2025-01-12T10:15:00Z"
+status_reason: 'Known issues accepted for MVP release.'
+reviewer: 'Quinn'
+updated: '2025-01-12T10:15:00Z'
 top_issues:
-  - id: "PERF-001"
+  - id: 'PERF-001'
     severity: low
-    finding: "Dashboard loads slowly with 1000+ items"
-    suggested_action: "Implement pagination in next sprint"
+    finding: 'Dashboard loads slowly with 1000+ items'
+    suggested_action: 'Implement pagination in next sprint'
 waiver:
   active: true
-  reason: "MVP release - performance optimization deferred"
-  approved_by: "Product Owner"
+  reason: 'MVP release - performance optimization deferred'
+  approved_by: 'Product Owner'
 ```
 
 ## Gate Decision Criteria
@@ -9362,21 +9407,21 @@ Identify all testable requirements from:
 For each requirement, document which tests validate it. Use Given-When-Then to describe what the test validates (not how it's written):
 
 ```yaml
-requirement: "AC1: User can login with valid credentials"
+requirement: 'AC1: User can login with valid credentials'
 test_mappings:
-  - test_file: "auth/login.test.ts"
-    test_case: "should successfully login with valid email and password"
+  - test_file: 'auth/login.test.ts'
+    test_case: 'should successfully login with valid email and password'
     # Given-When-Then describes WHAT the test validates, not HOW it's coded
-    given: "A registered user with valid credentials"
-    when: "They submit the login form"
-    then: "They are redirected to dashboard and session is created"
+    given: 'A registered user with valid credentials'
+    when: 'They submit the login form'
+    then: 'They are redirected to dashboard and session is created'
     coverage: full
 
-  - test_file: "e2e/auth-flow.test.ts"
-    test_case: "complete login flow"
-    given: "User on login page"
-    when: "Entering valid credentials and submitting"
-    then: "Dashboard loads with user data"
+  - test_file: 'e2e/auth-flow.test.ts'
+    test_case: 'complete login flow'
+    given: 'User on login page'
+    when: 'Entering valid credentials and submitting'
+    then: 'Dashboard loads with user data'
     coverage: integration
 ```
 
@@ -9398,19 +9443,19 @@ Document any gaps found:
 
 ```yaml
 coverage_gaps:
-  - requirement: "AC3: Password reset email sent within 60 seconds"
-    gap: "No test for email delivery timing"
+  - requirement: 'AC3: Password reset email sent within 60 seconds'
+    gap: 'No test for email delivery timing'
     severity: medium
     suggested_test:
       type: integration
-      description: "Test email service SLA compliance"
+      description: 'Test email service SLA compliance'
 
-  - requirement: "AC5: Support 1000 concurrent users"
-    gap: "No load testing implemented"
+  - requirement: 'AC5: Support 1000 concurrent users'
+    gap: 'No load testing implemented'
     severity: high
     suggested_test:
       type: performance
-      description: "Load test with 1000 concurrent connections"
+      description: 'Load test with 1000 concurrent connections'
 ```
 
 ## Outputs
@@ -9426,11 +9471,11 @@ trace:
     full: Y
     partial: Z
     none: W
-  planning_ref: "docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md"
+  planning_ref: 'docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md'
   uncovered:
-    - ac: "AC3"
-      reason: "No test found for password reset timing"
-  notes: "See docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md"
+    - ac: 'AC3'
+      reason: 'No test found for password reset timing'
+  notes: 'See docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md'
 ```
 
 ### Output 2: Traceability Report
@@ -9604,10 +9649,10 @@ Generate a comprehensive risk assessment matrix for a story implementation using
 
 ```yaml
 required:
-  - story_id: "{epic}.{story}" # e.g., "1.3"
-  - story_path: "docs/stories/{epic}.{story}.*.md"
-  - story_title: "{title}" # If missing, derive from story file H1
-  - story_slug: "{slug}" # If missing, derive from title (lowercase, hyphenated)
+  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_path: 'docs/stories/{epic}.{story}.*.md'
+  - story_title: '{title}' # If missing, derive from story file H1
+  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
 ```
 
 ## Purpose
@@ -9677,14 +9722,14 @@ For each category, identify specific risks:
 
 ```yaml
 risk:
-  id: "SEC-001" # Use prefixes: SEC, PERF, DATA, BUS, OPS, TECH
+  id: 'SEC-001' # Use prefixes: SEC, PERF, DATA, BUS, OPS, TECH
   category: security
-  title: "Insufficient input validation on user forms"
-  description: "Form inputs not properly sanitized could lead to XSS attacks"
+  title: 'Insufficient input validation on user forms'
+  description: 'Form inputs not properly sanitized could lead to XSS attacks'
   affected_components:
-    - "UserRegistrationForm"
-    - "ProfileUpdateForm"
-  detection_method: "Code review revealed missing validation"
+    - 'UserRegistrationForm'
+    - 'ProfileUpdateForm'
+  detection_method: 'Code review revealed missing validation'
 ```
 
 ### 2. Risk Assessment
@@ -9731,20 +9776,20 @@ For each identified risk, provide mitigation:
 
 ```yaml
 mitigation:
-  risk_id: "SEC-001"
-  strategy: "preventive" # preventive|detective|corrective
+  risk_id: 'SEC-001'
+  strategy: 'preventive' # preventive|detective|corrective
   actions:
-    - "Implement input validation library (e.g., validator.js)"
-    - "Add CSP headers to prevent XSS execution"
-    - "Sanitize all user inputs before storage"
-    - "Escape all outputs in templates"
+    - 'Implement input validation library (e.g., validator.js)'
+    - 'Add CSP headers to prevent XSS execution'
+    - 'Sanitize all user inputs before storage'
+    - 'Escape all outputs in templates'
   testing_requirements:
-    - "Security testing with OWASP ZAP"
-    - "Manual penetration testing of forms"
-    - "Unit tests for validation functions"
-  residual_risk: "Low - Some zero-day vulnerabilities may remain"
-  owner: "dev"
-  timeline: "Before deployment"
+    - 'Security testing with OWASP ZAP'
+    - 'Manual penetration testing of forms'
+    - 'Unit tests for validation functions'
+  residual_risk: 'Low - Some zero-day vulnerabilities may remain'
+  owner: 'dev'
+  timeline: 'Before deployment'
 ```
 
 ## Outputs
@@ -9770,12 +9815,12 @@ risk_summary:
   highest:
     id: SEC-001
     score: 9
-    title: "XSS on profile form"
+    title: 'XSS on profile form'
   recommendations:
     must_fix:
-      - "Add input sanitization & CSP"
+      - 'Add input sanitization & CSP'
     monitor:
-      - "Add security alerts for auth endpoints"
+      - 'Add security alerts for auth endpoints'
 ```
 
 ### Output 2: Markdown Report
@@ -9960,299 +10005,79 @@ Create comprehensive test scenarios with appropriate test level recommendations
 
 ```yaml
 required:
-  - story_id: "{epic}.{story}" # e.g., "1.3"
-  - story_path: "docs/stories/{epic}.{story}.*.md"
-  - story_title: "{title}" # If missing, derive from story file H1
-  - story_slug: "{slug}" # If missing, derive from title (lowercase, hyphenated)
+  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
+  - story_title: '{title}' # If missing, derive from story file H1
+  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
 ```
 
 ## Purpose
 
 Design a complete test strategy that identifies what to test, at which level (unit/integration/e2e), and why. This ensures efficient test coverage without redundancy while maintaining appropriate test boundaries.
 
-## Test Level Decision Framework
-
-### Unit Tests
-
-**When to use:**
-
-- Testing pure functions and business logic
-- Algorithm correctness
-- Input validation and data transformation
-- Error handling in isolated components
-- Complex calculations or state machines
-
-**Characteristics:**
-
-- Fast execution (immediate feedback)
-- No external dependencies (DB, API, file system)
-- Highly maintainable and stable
-- Easy to debug failures
-
-**Example scenarios:**
-
-```yaml
-unit_test:
-  component: "PriceCalculator"
-  scenario: "Calculate discount with multiple rules"
-  justification: "Complex business logic with multiple branches"
-  mock_requirements: "None - pure function"
-```
-
-### Integration Tests
-
-**When to use:**
-
-- Testing component interactions
-- Database operations and queries
-- API endpoint behavior
-- Service layer orchestration
-- External service integration (with test doubles)
-
-**Characteristics:**
-
-- Moderate execution time
-- May use test databases or containers
-- Tests multiple components together
-- Validates contracts between components
-
-**Example scenarios:**
+## Dependencies
 
 ```yaml
-integration_test:
-  components: ["UserService", "UserRepository", "Database"]
-  scenario: "Create user with duplicate email check"
-  justification: "Tests transaction boundaries and constraint handling"
-  test_doubles: "Mock email service, real test database"
+data:
+  - test-levels-framework.md # Unit/Integration/E2E decision criteria
+  - test-priorities-matrix.md # P0/P1/P2/P3 classification system
 ```
 
-### End-to-End Tests
-
-**When to use:**
-
-- Critical user journeys
-- Cross-system workflows
-- UI interaction flows
-- Full stack validation
-- Production-like scenario testing
-
-**Characteristics:**
-
-- Keep under 90 seconds per test
-- Tests complete user scenarios
-- Uses real or production-like environment
-- Higher maintenance cost
-- More prone to flakiness
-
-**Example scenarios:**
-
-```yaml
-e2e_test:
-  flow: "Complete purchase flow"
-  scenario: "User browses, adds to cart, and completes checkout"
-  justification: "Critical business flow requiring full stack validation"
-  environment: "Staging with test payment gateway"
-```
-
-## Test Design Process
+## Process
 
 ### 1. Analyze Story Requirements
 
-Break down each acceptance criterion into testable scenarios:
+Break down each acceptance criterion into testable scenarios. For each AC:
 
-```yaml
-acceptance_criterion: "User can reset password via email"
-test_scenarios:
-  - level: unit
-    what: "Password validation rules"
-    why: "Complex regex and business rules"
-
-  - level: integration
-    what: "Password reset token generation and storage"
-    why: "Database interaction with expiry logic"
-
-  - level: integration
-    what: "Email service integration"
-    why: "External service with retry logic"
-
-  - level: e2e
-    what: "Complete password reset flow"
-    why: "Critical security flow needing full validation"
-```
+- Identify the core functionality to test
+- Determine data variations needed
+- Consider error conditions
+- Note edge cases
 
-### 2. Apply Test Level Heuristics
+### 2. Apply Test Level Framework
 
-Use these rules to determine appropriate test levels:
+**Reference:** Load `test-levels-framework.md` for detailed criteria
 
-```markdown
-## Test Level Selection Rules
-
-### Favor Unit Tests When:
-
-- Logic can be isolated
-- No side effects involved
-- Fast feedback needed
-- High cyclomatic complexity
-
-### Favor Integration Tests When:
-
-- Testing persistence layer
-- Validating service contracts
-- Testing middleware/interceptors
-- Component boundaries critical
-
-### Favor E2E Tests When:
-
-- User-facing critical paths
-- Multi-system interactions
-- Regulatory compliance scenarios
-- Visual regression important
-
-### Anti-patterns to Avoid:
-
-- E2E testing for business logic validation
-- Unit testing framework behavior
-- Integration testing third-party libraries
-- Duplicate coverage across levels
-
-### Duplicate Coverage Guard
-
-**Before adding any test, check:**
+Quick rules:
 
-1. Is this already tested at a lower level?
-2. Can a unit test cover this instead of integration?
-3. Can an integration test cover this instead of E2E?
+- **Unit**: Pure logic, algorithms, calculations
+- **Integration**: Component interactions, DB operations
+- **E2E**: Critical user journeys, compliance
 
-**Coverage overlap is only acceptable when:**
+### 3. Assign Priorities
 
-- Testing different aspects (unit: logic, integration: interaction, e2e: user experience)
-- Critical paths requiring defense in depth
-- Regression prevention for previously broken functionality
-```
-
-### 3. Design Test Scenarios
-
-**Test ID Format:** `{EPIC}.{STORY}-{LEVEL}-{SEQ}`
+**Reference:** Load `test-priorities-matrix.md` for classification
 
-- Example: `1.3-UNIT-001`, `1.3-INT-002`, `1.3-E2E-001`
-- Ensures traceability across all artifacts
+Quick priority assignment:
 
-**Naming Convention:**
+- **P0**: Revenue-critical, security, compliance
+- **P1**: Core user journeys, frequently used
+- **P2**: Secondary features, admin functions
+- **P3**: Nice-to-have, rarely used
 
-- Unit: `test_{component}_{scenario}`
-- Integration: `test_{flow}_{interaction}`
-- E2E: `test_{journey}_{outcome}`
+### 4. Design Test Scenarios
 
-**Risk Linkage:**
-
-- Tag tests with risk IDs they mitigate
-- Prioritize tests for high-risk areas (P0)
-- Link to risk profile when available
-
-For each identified test need:
+For each identified test need, create:
 
 ```yaml
 test_scenario:
-  id: "1.3-INT-002"
-  requirement: "AC2: Rate limiting on login attempts"
-  mitigates_risks: ["SEC-001", "PERF-003"] # Links to risk profile
-  priority: P0 # Based on risk score
-
-  unit_tests:
-    - name: "RateLimiter calculates window correctly"
-      input: "Timestamp array"
-      expected: "Correct window calculation"
-
-  integration_tests:
-    - name: "Login endpoint enforces rate limit"
-      setup: "5 failed attempts"
-      action: "6th attempt"
-      expected: "429 response with retry-after header"
-
-  e2e_tests:
-    - name: "User sees rate limit message"
-      setup: "Trigger rate limit"
-      validation: "Error message displayed, retry timer shown"
+  id: '{epic}.{story}-{LEVEL}-{SEQ}'
+  requirement: 'AC reference'
+  priority: P0|P1|P2|P3
+  level: unit|integration|e2e
+  description: 'What is being tested'
+  justification: 'Why this level was chosen'
+  mitigates_risks: ['RISK-001'] # If risk profile exists
 ```
 
-## Deterministic Test Level Minimums
-
-**Per Acceptance Criterion:**
-
-- At least 1 unit test for business logic
-- At least 1 integration test if multiple components interact
-- At least 1 E2E test if it's a user-facing feature
-
-**Exceptions:**
-
-- Pure UI changes: May skip unit tests
-- Pure logic changes: May skip E2E tests
-- Infrastructure changes: May focus on integration tests
-
-**When in doubt:** Start with unit tests, add integration for interactions, E2E for critical paths only.
-
-## Test Quality Standards
+### 5. Validate Coverage
 
-### Core Testing Principles
+Ensure:
 
-**No Flaky Tests:** Ensure reliability through proper async handling, explicit waits, and atomic test design.
-
-**No Hard Waits/Sleeps:** Use dynamic waiting strategies (e.g., polling, event-based triggers).
-
-**Stateless & Parallel-Safe:** Tests run independently; use cron jobs or semaphores only if unavoidable.
-
-**No Order Dependency:** Every it/describe/context block works in isolation (supports .only execution).
-
-**Self-Cleaning Tests:** Test sets up its own data and automatically deletes/deactivates entities created during testing.
-
-**Tests Live Near Source Code:** Co-locate test files with the code they validate (e.g., `*.spec.js` alongside components).
-
-### Execution Strategy
-
-**Shifted Left:**
-
-- Start with local environments or ephemeral stacks
-- Validate functionality across all deployment stages (local → dev → stage)
-
-**Low Maintenance:** Minimize manual upkeep (avoid brittle selectors, do not repeat UI actions, leverage APIs).
-
-**CI Execution Evidence:** Integrate into pipelines with clear logs/artifacts.
-
-**Visibility:** Generate test reports (e.g., JUnit XML, HTML) for failures and trends.
-
-### Coverage Requirements
-
-**Release Confidence:**
-
-- Happy Path: Core user journeys are prioritized
-- Edge Cases: Critical error/validation scenarios are covered
-- Feature Flags: Test both enabled and disabled states where applicable
-
-### Test Design Rules
-
-**Assertions:** Keep them explicit in tests; avoid abstraction into helpers. Use parametrized tests for soft assertions.
-
-**Naming:** Follow conventions (e.g., `describe('Component')`, `it('should do X when Y')`).
-
-**Size:** Aim for files ≤200 lines; split/chunk large tests logically.
-
-**Speed:** Target individual tests ≤90 seconds; optimize slow setups (e.g., shared fixtures).
-
-**Careful Abstractions:** Favor readability over DRY when balancing helper reuse (page objects are okay, assertion logic is not).
-
-**Test Cleanup:** Ensure tests clean up resources they create (e.g., closing browser, deleting test data).
-
-**Deterministic Flow:** Tests should refrain from using conditionals (e.g., if/else) to control flow or try/catch blocks where possible.
-
-### API Testing Standards
-
-- Tests must not depend on hardcoded data → use factories and per-test setup
-- Always test both happy path and negative/error cases
-- API tests should run parallel safely (no global state shared)
-- Test idempotency where applicable (e.g., duplicate requests)
-- Tests should clean up their data
-- Response logs should only be printed in case of failure
-- Auth tests must validate token expiration and renewal
+- Every AC has at least one test
+- No duplicate coverage across levels
+- Critical paths have multiple levels
+- Risk mitigations are addressed
 
 ## Outputs
 
@@ -10260,13 +10085,11 @@ test_scenario:
 
 **Save to:** `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`
 
-Generate a comprehensive test design document:
-
 ```markdown
 # Test Design: Story {epic}.{story}
 
 Date: {date}
-Reviewer: Quinn (Test Architect)
+Designer: Quinn (Test Architect)
 
 ## Test Strategy Overview
 
@@ -10274,212 +10097,80 @@ Reviewer: Quinn (Test Architect)
 - Unit tests: Y (A%)
 - Integration tests: Z (B%)
 - E2E tests: W (C%)
+- Priority distribution: P0: X, P1: Y, P2: Z
 
-## Test Level Rationale
-
-[Explain why this distribution was chosen]
-
-## Detailed Test Scenarios
-
-### Requirement: AC1 - {description}
-
-#### Unit Tests (3 scenarios)
-
-1. **ID**: 1.3-UNIT-001
-   **Test**: Validate input format
-   - **Why Unit**: Pure validation logic
-   - **Coverage**: Input edge cases
-   - **Mocks**: None needed
-   - **Mitigates**: DATA-001 (if applicable)
-
-#### Integration Tests (2 scenarios)
-
-1. **ID**: 1.3-INT-001
-   **Test**: Service processes valid request
-   - **Why Integration**: Multiple components involved
-   - **Coverage**: Happy path + error handling
-   - **Test Doubles**: Mock external API
-   - **Mitigates**: TECH-002
-
-#### E2E Tests (1 scenario)
-
-1. **ID**: 1.3-E2E-001
-   **Test**: Complete user workflow
-   - **Why E2E**: Critical user journey
-   - **Coverage**: Full stack validation
-   - **Environment**: Staging
-   - **Max Duration**: 90 seconds
-   - **Mitigates**: BUS-001
-
-[Continue for all requirements...]
-
-## Test Data Requirements
-
-### Unit Test Data
-
-- Static fixtures for calculations
-- Edge case values arrays
-
-### Integration Test Data
-
-- Test database seeds
-- API response fixtures
-
-### E2E Test Data
-
-- Test user accounts
-- Sandbox environment data
-
-## Mock/Stub Strategy
+## Test Scenarios by Acceptance Criteria
 
-### What to Mock
+### AC1: {description}
 
-- External services (payment, email)
-- Time-dependent functions
-- Random number generators
+#### Scenarios
 
-### What NOT to Mock
+| ID           | Level       | Priority | Test                      | Justification            |
+| ------------ | ----------- | -------- | ------------------------- | ------------------------ |
+| 1.3-UNIT-001 | Unit        | P0       | Validate input format     | Pure validation logic    |
+| 1.3-INT-001  | Integration | P0       | Service processes request | Multi-component flow     |
+| 1.3-E2E-001  | E2E         | P1       | User completes journey    | Critical path validation |
 
-- Core business logic
-- Database in integration tests
-- Critical security functions
-
-## Test Execution Implementation
-
-### Parallel Execution
-
-- All unit tests: Fully parallel (stateless requirement)
-- Integration tests: Parallel with isolated databases
-- E2E tests: Sequential or limited parallelism
-
-### Execution Order
-
-1. Unit tests first (fail fast)
-2. Integration tests second
-3. E2E tests last (expensive, max 90 seconds each)
-
-## Risk-Based Test Priority
-
-### P0 - Must Have (Linked to Critical/High Risks)
-
-- Security-related tests (SEC-\* risks)
-- Data integrity tests (DATA-\* risks)
-- Critical business flow tests (BUS-\* risks)
-- Tests for risks scored ≥6 in risk profile
-
-### P1 - Should Have (Medium Risks)
-
-- Edge case coverage
-- Performance tests (PERF-\* risks)
-- Error recovery tests
-- Tests for risks scored 4-5
-
-### P2 - Nice to Have (Low Risks)
-
-- UI polish tests
-- Minor validation tests
-- Tests for risks scored ≤3
-
-## Test Maintenance Considerations
-
-### High Maintenance Tests
-
-[List tests that may need frequent updates]
-
-### Stability Measures
-
-- No retry strategies (tests must be deterministic)
-- Dynamic waits only (no hard sleeps)
-- Environment isolation
-- Self-cleaning test data
-
-## Coverage Goals
-
-### Unit Test Coverage
-
-- Target: 80% line coverage
-- Focus: Business logic, calculations
+[Continue for all ACs...]
 
-### Integration Coverage
+## Risk Coverage
 
-- Target: All API endpoints
-- Focus: Contract validation
+[Map test scenarios to identified risks if risk profile exists]
 
-### E2E Coverage
+## Recommended Execution Order
 
-- Target: Critical paths only
-- Focus: User value delivery
+1. P0 Unit tests (fail fast)
+2. P0 Integration tests
+3. P0 E2E tests
+4. P1 tests in order
+5. P2+ as time permits
 ```
 
-## Test Level Smells to Flag
-
-### Over-testing Smells
+### Output 2: Gate YAML Block
 
-- Same logic tested at multiple levels
-- E2E tests for calculations
-- Integration tests for framework features
+Generate for inclusion in quality gate:
 
-### Under-testing Smells
-
-- No unit tests for complex logic
-- Missing integration tests for data operations
-- No E2E tests for critical user paths
-
-### Wrong Level Smells
-
-- Unit tests with real database
-- E2E tests checking calculation results
-- Integration tests mocking everything
-
-## Quality Indicators
-
-Good test design shows:
-
-- Clear level separation
-- No redundant coverage
-- Fast feedback from unit tests
-- Reliable integration tests
-- Focused e2e tests
-
-## Key Principles
-
-- Test at the lowest appropriate level
-- One clear owner per test
-- Fast tests run first
-- Mock at boundaries, not internals
-- E2E for user value, not implementation
-- Maintain test/production parity where critical
-- Tests must be atomic and self-contained
-- No shared state between tests
-- Explicit assertions in test files (not helpers)
+```yaml
+test_design:
+  scenarios_total: X
+  by_level:
+    unit: Y
+    integration: Z
+    e2e: W
+  by_priority:
+    p0: A
+    p1: B
+    p2: C
+  coverage_gaps: [] # List any ACs without tests
+```
 
-### Output 2: Story Hook Line
+### Output 3: Trace References
 
-**Print this line for review task to quote:**
+Print for use by trace-requirements task:
 
 ```text
-Test design: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
+Test design matrix: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
+P0 tests identified: {count}
 ```
 
-**For traceability:** This planning document will be referenced by trace-requirements task.
+## Quality Checklist
 
-### Output 3: Test Count Summary
+Before finalizing, verify:
 
-**Print summary for quick reference:**
+- [ ] Every AC has test coverage
+- [ ] Test levels are appropriate (not over-testing)
+- [ ] No duplicate coverage across levels
+- [ ] Priorities align with business risk
+- [ ] Test IDs follow naming convention
+- [ ] Scenarios are atomic and independent
 
-```yaml
-test_summary:
-  total: { total_count }
-  by_level:
-    unit: { unit_count }
-    integration: { int_count }
-    e2e: { e2e_count }
-  by_priority:
-    P0: { p0_count }
-    P1: { p1_count }
-    P2: { p2_count }
-  coverage_gaps: [] # List any ACs without tests
-```
+## Key Principles
+
+- **Shift left**: Prefer unit over integration, integration over E2E
+- **Risk-based**: Focus on what could go wrong
+- **Efficient coverage**: Test once at the right level
+- **Maintainability**: Consider long-term test maintenance
+- **Fast feedback**: Quick tests run first
 ==================== END: .bmad-core/tasks/test-design.md ====================
 
 ==================== START: .bmad-core/tasks/nfr-assess.md ====================
@@ -10491,12 +10182,12 @@ Quick NFR validation focused on the core four: security, performance, reliabilit
 
 ```yaml
 required:
-  - story_id: "{epic}.{story}" # e.g., "1.3"
-  - story_path: "docs/stories/{epic}.{story}.*.md"
+  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_path: 'docs/stories/{epic}.{story}.*.md'
 
 optional:
-  - architecture_refs: "docs/architecture/*.md"
-  - technical_preferences: "docs/technical-preferences.md"
+  - architecture_refs: 'docs/architecture/*.md'
+  - technical_preferences: 'docs/technical-preferences.md'
   - acceptance_criteria: From story file
 ```
 
@@ -10577,16 +10268,16 @@ nfr_validation:
   _assessed: [security, performance, reliability, maintainability]
   security:
     status: CONCERNS
-    notes: "No rate limiting on auth endpoints"
+    notes: 'No rate limiting on auth endpoints'
   performance:
     status: PASS
-    notes: "Response times < 200ms verified"
+    notes: 'Response times < 200ms verified'
   reliability:
     status: PASS
-    notes: "Error handling and retries implemented"
+    notes: 'Error handling and retries implemented'
   maintainability:
     status: CONCERNS
-    notes: "Test coverage at 65%, target is 80%"
+    notes: 'Test coverage at 65%, target is 80%'
 ```
 
 ## Deterministic Status Rules
@@ -10816,10 +10507,10 @@ performance_deep_dive:
     p99: 350ms
   database:
     slow_queries: 2
-    missing_indexes: ["users.email", "orders.user_id"]
+    missing_indexes: ['users.email', 'orders.user_id']
   caching:
     hit_rate: 0%
-    recommendation: "Add Redis for session data"
+    recommendation: 'Add Redis for session data'
   load_test:
     max_rps: 150
     breaking_point: 200 rps
@@ -10842,8 +10533,8 @@ template:
 schema: 1
 story: "{{epic_num}}.{{story_num}}"
 story_title: "{{story_title}}"
-gate: "{{gate_status}}"  # PASS|CONCERNS|FAIL|WAIVED
-status_reason: "{{status_reason}}"  # 1-2 sentence summary of why this gate decision
+gate: "{{gate_status}}" # PASS|CONCERNS|FAIL|WAIVED
+status_reason: "{{status_reason}}" # 1-2 sentence summary of why this gate decision
 reviewer: "Quinn (Test Architect)"
 updated: "{{iso_timestamp}}"
 
@@ -10860,68 +10551,77 @@ risk_summary:
     must_fix: []
     monitor: []
 
-# Example with issues:
-# top_issues:
-#   - id: "SEC-001"
-#     severity: high  # ONLY: low|medium|high
-#     finding: "No rate limiting on login endpoint"
-#     suggested_action: "Add rate limiting middleware before production"
-#   - id: "TEST-001"  
-#     severity: medium
-#     finding: "Missing integration tests for auth flow"
-#     suggested_action: "Add test coverage for critical paths"
-
-# Example when waived:
-# waiver:
-#   active: true
-#   reason: "Accepted for MVP release - will address in next sprint"
-#   approved_by: "Product Owner"
+# Examples section using block scalars for clarity
+examples:
+  with_issues: |
+    top_issues:
+      - id: "SEC-001"
+        severity: high  # ONLY: low|medium|high
+        finding: "No rate limiting on login endpoint"
+        suggested_action: "Add rate limiting middleware before production"
+      - id: "TEST-001"  
+        severity: medium
+        finding: "Missing integration tests for auth flow"
+        suggested_action: "Add test coverage for critical paths"
+
+  when_waived: |
+    waiver:
+      active: true
+      reason: "Accepted for MVP release - will address in next sprint"
+      approved_by: "Product Owner"
 
 # ============ Optional Extended Fields ============
 # Uncomment and use if your team wants more detail
 
-# quality_score: 75  # 0-100 (optional scoring)
-# expires: "2025-01-26T00:00:00Z"  # Optional gate freshness window
-
-# evidence:
-#   tests_reviewed: 15
-#   risks_identified: 3
-#   trace:
-#     ac_covered: [1, 2, 3]  # AC numbers with test coverage
-#     ac_gaps: [4]  # AC numbers lacking coverage
-
-# nfr_validation:
-#   security: { status: CONCERNS, notes: "Rate limiting missing" }
-#   performance: { status: PASS, notes: "" }
-#   reliability: { status: PASS, notes: "" }
-#   maintainability: { status: PASS, notes: "" }
-
-# history:  # Append-only audit trail
-#   - at: "2025-01-12T10:00:00Z"
-#     gate: FAIL
-#     note: "Initial review - missing tests"
-#   - at: "2025-01-12T15:00:00Z"  
-#     gate: CONCERNS
-#     note: "Tests added but rate limiting still missing"
-
-# risk_summary:  # From risk-profile task
-#   totals:
-#     critical: 0
-#     high: 0
-#     medium: 0
-#     low: 0
-#   # 'highest' is emitted only when risks exist
-#   recommendations:
-#     must_fix: []
-#     monitor: []
-
-# recommendations:
-#   immediate:  # Must fix before production
-#     - action: "Add rate limiting to auth endpoints"
-#       refs: ["api/auth/login.ts:42-68"]
-#   future:  # Can be addressed later
-#     - action: "Consider caching for better performance"
-#       refs: ["services/data.service.ts"]
+optional_fields_examples:
+  quality_and_expiry: |
+    quality_score: 75  # 0-100 (optional scoring)
+    expires: "2025-01-26T00:00:00Z"  # Optional gate freshness window
+
+  evidence: |
+    evidence:
+      tests_reviewed: 15
+      risks_identified: 3
+      trace:
+        ac_covered: [1, 2, 3]  # AC numbers with test coverage
+        ac_gaps: [4]  # AC numbers lacking coverage
+
+  nfr_validation: |
+    nfr_validation:
+      security: { status: CONCERNS, notes: "Rate limiting missing" }
+      performance: { status: PASS, notes: "" }
+      reliability: { status: PASS, notes: "" }
+      maintainability: { status: PASS, notes: "" }
+
+  history: |
+    history:  # Append-only audit trail
+      - at: "2025-01-12T10:00:00Z"
+        gate: FAIL
+        note: "Initial review - missing tests"
+      - at: "2025-01-12T15:00:00Z"  
+        gate: CONCERNS
+        note: "Tests added but rate limiting still missing"
+
+  risk_summary: |
+    risk_summary:  # From risk-profile task
+      totals:
+        critical: 0
+        high: 0
+        medium: 0
+        low: 0
+      # 'highest' is emitted only when risks exist
+      recommendations:
+        must_fix: []
+        monitor: []
+
+  recommendations: |
+    recommendations:
+      immediate:  # Must fix before production
+        - action: "Add rate limiting to auth endpoints"
+          refs: ["api/auth/login.ts:42-68"]
+      future:  # Can be addressed later
+        - action: "Consider caching for better performance"
+          refs: ["services/data.service.ts"]
 ==================== END: .bmad-core/templates/qa-gate-tmpl.yaml ====================
 
 ==================== START: .bmad-core/tasks/create-next-story.md ====================
@@ -11268,7 +10968,7 @@ sections:
     title: Introduction
     instruction: |
       Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.
-      
+
       Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
     content: |
       This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
@@ -11277,7 +10977,7 @@ sections:
         title: Overall UX Goals & Principles
         instruction: |
           Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
-          
+
           1. Target User Personas - elicit details or confirm existing ones from PRD
           2. Key Usability Goals - understand what success looks like for users
           3. Core Design Principles - establish 3-5 guiding principles
@@ -11318,7 +11018,7 @@ sections:
     title: Information Architecture (IA)
     instruction: |
       Collaborate with the user to create a comprehensive information architecture:
-      
+
       1. Build a Site Map or Screen Inventory showing all major areas
       2. Define the Navigation Structure (primary, secondary, breadcrumbs)
       3. Use Mermaid diagrams for visual representation
@@ -11348,22 +11048,22 @@ sections:
         title: Navigation Structure
         template: |
           **Primary Navigation:** {{primary_nav_description}}
-          
+
           **Secondary Navigation:** {{secondary_nav_description}}
-          
+
           **Breadcrumb Strategy:** {{breadcrumb_strategy}}
 
   - id: user-flows
     title: User Flows
     instruction: |
       For each critical user task identified in the PRD:
-      
+
       1. Define the user's goal clearly
       2. Map out all steps including decision points
       3. Consider edge cases and error states
       4. Use Mermaid flow diagrams for clarity
       5. Link to external tools (Figma/Miro) if detailed flows exist there
-      
+
       Create subsections for each major flow.
     elicit: true
     repeatable: true
@@ -11372,9 +11072,9 @@ sections:
         title: "{{flow_name}}"
         template: |
           **User Goal:** {{flow_goal}}
-          
+
           **Entry Points:** {{entry_points}}
-          
+
           **Success Criteria:** {{success_criteria}}
         sections:
           - id: flow-diagram
@@ -11405,14 +11105,14 @@ sections:
             title: "{{screen_name}}"
             template: |
               **Purpose:** {{screen_purpose}}
-              
+
               **Key Elements:**
               - {{element_1}}
               - {{element_2}}
               - {{element_3}}
-              
+
               **Interaction Notes:** {{interaction_notes}}
-              
+
               **Design File Reference:** {{specific_frame_link}}
 
   - id: component-library
@@ -11431,11 +11131,11 @@ sections:
             title: "{{component_name}}"
             template: |
               **Purpose:** {{component_purpose}}
-              
+
               **Variants:** {{component_variants}}
-              
+
               **States:** {{component_states}}
-              
+
               **Usage Guidelines:** {{usage_guidelines}}
 
   - id: branding-style
@@ -11481,13 +11181,13 @@ sections:
         title: Iconography
         template: |
           **Icon Library:** {{icon_library}}
-          
+
           **Usage Guidelines:** {{icon_guidelines}}
       - id: spacing-layout
         title: Spacing & Layout
         template: |
           **Grid System:** {{grid_system}}
-          
+
           **Spacing Scale:** {{spacing_scale}}
 
   - id: accessibility
@@ -11505,12 +11205,12 @@ sections:
           - Color contrast ratios: {{contrast_requirements}}
           - Focus indicators: {{focus_requirements}}
           - Text sizing: {{text_requirements}}
-          
+
           **Interaction:**
           - Keyboard navigation: {{keyboard_requirements}}
           - Screen reader support: {{screen_reader_requirements}}
           - Touch targets: {{touch_requirements}}
-          
+
           **Content:**
           - Alternative text: {{alt_text_requirements}}
           - Heading structure: {{heading_requirements}}
@@ -11537,11 +11237,11 @@ sections:
         title: Adaptation Patterns
         template: |
           **Layout Changes:** {{layout_adaptations}}
-          
+
           **Navigation Changes:** {{nav_adaptations}}
-          
+
           **Content Priority:** {{content_adaptations}}
-          
+
           **Interaction Changes:** {{interaction_adaptations}}
 
   - id: animation
@@ -11575,7 +11275,7 @@ sections:
     title: Next Steps
     instruction: |
       After completing the UI/UX specification:
-      
+
       1. Recommend review with stakeholders
       2. Suggest creating/updating visual designs in design tool
       3. Prepare for handoff to Design Architect for frontend architecture
@@ -11624,7 +11324,7 @@ workflow:
         - Single story (< 4 hours) → Use brownfield-create-story task
         - Small feature (1-3 stories) → Use brownfield-create-epic task  
         - Major enhancement (multiple epics) → Continue with full workflow
-        
+
         Ask user: "Can you describe the enhancement scope? Is this a small fix, a feature addition, or a major enhancement requiring architectural changes?"
 
     - step: routing_decision
@@ -11785,7 +11485,7 @@ workflow:
       notes: |
         All stories implemented and reviewed!
         Project development phase complete.
-        
+
         Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
 
   flow_diagram: |
@@ -11869,35 +11569,35 @@ workflow:
       {{if single_story}}: Proceeding with brownfield-create-story task for immediate implementation.
       {{if small_feature}}: Creating focused epic with brownfield-create-epic task.
       {{if major_enhancement}}: Continuing with comprehensive planning workflow.
-    
+
     documentation_assessment: |
       Documentation assessment complete:
       {{if adequate}}: Existing documentation is sufficient. Proceeding directly to PRD creation.
       {{if inadequate}}: Running document-project to capture current system state before PRD.
-    
+
     document_project_to_pm: |
       Project analysis complete. Key findings documented in:
       - {{document_list}}
       Use these findings to inform PRD creation and avoid re-analyzing the same aspects.
-    
+
     pm_to_architect_decision: |
       PRD complete and saved as docs/prd.md. 
       Architectural changes identified: {{yes/no}}
       {{if yes}}: Proceeding to create architecture document for: {{specific_changes}}
       {{if no}}: No architectural changes needed. Proceeding to validation.
-    
+
     architect_to_po: "Architecture complete. Save it as docs/architecture.md. Please validate all artifacts for integration safety."
-    
+
     po_to_sm: |
       All artifacts validated. 
       Documentation type available: {{sharded_prd / brownfield_docs}}
       {{if sharded}}: Use standard create-next-story task.
       {{if brownfield}}: Use create-brownfield-story task to handle varied documentation formats.
-    
+
     sm_story_creation: |
       Creating story from {{documentation_type}}.
       {{if missing_context}}: May need to gather additional context from user during story creation.
-    
+
     complete: "All planning artifacts validated and development can begin. Stories will be created based on available documentation format."
 ==================== END: .bmad-core/workflows/brownfield-fullstack.yaml ====================
 
@@ -12031,7 +11731,7 @@ workflow:
       notes: |
         All stories implemented and reviewed!
         Project development phase complete.
-        
+
         Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
 
   flow_diagram: |
@@ -12228,7 +11928,7 @@ workflow:
       notes: |
         All stories implemented and reviewed!
         Project development phase complete.
-        
+
         Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
 
   flow_diagram: |
@@ -12453,7 +12153,7 @@ workflow:
       notes: |
         All stories implemented and reviewed!
         Project development phase complete.
-        
+
         Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
 
   flow_diagram: |
@@ -12672,7 +12372,7 @@ workflow:
       notes: |
         All stories implemented and reviewed!
         Service development phase complete.
-        
+
         Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
 
   flow_diagram: |
@@ -12900,7 +12600,7 @@ workflow:
       notes: |
         All stories implemented and reviewed!
         Project development phase complete.
-        
+
         Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow
 
   flow_diagram: |