diff --git a/dist/agents/analyst.txt b/dist/agents/analyst.txt index 217b2d4d..6f24d041 100644 --- a/dist/agents/analyst.txt +++ b/dist/agents/analyst.txt @@ -106,7 +106,7 @@ dependencies: ==================== 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 @@ -1124,12 +1124,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 @@ -1450,7 +1450,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}} @@ -1651,7 +1651,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 @@ -1716,7 +1716,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: @@ -1728,7 +1735,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: @@ -1755,7 +1768,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 @@ -1790,7 +1803,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -1894,11 +1907,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:" @@ -2023,7 +2036,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-core/templates/brainstorming-output-tmpl.yaml ==================== diff --git a/dist/agents/architect.txt b/dist/agents/architect.txt index 2bbdfa3a..d50c89b7 100644 --- a/dist/agents/architect.txt +++ b/dist/agents/architect.txt @@ -948,20 +948,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 @@ -974,16 +974,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 @@ -1011,7 +1011,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 @@ -1028,17 +1028,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) @@ -1054,23 +1054,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: @@ -1094,13 +1094,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 @@ -1109,11 +1109,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}} @@ -1122,7 +1122,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 @@ -1131,7 +1131,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: @@ -1140,13 +1140,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 @@ -1163,13 +1163,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 @@ -1182,10 +1182,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 @@ -1194,13 +1194,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 @@ -1211,13 +1211,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: | @@ -1234,13 +1234,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 @@ -1250,14 +1250,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: @@ -1275,13 +1275,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: @@ -1317,13 +1317,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: @@ -1370,13 +1370,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: @@ -1398,7 +1398,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}}" @@ -1416,14 +1416,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: @@ -1444,7 +1444,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 @@ -1486,7 +1486,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 @@ -1555,16 +1555,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 @@ -1597,16 +1597,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 @@ -1622,7 +1622,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 @@ -1630,11 +1630,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 @@ -1656,12 +1656,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}}"] @@ -1809,33 +1821,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 @@ -1861,17 +1873,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}} @@ -1881,7 +1893,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 @@ -1903,7 +1915,7 @@ sections: - Databases and storage - External integrations - CDN and caching layers - + Use appropriate diagram type for clarity. - id: architectural-patterns title: Architectural Patterns @@ -1913,7 +1925,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}}" @@ -1927,7 +1939,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 @@ -1936,7 +1948,7 @@ sections: - Testing tools for both frontend and backend - Build and deployment tools - Monitoring and logging - + Upon render, elicit feedback immediately. elicit: true sections: @@ -1946,11 +1958,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}}"] @@ -1971,14 +2001,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 @@ -1987,7 +2017,7 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} @@ -2006,7 +2036,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 @@ -2014,7 +2044,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: @@ -2049,7 +2079,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 @@ -2058,7 +2088,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: @@ -2067,13 +2097,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 @@ -2090,13 +2120,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 @@ -2109,10 +2139,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 @@ -2121,14 +2151,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 @@ -2136,13 +2166,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 @@ -2278,60 +2308,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 @@ -2358,13 +2388,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 @@ -2377,10 +2407,10 @@ sections: template: | # Frontend (.env.local) {{frontend_env_vars}} - + # Backend (.env) {{backend_env_vars}} - + # Shared {{shared_env_vars}} @@ -2397,7 +2427,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}} @@ -2428,12 +2458,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}} @@ -2445,7 +2475,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}} @@ -2461,10 +2491,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 @@ -2583,7 +2613,7 @@ sections: - JavaScript errors - API response times - User interactions - + **Backend Metrics:** - Request rate - Error rate @@ -2614,40 +2644,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: @@ -2676,12 +2706,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: @@ -2710,7 +2740,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 @@ -2733,7 +2763,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) @@ -2749,11 +2779,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}} @@ -2765,7 +2795,7 @@ sections: - **Modified Tables:** {{modified_tables_list}} - **New Indexes:** {{new_indexes_list}} - **Migration Strategy:** {{migration_approach}} - + **Backward Compatibility:** - {{compatibility_measure_1}} - {{compatibility_measure_2}} @@ -2774,12 +2804,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: @@ -2792,15 +2822,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 @@ -2813,7 +2843,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 @@ -2863,17 +2893,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 @@ -2912,7 +2942,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 @@ -2942,7 +2972,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 @@ -2973,7 +3003,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 @@ -3013,7 +3043,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 @@ -3048,7 +3078,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 diff --git a/dist/agents/bmad-master.txt b/dist/agents/bmad-master.txt index 1898b5bd..0e1b5b28 100644 --- a/dist/agents/bmad-master.txt +++ b/dist/agents/bmad-master.txt @@ -248,7 +248,7 @@ Choose a number (0-8) or 9 to proceed: ==================== 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 @@ -2146,20 +2146,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 @@ -2172,16 +2172,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 @@ -2209,7 +2209,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 @@ -2226,17 +2226,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) @@ -2252,23 +2252,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: @@ -2292,13 +2292,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 @@ -2307,11 +2307,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}} @@ -2320,7 +2320,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 @@ -2329,7 +2329,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: @@ -2338,13 +2338,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 @@ -2361,13 +2361,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 @@ -2380,10 +2380,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 @@ -2392,13 +2392,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 @@ -2409,13 +2409,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: | @@ -2432,13 +2432,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 @@ -2448,14 +2448,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: @@ -2473,13 +2473,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: @@ -2515,13 +2515,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: @@ -2568,13 +2568,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: @@ -2596,7 +2596,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}}" @@ -2614,14 +2614,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: @@ -2642,7 +2642,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 @@ -2684,7 +2684,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 @@ -2753,16 +2753,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 @@ -2795,40 +2795,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: @@ -2857,12 +2857,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: @@ -2891,7 +2891,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 @@ -2914,7 +2914,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) @@ -2930,11 +2930,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}} @@ -2946,7 +2946,7 @@ sections: - **Modified Tables:** {{modified_tables_list}} - **New Indexes:** {{new_indexes_list}} - **Migration Strategy:** {{migration_approach}} - + **Backward Compatibility:** - {{compatibility_measure_1}} - {{compatibility_measure_2}} @@ -2955,12 +2955,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: @@ -2973,15 +2973,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 @@ -2994,7 +2994,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 @@ -3044,17 +3044,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 @@ -3093,7 +3093,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 @@ -3123,7 +3123,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 @@ -3154,7 +3154,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 @@ -3194,7 +3194,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 @@ -3229,7 +3229,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 @@ -3274,19 +3274,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 @@ -3312,7 +3312,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 @@ -3436,7 +3436,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}} @@ -3475,7 +3475,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}} @@ -3498,7 +3498,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 @@ -3511,7 +3511,7 @@ sections: - Each story must deliver value while maintaining system integrity template: | **Epic Goal**: {{epic_goal}} - + **Integration Requirements**: {{integration_requirements}} sections: - id: story @@ -3617,7 +3617,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 @@ -3682,7 +3682,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: @@ -3694,7 +3701,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: @@ -3721,7 +3734,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 @@ -3756,7 +3769,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -3853,16 +3866,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 @@ -3878,7 +3891,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 @@ -3886,11 +3899,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 @@ -3912,12 +3925,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}}"] @@ -4062,7 +4087,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. @@ -4071,7 +4096,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 @@ -4112,7 +4137,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 @@ -4142,22 +4167,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 @@ -4166,9 +4191,9 @@ sections: title: "{{flow_name}}" template: | **User Goal:** {{flow_goal}} - + **Entry Points:** {{entry_points}} - + **Success Criteria:** {{success_criteria}} sections: - id: flow-diagram @@ -4199,14 +4224,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 @@ -4225,11 +4250,11 @@ sections: title: "{{component_name}}" template: | **Purpose:** {{component_purpose}} - + **Variants:** {{component_variants}} - + **States:** {{component_states}} - + **Usage Guidelines:** {{usage_guidelines}} - id: branding-style @@ -4275,13 +4300,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 @@ -4299,12 +4324,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}} @@ -4331,11 +4356,11 @@ sections: title: Adaptation Patterns template: | **Layout Changes:** {{layout_adaptations}} - + **Navigation Changes:** {{nav_adaptations}} - + **Content Priority:** {{content_adaptations}} - + **Interaction Changes:** {{interaction_adaptations}} - id: animation @@ -4369,7 +4394,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 @@ -4417,33 +4442,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 @@ -4469,17 +4494,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}} @@ -4489,7 +4514,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 @@ -4511,7 +4536,7 @@ sections: - Databases and storage - External integrations - CDN and caching layers - + Use appropriate diagram type for clarity. - id: architectural-patterns title: Architectural Patterns @@ -4521,7 +4546,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}}" @@ -4535,7 +4560,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 @@ -4544,7 +4569,7 @@ sections: - Testing tools for both frontend and backend - Build and deployment tools - Monitoring and logging - + Upon render, elicit feedback immediately. elicit: true sections: @@ -4554,11 +4579,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}}"] @@ -4579,14 +4622,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 @@ -4595,7 +4638,7 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} @@ -4614,7 +4657,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 @@ -4622,7 +4665,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: @@ -4657,7 +4700,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 @@ -4666,7 +4709,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: @@ -4675,13 +4718,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 @@ -4698,13 +4741,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 @@ -4717,10 +4760,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 @@ -4729,14 +4772,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 @@ -4744,13 +4787,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 @@ -4886,60 +4929,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 @@ -4966,13 +5009,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 @@ -4985,10 +5028,10 @@ sections: template: | # Frontend (.env.local) {{frontend_env_vars}} - + # Backend (.env) {{backend_env_vars}} - + # Shared {{shared_env_vars}} @@ -5005,7 +5048,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}} @@ -5036,12 +5079,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}} @@ -5053,7 +5096,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}} @@ -5069,10 +5112,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 @@ -5191,7 +5234,7 @@ sections: - JavaScript errors - API response times - User interactions - + **Backend Metrics:** - Request rate - Error rate @@ -5336,7 +5379,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}} @@ -5517,7 +5560,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 @@ -5559,7 +5602,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 @@ -5587,9 +5630,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 @@ -5608,11 +5651,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 @@ -5640,7 +5683,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 @@ -5694,12 +5737,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 @@ -5902,7 +5945,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -5919,7 +5962,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 @@ -5931,7 +5974,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -5939,7 +5982,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -5956,7 +5999,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -5980,7 +6023,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -5988,7 +6031,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 @@ -6001,25 +6044,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 diff --git a/dist/agents/pm.txt b/dist/agents/pm.txt index 3f1bb1b6..1248cacd 100644 --- a/dist/agents/pm.txt +++ b/dist/agents/pm.txt @@ -1210,7 +1210,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 @@ -1252,7 +1252,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 @@ -1280,9 +1280,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 @@ -1301,11 +1301,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 @@ -1333,7 +1333,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 @@ -1375,19 +1375,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 @@ -1413,7 +1413,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 @@ -1537,7 +1537,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}} @@ -1576,7 +1576,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}} @@ -1599,7 +1599,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 @@ -1612,7 +1612,7 @@ sections: - Each story must deliver value while maintaining system integrity template: | **Epic Goal**: {{epic_goal}} - + **Integration Requirements**: {{integration_requirements}} sections: - id: story diff --git a/dist/agents/po.txt b/dist/agents/po.txt index 8a06bdde..dd7ea0b4 100644 --- a/dist/agents/po.txt +++ b/dist/agents/po.txt @@ -600,7 +600,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -617,7 +617,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 @@ -629,7 +629,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -637,7 +637,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -654,7 +654,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -678,7 +678,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -686,7 +686,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 @@ -699,25 +699,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 diff --git a/dist/agents/qa.txt b/dist/agents/qa.txt index 368d2a38..909d98cc 100644 --- a/dist/agents/qa.txt +++ b/dist/agents/qa.txt @@ -119,10 +119,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 @@ -284,6 +284,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] @@ -295,26 +297,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 } @@ -326,24 +328,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 @@ -455,11 +457,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 ``` @@ -468,20 +470,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 } ``` @@ -489,20 +491,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 @@ -621,21 +623,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 ``` @@ -657,19 +659,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 @@ -685,11 +687,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 @@ -863,10 +865,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 @@ -936,14 +938,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 @@ -990,20 +992,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 @@ -1029,12 +1031,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 @@ -1219,299 +1221,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:** +## Dependencies ```yaml -unit_test: - component: "PriceCalculator" - scenario: "Calculate discount with multiple rules" - justification: "Complex business logic with multiple branches" - mock_requirements: "None - pure function" +data: + - test-levels-framework.md # Unit/Integration/E2E decision criteria + - test-priorities-matrix.md # P0/P1/P2/P3 classification system ``` -### 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:** - -```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" -``` - -### 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" +- Identify the core functionality to test +- Determine data variations needed +- Consider error conditions +- Note edge cases - - level: integration - what: "Password reset token generation and storage" - why: "Database interaction with expiry logic" +### 2. Apply Test Level Framework - - level: integration - what: "Email service integration" - why: "External service with retry logic" +**Reference:** Load `test-levels-framework.md` for detailed criteria - - level: e2e - what: "Complete password reset flow" - why: "Critical security flow needing full validation" -``` +Quick rules: -### 2. Apply Test Level Heuristics +- **Unit**: Pure logic, algorithms, calculations +- **Integration**: Component interactions, DB operations +- **E2E**: Critical user journeys, compliance -Use these rules to determine appropriate test levels: +### 3. Assign Priorities -```markdown -## Test Level Selection Rules +**Reference:** Load `test-priorities-matrix.md` for classification -### Favor Unit Tests When: +Quick priority assignment: -- Logic can be isolated -- No side effects involved -- Fast feedback needed -- High cyclomatic complexity +- **P0**: Revenue-critical, security, compliance +- **P1**: Core user journeys, frequently used +- **P2**: Secondary features, admin functions +- **P3**: Nice-to-have, rarely used -### Favor Integration Tests When: +### 4. Design Test Scenarios -- 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:** - -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? - -**Coverage overlap is only acceptable when:** - -- 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}` - -- Example: `1.3-UNIT-001`, `1.3-INT-002`, `1.3-E2E-001` -- Ensures traceability across all artifacts - -**Naming Convention:** - -- Unit: `test_{component}_{scenario}` -- Integration: `test_{flow}_{interaction}` -- E2E: `test_{journey}_{outcome}` - -**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 +### 5. Validate Coverage -**Per Acceptance Criterion:** +Ensure: -- 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 - -### Core Testing Principles - -**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 @@ -1519,13 +1301,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 @@ -1533,212 +1313,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 +## Test Scenarios by Acceptance Criteria -[Explain why this distribution was chosen] +### AC1: {description} -## Detailed Test Scenarios +#### Scenarios -### Requirement: AC1 - {description} +| 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 | -#### Unit Tests (3 scenarios) +[Continue for all ACs...] -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) +## Risk Coverage -#### Integration Tests (2 scenarios) +[Map test scenarios to identified risks if risk profile exists] -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 +## Recommended Execution Order -#### 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 - -### What to Mock - -- External services (payment, email) -- Time-dependent functions -- Random number generators - -### What NOT to Mock - -- 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 - -### Integration Coverage - -- Target: All API endpoints -- Focus: Contract validation - -### E2E Coverage - -- 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 +### Output 2: Gate YAML Block -### Over-testing Smells +Generate for inclusion in quality gate: -- Same logic tested at multiple levels -- E2E tests for calculations -- Integration tests for framework features +```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 +``` -### Under-testing Smells +### Output 3: Trace References -- No unit tests for complex logic -- Missing integration tests for data operations -- No E2E tests for critical user paths +Print for use by trace-requirements task: -### Wrong Level Smells +```text +Test design matrix: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md +P0 tests identified: {count} +``` -- Unit tests with real database -- E2E tests checking calculation results -- Integration tests mocking everything +## Quality Checklist -## Quality Indicators +Before finalizing, verify: -Good test design shows: - -- Clear level separation -- No redundant coverage -- Fast feedback from unit tests -- Reliable integration tests -- Focused e2e tests +- [ ] 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 ## 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) - -### Output 2: Story Hook Line - -**Print this line for review task to quote:** - -```text -Test design: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md -``` - -**For traceability:** This planning document will be referenced by trace-requirements task. - -### Output 3: Test Count Summary - -**Print summary for quick reference:** - -```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 -``` +- **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 ==================== @@ -1750,12 +1398,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 ``` @@ -1836,16 +1484,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 @@ -2075,10 +1723,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 @@ -2102,7 +1750,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -2119,7 +1767,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 @@ -2131,7 +1779,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -2139,7 +1787,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -2156,7 +1804,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -2180,7 +1828,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -2188,7 +1836,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 @@ -2201,25 +1849,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 @@ -2241,8 +1889,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}}" @@ -2259,68 +1907,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" +# 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" -# Example when waived: -# waiver: -# active: true -# reason: "Accepted for MVP release - will address in next sprint" -# approved_by: "Product Owner" + 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 +optional_fields_examples: + quality_and_expiry: | + 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 + 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: -# security: { status: CONCERNS, notes: "Rate limiting missing" } -# performance: { status: PASS, notes: "" } -# reliability: { status: PASS, notes: "" } -# maintainability: { status: PASS, notes: "" } + nfr_validation: | + 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" + 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: # From risk-profile task -# totals: -# critical: 0 -# high: 0 -# medium: 0 -# low: 0 -# # 'highest' is emitted only when risks exist -# recommendations: -# must_fix: [] -# monitor: [] + 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: -# 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"] + 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/data/technical-preferences.md ==================== diff --git a/dist/agents/sm.txt b/dist/agents/sm.txt index ff1a7ae2..e0fbe32b 100644 --- a/dist/agents/sm.txt +++ b/dist/agents/sm.txt @@ -376,7 +376,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -393,7 +393,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 @@ -405,7 +405,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -413,7 +413,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -430,7 +430,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -454,7 +454,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -462,7 +462,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 @@ -475,25 +475,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 diff --git a/dist/agents/ux-expert.txt b/dist/agents/ux-expert.txt index d6bf6596..e1855b09 100644 --- a/dist/agents/ux-expert.txt +++ b/dist/agents/ux-expert.txt @@ -354,7 +354,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. @@ -363,7 +363,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 @@ -404,7 +404,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 @@ -434,22 +434,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 @@ -458,9 +458,9 @@ sections: title: "{{flow_name}}" template: | **User Goal:** {{flow_goal}} - + **Entry Points:** {{entry_points}} - + **Success Criteria:** {{success_criteria}} sections: - id: flow-diagram @@ -491,14 +491,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 @@ -517,11 +517,11 @@ sections: title: "{{component_name}}" template: | **Purpose:** {{component_purpose}} - + **Variants:** {{component_variants}} - + **States:** {{component_states}} - + **Usage Guidelines:** {{usage_guidelines}} - id: branding-style @@ -567,13 +567,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 @@ -591,12 +591,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}} @@ -623,11 +623,11 @@ sections: title: Adaptation Patterns template: | **Layout Changes:** {{layout_adaptations}} - + **Navigation Changes:** {{nav_adaptations}} - + **Content Priority:** {{content_adaptations}} - + **Interaction Changes:** {{interaction_adaptations}} - id: animation @@ -661,7 +661,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 diff --git a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.txt b/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.txt index 221c4565..b5fa9723 100644 --- a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.txt +++ b/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-designer.txt @@ -991,7 +991,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features. - + If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis - id: executive-summary @@ -1036,7 +1036,7 @@ sections: instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions. template: | **Primary Loop ({{duration}} seconds):** - + 1. {{action_1}} ({{time_1}}s) 2. {{action_2}} ({{time_2}}s) 3. {{action_3}} ({{time_3}}s) @@ -1046,12 +1046,12 @@ sections: instruction: Clearly define success and failure states template: | **Victory Conditions:** - + - {{win_condition_1}} - {{win_condition_2}} - + **Failure States:** - + - {{loss_condition_1}} - {{loss_condition_2}} @@ -1067,17 +1067,17 @@ sections: title: "{{mechanic_name}}" template: | **Description:** {{detailed_description}} - + **Player Input:** {{input_method}} - + **System Response:** {{game_response}} - + **Implementation Notes:** - + - {{tech_requirement_1}} - {{tech_requirement_2}} - {{performance_consideration}} - + **Dependencies:** {{other_mechanics_needed}} - id: controls title: Controls @@ -1096,9 +1096,9 @@ sections: title: Player Progression template: | **Progression Type:** {{linear|branching|metroidvania}} - + **Key Milestones:** - + 1. **{{milestone_1}}** - {{unlock_description}} 2. **{{milestone_2}}** - {{unlock_description}} 3. **{{milestone_3}}** - {{unlock_description}} @@ -1135,9 +1135,9 @@ sections: **Duration:** {{target_time}} **Key Elements:** {{required_mechanics}} **Difficulty:** {{relative_difficulty}} - + **Structure Template:** - + - Introduction: {{intro_description}} - Challenge: {{main_challenge}} - Resolution: {{completion_requirement}} @@ -1163,13 +1163,13 @@ sections: title: Platform Specific template: | **Desktop:** - + - Resolution: {{min_resolution}} - {{max_resolution}} - Input: Keyboard, Mouse, Gamepad - Browser: Chrome 80+, Firefox 75+, Safari 13+ - + **Mobile:** - + - Resolution: {{mobile_min}} - {{mobile_max}} - Input: Touch, Tilt (optional) - OS: iOS 13+, Android 8+ @@ -1178,14 +1178,14 @@ sections: instruction: Define asset specifications for the art and audio teams template: | **Visual Assets:** - + - Art Style: {{style_description}} - Color Palette: {{color_specification}} - Animation: {{animation_requirements}} - UI Resolution: {{ui_specs}} - + **Audio Assets:** - + - Music Style: {{music_genre}} - Sound Effects: {{sfx_requirements}} - Voice Acting: {{voice_needs}} @@ -1198,7 +1198,7 @@ sections: title: Engine Configuration template: | **Phaser 3 Setup:** - + - TypeScript: Strict mode enabled - Physics: {{physics_system}} (Arcade/Matter) - Renderer: WebGL with Canvas fallback @@ -1207,7 +1207,7 @@ sections: title: Code Architecture template: | **Required Systems:** - + - Scene Management - State Management - Asset Loading @@ -1219,7 +1219,7 @@ sections: title: Data Management template: | **Save Data:** - + - Progress tracking - Settings persistence - Statistics collection @@ -1337,7 +1337,7 @@ sections: - id: initial-setup instruction: | This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels. - + If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents. - id: introduction @@ -1345,7 +1345,7 @@ sections: instruction: Establish the purpose and scope of level design for this game content: | This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document. - + This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints. sections: - id: change-log @@ -1392,29 +1392,29 @@ sections: title: "{{category_name}} Levels" template: | **Purpose:** {{gameplay_purpose}} - + **Target Duration:** {{min_time}} - {{max_time}} minutes - + **Difficulty Range:** {{difficulty_scale}} - + **Key Mechanics Featured:** - + - {{mechanic_1}} - {{usage_description}} - {{mechanic_2}} - {{usage_description}} - + **Player Objectives:** - + - Primary: {{primary_objective}} - Secondary: {{secondary_objective}} - Hidden: {{secret_objective}} - + **Success Criteria:** - + - {{completion_requirement_1}} - {{completion_requirement_2}} - + **Technical Requirements:** - + - Maximum entities: {{entity_limit}} - Performance target: {{fps_target}} FPS - Memory budget: {{memory_limit}}MB @@ -1429,11 +1429,11 @@ sections: instruction: Based on GDD requirements, define the overall level organization template: | **Organization Type:** {{linear|hub_world|open_world}} - + **Total Level Count:** {{number}} - + **World Breakdown:** - + - World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}} @@ -1468,7 +1468,7 @@ sections: instruction: Define how players access new levels template: | **Progression Gates:** - + - Linear progression: Complete previous level - Star requirements: {{star_count}} stars to unlock - Skill gates: Demonstrate {{skill_requirement}} @@ -1483,17 +1483,17 @@ sections: instruction: Define all environmental components that can be used in levels template: | **Terrain Types:** - + - {{terrain_1}}: {{properties_and_usage}} - {{terrain_2}}: {{properties_and_usage}} - + **Interactive Objects:** - + - {{object_1}}: {{behavior_and_purpose}} - {{object_2}}: {{behavior_and_purpose}} - + **Hazards and Obstacles:** - + - {{hazard_1}}: {{damage_and_behavior}} - {{hazard_2}}: {{damage_and_behavior}} - id: collectibles-rewards @@ -1501,18 +1501,18 @@ sections: instruction: Define all collectible items and their placement rules template: | **Collectible Types:** - + - {{collectible_1}}: {{value_and_purpose}} - {{collectible_2}}: {{value_and_purpose}} - + **Placement Guidelines:** - + - Mandatory collectibles: {{placement_rules}} - Optional collectibles: {{placement_rules}} - Secret collectibles: {{placement_rules}} - + **Reward Distribution:** - + - Easy to find: {{percentage}}% - Moderate challenge: {{percentage}}% - High skill required: {{percentage}}% @@ -1521,18 +1521,18 @@ sections: instruction: Define how enemies should be placed and balanced in levels template: | **Enemy Categories:** - + - {{enemy_type_1}}: {{behavior_and_usage}} - {{enemy_type_2}}: {{behavior_and_usage}} - + **Placement Principles:** - + - Introduction encounters: {{guideline}} - Standard encounters: {{guideline}} - Challenge encounters: {{guideline}} - + **Difficulty Scaling:** - + - Enemy count progression: {{scaling_rule}} - Enemy type introduction: {{pacing_rule}} - Encounter complexity: {{complexity_rule}} @@ -1545,14 +1545,14 @@ sections: title: Level Layout Principles template: | **Spatial Design:** - + - Grid size: {{grid_dimensions}} - Minimum path width: {{width_units}} - Maximum vertical distance: {{height_units}} - Safe zones placement: {{safety_guidelines}} - + **Navigation Design:** - + - Clear path indication: {{visual_cues}} - Landmark placement: {{landmark_rules}} - Dead end avoidance: {{dead_end_policy}} @@ -1562,13 +1562,13 @@ sections: instruction: Define how to control the rhythm and pace of gameplay within levels template: | **Action Sequences:** - + - High intensity duration: {{max_duration}} - Rest period requirement: {{min_rest_time}} - Intensity variation: {{pacing_pattern}} - + **Learning Sequences:** - + - New mechanic introduction: {{teaching_method}} - Practice opportunity: {{practice_duration}} - Skill application: {{application_context}} @@ -1577,14 +1577,14 @@ sections: instruction: Define how to create appropriate challenges for each level type template: | **Challenge Types:** - + - Execution challenges: {{skill_requirements}} - Puzzle challenges: {{complexity_guidelines}} - Time challenges: {{time_pressure_rules}} - Resource challenges: {{resource_management}} - + **Difficulty Calibration:** - + - Skill check frequency: {{frequency_guidelines}} - Failure recovery: {{retry_mechanics}} - Hint system integration: {{help_system}} @@ -1598,7 +1598,7 @@ sections: instruction: Define how level data should be structured for implementation template: | **Level File Format:** - + - Data format: {{json|yaml|custom}} - File naming: `level_{{world}}_{{number}}.{{extension}}` - Data organization: {{structure_description}} @@ -1636,14 +1636,14 @@ sections: instruction: Define how level assets are organized and loaded template: | **Tilemap Requirements:** - + - Tile size: {{tile_dimensions}}px - Tileset organization: {{tileset_structure}} - Layer organization: {{layer_system}} - Collision data: {{collision_format}} - + **Audio Integration:** - + - Background music: {{music_requirements}} - Ambient sounds: {{ambient_system}} - Dynamic audio: {{dynamic_audio_rules}} @@ -1652,19 +1652,19 @@ sections: instruction: Define performance requirements for level systems template: | **Entity Limits:** - + - Maximum active entities: {{entity_limit}} - Maximum particles: {{particle_limit}} - Maximum audio sources: {{audio_limit}} - + **Memory Management:** - + - Texture memory budget: {{texture_memory}}MB - Audio memory budget: {{audio_memory}}MB - Level loading time: <{{load_time}}s - + **Culling and LOD:** - + - Off-screen culling: {{culling_distance}} - Level-of-detail rules: {{lod_system}} - Asset streaming: {{streaming_requirements}} @@ -1677,13 +1677,13 @@ sections: title: Automated Testing template: | **Performance Testing:** - + - Frame rate validation: Maintain {{fps_target}} FPS - Memory usage monitoring: Stay under {{memory_limit}}MB - Loading time verification: Complete in <{{load_time}}s - + **Gameplay Testing:** - + - Completion path validation: All objectives achievable - Collectible accessibility: All items reachable - Softlock prevention: No unwinnable states @@ -1711,14 +1711,14 @@ sections: title: Balance Validation template: | **Metrics Collection:** - + - Completion rate: Target {{completion_percentage}}% - Average completion time: {{target_time}} ± {{variance}} - Death count per level: <{{max_deaths}} - Collectible discovery rate: {{discovery_percentage}}% - + **Iteration Guidelines:** - + - Adjustment criteria: {{criteria_for_changes}} - Testing sample size: {{minimum_testers}} - Validation period: {{testing_duration}} @@ -1731,14 +1731,14 @@ sections: title: Design Phase template: | **Concept Development:** - + 1. Define level purpose and goals 2. Create rough layout sketch 3. Identify key mechanics and challenges 4. Estimate difficulty and duration - + **Documentation Requirements:** - + - Level design brief - Layout diagrams - Mechanic integration notes @@ -1747,15 +1747,15 @@ sections: title: Implementation Phase template: | **Technical Implementation:** - + 1. Create level data file 2. Build tilemap and layout 3. Place entities and objects 4. Configure level logic and triggers 5. Integrate audio and visual effects - + **Quality Assurance:** - + 1. Automated testing execution 2. Internal playtesting 3. Performance validation @@ -1764,14 +1764,14 @@ sections: title: Integration Phase template: | **Game Integration:** - + 1. Level progression integration 2. Save system compatibility 3. Analytics integration 4. Achievement system integration - + **Final Validation:** - + 1. Full game context testing 2. Performance regression testing 3. Platform compatibility verification @@ -1824,7 +1824,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document. - + This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design. - id: game-vision @@ -1881,7 +1881,7 @@ sections: repeatable: true template: | **Core Mechanic: {{mechanic_name}}** - + - **Description:** {{how_it_works}} - **Player Value:** {{why_its_fun}} - **Implementation Scope:** {{complexity_estimate}} @@ -1908,12 +1908,12 @@ sections: title: Technical Constraints template: | **Platform Requirements:** - + - Primary: {{platform_1}} - {{requirements}} - Secondary: {{platform_2}} - {{requirements}} - + **Technical Specifications:** - + - Engine: Phaser 3 + TypeScript - Performance Target: {{fps_target}} FPS on {{target_device}} - Memory Budget: <{{memory_limit}}MB @@ -1951,10 +1951,10 @@ sections: title: Competitive Analysis template: | **Direct Competitors:** - + - {{competitor_1}}: {{strengths_and_weaknesses}} - {{competitor_2}}: {{strengths_and_weaknesses}} - + **Differentiation Strategy:** {{how_we_differ_and_why_thats_valuable}} - id: market-opportunity @@ -1978,16 +1978,16 @@ sections: title: Content Categories template: | **Core Content:** - + - {{content_type_1}}: {{quantity_and_description}} - {{content_type_2}}: {{quantity_and_description}} - + **Optional Content:** - + - {{optional_content_type}}: {{quantity_and_description}} - + **Replay Elements:** - + - {{replayability_features}} - id: difficulty-accessibility title: Difficulty and Accessibility @@ -2054,13 +2054,13 @@ sections: title: Player Experience Metrics template: | **Engagement Goals:** - + - Tutorial completion rate: >{{percentage}}% - Average session length: {{duration}} minutes - Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}% - + **Quality Benchmarks:** - + - Player satisfaction: >{{rating}}/10 - Completion rate: >{{percentage}}% - Technical performance: {{fps_target}} FPS consistent @@ -2068,13 +2068,13 @@ sections: title: Development Metrics template: | **Technical Targets:** - + - Zero critical bugs at launch - Performance targets met on all platforms - Load times under {{seconds}}s - + **Process Goals:** - + - Development timeline adherence - Feature scope completion - Quality assurance standards @@ -2083,7 +2083,7 @@ sections: condition: has_business_goals template: | **Commercial Goals:** - + - {{revenue_target}} in first {{time_period}} - {{user_acquisition_target}} players in first {{time_period}} - {{retention_target}} monthly active users @@ -2136,12 +2136,12 @@ sections: title: Validation Plan template: | **Concept Testing:** - + - {{validation_method_1}} - {{timeline}} - {{validation_method_2}} - {{timeline}} - + **Prototype Testing:** - + - {{testing_approach}} - {{timeline}} - {{feedback_collection_method}} - {{timeline}} diff --git a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt b/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt index 8a7a0f3d..e8b10de4 100644 --- a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt +++ b/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-developer.txt @@ -207,7 +207,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics. - + If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD. - id: introduction @@ -215,7 +215,7 @@ sections: instruction: Establish the document's purpose and scope for game development content: | This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems. - + This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility. sections: - id: change-log @@ -234,7 +234,7 @@ sections: title: Architecture Summary instruction: | Provide a comprehensive overview covering: - + - Game engine choice and configuration - Project structure and organization - Key systems and their interactions @@ -322,23 +322,23 @@ sections: title: Scene Management System template: | **Purpose:** Handle game flow and scene transitions - + **Key Components:** - + - Scene loading and unloading - Data passing between scenes - Transition effects - Memory management - + **Implementation Requirements:** - + - Preload scene for asset loading - Menu system with navigation - Gameplay scenes with state management - Pause/resume functionality - + **Files to Create:** - + - `src/scenes/BootScene.ts` - `src/scenes/PreloadScene.ts` - `src/scenes/MenuScene.ts` @@ -348,23 +348,23 @@ sections: title: Game State Management template: | **Purpose:** Track player progress and game status - + **State Categories:** - + - Player progress (levels, unlocks) - Game settings (audio, controls) - Session data (current level, score) - Persistent data (achievements, statistics) - + **Implementation Requirements:** - + - Save/load system with localStorage - State validation and error recovery - Cross-session data persistence - Settings management - + **Files to Create:** - + - `src/systems/GameState.ts` - `src/systems/SaveManager.ts` - `src/types/GameData.ts` @@ -372,23 +372,23 @@ sections: title: Asset Management System template: | **Purpose:** Efficient loading and management of game assets - + **Asset Categories:** - + - Sprite sheets and animations - Audio files and music - Level data and configurations - UI assets and fonts - + **Implementation Requirements:** - + - Progressive loading strategy - Asset caching and optimization - Error handling for failed loads - Memory management for large assets - + **Files to Create:** - + - `src/systems/AssetManager.ts` - `src/config/AssetConfig.ts` - `src/utils/AssetLoader.ts` @@ -396,23 +396,23 @@ sections: title: Input Management System template: | **Purpose:** Handle all player input across platforms - + **Input Types:** - + - Keyboard controls - Mouse/pointer interaction - Touch gestures (mobile) - Gamepad support (optional) - + **Implementation Requirements:** - + - Input mapping and configuration - Touch-friendly mobile controls - Input buffering for responsive gameplay - Customizable control schemes - + **Files to Create:** - + - `src/systems/InputManager.ts` - `src/utils/TouchControls.ts` - `src/types/InputTypes.ts` @@ -425,19 +425,19 @@ sections: title: "{{mechanic_name}} System" template: | **Purpose:** {{system_purpose}} - + **Core Functionality:** - + - {{feature_1}} - {{feature_2}} - {{feature_3}} - + **Dependencies:** {{required_systems}} - + **Performance Considerations:** {{optimization_notes}} - + **Files to Create:** - + - `src/systems/{{system_name}}.ts` - `src/gameObjects/{{related_object}}.ts` - `src/types/{{system_types}}.ts` @@ -445,65 +445,65 @@ sections: title: Physics & Collision System template: | **Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js) - + **Collision Categories:** - + - Player collision - Enemy interactions - Environmental objects - Collectibles and items - + **Implementation Requirements:** - + - Optimized collision detection - Physics body management - Collision callbacks and events - Performance monitoring - + **Files to Create:** - + - `src/systems/PhysicsManager.ts` - `src/utils/CollisionGroups.ts` - id: audio-system title: Audio System template: | **Audio Requirements:** - + - Background music with looping - Sound effects for actions - Audio settings and volume control - Mobile audio optimization - + **Implementation Features:** - + - Audio sprite management - Dynamic music system - Spatial audio (if applicable) - Audio pooling for performance - + **Files to Create:** - + - `src/systems/AudioManager.ts` - `src/config/AudioConfig.ts` - id: ui-system title: UI System template: | **UI Components:** - + - HUD elements (score, health, etc.) - Menu navigation - Modal dialogs - Settings screens - + **Implementation Requirements:** - + - Responsive layout system - Touch-friendly interface - Keyboard navigation support - Animation and transitions - + **Files to Create:** - + - `src/systems/UIManager.ts` - `src/gameObjects/UI/` - `src/types/UITypes.ts` @@ -1045,7 +1045,7 @@ interface GameState { interface GameSettings { musicVolume: number; sfxVolume: number; - difficulty: "easy" | "normal" | "hard"; + difficulty: 'easy' | 'normal' | 'hard'; controls: ControlScheme; } ``` @@ -1086,12 +1086,12 @@ class GameScene extends Phaser.Scene { private inputManager!: InputManager; constructor() { - super({ key: "GameScene" }); + super({ key: 'GameScene' }); } preload(): void { // Load only scene-specific assets - this.load.image("player", "assets/player.png"); + this.load.image('player', 'assets/player.png'); } create(data: SceneData): void { @@ -1116,7 +1116,7 @@ class GameScene extends Phaser.Scene { this.inputManager.destroy(); // Remove event listeners - this.events.off("*"); + this.events.off('*'); } } ``` @@ -1125,13 +1125,13 @@ class GameScene extends Phaser.Scene { ```typescript // Proper scene transitions with data -this.scene.start("NextScene", { +this.scene.start('NextScene', { playerScore: this.playerScore, currentLevel: this.currentLevel + 1, }); // Scene overlays for UI -this.scene.launch("PauseMenuScene"); +this.scene.launch('PauseMenuScene'); this.scene.pause(); ``` @@ -1175,7 +1175,7 @@ class Player extends GameEntity { private health!: HealthComponent; constructor(scene: Phaser.Scene, x: number, y: number) { - super(scene, x, y, "player"); + super(scene, x, y, 'player'); this.movement = this.addComponent(new MovementComponent(this)); this.health = this.addComponent(new HealthComponent(this, 100)); @@ -1195,7 +1195,7 @@ class GameManager { constructor(scene: Phaser.Scene) { if (GameManager.instance) { - throw new Error("GameManager already exists!"); + throw new Error('GameManager already exists!'); } this.scene = scene; @@ -1205,7 +1205,7 @@ class GameManager { static getInstance(): GameManager { if (!GameManager.instance) { - throw new Error("GameManager not initialized!"); + throw new Error('GameManager not initialized!'); } return GameManager.instance; } @@ -1252,7 +1252,7 @@ class BulletPool { } // Pool exhausted - create new bullet - console.warn("Bullet pool exhausted, creating new bullet"); + console.warn('Bullet pool exhausted, creating new bullet'); return new Bullet(this.scene, 0, 0); } @@ -1352,14 +1352,12 @@ class InputManager { } private setupKeyboard(): void { - this.keys = this.scene.input.keyboard.addKeys( - "W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT", - ); + this.keys = this.scene.input.keyboard.addKeys('W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT'); } private setupTouch(): void { - this.scene.input.on("pointerdown", this.handlePointerDown, this); - this.scene.input.on("pointerup", this.handlePointerUp, this); + this.scene.input.on('pointerdown', this.handlePointerDown, this); + this.scene.input.on('pointerup', this.handlePointerUp, this); } update(): void { @@ -1386,9 +1384,9 @@ class InputManager { class AssetManager { loadAssets(): Promise { return new Promise((resolve, reject) => { - this.scene.load.on("filecomplete", this.handleFileComplete, this); - this.scene.load.on("loaderror", this.handleLoadError, this); - this.scene.load.on("complete", () => resolve()); + this.scene.load.on('filecomplete', this.handleFileComplete, this); + this.scene.load.on('loaderror', this.handleLoadError, this); + this.scene.load.on('complete', () => resolve()); this.scene.load.start(); }); @@ -1404,8 +1402,8 @@ class AssetManager { private loadFallbackAsset(key: string): void { // Load placeholder or default assets switch (key) { - case "player": - this.scene.load.image("player", "assets/defaults/default-player.png"); + case 'player': + this.scene.load.image('player', 'assets/defaults/default-player.png'); break; default: console.warn(`No fallback for asset: ${key}`); @@ -1432,11 +1430,11 @@ class GameSystem { private attemptRecovery(context: string): void { switch (context) { - case "update": + case 'update': // Reset system state this.reset(); break; - case "render": + case 'render': // Disable visual effects this.disableEffects(); break; @@ -1456,7 +1454,7 @@ class GameSystem { ```typescript // Example test for game mechanics -describe("HealthComponent", () => { +describe('HealthComponent', () => { let healthComponent: HealthComponent; beforeEach(() => { @@ -1464,18 +1462,18 @@ describe("HealthComponent", () => { healthComponent = new HealthComponent(mockEntity, 100); }); - test("should initialize with correct health", () => { + test('should initialize with correct health', () => { expect(healthComponent.currentHealth).toBe(100); expect(healthComponent.maxHealth).toBe(100); }); - test("should handle damage correctly", () => { + test('should handle damage correctly', () => { healthComponent.takeDamage(25); expect(healthComponent.currentHealth).toBe(75); expect(healthComponent.isAlive()).toBe(true); }); - test("should handle death correctly", () => { + test('should handle death correctly', () => { healthComponent.takeDamage(150); expect(healthComponent.currentHealth).toBe(0); expect(healthComponent.isAlive()).toBe(false); @@ -1488,7 +1486,7 @@ describe("HealthComponent", () => { **Scene Testing:** ```typescript -describe("GameScene Integration", () => { +describe('GameScene Integration', () => { let scene: GameScene; let mockGame: Phaser.Game; @@ -1498,7 +1496,7 @@ describe("GameScene Integration", () => { scene = new GameScene(); }); - test("should initialize all systems", () => { + test('should initialize all systems', () => { scene.create({}); expect(scene.gameManager).toBeDefined(); diff --git a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.txt b/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.txt index 0612630f..c38591de 100644 --- a/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.txt +++ b/dist/expansion-packs/bmad-2d-phaser-game-dev/agents/game-sm.txt @@ -412,13 +412,13 @@ sections: - id: initial-setup instruction: | This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality. - + Before starting, ensure you have access to: - + - Game Design Document (GDD) - Game Architecture Document - Any existing stories in this epic - + The story should be specific enough that a developer can implement it without requiring additional design decisions. - id: story-header @@ -467,12 +467,12 @@ sections: title: Files to Create/Modify template: | **New Files:** - + - `{{file_path_1}}` - {{purpose}} - `{{file_path_2}}` - {{purpose}} - + **Modified Files:** - + - `{{existing_file_1}}` - {{changes_needed}} - `{{existing_file_2}}` - {{changes_needed}} - id: class-interface-definitions @@ -487,15 +487,15 @@ sections: {{property_2}}: {{type}}; {{method_1}}({{params}}): {{return_type}}; } - + // {{class_name}} class {{class_name}} extends {{phaser_class}} { private {{property}}: {{type}}; - + constructor({{params}}) { // Implementation requirements } - + public {{method}}({{params}}): {{return_type}} { // Method requirements } @@ -505,15 +505,15 @@ sections: instruction: Specify how this feature integrates with existing systems template: | **Scene Integration:** - + - {{scene_name}}: {{integration_details}} - + **System Dependencies:** - + - {{system_name}}: {{dependency_description}} - + **Event Communication:** - + - Emits: `{{event_name}}` when {{condition}} - Listens: `{{event_name}}` to {{response}} @@ -525,7 +525,7 @@ sections: title: Dev Agent Record template: | **Tasks:** - + - [ ] {{task_1_description}} - [ ] {{task_2_description}} - [ ] {{task_3_description}} @@ -533,18 +533,18 @@ sections: - [ ] Write unit tests for {{component}} - [ ] Integration testing with {{related_system}} - [ ] Performance testing and optimization - + **Debug Log:** | Task | File | Change | Reverted? | |------|------|--------|-----------| | | | | | - + **Completion Notes:** - + - + **Change Log:** - + - id: game-design-context @@ -552,13 +552,13 @@ sections: instruction: Reference the specific sections of the GDD that this story implements template: | **GDD Reference:** {{section_name}} ({{page_or_section_number}}) - + **Game Mechanic:** {{mechanic_name}} - + **Player Experience Goal:** {{experience_description}} - + **Balance Parameters:** - + - {{parameter_1}}: {{value_or_range}} - {{parameter_2}}: {{value_or_range}} @@ -570,11 +570,11 @@ sections: title: Unit Tests template: | **Test Files:** - + - `tests/{{component_name}}.test.ts` - + **Test Scenarios:** - + - {{test_scenario_1}} - {{test_scenario_2}} - {{edge_case_test}} @@ -582,12 +582,12 @@ sections: title: Game Testing template: | **Manual Test Cases:** - + 1. {{test_case_1_description}} - + - Expected: {{expected_behavior}} - Performance: {{performance_expectation}} - + 2. {{test_case_2_description}} - Expected: {{expected_behavior}} - Edge Case: {{edge_case_handling}} @@ -595,7 +595,7 @@ sections: title: Performance Tests template: | **Metrics to Verify:** - + - Frame rate maintains {{fps_target}} FPS - Memory usage stays under {{memory_limit}}MB - {{feature_specific_performance_metric}} @@ -605,15 +605,15 @@ sections: instruction: List any dependencies that must be completed before this story can be implemented template: | **Story Dependencies:** - + - {{story_id}}: {{dependency_description}} - + **Technical Dependencies:** - + - {{system_or_file}}: {{requirement}} - + **Asset Dependencies:** - + - {{asset_type}}: {{asset_description}} - Location: `{{asset_path}}` @@ -636,17 +636,17 @@ sections: instruction: Any additional context, design decisions, or implementation notes template: | **Implementation Notes:** - + - {{note_1}} - {{note_2}} - + **Design Decisions:** - + - {{decision_1}}: {{rationale}} - {{decision_2}}: {{rationale}} - + **Future Considerations:** - + - {{future_enhancement_1}} - {{future_optimization_1}} ==================== END: .bmad-2d-phaser-game-dev/templates/game-story-tmpl.yaml ==================== diff --git a/dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt b/dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt index cb03a56e..2f275ee6 100644 --- a/dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt +++ b/dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt @@ -420,7 +420,7 @@ dependencies: ==================== START: .bmad-2d-phaser-game-dev/tasks/facilitate-brainstorming-session.md ==================== --- docOutputLocation: docs/brainstorming-session-results.md -template: ".bmad-2d-phaser-game-dev/templates/brainstorming-output-tmpl.yaml" +template: '.bmad-2d-phaser-game-dev/templates/brainstorming-output-tmpl.yaml' --- # Facilitate Brainstorming Session Task @@ -1431,12 +1431,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 @@ -1757,7 +1757,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}} @@ -1958,7 +1958,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 @@ -2023,7 +2023,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: @@ -2035,7 +2042,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: @@ -2062,7 +2075,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 @@ -2097,7 +2110,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -2201,11 +2214,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:" @@ -2330,7 +2343,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-2d-phaser-game-dev/templates/brainstorming-output-tmpl.yaml ==================== @@ -3332,7 +3345,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features. - + If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis - id: executive-summary @@ -3377,7 +3390,7 @@ sections: instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions. template: | **Primary Loop ({{duration}} seconds):** - + 1. {{action_1}} ({{time_1}}s) 2. {{action_2}} ({{time_2}}s) 3. {{action_3}} ({{time_3}}s) @@ -3387,12 +3400,12 @@ sections: instruction: Clearly define success and failure states template: | **Victory Conditions:** - + - {{win_condition_1}} - {{win_condition_2}} - + **Failure States:** - + - {{loss_condition_1}} - {{loss_condition_2}} @@ -3408,17 +3421,17 @@ sections: title: "{{mechanic_name}}" template: | **Description:** {{detailed_description}} - + **Player Input:** {{input_method}} - + **System Response:** {{game_response}} - + **Implementation Notes:** - + - {{tech_requirement_1}} - {{tech_requirement_2}} - {{performance_consideration}} - + **Dependencies:** {{other_mechanics_needed}} - id: controls title: Controls @@ -3437,9 +3450,9 @@ sections: title: Player Progression template: | **Progression Type:** {{linear|branching|metroidvania}} - + **Key Milestones:** - + 1. **{{milestone_1}}** - {{unlock_description}} 2. **{{milestone_2}}** - {{unlock_description}} 3. **{{milestone_3}}** - {{unlock_description}} @@ -3476,9 +3489,9 @@ sections: **Duration:** {{target_time}} **Key Elements:** {{required_mechanics}} **Difficulty:** {{relative_difficulty}} - + **Structure Template:** - + - Introduction: {{intro_description}} - Challenge: {{main_challenge}} - Resolution: {{completion_requirement}} @@ -3504,13 +3517,13 @@ sections: title: Platform Specific template: | **Desktop:** - + - Resolution: {{min_resolution}} - {{max_resolution}} - Input: Keyboard, Mouse, Gamepad - Browser: Chrome 80+, Firefox 75+, Safari 13+ - + **Mobile:** - + - Resolution: {{mobile_min}} - {{mobile_max}} - Input: Touch, Tilt (optional) - OS: iOS 13+, Android 8+ @@ -3519,14 +3532,14 @@ sections: instruction: Define asset specifications for the art and audio teams template: | **Visual Assets:** - + - Art Style: {{style_description}} - Color Palette: {{color_specification}} - Animation: {{animation_requirements}} - UI Resolution: {{ui_specs}} - + **Audio Assets:** - + - Music Style: {{music_genre}} - Sound Effects: {{sfx_requirements}} - Voice Acting: {{voice_needs}} @@ -3539,7 +3552,7 @@ sections: title: Engine Configuration template: | **Phaser 3 Setup:** - + - TypeScript: Strict mode enabled - Physics: {{physics_system}} (Arcade/Matter) - Renderer: WebGL with Canvas fallback @@ -3548,7 +3561,7 @@ sections: title: Code Architecture template: | **Required Systems:** - + - Scene Management - State Management - Asset Loading @@ -3560,7 +3573,7 @@ sections: title: Data Management template: | **Save Data:** - + - Progress tracking - Settings persistence - Statistics collection @@ -3678,7 +3691,7 @@ sections: - id: initial-setup instruction: | This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels. - + If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents. - id: introduction @@ -3686,7 +3699,7 @@ sections: instruction: Establish the purpose and scope of level design for this game content: | This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document. - + This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints. sections: - id: change-log @@ -3733,29 +3746,29 @@ sections: title: "{{category_name}} Levels" template: | **Purpose:** {{gameplay_purpose}} - + **Target Duration:** {{min_time}} - {{max_time}} minutes - + **Difficulty Range:** {{difficulty_scale}} - + **Key Mechanics Featured:** - + - {{mechanic_1}} - {{usage_description}} - {{mechanic_2}} - {{usage_description}} - + **Player Objectives:** - + - Primary: {{primary_objective}} - Secondary: {{secondary_objective}} - Hidden: {{secret_objective}} - + **Success Criteria:** - + - {{completion_requirement_1}} - {{completion_requirement_2}} - + **Technical Requirements:** - + - Maximum entities: {{entity_limit}} - Performance target: {{fps_target}} FPS - Memory budget: {{memory_limit}}MB @@ -3770,11 +3783,11 @@ sections: instruction: Based on GDD requirements, define the overall level organization template: | **Organization Type:** {{linear|hub_world|open_world}} - + **Total Level Count:** {{number}} - + **World Breakdown:** - + - World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}} @@ -3809,7 +3822,7 @@ sections: instruction: Define how players access new levels template: | **Progression Gates:** - + - Linear progression: Complete previous level - Star requirements: {{star_count}} stars to unlock - Skill gates: Demonstrate {{skill_requirement}} @@ -3824,17 +3837,17 @@ sections: instruction: Define all environmental components that can be used in levels template: | **Terrain Types:** - + - {{terrain_1}}: {{properties_and_usage}} - {{terrain_2}}: {{properties_and_usage}} - + **Interactive Objects:** - + - {{object_1}}: {{behavior_and_purpose}} - {{object_2}}: {{behavior_and_purpose}} - + **Hazards and Obstacles:** - + - {{hazard_1}}: {{damage_and_behavior}} - {{hazard_2}}: {{damage_and_behavior}} - id: collectibles-rewards @@ -3842,18 +3855,18 @@ sections: instruction: Define all collectible items and their placement rules template: | **Collectible Types:** - + - {{collectible_1}}: {{value_and_purpose}} - {{collectible_2}}: {{value_and_purpose}} - + **Placement Guidelines:** - + - Mandatory collectibles: {{placement_rules}} - Optional collectibles: {{placement_rules}} - Secret collectibles: {{placement_rules}} - + **Reward Distribution:** - + - Easy to find: {{percentage}}% - Moderate challenge: {{percentage}}% - High skill required: {{percentage}}% @@ -3862,18 +3875,18 @@ sections: instruction: Define how enemies should be placed and balanced in levels template: | **Enemy Categories:** - + - {{enemy_type_1}}: {{behavior_and_usage}} - {{enemy_type_2}}: {{behavior_and_usage}} - + **Placement Principles:** - + - Introduction encounters: {{guideline}} - Standard encounters: {{guideline}} - Challenge encounters: {{guideline}} - + **Difficulty Scaling:** - + - Enemy count progression: {{scaling_rule}} - Enemy type introduction: {{pacing_rule}} - Encounter complexity: {{complexity_rule}} @@ -3886,14 +3899,14 @@ sections: title: Level Layout Principles template: | **Spatial Design:** - + - Grid size: {{grid_dimensions}} - Minimum path width: {{width_units}} - Maximum vertical distance: {{height_units}} - Safe zones placement: {{safety_guidelines}} - + **Navigation Design:** - + - Clear path indication: {{visual_cues}} - Landmark placement: {{landmark_rules}} - Dead end avoidance: {{dead_end_policy}} @@ -3903,13 +3916,13 @@ sections: instruction: Define how to control the rhythm and pace of gameplay within levels template: | **Action Sequences:** - + - High intensity duration: {{max_duration}} - Rest period requirement: {{min_rest_time}} - Intensity variation: {{pacing_pattern}} - + **Learning Sequences:** - + - New mechanic introduction: {{teaching_method}} - Practice opportunity: {{practice_duration}} - Skill application: {{application_context}} @@ -3918,14 +3931,14 @@ sections: instruction: Define how to create appropriate challenges for each level type template: | **Challenge Types:** - + - Execution challenges: {{skill_requirements}} - Puzzle challenges: {{complexity_guidelines}} - Time challenges: {{time_pressure_rules}} - Resource challenges: {{resource_management}} - + **Difficulty Calibration:** - + - Skill check frequency: {{frequency_guidelines}} - Failure recovery: {{retry_mechanics}} - Hint system integration: {{help_system}} @@ -3939,7 +3952,7 @@ sections: instruction: Define how level data should be structured for implementation template: | **Level File Format:** - + - Data format: {{json|yaml|custom}} - File naming: `level_{{world}}_{{number}}.{{extension}}` - Data organization: {{structure_description}} @@ -3977,14 +3990,14 @@ sections: instruction: Define how level assets are organized and loaded template: | **Tilemap Requirements:** - + - Tile size: {{tile_dimensions}}px - Tileset organization: {{tileset_structure}} - Layer organization: {{layer_system}} - Collision data: {{collision_format}} - + **Audio Integration:** - + - Background music: {{music_requirements}} - Ambient sounds: {{ambient_system}} - Dynamic audio: {{dynamic_audio_rules}} @@ -3993,19 +4006,19 @@ sections: instruction: Define performance requirements for level systems template: | **Entity Limits:** - + - Maximum active entities: {{entity_limit}} - Maximum particles: {{particle_limit}} - Maximum audio sources: {{audio_limit}} - + **Memory Management:** - + - Texture memory budget: {{texture_memory}}MB - Audio memory budget: {{audio_memory}}MB - Level loading time: <{{load_time}}s - + **Culling and LOD:** - + - Off-screen culling: {{culling_distance}} - Level-of-detail rules: {{lod_system}} - Asset streaming: {{streaming_requirements}} @@ -4018,13 +4031,13 @@ sections: title: Automated Testing template: | **Performance Testing:** - + - Frame rate validation: Maintain {{fps_target}} FPS - Memory usage monitoring: Stay under {{memory_limit}}MB - Loading time verification: Complete in <{{load_time}}s - + **Gameplay Testing:** - + - Completion path validation: All objectives achievable - Collectible accessibility: All items reachable - Softlock prevention: No unwinnable states @@ -4052,14 +4065,14 @@ sections: title: Balance Validation template: | **Metrics Collection:** - + - Completion rate: Target {{completion_percentage}}% - Average completion time: {{target_time}} ± {{variance}} - Death count per level: <{{max_deaths}} - Collectible discovery rate: {{discovery_percentage}}% - + **Iteration Guidelines:** - + - Adjustment criteria: {{criteria_for_changes}} - Testing sample size: {{minimum_testers}} - Validation period: {{testing_duration}} @@ -4072,14 +4085,14 @@ sections: title: Design Phase template: | **Concept Development:** - + 1. Define level purpose and goals 2. Create rough layout sketch 3. Identify key mechanics and challenges 4. Estimate difficulty and duration - + **Documentation Requirements:** - + - Level design brief - Layout diagrams - Mechanic integration notes @@ -4088,15 +4101,15 @@ sections: title: Implementation Phase template: | **Technical Implementation:** - + 1. Create level data file 2. Build tilemap and layout 3. Place entities and objects 4. Configure level logic and triggers 5. Integrate audio and visual effects - + **Quality Assurance:** - + 1. Automated testing execution 2. Internal playtesting 3. Performance validation @@ -4105,14 +4118,14 @@ sections: title: Integration Phase template: | **Game Integration:** - + 1. Level progression integration 2. Save system compatibility 3. Analytics integration 4. Achievement system integration - + **Final Validation:** - + 1. Full game context testing 2. Performance regression testing 3. Platform compatibility verification @@ -4165,7 +4178,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document. - + This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design. - id: game-vision @@ -4222,7 +4235,7 @@ sections: repeatable: true template: | **Core Mechanic: {{mechanic_name}}** - + - **Description:** {{how_it_works}} - **Player Value:** {{why_its_fun}} - **Implementation Scope:** {{complexity_estimate}} @@ -4249,12 +4262,12 @@ sections: title: Technical Constraints template: | **Platform Requirements:** - + - Primary: {{platform_1}} - {{requirements}} - Secondary: {{platform_2}} - {{requirements}} - + **Technical Specifications:** - + - Engine: Phaser 3 + TypeScript - Performance Target: {{fps_target}} FPS on {{target_device}} - Memory Budget: <{{memory_limit}}MB @@ -4292,10 +4305,10 @@ sections: title: Competitive Analysis template: | **Direct Competitors:** - + - {{competitor_1}}: {{strengths_and_weaknesses}} - {{competitor_2}}: {{strengths_and_weaknesses}} - + **Differentiation Strategy:** {{how_we_differ_and_why_thats_valuable}} - id: market-opportunity @@ -4319,16 +4332,16 @@ sections: title: Content Categories template: | **Core Content:** - + - {{content_type_1}}: {{quantity_and_description}} - {{content_type_2}}: {{quantity_and_description}} - + **Optional Content:** - + - {{optional_content_type}}: {{quantity_and_description}} - + **Replay Elements:** - + - {{replayability_features}} - id: difficulty-accessibility title: Difficulty and Accessibility @@ -4395,13 +4408,13 @@ sections: title: Player Experience Metrics template: | **Engagement Goals:** - + - Tutorial completion rate: >{{percentage}}% - Average session length: {{duration}} minutes - Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}% - + **Quality Benchmarks:** - + - Player satisfaction: >{{rating}}/10 - Completion rate: >{{percentage}}% - Technical performance: {{fps_target}} FPS consistent @@ -4409,13 +4422,13 @@ sections: title: Development Metrics template: | **Technical Targets:** - + - Zero critical bugs at launch - Performance targets met on all platforms - Load times under {{seconds}}s - + **Process Goals:** - + - Development timeline adherence - Feature scope completion - Quality assurance standards @@ -4424,7 +4437,7 @@ sections: condition: has_business_goals template: | **Commercial Goals:** - + - {{revenue_target}} in first {{time_period}} - {{user_acquisition_target}} players in first {{time_period}} - {{retention_target}} monthly active users @@ -4477,12 +4490,12 @@ sections: title: Validation Plan template: | **Concept Testing:** - + - {{validation_method_1}} - {{timeline}} - {{validation_method_2}} - {{timeline}} - + **Prototype Testing:** - + - {{testing_approach}} - {{timeline}} - {{feedback_collection_method}} - {{timeline}} @@ -4728,7 +4741,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics. - + If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD. - id: introduction @@ -4736,7 +4749,7 @@ sections: instruction: Establish the document's purpose and scope for game development content: | This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems. - + This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility. sections: - id: change-log @@ -4755,7 +4768,7 @@ sections: title: Architecture Summary instruction: | Provide a comprehensive overview covering: - + - Game engine choice and configuration - Project structure and organization - Key systems and their interactions @@ -4843,23 +4856,23 @@ sections: title: Scene Management System template: | **Purpose:** Handle game flow and scene transitions - + **Key Components:** - + - Scene loading and unloading - Data passing between scenes - Transition effects - Memory management - + **Implementation Requirements:** - + - Preload scene for asset loading - Menu system with navigation - Gameplay scenes with state management - Pause/resume functionality - + **Files to Create:** - + - `src/scenes/BootScene.ts` - `src/scenes/PreloadScene.ts` - `src/scenes/MenuScene.ts` @@ -4869,23 +4882,23 @@ sections: title: Game State Management template: | **Purpose:** Track player progress and game status - + **State Categories:** - + - Player progress (levels, unlocks) - Game settings (audio, controls) - Session data (current level, score) - Persistent data (achievements, statistics) - + **Implementation Requirements:** - + - Save/load system with localStorage - State validation and error recovery - Cross-session data persistence - Settings management - + **Files to Create:** - + - `src/systems/GameState.ts` - `src/systems/SaveManager.ts` - `src/types/GameData.ts` @@ -4893,23 +4906,23 @@ sections: title: Asset Management System template: | **Purpose:** Efficient loading and management of game assets - + **Asset Categories:** - + - Sprite sheets and animations - Audio files and music - Level data and configurations - UI assets and fonts - + **Implementation Requirements:** - + - Progressive loading strategy - Asset caching and optimization - Error handling for failed loads - Memory management for large assets - + **Files to Create:** - + - `src/systems/AssetManager.ts` - `src/config/AssetConfig.ts` - `src/utils/AssetLoader.ts` @@ -4917,23 +4930,23 @@ sections: title: Input Management System template: | **Purpose:** Handle all player input across platforms - + **Input Types:** - + - Keyboard controls - Mouse/pointer interaction - Touch gestures (mobile) - Gamepad support (optional) - + **Implementation Requirements:** - + - Input mapping and configuration - Touch-friendly mobile controls - Input buffering for responsive gameplay - Customizable control schemes - + **Files to Create:** - + - `src/systems/InputManager.ts` - `src/utils/TouchControls.ts` - `src/types/InputTypes.ts` @@ -4946,19 +4959,19 @@ sections: title: "{{mechanic_name}} System" template: | **Purpose:** {{system_purpose}} - + **Core Functionality:** - + - {{feature_1}} - {{feature_2}} - {{feature_3}} - + **Dependencies:** {{required_systems}} - + **Performance Considerations:** {{optimization_notes}} - + **Files to Create:** - + - `src/systems/{{system_name}}.ts` - `src/gameObjects/{{related_object}}.ts` - `src/types/{{system_types}}.ts` @@ -4966,65 +4979,65 @@ sections: title: Physics & Collision System template: | **Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js) - + **Collision Categories:** - + - Player collision - Enemy interactions - Environmental objects - Collectibles and items - + **Implementation Requirements:** - + - Optimized collision detection - Physics body management - Collision callbacks and events - Performance monitoring - + **Files to Create:** - + - `src/systems/PhysicsManager.ts` - `src/utils/CollisionGroups.ts` - id: audio-system title: Audio System template: | **Audio Requirements:** - + - Background music with looping - Sound effects for actions - Audio settings and volume control - Mobile audio optimization - + **Implementation Features:** - + - Audio sprite management - Dynamic music system - Spatial audio (if applicable) - Audio pooling for performance - + **Files to Create:** - + - `src/systems/AudioManager.ts` - `src/config/AudioConfig.ts` - id: ui-system title: UI System template: | **UI Components:** - + - HUD elements (score, health, etc.) - Menu navigation - Modal dialogs - Settings screens - + **Implementation Requirements:** - + - Responsive layout system - Touch-friendly interface - Keyboard navigation support - Animation and transitions - + **Files to Create:** - + - `src/systems/UIManager.ts` - `src/gameObjects/UI/` - `src/types/UITypes.ts` @@ -5566,7 +5579,7 @@ interface GameState { interface GameSettings { musicVolume: number; sfxVolume: number; - difficulty: "easy" | "normal" | "hard"; + difficulty: 'easy' | 'normal' | 'hard'; controls: ControlScheme; } ``` @@ -5607,12 +5620,12 @@ class GameScene extends Phaser.Scene { private inputManager!: InputManager; constructor() { - super({ key: "GameScene" }); + super({ key: 'GameScene' }); } preload(): void { // Load only scene-specific assets - this.load.image("player", "assets/player.png"); + this.load.image('player', 'assets/player.png'); } create(data: SceneData): void { @@ -5637,7 +5650,7 @@ class GameScene extends Phaser.Scene { this.inputManager.destroy(); // Remove event listeners - this.events.off("*"); + this.events.off('*'); } } ``` @@ -5646,13 +5659,13 @@ class GameScene extends Phaser.Scene { ```typescript // Proper scene transitions with data -this.scene.start("NextScene", { +this.scene.start('NextScene', { playerScore: this.playerScore, currentLevel: this.currentLevel + 1, }); // Scene overlays for UI -this.scene.launch("PauseMenuScene"); +this.scene.launch('PauseMenuScene'); this.scene.pause(); ``` @@ -5696,7 +5709,7 @@ class Player extends GameEntity { private health!: HealthComponent; constructor(scene: Phaser.Scene, x: number, y: number) { - super(scene, x, y, "player"); + super(scene, x, y, 'player'); this.movement = this.addComponent(new MovementComponent(this)); this.health = this.addComponent(new HealthComponent(this, 100)); @@ -5716,7 +5729,7 @@ class GameManager { constructor(scene: Phaser.Scene) { if (GameManager.instance) { - throw new Error("GameManager already exists!"); + throw new Error('GameManager already exists!'); } this.scene = scene; @@ -5726,7 +5739,7 @@ class GameManager { static getInstance(): GameManager { if (!GameManager.instance) { - throw new Error("GameManager not initialized!"); + throw new Error('GameManager not initialized!'); } return GameManager.instance; } @@ -5773,7 +5786,7 @@ class BulletPool { } // Pool exhausted - create new bullet - console.warn("Bullet pool exhausted, creating new bullet"); + console.warn('Bullet pool exhausted, creating new bullet'); return new Bullet(this.scene, 0, 0); } @@ -5873,14 +5886,12 @@ class InputManager { } private setupKeyboard(): void { - this.keys = this.scene.input.keyboard.addKeys( - "W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT", - ); + this.keys = this.scene.input.keyboard.addKeys('W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT'); } private setupTouch(): void { - this.scene.input.on("pointerdown", this.handlePointerDown, this); - this.scene.input.on("pointerup", this.handlePointerUp, this); + this.scene.input.on('pointerdown', this.handlePointerDown, this); + this.scene.input.on('pointerup', this.handlePointerUp, this); } update(): void { @@ -5907,9 +5918,9 @@ class InputManager { class AssetManager { loadAssets(): Promise { return new Promise((resolve, reject) => { - this.scene.load.on("filecomplete", this.handleFileComplete, this); - this.scene.load.on("loaderror", this.handleLoadError, this); - this.scene.load.on("complete", () => resolve()); + this.scene.load.on('filecomplete', this.handleFileComplete, this); + this.scene.load.on('loaderror', this.handleLoadError, this); + this.scene.load.on('complete', () => resolve()); this.scene.load.start(); }); @@ -5925,8 +5936,8 @@ class AssetManager { private loadFallbackAsset(key: string): void { // Load placeholder or default assets switch (key) { - case "player": - this.scene.load.image("player", "assets/defaults/default-player.png"); + case 'player': + this.scene.load.image('player', 'assets/defaults/default-player.png'); break; default: console.warn(`No fallback for asset: ${key}`); @@ -5953,11 +5964,11 @@ class GameSystem { private attemptRecovery(context: string): void { switch (context) { - case "update": + case 'update': // Reset system state this.reset(); break; - case "render": + case 'render': // Disable visual effects this.disableEffects(); break; @@ -5977,7 +5988,7 @@ class GameSystem { ```typescript // Example test for game mechanics -describe("HealthComponent", () => { +describe('HealthComponent', () => { let healthComponent: HealthComponent; beforeEach(() => { @@ -5985,18 +5996,18 @@ describe("HealthComponent", () => { healthComponent = new HealthComponent(mockEntity, 100); }); - test("should initialize with correct health", () => { + test('should initialize with correct health', () => { expect(healthComponent.currentHealth).toBe(100); expect(healthComponent.maxHealth).toBe(100); }); - test("should handle damage correctly", () => { + test('should handle damage correctly', () => { healthComponent.takeDamage(25); expect(healthComponent.currentHealth).toBe(75); expect(healthComponent.isAlive()).toBe(true); }); - test("should handle death correctly", () => { + test('should handle death correctly', () => { healthComponent.takeDamage(150); expect(healthComponent.currentHealth).toBe(0); expect(healthComponent.isAlive()).toBe(false); @@ -6009,7 +6020,7 @@ describe("HealthComponent", () => { **Scene Testing:** ```typescript -describe("GameScene Integration", () => { +describe('GameScene Integration', () => { let scene: GameScene; let mockGame: Phaser.Game; @@ -6019,7 +6030,7 @@ describe("GameScene Integration", () => { scene = new GameScene(); }); - test("should initialize all systems", () => { + test('should initialize all systems', () => { scene.create({}); expect(scene.gameManager).toBeDefined(); @@ -6378,13 +6389,13 @@ sections: - id: initial-setup instruction: | This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality. - + Before starting, ensure you have access to: - + - Game Design Document (GDD) - Game Architecture Document - Any existing stories in this epic - + The story should be specific enough that a developer can implement it without requiring additional design decisions. - id: story-header @@ -6433,12 +6444,12 @@ sections: title: Files to Create/Modify template: | **New Files:** - + - `{{file_path_1}}` - {{purpose}} - `{{file_path_2}}` - {{purpose}} - + **Modified Files:** - + - `{{existing_file_1}}` - {{changes_needed}} - `{{existing_file_2}}` - {{changes_needed}} - id: class-interface-definitions @@ -6453,15 +6464,15 @@ sections: {{property_2}}: {{type}}; {{method_1}}({{params}}): {{return_type}}; } - + // {{class_name}} class {{class_name}} extends {{phaser_class}} { private {{property}}: {{type}}; - + constructor({{params}}) { // Implementation requirements } - + public {{method}}({{params}}): {{return_type}} { // Method requirements } @@ -6471,15 +6482,15 @@ sections: instruction: Specify how this feature integrates with existing systems template: | **Scene Integration:** - + - {{scene_name}}: {{integration_details}} - + **System Dependencies:** - + - {{system_name}}: {{dependency_description}} - + **Event Communication:** - + - Emits: `{{event_name}}` when {{condition}} - Listens: `{{event_name}}` to {{response}} @@ -6491,7 +6502,7 @@ sections: title: Dev Agent Record template: | **Tasks:** - + - [ ] {{task_1_description}} - [ ] {{task_2_description}} - [ ] {{task_3_description}} @@ -6499,18 +6510,18 @@ sections: - [ ] Write unit tests for {{component}} - [ ] Integration testing with {{related_system}} - [ ] Performance testing and optimization - + **Debug Log:** | Task | File | Change | Reverted? | |------|------|--------|-----------| | | | | | - + **Completion Notes:** - + - + **Change Log:** - + - id: game-design-context @@ -6518,13 +6529,13 @@ sections: instruction: Reference the specific sections of the GDD that this story implements template: | **GDD Reference:** {{section_name}} ({{page_or_section_number}}) - + **Game Mechanic:** {{mechanic_name}} - + **Player Experience Goal:** {{experience_description}} - + **Balance Parameters:** - + - {{parameter_1}}: {{value_or_range}} - {{parameter_2}}: {{value_or_range}} @@ -6536,11 +6547,11 @@ sections: title: Unit Tests template: | **Test Files:** - + - `tests/{{component_name}}.test.ts` - + **Test Scenarios:** - + - {{test_scenario_1}} - {{test_scenario_2}} - {{edge_case_test}} @@ -6548,12 +6559,12 @@ sections: title: Game Testing template: | **Manual Test Cases:** - + 1. {{test_case_1_description}} - + - Expected: {{expected_behavior}} - Performance: {{performance_expectation}} - + 2. {{test_case_2_description}} - Expected: {{expected_behavior}} - Edge Case: {{edge_case_handling}} @@ -6561,7 +6572,7 @@ sections: title: Performance Tests template: | **Metrics to Verify:** - + - Frame rate maintains {{fps_target}} FPS - Memory usage stays under {{memory_limit}}MB - {{feature_specific_performance_metric}} @@ -6571,15 +6582,15 @@ sections: instruction: List any dependencies that must be completed before this story can be implemented template: | **Story Dependencies:** - + - {{story_id}}: {{dependency_description}} - + **Technical Dependencies:** - + - {{system_or_file}}: {{requirement}} - + **Asset Dependencies:** - + - {{asset_type}}: {{asset_description}} - Location: `{{asset_path}}` @@ -6602,17 +6613,17 @@ sections: instruction: Any additional context, design decisions, or implementation notes template: | **Implementation Notes:** - + - {{note_1}} - {{note_2}} - + **Design Decisions:** - + - {{decision_1}}: {{rationale}} - {{decision_2}}: {{rationale}} - + **Future Considerations:** - + - {{future_enhancement_1}} - {{future_optimization_1}} ==================== END: .bmad-2d-phaser-game-dev/templates/game-story-tmpl.yaml ==================== @@ -6634,7 +6645,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game architecture document specifically for Phaser 3 + TypeScript projects. This should provide the technical foundation for all game development stories and epics. - + If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD. - id: introduction @@ -6642,7 +6653,7 @@ sections: instruction: Establish the document's purpose and scope for game development content: | This document outlines the complete technical architecture for {{game_title}}, a 2D game built with Phaser 3 and TypeScript. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems. - + This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining 60 FPS performance and cross-platform compatibility. sections: - id: change-log @@ -6661,7 +6672,7 @@ sections: title: Architecture Summary instruction: | Provide a comprehensive overview covering: - + - Game engine choice and configuration - Project structure and organization - Key systems and their interactions @@ -6749,23 +6760,23 @@ sections: title: Scene Management System template: | **Purpose:** Handle game flow and scene transitions - + **Key Components:** - + - Scene loading and unloading - Data passing between scenes - Transition effects - Memory management - + **Implementation Requirements:** - + - Preload scene for asset loading - Menu system with navigation - Gameplay scenes with state management - Pause/resume functionality - + **Files to Create:** - + - `src/scenes/BootScene.ts` - `src/scenes/PreloadScene.ts` - `src/scenes/MenuScene.ts` @@ -6775,23 +6786,23 @@ sections: title: Game State Management template: | **Purpose:** Track player progress and game status - + **State Categories:** - + - Player progress (levels, unlocks) - Game settings (audio, controls) - Session data (current level, score) - Persistent data (achievements, statistics) - + **Implementation Requirements:** - + - Save/load system with localStorage - State validation and error recovery - Cross-session data persistence - Settings management - + **Files to Create:** - + - `src/systems/GameState.ts` - `src/systems/SaveManager.ts` - `src/types/GameData.ts` @@ -6799,23 +6810,23 @@ sections: title: Asset Management System template: | **Purpose:** Efficient loading and management of game assets - + **Asset Categories:** - + - Sprite sheets and animations - Audio files and music - Level data and configurations - UI assets and fonts - + **Implementation Requirements:** - + - Progressive loading strategy - Asset caching and optimization - Error handling for failed loads - Memory management for large assets - + **Files to Create:** - + - `src/systems/AssetManager.ts` - `src/config/AssetConfig.ts` - `src/utils/AssetLoader.ts` @@ -6823,23 +6834,23 @@ sections: title: Input Management System template: | **Purpose:** Handle all player input across platforms - + **Input Types:** - + - Keyboard controls - Mouse/pointer interaction - Touch gestures (mobile) - Gamepad support (optional) - + **Implementation Requirements:** - + - Input mapping and configuration - Touch-friendly mobile controls - Input buffering for responsive gameplay - Customizable control schemes - + **Files to Create:** - + - `src/systems/InputManager.ts` - `src/utils/TouchControls.ts` - `src/types/InputTypes.ts` @@ -6852,19 +6863,19 @@ sections: title: "{{mechanic_name}} System" template: | **Purpose:** {{system_purpose}} - + **Core Functionality:** - + - {{feature_1}} - {{feature_2}} - {{feature_3}} - + **Dependencies:** {{required_systems}} - + **Performance Considerations:** {{optimization_notes}} - + **Files to Create:** - + - `src/systems/{{system_name}}.ts` - `src/gameObjects/{{related_object}}.ts` - `src/types/{{system_types}}.ts` @@ -6872,65 +6883,65 @@ sections: title: Physics & Collision System template: | **Physics Engine:** {{physics_choice}} (Arcade Physics/Matter.js) - + **Collision Categories:** - + - Player collision - Enemy interactions - Environmental objects - Collectibles and items - + **Implementation Requirements:** - + - Optimized collision detection - Physics body management - Collision callbacks and events - Performance monitoring - + **Files to Create:** - + - `src/systems/PhysicsManager.ts` - `src/utils/CollisionGroups.ts` - id: audio-system title: Audio System template: | **Audio Requirements:** - + - Background music with looping - Sound effects for actions - Audio settings and volume control - Mobile audio optimization - + **Implementation Features:** - + - Audio sprite management - Dynamic music system - Spatial audio (if applicable) - Audio pooling for performance - + **Files to Create:** - + - `src/systems/AudioManager.ts` - `src/config/AudioConfig.ts` - id: ui-system title: UI System template: | **UI Components:** - + - HUD elements (score, health, etc.) - Menu navigation - Modal dialogs - Settings screens - + **Implementation Requirements:** - + - Responsive layout system - Touch-friendly interface - Keyboard navigation support - Animation and transitions - + **Files to Create:** - + - `src/systems/UIManager.ts` - `src/gameObjects/UI/` - `src/types/UITypes.ts` @@ -7250,7 +7261,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document. - + This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design. - id: game-vision @@ -7307,7 +7318,7 @@ sections: repeatable: true template: | **Core Mechanic: {{mechanic_name}}** - + - **Description:** {{how_it_works}} - **Player Value:** {{why_its_fun}} - **Implementation Scope:** {{complexity_estimate}} @@ -7334,12 +7345,12 @@ sections: title: Technical Constraints template: | **Platform Requirements:** - + - Primary: {{platform_1}} - {{requirements}} - Secondary: {{platform_2}} - {{requirements}} - + **Technical Specifications:** - + - Engine: Phaser 3 + TypeScript - Performance Target: {{fps_target}} FPS on {{target_device}} - Memory Budget: <{{memory_limit}}MB @@ -7377,10 +7388,10 @@ sections: title: Competitive Analysis template: | **Direct Competitors:** - + - {{competitor_1}}: {{strengths_and_weaknesses}} - {{competitor_2}}: {{strengths_and_weaknesses}} - + **Differentiation Strategy:** {{how_we_differ_and_why_thats_valuable}} - id: market-opportunity @@ -7404,16 +7415,16 @@ sections: title: Content Categories template: | **Core Content:** - + - {{content_type_1}}: {{quantity_and_description}} - {{content_type_2}}: {{quantity_and_description}} - + **Optional Content:** - + - {{optional_content_type}}: {{quantity_and_description}} - + **Replay Elements:** - + - {{replayability_features}} - id: difficulty-accessibility title: Difficulty and Accessibility @@ -7480,13 +7491,13 @@ sections: title: Player Experience Metrics template: | **Engagement Goals:** - + - Tutorial completion rate: >{{percentage}}% - Average session length: {{duration}} minutes - Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}% - + **Quality Benchmarks:** - + - Player satisfaction: >{{rating}}/10 - Completion rate: >{{percentage}}% - Technical performance: {{fps_target}} FPS consistent @@ -7494,13 +7505,13 @@ sections: title: Development Metrics template: | **Technical Targets:** - + - Zero critical bugs at launch - Performance targets met on all platforms - Load times under {{seconds}}s - + **Process Goals:** - + - Development timeline adherence - Feature scope completion - Quality assurance standards @@ -7509,7 +7520,7 @@ sections: condition: has_business_goals template: | **Commercial Goals:** - + - {{revenue_target}} in first {{time_period}} - {{user_acquisition_target}} players in first {{time_period}} - {{retention_target}} monthly active users @@ -7562,12 +7573,12 @@ sections: title: Validation Plan template: | **Concept Testing:** - + - {{validation_method_1}} - {{timeline}} - {{validation_method_2}} - {{timeline}} - + **Prototype Testing:** - + - {{testing_approach}} - {{timeline}} - {{feedback_collection_method}} - {{timeline}} @@ -7609,7 +7620,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features. - + If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis - id: executive-summary @@ -7654,7 +7665,7 @@ sections: instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions. template: | **Primary Loop ({{duration}} seconds):** - + 1. {{action_1}} ({{time_1}}s) 2. {{action_2}} ({{time_2}}s) 3. {{action_3}} ({{time_3}}s) @@ -7664,12 +7675,12 @@ sections: instruction: Clearly define success and failure states template: | **Victory Conditions:** - + - {{win_condition_1}} - {{win_condition_2}} - + **Failure States:** - + - {{loss_condition_1}} - {{loss_condition_2}} @@ -7685,17 +7696,17 @@ sections: title: "{{mechanic_name}}" template: | **Description:** {{detailed_description}} - + **Player Input:** {{input_method}} - + **System Response:** {{game_response}} - + **Implementation Notes:** - + - {{tech_requirement_1}} - {{tech_requirement_2}} - {{performance_consideration}} - + **Dependencies:** {{other_mechanics_needed}} - id: controls title: Controls @@ -7714,9 +7725,9 @@ sections: title: Player Progression template: | **Progression Type:** {{linear|branching|metroidvania}} - + **Key Milestones:** - + 1. **{{milestone_1}}** - {{unlock_description}} 2. **{{milestone_2}}** - {{unlock_description}} 3. **{{milestone_3}}** - {{unlock_description}} @@ -7753,9 +7764,9 @@ sections: **Duration:** {{target_time}} **Key Elements:** {{required_mechanics}} **Difficulty:** {{relative_difficulty}} - + **Structure Template:** - + - Introduction: {{intro_description}} - Challenge: {{main_challenge}} - Resolution: {{completion_requirement}} @@ -7781,13 +7792,13 @@ sections: title: Platform Specific template: | **Desktop:** - + - Resolution: {{min_resolution}} - {{max_resolution}} - Input: Keyboard, Mouse, Gamepad - Browser: Chrome 80+, Firefox 75+, Safari 13+ - + **Mobile:** - + - Resolution: {{mobile_min}} - {{mobile_max}} - Input: Touch, Tilt (optional) - OS: iOS 13+, Android 8+ @@ -7796,14 +7807,14 @@ sections: instruction: Define asset specifications for the art and audio teams template: | **Visual Assets:** - + - Art Style: {{style_description}} - Color Palette: {{color_specification}} - Animation: {{animation_requirements}} - UI Resolution: {{ui_specs}} - + **Audio Assets:** - + - Music Style: {{music_genre}} - Sound Effects: {{sfx_requirements}} - Voice Acting: {{voice_needs}} @@ -7816,7 +7827,7 @@ sections: title: Engine Configuration template: | **Phaser 3 Setup:** - + - TypeScript: Strict mode enabled - Physics: {{physics_system}} (Arcade/Matter) - Renderer: WebGL with Canvas fallback @@ -7825,7 +7836,7 @@ sections: title: Code Architecture template: | **Required Systems:** - + - Scene Management - State Management - Asset Loading @@ -7837,7 +7848,7 @@ sections: title: Data Management template: | **Save Data:** - + - Progress tracking - Settings persistence - Statistics collection @@ -7955,13 +7966,13 @@ sections: - id: initial-setup instruction: | This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality. - + Before starting, ensure you have access to: - + - Game Design Document (GDD) - Game Architecture Document - Any existing stories in this epic - + The story should be specific enough that a developer can implement it without requiring additional design decisions. - id: story-header @@ -8010,12 +8021,12 @@ sections: title: Files to Create/Modify template: | **New Files:** - + - `{{file_path_1}}` - {{purpose}} - `{{file_path_2}}` - {{purpose}} - + **Modified Files:** - + - `{{existing_file_1}}` - {{changes_needed}} - `{{existing_file_2}}` - {{changes_needed}} - id: class-interface-definitions @@ -8030,15 +8041,15 @@ sections: {{property_2}}: {{type}}; {{method_1}}({{params}}): {{return_type}}; } - + // {{class_name}} class {{class_name}} extends {{phaser_class}} { private {{property}}: {{type}}; - + constructor({{params}}) { // Implementation requirements } - + public {{method}}({{params}}): {{return_type}} { // Method requirements } @@ -8048,15 +8059,15 @@ sections: instruction: Specify how this feature integrates with existing systems template: | **Scene Integration:** - + - {{scene_name}}: {{integration_details}} - + **System Dependencies:** - + - {{system_name}}: {{dependency_description}} - + **Event Communication:** - + - Emits: `{{event_name}}` when {{condition}} - Listens: `{{event_name}}` to {{response}} @@ -8068,7 +8079,7 @@ sections: title: Dev Agent Record template: | **Tasks:** - + - [ ] {{task_1_description}} - [ ] {{task_2_description}} - [ ] {{task_3_description}} @@ -8076,18 +8087,18 @@ sections: - [ ] Write unit tests for {{component}} - [ ] Integration testing with {{related_system}} - [ ] Performance testing and optimization - + **Debug Log:** | Task | File | Change | Reverted? | |------|------|--------|-----------| | | | | | - + **Completion Notes:** - + - + **Change Log:** - + - id: game-design-context @@ -8095,13 +8106,13 @@ sections: instruction: Reference the specific sections of the GDD that this story implements template: | **GDD Reference:** {{section_name}} ({{page_or_section_number}}) - + **Game Mechanic:** {{mechanic_name}} - + **Player Experience Goal:** {{experience_description}} - + **Balance Parameters:** - + - {{parameter_1}}: {{value_or_range}} - {{parameter_2}}: {{value_or_range}} @@ -8113,11 +8124,11 @@ sections: title: Unit Tests template: | **Test Files:** - + - `tests/{{component_name}}.test.ts` - + **Test Scenarios:** - + - {{test_scenario_1}} - {{test_scenario_2}} - {{edge_case_test}} @@ -8125,12 +8136,12 @@ sections: title: Game Testing template: | **Manual Test Cases:** - + 1. {{test_case_1_description}} - + - Expected: {{expected_behavior}} - Performance: {{performance_expectation}} - + 2. {{test_case_2_description}} - Expected: {{expected_behavior}} - Edge Case: {{edge_case_handling}} @@ -8138,7 +8149,7 @@ sections: title: Performance Tests template: | **Metrics to Verify:** - + - Frame rate maintains {{fps_target}} FPS - Memory usage stays under {{memory_limit}}MB - {{feature_specific_performance_metric}} @@ -8148,15 +8159,15 @@ sections: instruction: List any dependencies that must be completed before this story can be implemented template: | **Story Dependencies:** - + - {{story_id}}: {{dependency_description}} - + **Technical Dependencies:** - + - {{system_or_file}}: {{requirement}} - + **Asset Dependencies:** - + - {{asset_type}}: {{asset_description}} - Location: `{{asset_path}}` @@ -8179,17 +8190,17 @@ sections: instruction: Any additional context, design decisions, or implementation notes template: | **Implementation Notes:** - + - {{note_1}} - {{note_2}} - + **Design Decisions:** - + - {{decision_1}}: {{rationale}} - {{decision_2}}: {{rationale}} - + **Future Considerations:** - + - {{future_enhancement_1}} - {{future_optimization_1}} ==================== END: .bmad-2d-phaser-game-dev/templates/game-story-tmpl.yaml ==================== @@ -8211,7 +8222,7 @@ sections: - id: initial-setup instruction: | This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels. - + If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents. - id: introduction @@ -8219,7 +8230,7 @@ sections: instruction: Establish the purpose and scope of level design for this game content: | This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document. - + This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints. sections: - id: change-log @@ -8266,29 +8277,29 @@ sections: title: "{{category_name}} Levels" template: | **Purpose:** {{gameplay_purpose}} - + **Target Duration:** {{min_time}} - {{max_time}} minutes - + **Difficulty Range:** {{difficulty_scale}} - + **Key Mechanics Featured:** - + - {{mechanic_1}} - {{usage_description}} - {{mechanic_2}} - {{usage_description}} - + **Player Objectives:** - + - Primary: {{primary_objective}} - Secondary: {{secondary_objective}} - Hidden: {{secret_objective}} - + **Success Criteria:** - + - {{completion_requirement_1}} - {{completion_requirement_2}} - + **Technical Requirements:** - + - Maximum entities: {{entity_limit}} - Performance target: {{fps_target}} FPS - Memory budget: {{memory_limit}}MB @@ -8303,11 +8314,11 @@ sections: instruction: Based on GDD requirements, define the overall level organization template: | **Organization Type:** {{linear|hub_world|open_world}} - + **Total Level Count:** {{number}} - + **World Breakdown:** - + - World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}} @@ -8342,7 +8353,7 @@ sections: instruction: Define how players access new levels template: | **Progression Gates:** - + - Linear progression: Complete previous level - Star requirements: {{star_count}} stars to unlock - Skill gates: Demonstrate {{skill_requirement}} @@ -8357,17 +8368,17 @@ sections: instruction: Define all environmental components that can be used in levels template: | **Terrain Types:** - + - {{terrain_1}}: {{properties_and_usage}} - {{terrain_2}}: {{properties_and_usage}} - + **Interactive Objects:** - + - {{object_1}}: {{behavior_and_purpose}} - {{object_2}}: {{behavior_and_purpose}} - + **Hazards and Obstacles:** - + - {{hazard_1}}: {{damage_and_behavior}} - {{hazard_2}}: {{damage_and_behavior}} - id: collectibles-rewards @@ -8375,18 +8386,18 @@ sections: instruction: Define all collectible items and their placement rules template: | **Collectible Types:** - + - {{collectible_1}}: {{value_and_purpose}} - {{collectible_2}}: {{value_and_purpose}} - + **Placement Guidelines:** - + - Mandatory collectibles: {{placement_rules}} - Optional collectibles: {{placement_rules}} - Secret collectibles: {{placement_rules}} - + **Reward Distribution:** - + - Easy to find: {{percentage}}% - Moderate challenge: {{percentage}}% - High skill required: {{percentage}}% @@ -8395,18 +8406,18 @@ sections: instruction: Define how enemies should be placed and balanced in levels template: | **Enemy Categories:** - + - {{enemy_type_1}}: {{behavior_and_usage}} - {{enemy_type_2}}: {{behavior_and_usage}} - + **Placement Principles:** - + - Introduction encounters: {{guideline}} - Standard encounters: {{guideline}} - Challenge encounters: {{guideline}} - + **Difficulty Scaling:** - + - Enemy count progression: {{scaling_rule}} - Enemy type introduction: {{pacing_rule}} - Encounter complexity: {{complexity_rule}} @@ -8419,14 +8430,14 @@ sections: title: Level Layout Principles template: | **Spatial Design:** - + - Grid size: {{grid_dimensions}} - Minimum path width: {{width_units}} - Maximum vertical distance: {{height_units}} - Safe zones placement: {{safety_guidelines}} - + **Navigation Design:** - + - Clear path indication: {{visual_cues}} - Landmark placement: {{landmark_rules}} - Dead end avoidance: {{dead_end_policy}} @@ -8436,13 +8447,13 @@ sections: instruction: Define how to control the rhythm and pace of gameplay within levels template: | **Action Sequences:** - + - High intensity duration: {{max_duration}} - Rest period requirement: {{min_rest_time}} - Intensity variation: {{pacing_pattern}} - + **Learning Sequences:** - + - New mechanic introduction: {{teaching_method}} - Practice opportunity: {{practice_duration}} - Skill application: {{application_context}} @@ -8451,14 +8462,14 @@ sections: instruction: Define how to create appropriate challenges for each level type template: | **Challenge Types:** - + - Execution challenges: {{skill_requirements}} - Puzzle challenges: {{complexity_guidelines}} - Time challenges: {{time_pressure_rules}} - Resource challenges: {{resource_management}} - + **Difficulty Calibration:** - + - Skill check frequency: {{frequency_guidelines}} - Failure recovery: {{retry_mechanics}} - Hint system integration: {{help_system}} @@ -8472,7 +8483,7 @@ sections: instruction: Define how level data should be structured for implementation template: | **Level File Format:** - + - Data format: {{json|yaml|custom}} - File naming: `level_{{world}}_{{number}}.{{extension}}` - Data organization: {{structure_description}} @@ -8510,14 +8521,14 @@ sections: instruction: Define how level assets are organized and loaded template: | **Tilemap Requirements:** - + - Tile size: {{tile_dimensions}}px - Tileset organization: {{tileset_structure}} - Layer organization: {{layer_system}} - Collision data: {{collision_format}} - + **Audio Integration:** - + - Background music: {{music_requirements}} - Ambient sounds: {{ambient_system}} - Dynamic audio: {{dynamic_audio_rules}} @@ -8526,19 +8537,19 @@ sections: instruction: Define performance requirements for level systems template: | **Entity Limits:** - + - Maximum active entities: {{entity_limit}} - Maximum particles: {{particle_limit}} - Maximum audio sources: {{audio_limit}} - + **Memory Management:** - + - Texture memory budget: {{texture_memory}}MB - Audio memory budget: {{audio_memory}}MB - Level loading time: <{{load_time}}s - + **Culling and LOD:** - + - Off-screen culling: {{culling_distance}} - Level-of-detail rules: {{lod_system}} - Asset streaming: {{streaming_requirements}} @@ -8551,13 +8562,13 @@ sections: title: Automated Testing template: | **Performance Testing:** - + - Frame rate validation: Maintain {{fps_target}} FPS - Memory usage monitoring: Stay under {{memory_limit}}MB - Loading time verification: Complete in <{{load_time}}s - + **Gameplay Testing:** - + - Completion path validation: All objectives achievable - Collectible accessibility: All items reachable - Softlock prevention: No unwinnable states @@ -8585,14 +8596,14 @@ sections: title: Balance Validation template: | **Metrics Collection:** - + - Completion rate: Target {{completion_percentage}}% - Average completion time: {{target_time}} ± {{variance}} - Death count per level: <{{max_deaths}} - Collectible discovery rate: {{discovery_percentage}}% - + **Iteration Guidelines:** - + - Adjustment criteria: {{criteria_for_changes}} - Testing sample size: {{minimum_testers}} - Validation period: {{testing_duration}} @@ -8605,14 +8616,14 @@ sections: title: Design Phase template: | **Concept Development:** - + 1. Define level purpose and goals 2. Create rough layout sketch 3. Identify key mechanics and challenges 4. Estimate difficulty and duration - + **Documentation Requirements:** - + - Level design brief - Layout diagrams - Mechanic integration notes @@ -8621,15 +8632,15 @@ sections: title: Implementation Phase template: | **Technical Implementation:** - + 1. Create level data file 2. Build tilemap and layout 3. Place entities and objects 4. Configure level logic and triggers 5. Integrate audio and visual effects - + **Quality Assurance:** - + 1. Automated testing execution 2. Internal playtesting 3. Performance validation @@ -8638,14 +8649,14 @@ sections: title: Integration Phase template: | **Game Integration:** - + 1. Level progression integration 2. Save system compatibility 3. Analytics integration 4. Achievement system integration - + **Final Validation:** - + 1. Full game context testing 2. Performance regression testing 3. Platform compatibility verification @@ -9693,21 +9704,21 @@ workflow: - brainstorming_session - game_research_prompt - player_research - notes: 'Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/design/ folder.' + notes: "Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project's docs/design/ folder." - agent: game-designer creates: game-design-doc.md requires: game-brief.md optional_steps: - competitive_analysis - technical_research - notes: 'Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project''s docs/design/ folder.' + notes: "Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project's docs/design/ folder." - agent: game-designer creates: level-design-doc.md requires: game-design-doc.md optional_steps: - level_prototyping - difficulty_analysis - notes: 'Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project''s docs/design/ folder.' + notes: "Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project's docs/design/ folder." - agent: solution-architect creates: game-architecture.md requires: @@ -9717,7 +9728,7 @@ workflow: - technical_research_prompt - performance_analysis - platform_research - notes: 'Create comprehensive technical architecture using game-architecture-tmpl. Defines Phaser 3 systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project''s docs/architecture/ folder.' + notes: "Create comprehensive technical architecture using game-architecture-tmpl. Defines Phaser 3 systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project's docs/architecture/ folder." - agent: game-designer validates: design_consistency requires: all_design_documents @@ -9742,7 +9753,7 @@ workflow: optional_steps: - quick_brainstorming - concept_validation - notes: 'Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/ folder.' + notes: "Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project's docs/ folder." - agent: game-designer creates: prototype-design.md uses: create-doc prototype-design OR create-game-story @@ -9906,7 +9917,7 @@ workflow: notes: Implement stories in priority order. Test frequently and adjust design based on what feels fun. Document discoveries. workflow_end: action: prototype_evaluation - notes: 'Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive.' + notes: "Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive." game_jam_sequence: - step: jam_concept agent: game-designer @@ -10366,7 +10377,7 @@ interface GameState { interface GameSettings { musicVolume: number; sfxVolume: number; - difficulty: "easy" | "normal" | "hard"; + difficulty: 'easy' | 'normal' | 'hard'; controls: ControlScheme; } ``` @@ -10407,12 +10418,12 @@ class GameScene extends Phaser.Scene { private inputManager!: InputManager; constructor() { - super({ key: "GameScene" }); + super({ key: 'GameScene' }); } preload(): void { // Load only scene-specific assets - this.load.image("player", "assets/player.png"); + this.load.image('player', 'assets/player.png'); } create(data: SceneData): void { @@ -10437,7 +10448,7 @@ class GameScene extends Phaser.Scene { this.inputManager.destroy(); // Remove event listeners - this.events.off("*"); + this.events.off('*'); } } ``` @@ -10446,13 +10457,13 @@ class GameScene extends Phaser.Scene { ```typescript // Proper scene transitions with data -this.scene.start("NextScene", { +this.scene.start('NextScene', { playerScore: this.playerScore, currentLevel: this.currentLevel + 1, }); // Scene overlays for UI -this.scene.launch("PauseMenuScene"); +this.scene.launch('PauseMenuScene'); this.scene.pause(); ``` @@ -10496,7 +10507,7 @@ class Player extends GameEntity { private health!: HealthComponent; constructor(scene: Phaser.Scene, x: number, y: number) { - super(scene, x, y, "player"); + super(scene, x, y, 'player'); this.movement = this.addComponent(new MovementComponent(this)); this.health = this.addComponent(new HealthComponent(this, 100)); @@ -10516,7 +10527,7 @@ class GameManager { constructor(scene: Phaser.Scene) { if (GameManager.instance) { - throw new Error("GameManager already exists!"); + throw new Error('GameManager already exists!'); } this.scene = scene; @@ -10526,7 +10537,7 @@ class GameManager { static getInstance(): GameManager { if (!GameManager.instance) { - throw new Error("GameManager not initialized!"); + throw new Error('GameManager not initialized!'); } return GameManager.instance; } @@ -10573,7 +10584,7 @@ class BulletPool { } // Pool exhausted - create new bullet - console.warn("Bullet pool exhausted, creating new bullet"); + console.warn('Bullet pool exhausted, creating new bullet'); return new Bullet(this.scene, 0, 0); } @@ -10673,14 +10684,12 @@ class InputManager { } private setupKeyboard(): void { - this.keys = this.scene.input.keyboard.addKeys( - "W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT", - ); + this.keys = this.scene.input.keyboard.addKeys('W,A,S,D,SPACE,ESC,UP,DOWN,LEFT,RIGHT'); } private setupTouch(): void { - this.scene.input.on("pointerdown", this.handlePointerDown, this); - this.scene.input.on("pointerup", this.handlePointerUp, this); + this.scene.input.on('pointerdown', this.handlePointerDown, this); + this.scene.input.on('pointerup', this.handlePointerUp, this); } update(): void { @@ -10707,9 +10716,9 @@ class InputManager { class AssetManager { loadAssets(): Promise { return new Promise((resolve, reject) => { - this.scene.load.on("filecomplete", this.handleFileComplete, this); - this.scene.load.on("loaderror", this.handleLoadError, this); - this.scene.load.on("complete", () => resolve()); + this.scene.load.on('filecomplete', this.handleFileComplete, this); + this.scene.load.on('loaderror', this.handleLoadError, this); + this.scene.load.on('complete', () => resolve()); this.scene.load.start(); }); @@ -10725,8 +10734,8 @@ class AssetManager { private loadFallbackAsset(key: string): void { // Load placeholder or default assets switch (key) { - case "player": - this.scene.load.image("player", "assets/defaults/default-player.png"); + case 'player': + this.scene.load.image('player', 'assets/defaults/default-player.png'); break; default: console.warn(`No fallback for asset: ${key}`); @@ -10753,11 +10762,11 @@ class GameSystem { private attemptRecovery(context: string): void { switch (context) { - case "update": + case 'update': // Reset system state this.reset(); break; - case "render": + case 'render': // Disable visual effects this.disableEffects(); break; @@ -10777,7 +10786,7 @@ class GameSystem { ```typescript // Example test for game mechanics -describe("HealthComponent", () => { +describe('HealthComponent', () => { let healthComponent: HealthComponent; beforeEach(() => { @@ -10785,18 +10794,18 @@ describe("HealthComponent", () => { healthComponent = new HealthComponent(mockEntity, 100); }); - test("should initialize with correct health", () => { + test('should initialize with correct health', () => { expect(healthComponent.currentHealth).toBe(100); expect(healthComponent.maxHealth).toBe(100); }); - test("should handle damage correctly", () => { + test('should handle damage correctly', () => { healthComponent.takeDamage(25); expect(healthComponent.currentHealth).toBe(75); expect(healthComponent.isAlive()).toBe(true); }); - test("should handle death correctly", () => { + test('should handle death correctly', () => { healthComponent.takeDamage(150); expect(healthComponent.currentHealth).toBe(0); expect(healthComponent.isAlive()).toBe(false); @@ -10809,7 +10818,7 @@ describe("HealthComponent", () => { **Scene Testing:** ```typescript -describe("GameScene Integration", () => { +describe('GameScene Integration', () => { let scene: GameScene; let mockGame: Phaser.Game; @@ -10819,7 +10828,7 @@ describe("GameScene Integration", () => { scene = new GameScene(); }); - test("should initialize all systems", () => { + test('should initialize all systems', () => { scene.create({}); expect(scene.gameManager).toBeDefined(); diff --git a/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt b/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt index 87d17aac..275f881e 100644 --- a/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt +++ b/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt @@ -1265,7 +1265,7 @@ sections: instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions for Unity implementation. template: | **Primary Loop ({{duration}} seconds):** - + 1. {{action_1}} ({{time_1}}s) - {{unity_component}} 2. {{action_2}} ({{time_2}}s) - {{unity_component}} 3. {{action_3}} ({{time_3}}s) - {{unity_component}} @@ -1277,12 +1277,12 @@ sections: instruction: Clearly define success and failure states with Unity-specific implementation notes template: | **Victory Conditions:** - + - {{win_condition_1}} - Unity Event: {{unity_event}} - {{win_condition_2}} - Unity Event: {{unity_event}} - + **Failure States:** - + - {{loss_condition_1}} - Trigger: {{unity_trigger}} - {{loss_condition_2}} - Trigger: {{unity_trigger}} examples: @@ -1302,22 +1302,22 @@ sections: title: "{{mechanic_name}}" template: | **Description:** {{detailed_description}} - + **Player Input:** {{input_method}} - Unity Input System: {{input_action}} - + **System Response:** {{game_response}} - + **Unity Implementation Notes:** - + - **Components Needed:** {{component_list}} - **Physics Requirements:** {{physics_2d_setup}} - **Animation States:** {{animator_states}} - **Performance Considerations:** {{optimization_notes}} - + **Dependencies:** {{other_mechanics_needed}} - + **Script Architecture:** - + - {{script_name}}.cs - {{responsibility}} - {{manager_script}}.cs - {{management_role}} examples: @@ -1343,15 +1343,15 @@ sections: title: Player Progression template: | **Progression Type:** {{linear|branching|metroidvania}} - + **Key Milestones:** - + 1. **{{milestone_1}}** - {{unlock_description}} - Unity: {{scriptable_object_update}} 2. **{{milestone_2}}** - {{unlock_description}} - Unity: {{scriptable_object_update}} 3. **{{milestone_3}}** - {{unlock_description}} - Unity: {{scriptable_object_update}} - + **Save Data Structure:** - + ```csharp [System.Serializable] public class PlayerProgress @@ -1367,13 +1367,13 @@ sections: template: | **Tutorial Phase:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} - + **Early Game:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} - + **Mid Game:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} - + **Late Game:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} examples: @@ -1406,22 +1406,22 @@ sections: **Target Duration:** {{target_time}} **Key Elements:** {{required_mechanics}} **Difficulty Rating:** {{relative_difficulty}} - + **Unity Scene Structure:** - + - **Environment:** {{tilemap_setup}} - **Gameplay Objects:** {{prefab_list}} - **Lighting:** {{lighting_setup}} - **Audio:** {{audio_sources}} - + **Level Flow Template:** - + - **Introduction:** {{intro_description}} - Area: {{unity_area_bounds}} - **Challenge:** {{main_challenge}} - Mechanics: {{active_components}} - **Resolution:** {{completion_requirement}} - Trigger: {{completion_trigger}} - + **Reusable Prefabs:** - + - {{prefab_name}} - {{prefab_purpose}} examples: - "Environment: TilemapRenderer with Platform tileset, Lighting: 2D Global Light + Point Lights" @@ -1432,9 +1432,9 @@ sections: **Total Levels:** {{number}} **Unlock Pattern:** {{progression_method}} **Scene Management:** {{unity_scene_loading}} - + **Unity Scene Organization:** - + - Scene Naming: {{naming_convention}} - Addressable Assets: {{addressable_groups}} - Loading Screens: {{loading_implementation}} @@ -1459,13 +1459,13 @@ sections: **Physics:** {{2D Only|3D Only|Hybrid}} **Scripting Backend:** {{Mono|IL2CPP}} **API Compatibility:** {{.NET Standard 2.1|.NET Framework}} - + **Required Packages:** - + - {{package_name}} {{version}} - {{purpose}} - + **Project Settings:** - + - Color Space: {{Linear|Gamma}} - Quality Settings: {{quality_levels}} - Physics Settings: {{physics_config}} @@ -1479,9 +1479,9 @@ sections: **Memory Usage:** <{{memory_limit}}MB heap, <{{texture_memory}}MB textures **Load Times:** <{{load_time}}s initial, <{{level_load}}s between levels **Battery Usage:** Optimized for mobile devices - {{battery_target}} hours gameplay - + **Unity Profiler Targets:** - + - CPU Frame Time: <{{cpu_time}}ms - GPU Frame Time: <{{gpu_time}}ms - GC Allocs: <{{gc_limit}}KB per frame @@ -1492,20 +1492,20 @@ sections: title: Platform Specific Requirements template: | **Desktop:** - + - Resolution: {{min_resolution}} - {{max_resolution}} - Input: Keyboard, Mouse, Gamepad ({{gamepad_support}}) - Build Target: {{desktop_targets}} - + **Mobile:** - + - Resolution: {{mobile_min}} - {{mobile_max}} - Input: Touch, Accelerometer ({{sensor_support}}) - OS: iOS {{ios_min}}+, Android {{android_min}}+ (API {{api_level}}) - Device Requirements: {{device_specs}} - + **Web (if applicable):** - + - WebGL Version: {{webgl_version}} - Browser Support: {{browser_list}} - Compression: {{compression_format}} @@ -1516,21 +1516,21 @@ sections: instruction: Define asset specifications for Unity pipeline optimization template: | **2D Art Assets:** - + - Sprites: {{sprite_resolution}} at {{ppu}} PPU - Texture Format: {{texture_compression}} - Atlas Strategy: {{sprite_atlas_setup}} - Animation: {{animation_type}} at {{framerate}} FPS - + **Audio Assets:** - + - Music: {{audio_format}} at {{sample_rate}} Hz - SFX: {{sfx_format}} at {{sfx_sample_rate}} Hz - Compression: {{audio_compression}} - 3D Audio: {{spatial_audio}} - + **UI Assets:** - + - Canvas Resolution: {{ui_resolution}} - UI Scale Mode: {{scale_mode}} - Font: {{font_requirements}} @@ -1551,17 +1551,17 @@ sections: title: Code Architecture Pattern template: | **Architecture Pattern:** {{MVC|MVVM|ECS|Component-Based|Custom}} - + **Core Systems Required:** - + - **Scene Management:** {{scene_manager_approach}} - **State Management:** {{state_pattern_implementation}} - **Event System:** {{event_system_choice}} - **Object Pooling:** {{pooling_strategy}} - **Save/Load System:** {{save_system_approach}} - + **Folder Structure:** - + ``` Assets/ ├── _Project/ @@ -1571,9 +1571,9 @@ sections: │ ├── Scenes/ │ └── {{additional_folders}} ``` - + **Naming Conventions:** - + - Scripts: {{script_naming}} - Prefabs: {{prefab_naming}} - Scenes: {{scene_naming}} @@ -1584,19 +1584,19 @@ sections: title: Unity Systems Integration template: | **Required Unity Systems:** - + - **Input System:** {{input_implementation}} - **Animation System:** {{animation_approach}} - **Physics Integration:** {{physics_usage}} - **Rendering Features:** {{rendering_requirements}} - **Asset Streaming:** {{asset_loading_strategy}} - + **Third-Party Integrations:** - + - {{integration_name}}: {{integration_purpose}} - + **Performance Systems:** - + - **Profiling Integration:** {{profiling_setup}} - **Memory Management:** {{memory_strategy}} - **Build Pipeline:** {{build_automation}} @@ -1607,20 +1607,20 @@ sections: title: Data Management template: | **Save Data Architecture:** - + - **Format:** {{PlayerPrefs|JSON|Binary|Cloud}} - **Structure:** {{save_data_organization}} - **Encryption:** {{security_approach}} - **Cloud Sync:** {{cloud_integration}} - + **Configuration Data:** - + - **ScriptableObjects:** {{scriptable_object_usage}} - **Settings Management:** {{settings_system}} - **Localization:** {{localization_approach}} - + **Runtime Data:** - + - **Caching Strategy:** {{cache_implementation}} - **Memory Pools:** {{pooling_objects}} - **Asset References:** {{asset_reference_system}} @@ -1848,15 +1848,15 @@ sections: instruction: Provide guidance for the Story Manager (SM) agent on how to break down this GDD into implementable user stories template: | **Epic Prioritization:** {{epic_order_rationale}} - + **Story Sizing Guidelines:** - + - Foundation stories: {{foundation_story_scope}} - Feature stories: {{feature_story_scope}} - Polish stories: {{polish_story_scope}} - + **Unity-Specific Story Considerations:** - + - Each story should result in testable Unity scenes or prefabs - Include specific Unity components and systems in acceptance criteria - Consider cross-platform testing requirements @@ -1892,7 +1892,7 @@ sections: - id: initial-setup instruction: | This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels. - + If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents. - id: introduction @@ -1900,7 +1900,7 @@ sections: instruction: Establish the purpose and scope of level design for this game content: | This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document. - + This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints. sections: - id: change-log @@ -1947,29 +1947,29 @@ sections: title: "{{category_name}} Levels" template: | **Purpose:** {{gameplay_purpose}} - + **Target Duration:** {{min_time}} - {{max_time}} minutes - + **Difficulty Range:** {{difficulty_scale}} - + **Key Mechanics Featured:** - + - {{mechanic_1}} - {{usage_description}} - {{mechanic_2}} - {{usage_description}} - + **Player Objectives:** - + - Primary: {{primary_objective}} - Secondary: {{secondary_objective}} - Hidden: {{secret_objective}} - + **Success Criteria:** - + - {{completion_requirement_1}} - {{completion_requirement_2}} - + **Technical Requirements:** - + - Maximum entities: {{entity_limit}} - Performance target: {{fps_target}} FPS - Memory budget: {{memory_limit}}MB @@ -1984,11 +1984,11 @@ sections: instruction: Based on GDD requirements, define the overall level organization template: | **Organization Type:** {{linear|hub_world|open_world}} - + **Total Level Count:** {{number}} - + **World Breakdown:** - + - World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}} @@ -2023,7 +2023,7 @@ sections: instruction: Define how players access new levels template: | **Progression Gates:** - + - Linear progression: Complete previous level - Star requirements: {{star_count}} stars to unlock - Skill gates: Demonstrate {{skill_requirement}} @@ -2038,17 +2038,17 @@ sections: instruction: Define all environmental components that can be used in levels template: | **Terrain Types:** - + - {{terrain_1}}: {{properties_and_usage}} - {{terrain_2}}: {{properties_and_usage}} - + **Interactive Objects:** - + - {{object_1}}: {{behavior_and_purpose}} - {{object_2}}: {{behavior_and_purpose}} - + **Hazards and Obstacles:** - + - {{hazard_1}}: {{damage_and_behavior}} - {{hazard_2}}: {{damage_and_behavior}} - id: collectibles-rewards @@ -2056,18 +2056,18 @@ sections: instruction: Define all collectible items and their placement rules template: | **Collectible Types:** - + - {{collectible_1}}: {{value_and_purpose}} - {{collectible_2}}: {{value_and_purpose}} - + **Placement Guidelines:** - + - Mandatory collectibles: {{placement_rules}} - Optional collectibles: {{placement_rules}} - Secret collectibles: {{placement_rules}} - + **Reward Distribution:** - + - Easy to find: {{percentage}}% - Moderate challenge: {{percentage}}% - High skill required: {{percentage}}% @@ -2076,18 +2076,18 @@ sections: instruction: Define how enemies should be placed and balanced in levels template: | **Enemy Categories:** - + - {{enemy_type_1}}: {{behavior_and_usage}} - {{enemy_type_2}}: {{behavior_and_usage}} - + **Placement Principles:** - + - Introduction encounters: {{guideline}} - Standard encounters: {{guideline}} - Challenge encounters: {{guideline}} - + **Difficulty Scaling:** - + - Enemy count progression: {{scaling_rule}} - Enemy type introduction: {{pacing_rule}} - Encounter complexity: {{complexity_rule}} @@ -2100,14 +2100,14 @@ sections: title: Level Layout Principles template: | **Spatial Design:** - + - Grid size: {{grid_dimensions}} - Minimum path width: {{width_units}} - Maximum vertical distance: {{height_units}} - Safe zones placement: {{safety_guidelines}} - + **Navigation Design:** - + - Clear path indication: {{visual_cues}} - Landmark placement: {{landmark_rules}} - Dead end avoidance: {{dead_end_policy}} @@ -2117,13 +2117,13 @@ sections: instruction: Define how to control the rhythm and pace of gameplay within levels template: | **Action Sequences:** - + - High intensity duration: {{max_duration}} - Rest period requirement: {{min_rest_time}} - Intensity variation: {{pacing_pattern}} - + **Learning Sequences:** - + - New mechanic introduction: {{teaching_method}} - Practice opportunity: {{practice_duration}} - Skill application: {{application_context}} @@ -2132,14 +2132,14 @@ sections: instruction: Define how to create appropriate challenges for each level type template: | **Challenge Types:** - + - Execution challenges: {{skill_requirements}} - Puzzle challenges: {{complexity_guidelines}} - Time challenges: {{time_pressure_rules}} - Resource challenges: {{resource_management}} - + **Difficulty Calibration:** - + - Skill check frequency: {{frequency_guidelines}} - Failure recovery: {{retry_mechanics}} - Hint system integration: {{help_system}} @@ -2153,7 +2153,7 @@ sections: instruction: Define how level data should be structured for implementation template: | **Level File Format:** - + - Data format: {{json|yaml|custom}} - File naming: `level_{{world}}_{{number}}.{{extension}}` - Data organization: {{structure_description}} @@ -2191,14 +2191,14 @@ sections: instruction: Define how level assets are organized and loaded template: | **Tilemap Requirements:** - + - Tile size: {{tile_dimensions}}px - Tileset organization: {{tileset_structure}} - Layer organization: {{layer_system}} - Collision data: {{collision_format}} - + **Audio Integration:** - + - Background music: {{music_requirements}} - Ambient sounds: {{ambient_system}} - Dynamic audio: {{dynamic_audio_rules}} @@ -2207,19 +2207,19 @@ sections: instruction: Define performance requirements for level systems template: | **Entity Limits:** - + - Maximum active entities: {{entity_limit}} - Maximum particles: {{particle_limit}} - Maximum audio sources: {{audio_limit}} - + **Memory Management:** - + - Texture memory budget: {{texture_memory}}MB - Audio memory budget: {{audio_memory}}MB - Level loading time: <{{load_time}}s - + **Culling and LOD:** - + - Off-screen culling: {{culling_distance}} - Level-of-detail rules: {{lod_system}} - Asset streaming: {{streaming_requirements}} @@ -2232,13 +2232,13 @@ sections: title: Automated Testing template: | **Performance Testing:** - + - Frame rate validation: Maintain {{fps_target}} FPS - Memory usage monitoring: Stay under {{memory_limit}}MB - Loading time verification: Complete in <{{load_time}}s - + **Gameplay Testing:** - + - Completion path validation: All objectives achievable - Collectible accessibility: All items reachable - Softlock prevention: No unwinnable states @@ -2266,14 +2266,14 @@ sections: title: Balance Validation template: | **Metrics Collection:** - + - Completion rate: Target {{completion_percentage}}% - Average completion time: {{target_time}} ± {{variance}} - Death count per level: <{{max_deaths}} - Collectible discovery rate: {{discovery_percentage}}% - + **Iteration Guidelines:** - + - Adjustment criteria: {{criteria_for_changes}} - Testing sample size: {{minimum_testers}} - Validation period: {{testing_duration}} @@ -2286,14 +2286,14 @@ sections: title: Design Phase template: | **Concept Development:** - + 1. Define level purpose and goals 2. Create rough layout sketch 3. Identify key mechanics and challenges 4. Estimate difficulty and duration - + **Documentation Requirements:** - + - Level design brief - Layout diagrams - Mechanic integration notes @@ -2302,15 +2302,15 @@ sections: title: Implementation Phase template: | **Technical Implementation:** - + 1. Create level data file 2. Build tilemap and layout 3. Place entities and objects 4. Configure level logic and triggers 5. Integrate audio and visual effects - + **Quality Assurance:** - + 1. Automated testing execution 2. Internal playtesting 3. Performance validation @@ -2319,14 +2319,14 @@ sections: title: Integration Phase template: | **Game Integration:** - + 1. Level progression integration 2. Save system compatibility 3. Analytics integration 4. Achievement system integration - + **Final Validation:** - + 1. Full game context testing 2. Performance regression testing 3. Platform compatibility verification @@ -2379,7 +2379,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document. - + This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design. - id: game-vision @@ -2436,7 +2436,7 @@ sections: repeatable: true template: | **Core Mechanic: {{mechanic_name}}** - + - **Description:** {{how_it_works}} - **Player Value:** {{why_its_fun}} - **Implementation Scope:** {{complexity_estimate}} @@ -2463,12 +2463,12 @@ sections: title: Technical Constraints template: | **Platform Requirements:** - + - Primary: {{platform_1}} - {{requirements}} - Secondary: {{platform_2}} - {{requirements}} - + **Technical Specifications:** - + - Engine: Unity & C# - Performance Target: {{fps_target}} FPS on {{target_device}} - Memory Budget: <{{memory_limit}}MB @@ -2506,10 +2506,10 @@ sections: title: Competitive Analysis template: | **Direct Competitors:** - + - {{competitor_1}}: {{strengths_and_weaknesses}} - {{competitor_2}}: {{strengths_and_weaknesses}} - + **Differentiation Strategy:** {{how_we_differ_and_why_thats_valuable}} - id: market-opportunity @@ -2533,16 +2533,16 @@ sections: title: Content Categories template: | **Core Content:** - + - {{content_type_1}}: {{quantity_and_description}} - {{content_type_2}}: {{quantity_and_description}} - + **Optional Content:** - + - {{optional_content_type}}: {{quantity_and_description}} - + **Replay Elements:** - + - {{replayability_features}} - id: difficulty-accessibility title: Difficulty and Accessibility @@ -2609,13 +2609,13 @@ sections: title: Player Experience Metrics template: | **Engagement Goals:** - + - Tutorial completion rate: >{{percentage}}% - Average session length: {{duration}} minutes - Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}% - + **Quality Benchmarks:** - + - Player satisfaction: >{{rating}}/10 - Completion rate: >{{percentage}}% - Technical performance: {{fps_target}} FPS consistent @@ -2623,13 +2623,13 @@ sections: title: Development Metrics template: | **Technical Targets:** - + - Zero critical bugs at launch - Performance targets met on all platforms - Load times under {{seconds}}s - + **Process Goals:** - + - Development timeline adherence - Feature scope completion - Quality assurance standards @@ -2638,7 +2638,7 @@ sections: condition: has_business_goals template: | **Commercial Goals:** - + - {{revenue_target}} in first {{time_period}} - {{user_acquisition_target}} players in first {{time_period}} - {{retention_target}} monthly active users @@ -2691,12 +2691,12 @@ sections: title: Validation Plan template: | **Concept Testing:** - + - {{validation_method_1}} - {{timeline}} - {{validation_method_2}} - {{timeline}} - + **Prototype Testing:** - + - {{testing_approach}} - {{timeline}} - {{feedback_collection_method}} - {{timeline}} diff --git a/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt b/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt index d1987ffb..6637e712 100644 --- a/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt +++ b/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt @@ -524,13 +524,13 @@ sections: - id: initial-setup instruction: | This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality. - + Before starting, ensure you have access to: - + - Game Design Document (GDD) - Game Architecture Document - Any existing stories in this epic - + The story should be specific enough that a developer can implement it without requiring additional design decisions. - id: story-header @@ -579,12 +579,12 @@ sections: title: Files to Create/Modify template: | **New Files:** - + - `{{file_path_1}}` - {{purpose}} - `{{file_path_2}}` - {{purpose}} - + **Modified Files:** - + - `{{existing_file_1}}` - {{changes_needed}} - `{{existing_file_2}}` - {{changes_needed}} - id: class-interface-definitions @@ -667,13 +667,13 @@ sections: instruction: Reference the specific sections of the GDD that this story implements template: | **GDD Reference:** {{section_name}} ({{page_or_section_number}}) - + **Game Mechanic:** {{mechanic_name}} - + **Player Experience Goal:** {{experience_description}} - + **Balance Parameters:** - + - {{parameter_1}}: {{value_or_range}} - {{parameter_2}}: {{value_or_range}} @@ -720,15 +720,15 @@ sections: instruction: List any dependencies that must be completed before this story can be implemented template: | **Story Dependencies:** - + - {{story_id}}: {{dependency_description}} - + **Technical Dependencies:** - + - {{system_or_file}}: {{requirement}} - + **Asset Dependencies:** - + - {{asset_type}}: {{asset_description}} - Location: `{{asset_path}}` @@ -751,17 +751,17 @@ sections: instruction: Any additional context, design decisions, or implementation notes template: | **Implementation Notes:** - + - {{note_1}} - {{note_2}} - + **Design Decisions:** - + - {{decision_1}}: {{rationale}} - {{decision_2}}: {{rationale}} - + **Future Considerations:** - + - {{future_enhancement_1}} - {{future_optimization_1}} ==================== END: .bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml ==================== diff --git a/dist/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt b/dist/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt index 46f0f929..4e45a0e2 100644 --- a/dist/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt +++ b/dist/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt @@ -484,7 +484,7 @@ dependencies: ==================== START: .bmad-2d-unity-game-dev/tasks/facilitate-brainstorming-session.md ==================== --- docOutputLocation: docs/brainstorming-session-results.md -template: ".bmad-2d-unity-game-dev/templates/brainstorming-output-tmpl.yaml" +template: '.bmad-2d-unity-game-dev/templates/brainstorming-output-tmpl.yaml' --- # Facilitate Brainstorming Session Task @@ -1495,12 +1495,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 @@ -1821,7 +1821,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}} @@ -2022,7 +2022,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 @@ -2087,7 +2087,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: @@ -2099,7 +2106,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: @@ -2126,7 +2139,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 @@ -2161,7 +2174,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -2265,11 +2278,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:" @@ -2394,7 +2407,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-2d-unity-game-dev/templates/brainstorming-output-tmpl.yaml ==================== @@ -4184,7 +4197,7 @@ sections: instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions for Unity implementation. template: | **Primary Loop ({{duration}} seconds):** - + 1. {{action_1}} ({{time_1}}s) - {{unity_component}} 2. {{action_2}} ({{time_2}}s) - {{unity_component}} 3. {{action_3}} ({{time_3}}s) - {{unity_component}} @@ -4196,12 +4209,12 @@ sections: instruction: Clearly define success and failure states with Unity-specific implementation notes template: | **Victory Conditions:** - + - {{win_condition_1}} - Unity Event: {{unity_event}} - {{win_condition_2}} - Unity Event: {{unity_event}} - + **Failure States:** - + - {{loss_condition_1}} - Trigger: {{unity_trigger}} - {{loss_condition_2}} - Trigger: {{unity_trigger}} examples: @@ -4221,22 +4234,22 @@ sections: title: "{{mechanic_name}}" template: | **Description:** {{detailed_description}} - + **Player Input:** {{input_method}} - Unity Input System: {{input_action}} - + **System Response:** {{game_response}} - + **Unity Implementation Notes:** - + - **Components Needed:** {{component_list}} - **Physics Requirements:** {{physics_2d_setup}} - **Animation States:** {{animator_states}} - **Performance Considerations:** {{optimization_notes}} - + **Dependencies:** {{other_mechanics_needed}} - + **Script Architecture:** - + - {{script_name}}.cs - {{responsibility}} - {{manager_script}}.cs - {{management_role}} examples: @@ -4262,15 +4275,15 @@ sections: title: Player Progression template: | **Progression Type:** {{linear|branching|metroidvania}} - + **Key Milestones:** - + 1. **{{milestone_1}}** - {{unlock_description}} - Unity: {{scriptable_object_update}} 2. **{{milestone_2}}** - {{unlock_description}} - Unity: {{scriptable_object_update}} 3. **{{milestone_3}}** - {{unlock_description}} - Unity: {{scriptable_object_update}} - + **Save Data Structure:** - + ```csharp [System.Serializable] public class PlayerProgress @@ -4286,13 +4299,13 @@ sections: template: | **Tutorial Phase:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} - + **Early Game:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} - + **Mid Game:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} - + **Late Game:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} examples: @@ -4325,22 +4338,22 @@ sections: **Target Duration:** {{target_time}} **Key Elements:** {{required_mechanics}} **Difficulty Rating:** {{relative_difficulty}} - + **Unity Scene Structure:** - + - **Environment:** {{tilemap_setup}} - **Gameplay Objects:** {{prefab_list}} - **Lighting:** {{lighting_setup}} - **Audio:** {{audio_sources}} - + **Level Flow Template:** - + - **Introduction:** {{intro_description}} - Area: {{unity_area_bounds}} - **Challenge:** {{main_challenge}} - Mechanics: {{active_components}} - **Resolution:** {{completion_requirement}} - Trigger: {{completion_trigger}} - + **Reusable Prefabs:** - + - {{prefab_name}} - {{prefab_purpose}} examples: - "Environment: TilemapRenderer with Platform tileset, Lighting: 2D Global Light + Point Lights" @@ -4351,9 +4364,9 @@ sections: **Total Levels:** {{number}} **Unlock Pattern:** {{progression_method}} **Scene Management:** {{unity_scene_loading}} - + **Unity Scene Organization:** - + - Scene Naming: {{naming_convention}} - Addressable Assets: {{addressable_groups}} - Loading Screens: {{loading_implementation}} @@ -4378,13 +4391,13 @@ sections: **Physics:** {{2D Only|3D Only|Hybrid}} **Scripting Backend:** {{Mono|IL2CPP}} **API Compatibility:** {{.NET Standard 2.1|.NET Framework}} - + **Required Packages:** - + - {{package_name}} {{version}} - {{purpose}} - + **Project Settings:** - + - Color Space: {{Linear|Gamma}} - Quality Settings: {{quality_levels}} - Physics Settings: {{physics_config}} @@ -4398,9 +4411,9 @@ sections: **Memory Usage:** <{{memory_limit}}MB heap, <{{texture_memory}}MB textures **Load Times:** <{{load_time}}s initial, <{{level_load}}s between levels **Battery Usage:** Optimized for mobile devices - {{battery_target}} hours gameplay - + **Unity Profiler Targets:** - + - CPU Frame Time: <{{cpu_time}}ms - GPU Frame Time: <{{gpu_time}}ms - GC Allocs: <{{gc_limit}}KB per frame @@ -4411,20 +4424,20 @@ sections: title: Platform Specific Requirements template: | **Desktop:** - + - Resolution: {{min_resolution}} - {{max_resolution}} - Input: Keyboard, Mouse, Gamepad ({{gamepad_support}}) - Build Target: {{desktop_targets}} - + **Mobile:** - + - Resolution: {{mobile_min}} - {{mobile_max}} - Input: Touch, Accelerometer ({{sensor_support}}) - OS: iOS {{ios_min}}+, Android {{android_min}}+ (API {{api_level}}) - Device Requirements: {{device_specs}} - + **Web (if applicable):** - + - WebGL Version: {{webgl_version}} - Browser Support: {{browser_list}} - Compression: {{compression_format}} @@ -4435,21 +4448,21 @@ sections: instruction: Define asset specifications for Unity pipeline optimization template: | **2D Art Assets:** - + - Sprites: {{sprite_resolution}} at {{ppu}} PPU - Texture Format: {{texture_compression}} - Atlas Strategy: {{sprite_atlas_setup}} - Animation: {{animation_type}} at {{framerate}} FPS - + **Audio Assets:** - + - Music: {{audio_format}} at {{sample_rate}} Hz - SFX: {{sfx_format}} at {{sfx_sample_rate}} Hz - Compression: {{audio_compression}} - 3D Audio: {{spatial_audio}} - + **UI Assets:** - + - Canvas Resolution: {{ui_resolution}} - UI Scale Mode: {{scale_mode}} - Font: {{font_requirements}} @@ -4470,17 +4483,17 @@ sections: title: Code Architecture Pattern template: | **Architecture Pattern:** {{MVC|MVVM|ECS|Component-Based|Custom}} - + **Core Systems Required:** - + - **Scene Management:** {{scene_manager_approach}} - **State Management:** {{state_pattern_implementation}} - **Event System:** {{event_system_choice}} - **Object Pooling:** {{pooling_strategy}} - **Save/Load System:** {{save_system_approach}} - + **Folder Structure:** - + ``` Assets/ ├── _Project/ @@ -4490,9 +4503,9 @@ sections: │ ├── Scenes/ │ └── {{additional_folders}} ``` - + **Naming Conventions:** - + - Scripts: {{script_naming}} - Prefabs: {{prefab_naming}} - Scenes: {{scene_naming}} @@ -4503,19 +4516,19 @@ sections: title: Unity Systems Integration template: | **Required Unity Systems:** - + - **Input System:** {{input_implementation}} - **Animation System:** {{animation_approach}} - **Physics Integration:** {{physics_usage}} - **Rendering Features:** {{rendering_requirements}} - **Asset Streaming:** {{asset_loading_strategy}} - + **Third-Party Integrations:** - + - {{integration_name}}: {{integration_purpose}} - + **Performance Systems:** - + - **Profiling Integration:** {{profiling_setup}} - **Memory Management:** {{memory_strategy}} - **Build Pipeline:** {{build_automation}} @@ -4526,20 +4539,20 @@ sections: title: Data Management template: | **Save Data Architecture:** - + - **Format:** {{PlayerPrefs|JSON|Binary|Cloud}} - **Structure:** {{save_data_organization}} - **Encryption:** {{security_approach}} - **Cloud Sync:** {{cloud_integration}} - + **Configuration Data:** - + - **ScriptableObjects:** {{scriptable_object_usage}} - **Settings Management:** {{settings_system}} - **Localization:** {{localization_approach}} - + **Runtime Data:** - + - **Caching Strategy:** {{cache_implementation}} - **Memory Pools:** {{pooling_objects}} - **Asset References:** {{asset_reference_system}} @@ -4767,15 +4780,15 @@ sections: instruction: Provide guidance for the Story Manager (SM) agent on how to break down this GDD into implementable user stories template: | **Epic Prioritization:** {{epic_order_rationale}} - + **Story Sizing Guidelines:** - + - Foundation stories: {{foundation_story_scope}} - Feature stories: {{feature_story_scope}} - Polish stories: {{polish_story_scope}} - + **Unity-Specific Story Considerations:** - + - Each story should result in testable Unity scenes or prefabs - Include specific Unity components and systems in acceptance criteria - Consider cross-platform testing requirements @@ -4811,7 +4824,7 @@ sections: - id: initial-setup instruction: | This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels. - + If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents. - id: introduction @@ -4819,7 +4832,7 @@ sections: instruction: Establish the purpose and scope of level design for this game content: | This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document. - + This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints. sections: - id: change-log @@ -4866,29 +4879,29 @@ sections: title: "{{category_name}} Levels" template: | **Purpose:** {{gameplay_purpose}} - + **Target Duration:** {{min_time}} - {{max_time}} minutes - + **Difficulty Range:** {{difficulty_scale}} - + **Key Mechanics Featured:** - + - {{mechanic_1}} - {{usage_description}} - {{mechanic_2}} - {{usage_description}} - + **Player Objectives:** - + - Primary: {{primary_objective}} - Secondary: {{secondary_objective}} - Hidden: {{secret_objective}} - + **Success Criteria:** - + - {{completion_requirement_1}} - {{completion_requirement_2}} - + **Technical Requirements:** - + - Maximum entities: {{entity_limit}} - Performance target: {{fps_target}} FPS - Memory budget: {{memory_limit}}MB @@ -4903,11 +4916,11 @@ sections: instruction: Based on GDD requirements, define the overall level organization template: | **Organization Type:** {{linear|hub_world|open_world}} - + **Total Level Count:** {{number}} - + **World Breakdown:** - + - World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}} @@ -4942,7 +4955,7 @@ sections: instruction: Define how players access new levels template: | **Progression Gates:** - + - Linear progression: Complete previous level - Star requirements: {{star_count}} stars to unlock - Skill gates: Demonstrate {{skill_requirement}} @@ -4957,17 +4970,17 @@ sections: instruction: Define all environmental components that can be used in levels template: | **Terrain Types:** - + - {{terrain_1}}: {{properties_and_usage}} - {{terrain_2}}: {{properties_and_usage}} - + **Interactive Objects:** - + - {{object_1}}: {{behavior_and_purpose}} - {{object_2}}: {{behavior_and_purpose}} - + **Hazards and Obstacles:** - + - {{hazard_1}}: {{damage_and_behavior}} - {{hazard_2}}: {{damage_and_behavior}} - id: collectibles-rewards @@ -4975,18 +4988,18 @@ sections: instruction: Define all collectible items and their placement rules template: | **Collectible Types:** - + - {{collectible_1}}: {{value_and_purpose}} - {{collectible_2}}: {{value_and_purpose}} - + **Placement Guidelines:** - + - Mandatory collectibles: {{placement_rules}} - Optional collectibles: {{placement_rules}} - Secret collectibles: {{placement_rules}} - + **Reward Distribution:** - + - Easy to find: {{percentage}}% - Moderate challenge: {{percentage}}% - High skill required: {{percentage}}% @@ -4995,18 +5008,18 @@ sections: instruction: Define how enemies should be placed and balanced in levels template: | **Enemy Categories:** - + - {{enemy_type_1}}: {{behavior_and_usage}} - {{enemy_type_2}}: {{behavior_and_usage}} - + **Placement Principles:** - + - Introduction encounters: {{guideline}} - Standard encounters: {{guideline}} - Challenge encounters: {{guideline}} - + **Difficulty Scaling:** - + - Enemy count progression: {{scaling_rule}} - Enemy type introduction: {{pacing_rule}} - Encounter complexity: {{complexity_rule}} @@ -5019,14 +5032,14 @@ sections: title: Level Layout Principles template: | **Spatial Design:** - + - Grid size: {{grid_dimensions}} - Minimum path width: {{width_units}} - Maximum vertical distance: {{height_units}} - Safe zones placement: {{safety_guidelines}} - + **Navigation Design:** - + - Clear path indication: {{visual_cues}} - Landmark placement: {{landmark_rules}} - Dead end avoidance: {{dead_end_policy}} @@ -5036,13 +5049,13 @@ sections: instruction: Define how to control the rhythm and pace of gameplay within levels template: | **Action Sequences:** - + - High intensity duration: {{max_duration}} - Rest period requirement: {{min_rest_time}} - Intensity variation: {{pacing_pattern}} - + **Learning Sequences:** - + - New mechanic introduction: {{teaching_method}} - Practice opportunity: {{practice_duration}} - Skill application: {{application_context}} @@ -5051,14 +5064,14 @@ sections: instruction: Define how to create appropriate challenges for each level type template: | **Challenge Types:** - + - Execution challenges: {{skill_requirements}} - Puzzle challenges: {{complexity_guidelines}} - Time challenges: {{time_pressure_rules}} - Resource challenges: {{resource_management}} - + **Difficulty Calibration:** - + - Skill check frequency: {{frequency_guidelines}} - Failure recovery: {{retry_mechanics}} - Hint system integration: {{help_system}} @@ -5072,7 +5085,7 @@ sections: instruction: Define how level data should be structured for implementation template: | **Level File Format:** - + - Data format: {{json|yaml|custom}} - File naming: `level_{{world}}_{{number}}.{{extension}}` - Data organization: {{structure_description}} @@ -5110,14 +5123,14 @@ sections: instruction: Define how level assets are organized and loaded template: | **Tilemap Requirements:** - + - Tile size: {{tile_dimensions}}px - Tileset organization: {{tileset_structure}} - Layer organization: {{layer_system}} - Collision data: {{collision_format}} - + **Audio Integration:** - + - Background music: {{music_requirements}} - Ambient sounds: {{ambient_system}} - Dynamic audio: {{dynamic_audio_rules}} @@ -5126,19 +5139,19 @@ sections: instruction: Define performance requirements for level systems template: | **Entity Limits:** - + - Maximum active entities: {{entity_limit}} - Maximum particles: {{particle_limit}} - Maximum audio sources: {{audio_limit}} - + **Memory Management:** - + - Texture memory budget: {{texture_memory}}MB - Audio memory budget: {{audio_memory}}MB - Level loading time: <{{load_time}}s - + **Culling and LOD:** - + - Off-screen culling: {{culling_distance}} - Level-of-detail rules: {{lod_system}} - Asset streaming: {{streaming_requirements}} @@ -5151,13 +5164,13 @@ sections: title: Automated Testing template: | **Performance Testing:** - + - Frame rate validation: Maintain {{fps_target}} FPS - Memory usage monitoring: Stay under {{memory_limit}}MB - Loading time verification: Complete in <{{load_time}}s - + **Gameplay Testing:** - + - Completion path validation: All objectives achievable - Collectible accessibility: All items reachable - Softlock prevention: No unwinnable states @@ -5185,14 +5198,14 @@ sections: title: Balance Validation template: | **Metrics Collection:** - + - Completion rate: Target {{completion_percentage}}% - Average completion time: {{target_time}} ± {{variance}} - Death count per level: <{{max_deaths}} - Collectible discovery rate: {{discovery_percentage}}% - + **Iteration Guidelines:** - + - Adjustment criteria: {{criteria_for_changes}} - Testing sample size: {{minimum_testers}} - Validation period: {{testing_duration}} @@ -5205,14 +5218,14 @@ sections: title: Design Phase template: | **Concept Development:** - + 1. Define level purpose and goals 2. Create rough layout sketch 3. Identify key mechanics and challenges 4. Estimate difficulty and duration - + **Documentation Requirements:** - + - Level design brief - Layout diagrams - Mechanic integration notes @@ -5221,15 +5234,15 @@ sections: title: Implementation Phase template: | **Technical Implementation:** - + 1. Create level data file 2. Build tilemap and layout 3. Place entities and objects 4. Configure level logic and triggers 5. Integrate audio and visual effects - + **Quality Assurance:** - + 1. Automated testing execution 2. Internal playtesting 3. Performance validation @@ -5238,14 +5251,14 @@ sections: title: Integration Phase template: | **Game Integration:** - + 1. Level progression integration 2. Save system compatibility 3. Analytics integration 4. Achievement system integration - + **Final Validation:** - + 1. Full game context testing 2. Performance regression testing 3. Platform compatibility verification @@ -5298,7 +5311,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document. - + This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design. - id: game-vision @@ -5355,7 +5368,7 @@ sections: repeatable: true template: | **Core Mechanic: {{mechanic_name}}** - + - **Description:** {{how_it_works}} - **Player Value:** {{why_its_fun}} - **Implementation Scope:** {{complexity_estimate}} @@ -5382,12 +5395,12 @@ sections: title: Technical Constraints template: | **Platform Requirements:** - + - Primary: {{platform_1}} - {{requirements}} - Secondary: {{platform_2}} - {{requirements}} - + **Technical Specifications:** - + - Engine: Unity & C# - Performance Target: {{fps_target}} FPS on {{target_device}} - Memory Budget: <{{memory_limit}}MB @@ -5425,10 +5438,10 @@ sections: title: Competitive Analysis template: | **Direct Competitors:** - + - {{competitor_1}}: {{strengths_and_weaknesses}} - {{competitor_2}}: {{strengths_and_weaknesses}} - + **Differentiation Strategy:** {{how_we_differ_and_why_thats_valuable}} - id: market-opportunity @@ -5452,16 +5465,16 @@ sections: title: Content Categories template: | **Core Content:** - + - {{content_type_1}}: {{quantity_and_description}} - {{content_type_2}}: {{quantity_and_description}} - + **Optional Content:** - + - {{optional_content_type}}: {{quantity_and_description}} - + **Replay Elements:** - + - {{replayability_features}} - id: difficulty-accessibility title: Difficulty and Accessibility @@ -5528,13 +5541,13 @@ sections: title: Player Experience Metrics template: | **Engagement Goals:** - + - Tutorial completion rate: >{{percentage}}% - Average session length: {{duration}} minutes - Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}% - + **Quality Benchmarks:** - + - Player satisfaction: >{{rating}}/10 - Completion rate: >{{percentage}}% - Technical performance: {{fps_target}} FPS consistent @@ -5542,13 +5555,13 @@ sections: title: Development Metrics template: | **Technical Targets:** - + - Zero critical bugs at launch - Performance targets met on all platforms - Load times under {{seconds}}s - + **Process Goals:** - + - Development timeline adherence - Feature scope completion - Quality assurance standards @@ -5557,7 +5570,7 @@ sections: condition: has_business_goals template: | **Commercial Goals:** - + - {{revenue_target}} in first {{time_period}} - {{user_acquisition_target}} players in first {{time_period}} - {{retention_target}} monthly active users @@ -5610,12 +5623,12 @@ sections: title: Validation Plan template: | **Concept Testing:** - + - {{validation_method_1}} - {{timeline}} - {{validation_method_2}} - {{timeline}} - + **Prototype Testing:** - + - {{testing_approach}} - {{timeline}} - {{feedback_collection_method}} - {{timeline}} @@ -8472,13 +8485,13 @@ sections: - id: initial-setup instruction: | This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality. - + Before starting, ensure you have access to: - + - Game Design Document (GDD) - Game Architecture Document - Any existing stories in this epic - + The story should be specific enough that a developer can implement it without requiring additional design decisions. - id: story-header @@ -8527,12 +8540,12 @@ sections: title: Files to Create/Modify template: | **New Files:** - + - `{{file_path_1}}` - {{purpose}} - `{{file_path_2}}` - {{purpose}} - + **Modified Files:** - + - `{{existing_file_1}}` - {{changes_needed}} - `{{existing_file_2}}` - {{changes_needed}} - id: class-interface-definitions @@ -8615,13 +8628,13 @@ sections: instruction: Reference the specific sections of the GDD that this story implements template: | **GDD Reference:** {{section_name}} ({{page_or_section_number}}) - + **Game Mechanic:** {{mechanic_name}} - + **Player Experience Goal:** {{experience_description}} - + **Balance Parameters:** - + - {{parameter_1}}: {{value_or_range}} - {{parameter_2}}: {{value_or_range}} @@ -8668,15 +8681,15 @@ sections: instruction: List any dependencies that must be completed before this story can be implemented template: | **Story Dependencies:** - + - {{story_id}}: {{dependency_description}} - + **Technical Dependencies:** - + - {{system_or_file}}: {{requirement}} - + **Asset Dependencies:** - + - {{asset_type}}: {{asset_description}} - Location: `{{asset_path}}` @@ -8699,17 +8712,17 @@ sections: instruction: Any additional context, design decisions, or implementation notes template: | **Implementation Notes:** - + - {{note_1}} - {{note_2}} - + **Design Decisions:** - + - {{decision_1}}: {{rationale}} - {{decision_2}}: {{rationale}} - + **Future Considerations:** - + - {{future_enhancement_1}} - {{future_optimization_1}} ==================== END: .bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml ==================== @@ -9970,7 +9983,7 @@ sections: - id: initial-setup instruction: | This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document. - + This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design. - id: game-vision @@ -10027,7 +10040,7 @@ sections: repeatable: true template: | **Core Mechanic: {{mechanic_name}}** - + - **Description:** {{how_it_works}} - **Player Value:** {{why_its_fun}} - **Implementation Scope:** {{complexity_estimate}} @@ -10054,12 +10067,12 @@ sections: title: Technical Constraints template: | **Platform Requirements:** - + - Primary: {{platform_1}} - {{requirements}} - Secondary: {{platform_2}} - {{requirements}} - + **Technical Specifications:** - + - Engine: Unity & C# - Performance Target: {{fps_target}} FPS on {{target_device}} - Memory Budget: <{{memory_limit}}MB @@ -10097,10 +10110,10 @@ sections: title: Competitive Analysis template: | **Direct Competitors:** - + - {{competitor_1}}: {{strengths_and_weaknesses}} - {{competitor_2}}: {{strengths_and_weaknesses}} - + **Differentiation Strategy:** {{how_we_differ_and_why_thats_valuable}} - id: market-opportunity @@ -10124,16 +10137,16 @@ sections: title: Content Categories template: | **Core Content:** - + - {{content_type_1}}: {{quantity_and_description}} - {{content_type_2}}: {{quantity_and_description}} - + **Optional Content:** - + - {{optional_content_type}}: {{quantity_and_description}} - + **Replay Elements:** - + - {{replayability_features}} - id: difficulty-accessibility title: Difficulty and Accessibility @@ -10200,13 +10213,13 @@ sections: title: Player Experience Metrics template: | **Engagement Goals:** - + - Tutorial completion rate: >{{percentage}}% - Average session length: {{duration}} minutes - Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}% - + **Quality Benchmarks:** - + - Player satisfaction: >{{rating}}/10 - Completion rate: >{{percentage}}% - Technical performance: {{fps_target}} FPS consistent @@ -10214,13 +10227,13 @@ sections: title: Development Metrics template: | **Technical Targets:** - + - Zero critical bugs at launch - Performance targets met on all platforms - Load times under {{seconds}}s - + **Process Goals:** - + - Development timeline adherence - Feature scope completion - Quality assurance standards @@ -10229,7 +10242,7 @@ sections: condition: has_business_goals template: | **Commercial Goals:** - + - {{revenue_target}} in first {{time_period}} - {{user_acquisition_target}} players in first {{time_period}} - {{retention_target}} monthly active users @@ -10282,12 +10295,12 @@ sections: title: Validation Plan template: | **Concept Testing:** - + - {{validation_method_1}} - {{timeline}} - {{validation_method_2}} - {{timeline}} - + **Prototype Testing:** - + - {{testing_approach}} - {{timeline}} - {{feedback_collection_method}} - {{timeline}} @@ -10410,7 +10423,7 @@ sections: instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions for Unity implementation. template: | **Primary Loop ({{duration}} seconds):** - + 1. {{action_1}} ({{time_1}}s) - {{unity_component}} 2. {{action_2}} ({{time_2}}s) - {{unity_component}} 3. {{action_3}} ({{time_3}}s) - {{unity_component}} @@ -10422,12 +10435,12 @@ sections: instruction: Clearly define success and failure states with Unity-specific implementation notes template: | **Victory Conditions:** - + - {{win_condition_1}} - Unity Event: {{unity_event}} - {{win_condition_2}} - Unity Event: {{unity_event}} - + **Failure States:** - + - {{loss_condition_1}} - Trigger: {{unity_trigger}} - {{loss_condition_2}} - Trigger: {{unity_trigger}} examples: @@ -10447,22 +10460,22 @@ sections: title: "{{mechanic_name}}" template: | **Description:** {{detailed_description}} - + **Player Input:** {{input_method}} - Unity Input System: {{input_action}} - + **System Response:** {{game_response}} - + **Unity Implementation Notes:** - + - **Components Needed:** {{component_list}} - **Physics Requirements:** {{physics_2d_setup}} - **Animation States:** {{animator_states}} - **Performance Considerations:** {{optimization_notes}} - + **Dependencies:** {{other_mechanics_needed}} - + **Script Architecture:** - + - {{script_name}}.cs - {{responsibility}} - {{manager_script}}.cs - {{management_role}} examples: @@ -10488,15 +10501,15 @@ sections: title: Player Progression template: | **Progression Type:** {{linear|branching|metroidvania}} - + **Key Milestones:** - + 1. **{{milestone_1}}** - {{unlock_description}} - Unity: {{scriptable_object_update}} 2. **{{milestone_2}}** - {{unlock_description}} - Unity: {{scriptable_object_update}} 3. **{{milestone_3}}** - {{unlock_description}} - Unity: {{scriptable_object_update}} - + **Save Data Structure:** - + ```csharp [System.Serializable] public class PlayerProgress @@ -10512,13 +10525,13 @@ sections: template: | **Tutorial Phase:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} - + **Early Game:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} - + **Mid Game:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} - + **Late Game:** {{duration}} - {{difficulty_description}} - Unity Config: {{scriptable_object_values}} examples: @@ -10551,22 +10564,22 @@ sections: **Target Duration:** {{target_time}} **Key Elements:** {{required_mechanics}} **Difficulty Rating:** {{relative_difficulty}} - + **Unity Scene Structure:** - + - **Environment:** {{tilemap_setup}} - **Gameplay Objects:** {{prefab_list}} - **Lighting:** {{lighting_setup}} - **Audio:** {{audio_sources}} - + **Level Flow Template:** - + - **Introduction:** {{intro_description}} - Area: {{unity_area_bounds}} - **Challenge:** {{main_challenge}} - Mechanics: {{active_components}} - **Resolution:** {{completion_requirement}} - Trigger: {{completion_trigger}} - + **Reusable Prefabs:** - + - {{prefab_name}} - {{prefab_purpose}} examples: - "Environment: TilemapRenderer with Platform tileset, Lighting: 2D Global Light + Point Lights" @@ -10577,9 +10590,9 @@ sections: **Total Levels:** {{number}} **Unlock Pattern:** {{progression_method}} **Scene Management:** {{unity_scene_loading}} - + **Unity Scene Organization:** - + - Scene Naming: {{naming_convention}} - Addressable Assets: {{addressable_groups}} - Loading Screens: {{loading_implementation}} @@ -10604,13 +10617,13 @@ sections: **Physics:** {{2D Only|3D Only|Hybrid}} **Scripting Backend:** {{Mono|IL2CPP}} **API Compatibility:** {{.NET Standard 2.1|.NET Framework}} - + **Required Packages:** - + - {{package_name}} {{version}} - {{purpose}} - + **Project Settings:** - + - Color Space: {{Linear|Gamma}} - Quality Settings: {{quality_levels}} - Physics Settings: {{physics_config}} @@ -10624,9 +10637,9 @@ sections: **Memory Usage:** <{{memory_limit}}MB heap, <{{texture_memory}}MB textures **Load Times:** <{{load_time}}s initial, <{{level_load}}s between levels **Battery Usage:** Optimized for mobile devices - {{battery_target}} hours gameplay - + **Unity Profiler Targets:** - + - CPU Frame Time: <{{cpu_time}}ms - GPU Frame Time: <{{gpu_time}}ms - GC Allocs: <{{gc_limit}}KB per frame @@ -10637,20 +10650,20 @@ sections: title: Platform Specific Requirements template: | **Desktop:** - + - Resolution: {{min_resolution}} - {{max_resolution}} - Input: Keyboard, Mouse, Gamepad ({{gamepad_support}}) - Build Target: {{desktop_targets}} - + **Mobile:** - + - Resolution: {{mobile_min}} - {{mobile_max}} - Input: Touch, Accelerometer ({{sensor_support}}) - OS: iOS {{ios_min}}+, Android {{android_min}}+ (API {{api_level}}) - Device Requirements: {{device_specs}} - + **Web (if applicable):** - + - WebGL Version: {{webgl_version}} - Browser Support: {{browser_list}} - Compression: {{compression_format}} @@ -10661,21 +10674,21 @@ sections: instruction: Define asset specifications for Unity pipeline optimization template: | **2D Art Assets:** - + - Sprites: {{sprite_resolution}} at {{ppu}} PPU - Texture Format: {{texture_compression}} - Atlas Strategy: {{sprite_atlas_setup}} - Animation: {{animation_type}} at {{framerate}} FPS - + **Audio Assets:** - + - Music: {{audio_format}} at {{sample_rate}} Hz - SFX: {{sfx_format}} at {{sfx_sample_rate}} Hz - Compression: {{audio_compression}} - 3D Audio: {{spatial_audio}} - + **UI Assets:** - + - Canvas Resolution: {{ui_resolution}} - UI Scale Mode: {{scale_mode}} - Font: {{font_requirements}} @@ -10696,17 +10709,17 @@ sections: title: Code Architecture Pattern template: | **Architecture Pattern:** {{MVC|MVVM|ECS|Component-Based|Custom}} - + **Core Systems Required:** - + - **Scene Management:** {{scene_manager_approach}} - **State Management:** {{state_pattern_implementation}} - **Event System:** {{event_system_choice}} - **Object Pooling:** {{pooling_strategy}} - **Save/Load System:** {{save_system_approach}} - + **Folder Structure:** - + ``` Assets/ ├── _Project/ @@ -10716,9 +10729,9 @@ sections: │ ├── Scenes/ │ └── {{additional_folders}} ``` - + **Naming Conventions:** - + - Scripts: {{script_naming}} - Prefabs: {{prefab_naming}} - Scenes: {{scene_naming}} @@ -10729,19 +10742,19 @@ sections: title: Unity Systems Integration template: | **Required Unity Systems:** - + - **Input System:** {{input_implementation}} - **Animation System:** {{animation_approach}} - **Physics Integration:** {{physics_usage}} - **Rendering Features:** {{rendering_requirements}} - **Asset Streaming:** {{asset_loading_strategy}} - + **Third-Party Integrations:** - + - {{integration_name}}: {{integration_purpose}} - + **Performance Systems:** - + - **Profiling Integration:** {{profiling_setup}} - **Memory Management:** {{memory_strategy}} - **Build Pipeline:** {{build_automation}} @@ -10752,20 +10765,20 @@ sections: title: Data Management template: | **Save Data Architecture:** - + - **Format:** {{PlayerPrefs|JSON|Binary|Cloud}} - **Structure:** {{save_data_organization}} - **Encryption:** {{security_approach}} - **Cloud Sync:** {{cloud_integration}} - + **Configuration Data:** - + - **ScriptableObjects:** {{scriptable_object_usage}} - **Settings Management:** {{settings_system}} - **Localization:** {{localization_approach}} - + **Runtime Data:** - + - **Caching Strategy:** {{cache_implementation}} - **Memory Pools:** {{pooling_objects}} - **Asset References:** {{asset_reference_system}} @@ -10993,15 +11006,15 @@ sections: instruction: Provide guidance for the Story Manager (SM) agent on how to break down this GDD into implementable user stories template: | **Epic Prioritization:** {{epic_order_rationale}} - + **Story Sizing Guidelines:** - + - Foundation stories: {{foundation_story_scope}} - Feature stories: {{feature_story_scope}} - Polish stories: {{polish_story_scope}} - + **Unity-Specific Story Considerations:** - + - Each story should result in testable Unity scenes or prefabs - Include specific Unity components and systems in acceptance criteria - Consider cross-platform testing requirements @@ -11037,13 +11050,13 @@ sections: - id: initial-setup instruction: | This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality. - + Before starting, ensure you have access to: - + - Game Design Document (GDD) - Game Architecture Document - Any existing stories in this epic - + The story should be specific enough that a developer can implement it without requiring additional design decisions. - id: story-header @@ -11092,12 +11105,12 @@ sections: title: Files to Create/Modify template: | **New Files:** - + - `{{file_path_1}}` - {{purpose}} - `{{file_path_2}}` - {{purpose}} - + **Modified Files:** - + - `{{existing_file_1}}` - {{changes_needed}} - `{{existing_file_2}}` - {{changes_needed}} - id: class-interface-definitions @@ -11180,13 +11193,13 @@ sections: instruction: Reference the specific sections of the GDD that this story implements template: | **GDD Reference:** {{section_name}} ({{page_or_section_number}}) - + **Game Mechanic:** {{mechanic_name}} - + **Player Experience Goal:** {{experience_description}} - + **Balance Parameters:** - + - {{parameter_1}}: {{value_or_range}} - {{parameter_2}}: {{value_or_range}} @@ -11233,15 +11246,15 @@ sections: instruction: List any dependencies that must be completed before this story can be implemented template: | **Story Dependencies:** - + - {{story_id}}: {{dependency_description}} - + **Technical Dependencies:** - + - {{system_or_file}}: {{requirement}} - + **Asset Dependencies:** - + - {{asset_type}}: {{asset_description}} - Location: `{{asset_path}}` @@ -11264,17 +11277,17 @@ sections: instruction: Any additional context, design decisions, or implementation notes template: | **Implementation Notes:** - + - {{note_1}} - {{note_2}} - + **Design Decisions:** - + - {{decision_1}}: {{rationale}} - {{decision_2}}: {{rationale}} - + **Future Considerations:** - + - {{future_enhancement_1}} - {{future_optimization_1}} ==================== END: .bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml ==================== @@ -11296,7 +11309,7 @@ sections: - id: initial-setup instruction: | This template creates comprehensive level design documentation that guides both content creation and technical implementation. This document should provide enough detail for developers to create level loading systems and for designers to create specific levels. - + If available, review: Game Design Document (GDD), Game Architecture Document. This document should align with the game mechanics and technical systems defined in those documents. - id: introduction @@ -11304,7 +11317,7 @@ sections: instruction: Establish the purpose and scope of level design for this game content: | This document defines the level design framework for {{game_title}}, providing guidelines for creating engaging, balanced levels that support the core gameplay mechanics defined in the Game Design Document. - + This framework ensures consistency across all levels while providing flexibility for creative level design within established technical and design constraints. sections: - id: change-log @@ -11351,29 +11364,29 @@ sections: title: "{{category_name}} Levels" template: | **Purpose:** {{gameplay_purpose}} - + **Target Duration:** {{min_time}} - {{max_time}} minutes - + **Difficulty Range:** {{difficulty_scale}} - + **Key Mechanics Featured:** - + - {{mechanic_1}} - {{usage_description}} - {{mechanic_2}} - {{usage_description}} - + **Player Objectives:** - + - Primary: {{primary_objective}} - Secondary: {{secondary_objective}} - Hidden: {{secret_objective}} - + **Success Criteria:** - + - {{completion_requirement_1}} - {{completion_requirement_2}} - + **Technical Requirements:** - + - Maximum entities: {{entity_limit}} - Performance target: {{fps_target}} FPS - Memory budget: {{memory_limit}}MB @@ -11388,11 +11401,11 @@ sections: instruction: Based on GDD requirements, define the overall level organization template: | **Organization Type:** {{linear|hub_world|open_world}} - + **Total Level Count:** {{number}} - + **World Breakdown:** - + - World 1: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 2: {{level_count}} levels - {{theme}} - {{difficulty_range}} - World 3: {{level_count}} levels - {{theme}} - {{difficulty_range}} @@ -11427,7 +11440,7 @@ sections: instruction: Define how players access new levels template: | **Progression Gates:** - + - Linear progression: Complete previous level - Star requirements: {{star_count}} stars to unlock - Skill gates: Demonstrate {{skill_requirement}} @@ -11442,17 +11455,17 @@ sections: instruction: Define all environmental components that can be used in levels template: | **Terrain Types:** - + - {{terrain_1}}: {{properties_and_usage}} - {{terrain_2}}: {{properties_and_usage}} - + **Interactive Objects:** - + - {{object_1}}: {{behavior_and_purpose}} - {{object_2}}: {{behavior_and_purpose}} - + **Hazards and Obstacles:** - + - {{hazard_1}}: {{damage_and_behavior}} - {{hazard_2}}: {{damage_and_behavior}} - id: collectibles-rewards @@ -11460,18 +11473,18 @@ sections: instruction: Define all collectible items and their placement rules template: | **Collectible Types:** - + - {{collectible_1}}: {{value_and_purpose}} - {{collectible_2}}: {{value_and_purpose}} - + **Placement Guidelines:** - + - Mandatory collectibles: {{placement_rules}} - Optional collectibles: {{placement_rules}} - Secret collectibles: {{placement_rules}} - + **Reward Distribution:** - + - Easy to find: {{percentage}}% - Moderate challenge: {{percentage}}% - High skill required: {{percentage}}% @@ -11480,18 +11493,18 @@ sections: instruction: Define how enemies should be placed and balanced in levels template: | **Enemy Categories:** - + - {{enemy_type_1}}: {{behavior_and_usage}} - {{enemy_type_2}}: {{behavior_and_usage}} - + **Placement Principles:** - + - Introduction encounters: {{guideline}} - Standard encounters: {{guideline}} - Challenge encounters: {{guideline}} - + **Difficulty Scaling:** - + - Enemy count progression: {{scaling_rule}} - Enemy type introduction: {{pacing_rule}} - Encounter complexity: {{complexity_rule}} @@ -11504,14 +11517,14 @@ sections: title: Level Layout Principles template: | **Spatial Design:** - + - Grid size: {{grid_dimensions}} - Minimum path width: {{width_units}} - Maximum vertical distance: {{height_units}} - Safe zones placement: {{safety_guidelines}} - + **Navigation Design:** - + - Clear path indication: {{visual_cues}} - Landmark placement: {{landmark_rules}} - Dead end avoidance: {{dead_end_policy}} @@ -11521,13 +11534,13 @@ sections: instruction: Define how to control the rhythm and pace of gameplay within levels template: | **Action Sequences:** - + - High intensity duration: {{max_duration}} - Rest period requirement: {{min_rest_time}} - Intensity variation: {{pacing_pattern}} - + **Learning Sequences:** - + - New mechanic introduction: {{teaching_method}} - Practice opportunity: {{practice_duration}} - Skill application: {{application_context}} @@ -11536,14 +11549,14 @@ sections: instruction: Define how to create appropriate challenges for each level type template: | **Challenge Types:** - + - Execution challenges: {{skill_requirements}} - Puzzle challenges: {{complexity_guidelines}} - Time challenges: {{time_pressure_rules}} - Resource challenges: {{resource_management}} - + **Difficulty Calibration:** - + - Skill check frequency: {{frequency_guidelines}} - Failure recovery: {{retry_mechanics}} - Hint system integration: {{help_system}} @@ -11557,7 +11570,7 @@ sections: instruction: Define how level data should be structured for implementation template: | **Level File Format:** - + - Data format: {{json|yaml|custom}} - File naming: `level_{{world}}_{{number}}.{{extension}}` - Data organization: {{structure_description}} @@ -11595,14 +11608,14 @@ sections: instruction: Define how level assets are organized and loaded template: | **Tilemap Requirements:** - + - Tile size: {{tile_dimensions}}px - Tileset organization: {{tileset_structure}} - Layer organization: {{layer_system}} - Collision data: {{collision_format}} - + **Audio Integration:** - + - Background music: {{music_requirements}} - Ambient sounds: {{ambient_system}} - Dynamic audio: {{dynamic_audio_rules}} @@ -11611,19 +11624,19 @@ sections: instruction: Define performance requirements for level systems template: | **Entity Limits:** - + - Maximum active entities: {{entity_limit}} - Maximum particles: {{particle_limit}} - Maximum audio sources: {{audio_limit}} - + **Memory Management:** - + - Texture memory budget: {{texture_memory}}MB - Audio memory budget: {{audio_memory}}MB - Level loading time: <{{load_time}}s - + **Culling and LOD:** - + - Off-screen culling: {{culling_distance}} - Level-of-detail rules: {{lod_system}} - Asset streaming: {{streaming_requirements}} @@ -11636,13 +11649,13 @@ sections: title: Automated Testing template: | **Performance Testing:** - + - Frame rate validation: Maintain {{fps_target}} FPS - Memory usage monitoring: Stay under {{memory_limit}}MB - Loading time verification: Complete in <{{load_time}}s - + **Gameplay Testing:** - + - Completion path validation: All objectives achievable - Collectible accessibility: All items reachable - Softlock prevention: No unwinnable states @@ -11670,14 +11683,14 @@ sections: title: Balance Validation template: | **Metrics Collection:** - + - Completion rate: Target {{completion_percentage}}% - Average completion time: {{target_time}} ± {{variance}} - Death count per level: <{{max_deaths}} - Collectible discovery rate: {{discovery_percentage}}% - + **Iteration Guidelines:** - + - Adjustment criteria: {{criteria_for_changes}} - Testing sample size: {{minimum_testers}} - Validation period: {{testing_duration}} @@ -11690,14 +11703,14 @@ sections: title: Design Phase template: | **Concept Development:** - + 1. Define level purpose and goals 2. Create rough layout sketch 3. Identify key mechanics and challenges 4. Estimate difficulty and duration - + **Documentation Requirements:** - + - Level design brief - Layout diagrams - Mechanic integration notes @@ -11706,15 +11719,15 @@ sections: title: Implementation Phase template: | **Technical Implementation:** - + 1. Create level data file 2. Build tilemap and layout 3. Place entities and objects 4. Configure level logic and triggers 5. Integrate audio and visual effects - + **Quality Assurance:** - + 1. Automated testing execution 2. Internal playtesting 3. Performance validation @@ -11723,14 +11736,14 @@ sections: title: Integration Phase template: | **Game Integration:** - + 1. Level progression integration 2. Save system compatibility 3. Analytics integration 4. Achievement system integration - + **Final Validation:** - + 1. Full game context testing 2. Performance regression testing 3. Platform compatibility verification @@ -13657,21 +13670,21 @@ workflow: - brainstorming_session - game_research_prompt - player_research - notes: 'Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/design/ folder.' + notes: "Start with brainstorming game concepts, then create comprehensive game brief. SAVE OUTPUT: Copy final game-brief.md to your project's docs/design/ folder." - agent: game-designer creates: game-design-doc.md requires: game-brief.md optional_steps: - competitive_analysis - technical_research - notes: 'Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project''s docs/design/ folder.' + notes: "Create detailed Game Design Document using game-design-doc-tmpl. Defines all gameplay mechanics, progression, and technical requirements. SAVE OUTPUT: Copy final game-design-doc.md to your project's docs/design/ folder." - agent: game-designer creates: level-design-doc.md requires: game-design-doc.md optional_steps: - level_prototyping - difficulty_analysis - notes: 'Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project''s docs/design/ folder.' + notes: "Create level design framework using level-design-doc-tmpl. Establishes content creation guidelines and performance requirements. SAVE OUTPUT: Copy final level-design-doc.md to your project's docs/design/ folder." - agent: solution-architect creates: game-architecture.md requires: @@ -13681,7 +13694,7 @@ workflow: - technical_research_prompt - performance_analysis - platform_research - notes: 'Create comprehensive technical architecture using game-architecture-tmpl. Defines Unity systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project''s docs/architecture/ folder.' + notes: "Create comprehensive technical architecture using game-architecture-tmpl. Defines Unity systems, performance optimization, and code structure. SAVE OUTPUT: Copy final game-architecture.md to your project's docs/architecture/ folder." - agent: game-designer validates: design_consistency requires: all_design_documents @@ -13706,7 +13719,7 @@ workflow: optional_steps: - quick_brainstorming - concept_validation - notes: 'Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project''s docs/ folder.' + notes: "Create focused game brief for prototype. Emphasize core mechanics and immediate playability. SAVE OUTPUT: Copy final game-brief.md to your project's docs/ folder." - agent: game-designer creates: prototype-design.md uses: create-doc prototype-design OR create-game-story @@ -13870,7 +13883,7 @@ workflow: notes: Implement stories in priority order. Test frequently in the Unity Editor and adjust design based on what feels fun. Document discoveries. workflow_end: action: prototype_evaluation - notes: 'Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive.' + notes: "Prototype complete. Evaluate core mechanics, gather feedback, and decide next steps: iterate, expand, or archive." game_jam_sequence: - step: jam_concept agent: game-designer diff --git a/dist/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt b/dist/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt index 36ef5a65..6dcc915e 100644 --- a/dist/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt +++ b/dist/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt @@ -552,18 +552,18 @@ sections: - id: initial-setup instruction: | Initial Setup - + 1. Replace {{project_name}} with the actual project name throughout the document 2. Gather and review required inputs: - Product Requirements Document (PRD) - Required for business needs and scale requirements - Main System Architecture - Required for infrastructure dependencies - Technical Preferences/Tech Stack Document - Required for technology choices - PRD Technical Assumptions - Required for cross-referencing repository and service architecture - + If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?" - + 3. Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture. - + Output file location: `docs/infrastructure-architecture.md` - id: infrastructure-overview @@ -592,7 +592,7 @@ sections: - Repository Structure - State Management - Dependency Management - + All infrastructure must be defined as code. No manual resource creation in production environments. - id: environment-configuration @@ -628,7 +628,7 @@ sections: title: Network Architecture instruction: | Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns. - + Create Mermaid diagram showing: - VPC/Network structure - Security zones and boundaries @@ -691,7 +691,7 @@ sections: title: Data Resources instruction: | Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements. - + Create data flow diagram showing: - Database topology - Replication patterns @@ -712,7 +712,7 @@ sections: - Data Encryption - Compliance Controls - Security Scanning & Monitoring - + Apply principle of least privilege for all access controls. Document all security exceptions with business justification. - id: shared-responsibility @@ -748,7 +748,7 @@ sections: title: CI/CD Pipeline instruction: | Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates. - + Create pipeline diagram showing: - Build stages - Test gates @@ -779,7 +779,7 @@ sections: - Recovery Procedures - RTO & RPO Targets - DR Testing Approach - + DR procedures must be tested at least quarterly. Document test results and improvement actions. - id: cost-optimization @@ -821,15 +821,15 @@ sections: title: DevOps/Platform Feasibility Review instruction: | CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on: - + - **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise? - **Resource Constraints:** Do infrastructure requirements align with available resources and budgets? - **Security Implementation:** Are security patterns achievable with current security toolchain? - **Operational Overhead:** Will the proposed architecture create excessive operational burden? - **Technology Constraints:** Are selected technologies compatible with existing infrastructure? - + Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback. - + Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing. sections: - id: feasibility-results @@ -847,7 +847,7 @@ sections: title: Validation Framework content: | This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures: - + - Completeness of architecture documentation - Consistency with broader system architecture - Appropriate level of detail for different stakeholders @@ -857,12 +857,12 @@ sections: title: Validation Process content: | The architecture documentation validation should be performed: - + - After initial architecture development - After significant architecture changes - Before major implementation phases - During periodic architecture reviews - + The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document. - id: implementation-handoff @@ -873,7 +873,7 @@ sections: title: Architecture Decision Records (ADRs) content: | Create ADRs for key infrastructure decisions: - + - Cloud provider selection rationale - Container orchestration platform choice - Networking architecture decisions @@ -883,7 +883,7 @@ sections: title: Implementation Validation Criteria content: | Define specific criteria for validating correct implementation: - + - Infrastructure as Code quality gates - Security compliance checkpoints - Performance benchmarks @@ -943,7 +943,7 @@ sections: instruction: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist. content: | --- - + _Document Version: 1.0_ _Last Updated: {{current_date}}_ _Next Review: {{review_date}}_ @@ -980,7 +980,7 @@ sections: - id: initial-setup instruction: | Initial Setup - + 1. Replace {{project_name}} with the actual project name throughout the document 2. Gather and review required inputs: - **Infrastructure Architecture Document** (Primary input - REQUIRED) @@ -989,10 +989,10 @@ sections: - Technology Stack Document - Infrastructure Checklist - NOTE: If Infrastructure Architecture Document is missing, HALT and request: "I need the Infrastructure Architecture Document to proceed with platform implementation. This document defines the infrastructure design that we'll be implementing." - + 3. Validate that the infrastructure architecture has been reviewed and approved 4. All platform implementation must align with the approved infrastructure architecture. Any deviations require architect approval. - + Output file location: `docs/platform-infrastructure/platform-implementation.md` - id: executive-summary @@ -1065,7 +1065,7 @@ sections: # Example Terraform for VPC setup module "vpc" { source = "./modules/vpc" - + cidr_block = "{{vpc_cidr}}" availability_zones = {{availability_zones}} public_subnets = {{public_subnets}} @@ -1460,7 +1460,7 @@ sections: // K6 Load Test Example import http from 'k6/http'; import { check } from 'k6'; - + export let options = { stages: [ { duration: '5m', target: {{target_users}} }, @@ -1574,7 +1574,7 @@ sections: instruction: Final Review - Ensure all platform layers are properly implemented, integrated, and documented. Verify that the implementation fully supports the BMAD methodology and all agent workflows. Confirm successful validation against the infrastructure checklist. content: | --- - + _Platform Version: 1.0_ _Implementation Date: {{implementation_date}}_ _Next Review: {{review_date}}_ diff --git a/dist/teams/team-all.txt b/dist/teams/team-all.txt index cb75346c..17d4ffe9 100644 --- a/dist/teams/team-all.txt +++ b/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 @@ -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:** +## Dependencies ```yaml -unit_test: - component: "PriceCalculator" - scenario: "Calculate discount with multiple rules" - justification: "Complex business logic with multiple branches" - mock_requirements: "None - pure function" +data: + - test-levels-framework.md # Unit/Integration/E2E decision criteria + - test-priorities-matrix.md # P0/P1/P2/P3 classification system ``` -### 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:** - -```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" -``` - -### 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" +- Identify the core functionality to test +- Determine data variations needed +- Consider error conditions +- Note edge cases - - level: integration - what: "Password reset token generation and storage" - why: "Database interaction with expiry logic" +### 2. Apply Test Level Framework - - level: integration - what: "Email service integration" - why: "External service with retry logic" +**Reference:** Load `test-levels-framework.md` for detailed criteria - - level: e2e - what: "Complete password reset flow" - why: "Critical security flow needing full validation" -``` +Quick rules: -### 2. Apply Test Level Heuristics +- **Unit**: Pure logic, algorithms, calculations +- **Integration**: Component interactions, DB operations +- **E2E**: Critical user journeys, compliance -Use these rules to determine appropriate test levels: +### 3. Assign Priorities -```markdown -## Test Level Selection Rules +**Reference:** Load `test-priorities-matrix.md` for classification -### Favor Unit Tests When: +Quick priority assignment: -- Logic can be isolated -- No side effects involved -- Fast feedback needed -- High cyclomatic complexity +- **P0**: Revenue-critical, security, compliance +- **P1**: Core user journeys, frequently used +- **P2**: Secondary features, admin functions +- **P3**: Nice-to-have, rarely used -### Favor Integration Tests When: +### 4. Design Test Scenarios -- 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:** - -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? - -**Coverage overlap is only acceptable when:** - -- 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}` - -- Example: `1.3-UNIT-001`, `1.3-INT-002`, `1.3-E2E-001` -- Ensures traceability across all artifacts - -**Naming Convention:** - -- Unit: `test_{component}_{scenario}` -- Integration: `test_{flow}_{interaction}` -- E2E: `test_{journey}_{outcome}` - -**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 +### 5. Validate Coverage -**Per Acceptance Criterion:** +Ensure: -- 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 - -### Core Testing Principles - -**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 +## Test Scenarios by Acceptance Criteria -[Explain why this distribution was chosen] +### AC1: {description} -## Detailed Test Scenarios +#### Scenarios -### Requirement: AC1 - {description} +| 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 | -#### Unit Tests (3 scenarios) +[Continue for all ACs...] -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) +## Risk Coverage -#### Integration Tests (2 scenarios) +[Map test scenarios to identified risks if risk profile exists] -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 +## Recommended Execution Order -#### 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 - -### What to Mock - -- External services (payment, email) -- Time-dependent functions -- Random number generators - -### What NOT to Mock - -- 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 - -### Integration Coverage - -- Target: All API endpoints -- Focus: Contract validation - -### E2E Coverage - -- 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 +### Output 2: Gate YAML Block -### Over-testing Smells +Generate for inclusion in quality gate: -- Same logic tested at multiple levels -- E2E tests for calculations -- Integration tests for framework features +```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 +``` -### Under-testing Smells +### Output 3: Trace References -- No unit tests for complex logic -- Missing integration tests for data operations -- No E2E tests for critical user paths +Print for use by trace-requirements task: -### Wrong Level Smells +```text +Test design matrix: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md +P0 tests identified: {count} +``` -- Unit tests with real database -- E2E tests checking calculation results -- Integration tests mocking everything +## Quality Checklist -## Quality Indicators +Before finalizing, verify: -Good test design shows: - -- Clear level separation -- No redundant coverage -- Fast feedback from unit tests -- Reliable integration tests -- Focused e2e tests +- [ ] 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 ## 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) - -### Output 2: Story Hook Line - -**Print this line for review task to quote:** - -```text -Test design: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md -``` - -**For traceability:** This planning document will be referenced by trace-requirements task. - -### Output 3: Test Count Summary - -**Print summary for quick reference:** - -```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 -``` +- **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" +# 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" -# Example when waived: -# waiver: -# active: true -# reason: "Accepted for MVP release - will address in next sprint" -# approved_by: "Product Owner" + 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 +optional_fields_examples: + quality_and_expiry: | + 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 + 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: -# security: { status: CONCERNS, notes: "Rate limiting missing" } -# performance: { status: PASS, notes: "" } -# reliability: { status: PASS, notes: "" } -# maintainability: { status: PASS, notes: "" } + nfr_validation: | + 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" + 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: # From risk-profile task -# totals: -# critical: 0 -# high: 0 -# medium: 0 -# low: 0 -# # 'highest' is emitted only when risks exist -# recommendations: -# must_fix: [] -# monitor: [] + 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: -# 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"] + 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: | diff --git a/dist/teams/team-fullstack.txt b/dist/teams/team-fullstack.txt index a9b70ec8..fef15db1 100644 --- a/dist/teams/team-fullstack.txt +++ b/dist/teams/team-fullstack.txt @@ -1838,7 +1838,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 @@ -2632,12 +2632,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 @@ -2958,7 +2958,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}} @@ -3159,7 +3159,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 @@ -3224,7 +3224,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: @@ -3236,7 +3243,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: @@ -3263,7 +3276,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 @@ -3298,7 +3311,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -3402,11 +3415,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:" @@ -3531,7 +3544,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-core/templates/brainstorming-output-tmpl.yaml ==================== @@ -4296,7 +4309,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 @@ -4338,7 +4351,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 @@ -4366,9 +4379,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 @@ -4387,11 +4400,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 @@ -4419,7 +4432,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 @@ -4461,19 +4474,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 @@ -4499,7 +4512,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 @@ -4623,7 +4636,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}} @@ -4662,7 +4675,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}} @@ -4685,7 +4698,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 @@ -4698,7 +4711,7 @@ sections: - Each story must deliver value while maintaining system integrity template: | **Epic Goal**: {{epic_goal}} - + **Integration Requirements**: {{integration_requirements}} sections: - id: story @@ -5362,7 +5375,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. @@ -5371,7 +5384,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 @@ -5412,7 +5425,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 @@ -5442,22 +5455,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 @@ -5466,9 +5479,9 @@ sections: title: "{{flow_name}}" template: | **User Goal:** {{flow_goal}} - + **Entry Points:** {{entry_points}} - + **Success Criteria:** {{success_criteria}} sections: - id: flow-diagram @@ -5499,14 +5512,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 @@ -5525,11 +5538,11 @@ sections: title: "{{component_name}}" template: | **Purpose:** {{component_purpose}} - + **Variants:** {{component_variants}} - + **States:** {{component_states}} - + **Usage Guidelines:** {{usage_guidelines}} - id: branding-style @@ -5575,13 +5588,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 @@ -5599,12 +5612,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}} @@ -5631,11 +5644,11 @@ sections: title: Adaptation Patterns template: | **Layout Changes:** {{layout_adaptations}} - + **Navigation Changes:** {{nav_adaptations}} - + **Content Priority:** {{content_adaptations}} - + **Interaction Changes:** {{interaction_adaptations}} - id: animation @@ -5669,7 +5682,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 @@ -5718,20 +5731,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 @@ -5744,16 +5757,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 @@ -5781,7 +5794,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 @@ -5798,17 +5811,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) @@ -5824,23 +5837,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: @@ -5864,13 +5877,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 @@ -5879,11 +5892,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}} @@ -5892,7 +5905,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 @@ -5901,7 +5914,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: @@ -5910,13 +5923,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 @@ -5933,13 +5946,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 @@ -5952,10 +5965,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 @@ -5964,13 +5977,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 @@ -5981,13 +5994,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: | @@ -6004,13 +6017,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 @@ -6020,14 +6033,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: @@ -6045,13 +6058,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: @@ -6087,13 +6100,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: @@ -6140,13 +6153,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: @@ -6168,7 +6181,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}}" @@ -6186,14 +6199,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: @@ -6214,7 +6227,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 @@ -6256,7 +6269,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 @@ -6325,16 +6338,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 @@ -6367,16 +6380,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 @@ -6392,7 +6405,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 @@ -6400,11 +6413,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 @@ -6426,12 +6439,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}}"] @@ -6579,33 +6604,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 @@ -6631,17 +6656,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}} @@ -6651,7 +6676,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 @@ -6673,7 +6698,7 @@ sections: - Databases and storage - External integrations - CDN and caching layers - + Use appropriate diagram type for clarity. - id: architectural-patterns title: Architectural Patterns @@ -6683,7 +6708,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}}" @@ -6697,7 +6722,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 @@ -6706,7 +6731,7 @@ sections: - Testing tools for both frontend and backend - Build and deployment tools - Monitoring and logging - + Upon render, elicit feedback immediately. elicit: true sections: @@ -6716,11 +6741,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}}"] @@ -6741,14 +6784,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 @@ -6757,7 +6800,7 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} @@ -6776,7 +6819,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 @@ -6784,7 +6827,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: @@ -6819,7 +6862,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 @@ -6828,7 +6871,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: @@ -6837,13 +6880,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 @@ -6860,13 +6903,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 @@ -6879,10 +6922,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 @@ -6891,14 +6934,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 @@ -6906,13 +6949,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 @@ -7048,60 +7091,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 @@ -7128,13 +7171,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 @@ -7147,10 +7190,10 @@ sections: template: | # Frontend (.env.local) {{frontend_env_vars}} - + # Backend (.env) {{backend_env_vars}} - + # Shared {{shared_env_vars}} @@ -7167,7 +7210,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}} @@ -7198,12 +7241,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}} @@ -7215,7 +7258,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}} @@ -7231,10 +7274,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 @@ -7353,7 +7396,7 @@ sections: - JavaScript errors - API response times - User interactions - + **Backend Metrics:** - Request rate - Error rate @@ -7384,40 +7427,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: @@ -7446,12 +7489,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: @@ -7480,7 +7523,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 @@ -7503,7 +7546,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) @@ -7519,11 +7562,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}} @@ -7535,7 +7578,7 @@ sections: - **Modified Tables:** {{modified_tables_list}} - **New Indexes:** {{new_indexes_list}} - **Migration Strategy:** {{migration_approach}} - + **Backward Compatibility:** - {{compatibility_measure_1}} - {{compatibility_measure_2}} @@ -7544,12 +7587,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: @@ -7562,15 +7605,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 @@ -7583,7 +7626,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 @@ -7633,17 +7676,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 @@ -7682,7 +7725,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 @@ -7712,7 +7755,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 @@ -7743,7 +7786,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 @@ -7783,7 +7826,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 @@ -7818,7 +7861,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 @@ -8437,7 +8480,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -8454,7 +8497,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 @@ -8466,7 +8509,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -8474,7 +8517,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -8491,7 +8534,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -8515,7 +8558,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -8523,7 +8566,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 @@ -8536,25 +8579,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 @@ -9020,7 +9063,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 @@ -9181,7 +9224,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -9265,35 +9308,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 ==================== @@ -9427,7 +9470,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -9624,7 +9667,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -9849,7 +9892,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -10068,7 +10111,7 @@ workflow: notes: | All stories implemented and reviewed! Service development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -10296,7 +10339,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | diff --git a/dist/teams/team-ide-minimal.txt b/dist/teams/team-ide-minimal.txt index 04b71d49..59f15bc6 100644 --- a/dist/teams/team-ide-minimal.txt +++ b/dist/teams/team-ide-minimal.txt @@ -2253,7 +2253,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -2270,7 +2270,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 @@ -2282,7 +2282,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -2290,7 +2290,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -2307,7 +2307,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -2331,7 +2331,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -2339,7 +2339,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 @@ -2352,25 +2352,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 @@ -3375,10 +3375,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 @@ -3540,6 +3540,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] @@ -3551,26 +3553,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 } @@ -3582,24 +3584,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 @@ -3711,11 +3713,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 ``` @@ -3724,20 +3726,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 } ``` @@ -3745,20 +3747,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 @@ -3877,21 +3879,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 ``` @@ -3913,19 +3915,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 @@ -3941,11 +3943,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 @@ -4119,10 +4121,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 @@ -4192,14 +4194,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 @@ -4246,20 +4248,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 @@ -4285,12 +4287,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 @@ -4475,299 +4477,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:** +## Dependencies ```yaml -unit_test: - component: "PriceCalculator" - scenario: "Calculate discount with multiple rules" - justification: "Complex business logic with multiple branches" - mock_requirements: "None - pure function" +data: + - test-levels-framework.md # Unit/Integration/E2E decision criteria + - test-priorities-matrix.md # P0/P1/P2/P3 classification system ``` -### 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:** - -```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" -``` - -### 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" +- Identify the core functionality to test +- Determine data variations needed +- Consider error conditions +- Note edge cases - - level: integration - what: "Password reset token generation and storage" - why: "Database interaction with expiry logic" +### 2. Apply Test Level Framework - - level: integration - what: "Email service integration" - why: "External service with retry logic" +**Reference:** Load `test-levels-framework.md` for detailed criteria - - level: e2e - what: "Complete password reset flow" - why: "Critical security flow needing full validation" -``` +Quick rules: -### 2. Apply Test Level Heuristics +- **Unit**: Pure logic, algorithms, calculations +- **Integration**: Component interactions, DB operations +- **E2E**: Critical user journeys, compliance -Use these rules to determine appropriate test levels: +### 3. Assign Priorities -```markdown -## Test Level Selection Rules +**Reference:** Load `test-priorities-matrix.md` for classification -### Favor Unit Tests When: +Quick priority assignment: -- Logic can be isolated -- No side effects involved -- Fast feedback needed -- High cyclomatic complexity +- **P0**: Revenue-critical, security, compliance +- **P1**: Core user journeys, frequently used +- **P2**: Secondary features, admin functions +- **P3**: Nice-to-have, rarely used -### Favor Integration Tests When: +### 4. Design Test Scenarios -- 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:** - -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? - -**Coverage overlap is only acceptable when:** - -- 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}` - -- Example: `1.3-UNIT-001`, `1.3-INT-002`, `1.3-E2E-001` -- Ensures traceability across all artifacts - -**Naming Convention:** - -- Unit: `test_{component}_{scenario}` -- Integration: `test_{flow}_{interaction}` -- E2E: `test_{journey}_{outcome}` - -**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 +### 5. Validate Coverage -**Per Acceptance Criterion:** +Ensure: -- 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 - -### Core Testing Principles - -**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 @@ -4775,13 +4557,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 @@ -4789,212 +4569,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 +## Test Scenarios by Acceptance Criteria -[Explain why this distribution was chosen] +### AC1: {description} -## Detailed Test Scenarios +#### Scenarios -### Requirement: AC1 - {description} +| 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 | -#### Unit Tests (3 scenarios) +[Continue for all ACs...] -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) +## Risk Coverage -#### Integration Tests (2 scenarios) +[Map test scenarios to identified risks if risk profile exists] -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 +## Recommended Execution Order -#### 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 - -### What to Mock - -- External services (payment, email) -- Time-dependent functions -- Random number generators - -### What NOT to Mock - -- 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 - -### Integration Coverage - -- Target: All API endpoints -- Focus: Contract validation - -### E2E Coverage - -- 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 +### Output 2: Gate YAML Block -### Over-testing Smells +Generate for inclusion in quality gate: -- Same logic tested at multiple levels -- E2E tests for calculations -- Integration tests for framework features +```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 +``` -### Under-testing Smells +### Output 3: Trace References -- No unit tests for complex logic -- Missing integration tests for data operations -- No E2E tests for critical user paths +Print for use by trace-requirements task: -### Wrong Level Smells +```text +Test design matrix: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md +P0 tests identified: {count} +``` -- Unit tests with real database -- E2E tests checking calculation results -- Integration tests mocking everything +## Quality Checklist -## Quality Indicators +Before finalizing, verify: -Good test design shows: - -- Clear level separation -- No redundant coverage -- Fast feedback from unit tests -- Reliable integration tests -- Focused e2e tests +- [ ] 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 ## 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) - -### Output 2: Story Hook Line - -**Print this line for review task to quote:** - -```text -Test design: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md -``` - -**For traceability:** This planning document will be referenced by trace-requirements task. - -### Output 3: Test Count Summary - -**Print summary for quick reference:** - -```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 -``` +- **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 ==================== @@ -5006,12 +4654,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 ``` @@ -5092,16 +4740,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 @@ -5331,10 +4979,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 @@ -5357,8 +5005,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}}" @@ -5375,68 +5023,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" +# 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" -# Example when waived: -# waiver: -# active: true -# reason: "Accepted for MVP release - will address in next sprint" -# approved_by: "Product Owner" + 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 +optional_fields_examples: + quality_and_expiry: | + 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 + 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: -# security: { status: CONCERNS, notes: "Rate limiting missing" } -# performance: { status: PASS, notes: "" } -# reliability: { status: PASS, notes: "" } -# maintainability: { status: PASS, notes: "" } + nfr_validation: | + 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" + 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: # From risk-profile task -# totals: -# critical: 0 -# high: 0 -# medium: 0 -# low: 0 -# # 'highest' is emitted only when risks exist -# recommendations: -# must_fix: [] -# monitor: [] + 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: -# 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"] + 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/data/technical-preferences.md ==================== diff --git a/dist/teams/team-no-ui.txt b/dist/teams/team-no-ui.txt index c1cbfef7..11db569e 100644 --- a/dist/teams/team-no-ui.txt +++ b/dist/teams/team-no-ui.txt @@ -1784,7 +1784,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 @@ -2578,12 +2578,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 @@ -2904,7 +2904,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}} @@ -3105,7 +3105,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 @@ -3170,7 +3170,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: @@ -3182,7 +3189,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: @@ -3209,7 +3222,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 @@ -3244,7 +3257,7 @@ sections: title: Blue Ocean Opportunities instruction: | Identify uncontested market spaces - + List opportunities to create new market space: - Underserved segments - Unaddressed use cases @@ -3348,11 +3361,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:" @@ -3477,7 +3490,7 @@ sections: - id: footer content: | --- - + *Session facilitated using the BMAD-METHOD brainstorming framework* ==================== END: .bmad-core/templates/brainstorming-output-tmpl.yaml ==================== @@ -4242,7 +4255,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 @@ -4284,7 +4297,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 @@ -4312,9 +4325,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 @@ -4333,11 +4346,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 @@ -4365,7 +4378,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 @@ -4407,19 +4420,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 @@ -4445,7 +4458,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 @@ -4569,7 +4582,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}} @@ -4608,7 +4621,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}} @@ -4631,7 +4644,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 @@ -4644,7 +4657,7 @@ sections: - Each story must deliver value while maintaining system integrity template: | **Epic Goal**: {{epic_goal}} - + **Integration Requirements**: {{integration_requirements}} sections: - id: story @@ -5258,20 +5271,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 @@ -5284,16 +5297,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 @@ -5321,7 +5334,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 @@ -5338,17 +5351,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) @@ -5364,23 +5377,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: @@ -5404,13 +5417,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 @@ -5419,11 +5432,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}} @@ -5432,7 +5445,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 @@ -5441,7 +5454,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: @@ -5450,13 +5463,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 @@ -5473,13 +5486,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 @@ -5492,10 +5505,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 @@ -5504,13 +5517,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 @@ -5521,13 +5534,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: | @@ -5544,13 +5557,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 @@ -5560,14 +5573,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: @@ -5585,13 +5598,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: @@ -5627,13 +5640,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: @@ -5680,13 +5693,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: @@ -5708,7 +5721,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}}" @@ -5726,14 +5739,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: @@ -5754,7 +5767,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 @@ -5796,7 +5809,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 @@ -5865,16 +5878,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 @@ -5907,16 +5920,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 @@ -5932,7 +5945,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 @@ -5940,11 +5953,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 @@ -5966,12 +5979,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}}"] @@ -6119,33 +6144,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 @@ -6171,17 +6196,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}} @@ -6191,7 +6216,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 @@ -6213,7 +6238,7 @@ sections: - Databases and storage - External integrations - CDN and caching layers - + Use appropriate diagram type for clarity. - id: architectural-patterns title: Architectural Patterns @@ -6223,7 +6248,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}}" @@ -6237,7 +6262,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 @@ -6246,7 +6271,7 @@ sections: - Testing tools for both frontend and backend - Build and deployment tools - Monitoring and logging - + Upon render, elicit feedback immediately. elicit: true sections: @@ -6256,11 +6281,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}}"] @@ -6281,14 +6324,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 @@ -6297,7 +6340,7 @@ sections: title: "{{model_name}}" template: | **Purpose:** {{model_purpose}} - + **Key Attributes:** - {{attribute_1}}: {{type_1}} - {{description_1}} - {{attribute_2}}: {{type_2}} - {{description_2}} @@ -6316,7 +6359,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 @@ -6324,7 +6367,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: @@ -6359,7 +6402,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 @@ -6368,7 +6411,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: @@ -6377,13 +6420,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 @@ -6400,13 +6443,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 @@ -6419,10 +6462,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 @@ -6431,14 +6474,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 @@ -6446,13 +6489,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 @@ -6588,60 +6631,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 @@ -6668,13 +6711,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 @@ -6687,10 +6730,10 @@ sections: template: | # Frontend (.env.local) {{frontend_env_vars}} - + # Backend (.env) {{backend_env_vars}} - + # Shared {{shared_env_vars}} @@ -6707,7 +6750,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}} @@ -6738,12 +6781,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}} @@ -6755,7 +6798,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}} @@ -6771,10 +6814,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 @@ -6893,7 +6936,7 @@ sections: - JavaScript errors - API response times - User interactions - + **Backend Metrics:** - Request rate - Error rate @@ -6924,40 +6967,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: @@ -6986,12 +7029,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: @@ -7020,7 +7063,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 @@ -7043,7 +7086,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) @@ -7059,11 +7102,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}} @@ -7075,7 +7118,7 @@ sections: - **Modified Tables:** {{modified_tables_list}} - **New Indexes:** {{new_indexes_list}} - **Migration Strategy:** {{migration_approach}} - + **Backward Compatibility:** - {{compatibility_measure_1}} - {{compatibility_measure_2}} @@ -7084,12 +7127,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: @@ -7102,15 +7145,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 @@ -7123,7 +7166,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 @@ -7173,17 +7216,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 @@ -7222,7 +7265,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 @@ -7252,7 +7295,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 @@ -7283,7 +7326,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 @@ -7323,7 +7366,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 @@ -7358,7 +7401,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 @@ -7977,7 +8020,7 @@ workflow: elicitation: advanced-elicitation agent_config: - editable_sections: + editable_sections: - Status - Story - Acceptance Criteria @@ -7994,7 +8037,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 @@ -8006,7 +8049,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: acceptance-criteria title: Acceptance Criteria type: numbered-list @@ -8014,7 +8057,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: tasks-subtasks title: Tasks / Subtasks type: bullet-list @@ -8031,7 +8074,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master, dev-agent] - + - id: dev-notes title: Dev Notes instruction: | @@ -8055,7 +8098,7 @@ sections: elicit: true owner: scrum-master editors: [scrum-master] - + - id: change-log title: Change Log type: table @@ -8063,7 +8106,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 @@ -8076,25 +8119,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 @@ -8675,7 +8718,7 @@ workflow: notes: | All stories implemented and reviewed! Service development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: | @@ -8876,7 +8919,7 @@ workflow: notes: | All stories implemented and reviewed! Project development phase complete. - + Reference: .bmad-core/data/bmad-kb.md#IDE Development Workflow flow_diagram: |