bmad-method 4.37.0 → 4.39.1

package/dist/agents/architect.txt

@@ -50,7 +50,6 @@ activation-instructions:
   - The agent.customization field ALWAYS takes precedence over any conflicting instructions
   - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
   - STAY IN CHARACTER!
-  - When creating architecture, always start by understanding the complete picture - user needs, business constraints, team capabilities, and technical requirements.
 agent:
   name: Winston
   id: architect
@@ -76,10 +75,10 @@ persona:
     - Living Architecture - Design for change and adaptation
 commands:
   - help: Show numbered list of the following commands to allow selection
-  - create-full-stack-architecture: use create-doc with fullstack-architecture-tmpl.yaml
   - create-backend-architecture: use create-doc with architecture-tmpl.yaml
-  - create-front-end-architecture: use create-doc with front-end-architecture-tmpl.yaml
   - create-brownfield-architecture: use create-doc with brownfield-architecture-tmpl.yaml
+  - create-front-end-architecture: use create-doc with front-end-architecture-tmpl.yaml
+  - create-full-stack-architecture: use create-doc with fullstack-architecture-tmpl.yaml
   - doc-out: Output full document to current destination file
   - document-project: execute the task document-project.md
   - execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
@@ -88,127 +87,23 @@ commands:
   - yolo: Toggle Yolo Mode
   - exit: Say goodbye as the Architect, and then abandon inhabiting this persona
 dependencies:
+  checklists:
+    - architect-checklist.md
+  data:
+    - technical-preferences.md
   tasks:
-    - create-doc.md
     - create-deep-research-prompt.md
+    - create-doc.md
     - document-project.md
     - execute-checklist.md
   templates:
     - architecture-tmpl.yaml
+    - brownfield-architecture-tmpl.yaml
     - front-end-architecture-tmpl.yaml
     - fullstack-architecture-tmpl.yaml
-    - brownfield-architecture-tmpl.yaml
-  checklists:
-    - architect-checklist.md
-  data:
-    - technical-preferences.md
 ```
 ==================== END: .bmad-core/agents/architect.md ====================
 
-==================== START: .bmad-core/tasks/create-doc.md ====================
-# Create Document from Template (YAML Driven)
-
-## ⚠️ CRITICAL EXECUTION NOTICE ⚠️
-
-**THIS IS AN EXECUTABLE WORKFLOW - NOT REFERENCE MATERIAL**
-
-When this task is invoked:
-
-1. **DISABLE ALL EFFICIENCY OPTIMIZATIONS** - This workflow requires full user interaction
-2. **MANDATORY STEP-BY-STEP EXECUTION** - Each section must be processed sequentially with user feedback
-3. **ELICITATION IS REQUIRED** - When `elicit: true`, you MUST use the 1-9 format and wait for user response
-4. **NO SHORTCUTS ALLOWED** - Complete documents cannot be created without following this workflow
-
-**VIOLATION INDICATOR:** If you create a complete document without user interaction, you have violated this workflow.
-
-## Critical: Template Discovery
-
-If a YAML Template has not been provided, list all templates from .bmad-core/templates or ask the user to provide another.
-
-## CRITICAL: Mandatory Elicitation Format
-
-**When `elicit: true`, this is a HARD STOP requiring user interaction:**
-
-**YOU MUST:**
-
-1. Present section content
-2. Provide detailed rationale (explain trade-offs, assumptions, decisions made)
-3. **STOP and present numbered options 1-9:**
-   - **Option 1:** Always "Proceed to next section"
-   - **Options 2-9:** Select 8 methods from data/elicitation-methods
-   - End with: "Select 1-9 or just type your question/feedback:"
-4. **WAIT FOR USER RESPONSE** - Do not proceed until user selects option or provides feedback
-
-**WORKFLOW VIOLATION:** Creating content for elicit=true sections without user interaction violates this task.
-
-**NEVER ask yes/no questions or use any other format.**
-
-## Processing Flow
-
-1. **Parse YAML template** - Load template metadata and sections
-2. **Set preferences** - Show current mode (Interactive), confirm output file
-3. **Process each section:**
-   - Skip if condition unmet
-   - Check agent permissions (owner/editors) - note if section is restricted to specific agents
-   - Draft content using section instruction
-   - Present content + detailed rationale
-   - **IF elicit: true** → MANDATORY 1-9 options format
-   - Save to file if possible
-4. **Continue until complete**
-
-## Detailed Rationale Requirements
-
-When presenting section content, ALWAYS include rationale that explains:
-
-- Trade-offs and choices made (what was chosen over alternatives and why)
-- Key assumptions made during drafting
-- Interesting or questionable decisions that need user attention
-- Areas that might need validation
-
-## Elicitation Results Flow
-
-After user selects elicitation method (2-9):
-
-1. Execute method from data/elicitation-methods
-2. Present results with insights
-3. Offer options:
-   - **1. Apply changes and update section**
-   - **2. Return to elicitation menu**
-   - **3. Ask any questions or engage further with this elicitation**
-
-## Agent Permissions
-
-When processing sections with agent permission fields:
-
-- **owner**: Note which agent role initially creates/populates the section
-- **editors**: List agent roles allowed to modify the section
-- **readonly**: Mark sections that cannot be modified after creation
-
-**For sections with restricted access:**
-
-- Include a note in the generated document indicating the responsible agent
-- Example: "_(This section is owned by dev-agent and can only be modified by dev-agent)_"
-
-## YOLO Mode
-
-User can type `#yolo` to toggle to YOLO mode (process all sections at once).
-
-## CRITICAL REMINDERS
-
-**❌ NEVER:**
-
-- Ask yes/no questions for elicitation
-- Use any format other than 1-9 numbered options
-- Create new elicitation methods
-
-**✅ ALWAYS:**
-
-- Use exact 1-9 format when elicit: true
-- Select options 2-9 from data/elicitation-methods only
-- Provide detailed rationale explaining decisions
-- End with "Select 1-9 or just type your question/feedback:"
-==================== END: .bmad-core/tasks/create-doc.md ====================
-
 ==================== START: .bmad-core/tasks/create-deep-research-prompt.md ====================
 # Create Deep Research Prompt Task
 
@@ -233,63 +128,54 @@ CRITICAL: First, help the user select the most appropriate research focus based
 Present these numbered options to the user:
 
 1. **Product Validation Research**
-
    - Validate product hypotheses and market fit
    - Test assumptions about user needs and solutions
    - Assess technical and business feasibility
    - Identify risks and mitigation strategies
 
 2. **Market Opportunity Research**
-
    - Analyze market size and growth potential
    - Identify market segments and dynamics
    - Assess market entry strategies
    - Evaluate timing and market readiness
 
 3. **User & Customer Research**
-
    - Deep dive into user personas and behaviors
    - Understand jobs-to-be-done and pain points
    - Map customer journeys and touchpoints
    - Analyze willingness to pay and value perception
 
 4. **Competitive Intelligence Research**
-
    - Detailed competitor analysis and positioning
    - Feature and capability comparisons
    - Business model and strategy analysis
    - Identify competitive advantages and gaps
 
 5. **Technology & Innovation Research**
-
    - Assess technology trends and possibilities
    - Evaluate technical approaches and architectures
    - Identify emerging technologies and disruptions
    - Analyze build vs. buy vs. partner options
 
 6. **Industry & Ecosystem Research**
-
    - Map industry value chains and dynamics
    - Identify key players and relationships
    - Analyze regulatory and compliance factors
    - Understand partnership opportunities
 
 7. **Strategic Options Research**
-
    - Evaluate different strategic directions
    - Assess business model alternatives
    - Analyze go-to-market strategies
    - Consider expansion and scaling paths
 
 8. **Risk & Feasibility Research**
-
    - Identify and assess various risk factors
    - Evaluate implementation challenges
    - Analyze resource requirements
    - Consider regulatory and legal implications
 
 9. **Custom Research Focus**
-
    - User-defined research objectives
    - Specialized domain investigation
    - Cross-functional research needs
@@ -458,13 +344,11 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
 ### 5. Review and Refinement
 
 1. **Present Complete Prompt**
-
    - Show the full research prompt
    - Explain key elements and rationale
    - Highlight any assumptions made
 
 2. **Gather Feedback**
-
    - Are the objectives clear and correct?
    - Do the questions address all concerns?
    - Is the scope appropriate?
@@ -501,6 +385,110 @@ CRITICAL: collaborate with the user to develop specific, actionable research que
 - Plan for iterative refinement based on initial findings
 ==================== END: .bmad-core/tasks/create-deep-research-prompt.md ====================
 
+==================== START: .bmad-core/tasks/create-doc.md ====================
+# Create Document from Template (YAML Driven)
+
+## ⚠️ CRITICAL EXECUTION NOTICE ⚠️
+
+**THIS IS AN EXECUTABLE WORKFLOW - NOT REFERENCE MATERIAL**
+
+When this task is invoked:
+
+1. **DISABLE ALL EFFICIENCY OPTIMIZATIONS** - This workflow requires full user interaction
+2. **MANDATORY STEP-BY-STEP EXECUTION** - Each section must be processed sequentially with user feedback
+3. **ELICITATION IS REQUIRED** - When `elicit: true`, you MUST use the 1-9 format and wait for user response
+4. **NO SHORTCUTS ALLOWED** - Complete documents cannot be created without following this workflow
+
+**VIOLATION INDICATOR:** If you create a complete document without user interaction, you have violated this workflow.
+
+## Critical: Template Discovery
+
+If a YAML Template has not been provided, list all templates from .bmad-core/templates or ask the user to provide another.
+
+## CRITICAL: Mandatory Elicitation Format
+
+**When `elicit: true`, this is a HARD STOP requiring user interaction:**
+
+**YOU MUST:**
+
+1. Present section content
+2. Provide detailed rationale (explain trade-offs, assumptions, decisions made)
+3. **STOP and present numbered options 1-9:**
+   - **Option 1:** Always "Proceed to next section"
+   - **Options 2-9:** Select 8 methods from data/elicitation-methods
+   - End with: "Select 1-9 or just type your question/feedback:"
+4. **WAIT FOR USER RESPONSE** - Do not proceed until user selects option or provides feedback
+
+**WORKFLOW VIOLATION:** Creating content for elicit=true sections without user interaction violates this task.
+
+**NEVER ask yes/no questions or use any other format.**
+
+## Processing Flow
+
+1. **Parse YAML template** - Load template metadata and sections
+2. **Set preferences** - Show current mode (Interactive), confirm output file
+3. **Process each section:**
+   - Skip if condition unmet
+   - Check agent permissions (owner/editors) - note if section is restricted to specific agents
+   - Draft content using section instruction
+   - Present content + detailed rationale
+   - **IF elicit: true** → MANDATORY 1-9 options format
+   - Save to file if possible
+4. **Continue until complete**
+
+## Detailed Rationale Requirements
+
+When presenting section content, ALWAYS include rationale that explains:
+
+- Trade-offs and choices made (what was chosen over alternatives and why)
+- Key assumptions made during drafting
+- Interesting or questionable decisions that need user attention
+- Areas that might need validation
+
+## Elicitation Results Flow
+
+After user selects elicitation method (2-9):
+
+1. Execute method from data/elicitation-methods
+2. Present results with insights
+3. Offer options:
+   - **1. Apply changes and update section**
+   - **2. Return to elicitation menu**
+   - **3. Ask any questions or engage further with this elicitation**
+
+## Agent Permissions
+
+When processing sections with agent permission fields:
+
+- **owner**: Note which agent role initially creates/populates the section
+- **editors**: List agent roles allowed to modify the section
+- **readonly**: Mark sections that cannot be modified after creation
+
+**For sections with restricted access:**
+
+- Include a note in the generated document indicating the responsible agent
+- Example: "_(This section is owned by dev-agent and can only be modified by dev-agent)_"
+
+## YOLO Mode
+
+User can type `#yolo` to toggle to YOLO mode (process all sections at once).
+
+## CRITICAL REMINDERS
+
+**❌ NEVER:**
+
+- Ask yes/no questions for elicitation
+- Use any format other than 1-9 numbered options
+- Create new elicitation methods
+
+**✅ ALWAYS:**
+
+- Use exact 1-9 format when elicit: true
+- Select options 2-9 from data/elicitation-methods only
+- Provide detailed rationale explaining decisions
+- End with "Select 1-9 or just type your question/feedback:"
+==================== END: .bmad-core/tasks/create-doc.md ====================
+
 ==================== START: .bmad-core/tasks/document-project.md ====================
 # Document an Existing Project
 
@@ -615,9 +603,9 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
 
 ### Change Log
 
-| Date | Version | Description | Author |
-|------|---------|-------------|--------|
-| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
+| Date   | Version | Description                 | Author    |
+| ------ | ------- | --------------------------- | --------- |
+| [Date] | 1.0     | Initial brownfield analysis | [Analyst] |
 
 ## Quick Reference - Key Files and Entry Points
 
@@ -640,11 +628,11 @@ This document captures the CURRENT STATE of the [Project Name] codebase, includi
 
 ### Actual Tech Stack (from package.json/requirements.txt)
 
-| Category | Technology | Version | Notes |
-|----------|------------|---------|--------|
-| Runtime | Node.js | 16.x | [Any constraints] |
-| Framework | Express | 4.18.2 | [Custom middleware?] |
-| Database | PostgreSQL | 13 | [Connection pooling setup] |
+| Category  | Technology | Version | Notes                      |
+| --------- | ---------- | ------- | -------------------------- |
+| Runtime   | Node.js    | 16.x    | [Any constraints]          |
+| Framework | Express    | 4.18.2  | [Custom middleware?]       |
+| Database  | PostgreSQL | 13      | [Connection pooling setup] |
 
 etc...
 
@@ -683,6 +671,7 @@ project-root/
 ### Data Models
 
 Instead of duplicating, reference actual model files:
+
 - **User Model**: See `src/models/User.js`
 - **Order Model**: See `src/models/Order.js`
 - **Related Types**: TypeScript definitions in `src/types/`
@@ -712,10 +701,10 @@ Instead of duplicating, reference actual model files:
 
 ### External Services
 
-| Service | Purpose | Integration Type | Key Files |
-|---------|---------|------------------|-----------|
-| Stripe | Payments | REST API | `src/integrations/stripe/` |
-| SendGrid | Emails | SDK | `src/services/emailService.js` |
+| Service  | Purpose  | Integration Type | Key Files                      |
+| -------- | -------- | ---------------- | ------------------------------ |
+| Stripe   | Payments | REST API         | `src/integrations/stripe/`     |
+| SendGrid | Emails   | SDK              | `src/services/emailService.js` |
 
 etc...
 
@@ -760,6 +749,7 @@ npm run test:integration  # Runs integration tests (requires local DB)
 ### Files That Will Need Modification
 
 Based on the enhancement requirements, these files will be affected:
+
 - `src/services/userService.js` - Add new user fields
 - `src/models/User.js` - Update schema
 - `src/routes/userRoutes.js` - New endpoints
@@ -857,7 +847,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 ## Instructions
 
 1. **Initial Assessment**
-
    - If user or the task being run provides a checklist name:
      - Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
      - If multiple matches found, ask user to clarify
@@ -870,14 +859,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
      - All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
 
 2. **Document and Artifact Gathering**
-
    - Each checklist will specify its required documents/artifacts at the beginning
    - Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
 
 3. **Checklist Processing**
 
    If in interactive mode:
-
    - Work through each section of the checklist one at a time
    - For each section:
      - Review all items in the section following instructions for that section embedded in the checklist
@@ -886,7 +873,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
      - Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
 
    If in YOLO mode:
-
    - Process all sections at once
    - Create a comprehensive report of all findings
    - Present the complete analysis to the user
@@ -894,7 +880,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 4. **Validation Approach**
 
    For each checklist item:
-
    - Read and understand the requirement
    - Look for evidence in the documentation that satisfies the requirement
    - Consider both explicit mentions and implicit coverage
@@ -908,7 +893,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 5. **Section Analysis**
 
    For each section:
-
    - think step by step to calculate pass rate
    - Identify common themes in failed items
    - Provide specific recommendations for improvement
@@ -918,7 +902,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 6. **Final Report**
 
    Prepare a summary that includes:
-
    - Overall checklist completion status
    - Pass rates by section
    - List of failed items with context
@@ -964,20 +947,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
@@ -990,16 +973,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
@@ -1027,7 +1010,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
@@ -1044,17 +1027,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)
@@ -1070,23 +1053,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:
@@ -1110,13 +1093,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
@@ -1125,11 +1108,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}}
@@ -1138,7 +1121,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
@@ -1147,7 +1130,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:
@@ -1156,13 +1139,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
@@ -1179,13 +1162,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
@@ -1198,10 +1181,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
@@ -1210,13 +1193,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
 
@@ -1227,13 +1210,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: |
@@ -1250,13 +1233,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
 
@@ -1266,14 +1249,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:
@@ -1291,13 +1274,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:
@@ -1333,13 +1316,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:
@@ -1386,13 +1369,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:
@@ -1414,7 +1397,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}}"
@@ -1432,14 +1415,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:
@@ -1460,7 +1443,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
@@ -1502,7 +1485,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
@@ -1571,16 +1554,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
@@ -1594,1501 +1577,1531 @@ sections:
           - Request for detailed frontend architecture
 ==================== END: .bmad-core/templates/architecture-tmpl.yaml ====================
 
-==================== START: .bmad-core/templates/front-end-architecture-tmpl.yaml ====================
+==================== START: .bmad-core/templates/brownfield-architecture-tmpl.yaml ====================
 template:
-  id: frontend-architecture-template-v2
-  name: Frontend Architecture Document
+  id: brownfield-architecture-template-v2
+  name: Brownfield Enhancement Architecture
   version: 2.0
   output:
     format: markdown
-    filename: docs/ui-architecture.md
-    title: "{{project_name}} Frontend Architecture Document"
+    filename: docs/architecture.md
+    title: "{{project_name}} Brownfield Enhancement Architecture"
 
 workflow:
   mode: interactive
   elicitation: advanced-elicitation
 
 sections:
-  - id: template-framework-selection
-    title: Template and Framework Selection
+  - id: introduction
+    title: Introduction
     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
-           - Upload/attach the project files (for small projects)
-           - Share a link to the project repository
-         - Analyze the starter/existing project to understand:
-           - Pre-installed dependencies and versions
-           - Folder structure and file organization
-           - Built-in components and utilities
-           - Styling approach (CSS modules, styled-components, Tailwind, etc.)
-           - State management setup (if any)
-           - Routing configuration
-           - 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
-           - Vue: Vue CLI, Nuxt.js, Vite + Vue
-           - 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.
+      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:
+          - id: current-state
+            title: Current Project State
+            template: |
+              - **Primary Purpose:** {{existing_project_purpose}}
+              - **Current Tech Stack:** {{existing_tech_summary}}
+              - **Architecture Style:** {{existing_architecture_style}}
+              - **Deployment Method:** {{existing_deployment_approach}}
+          - id: available-docs
+            title: Available Documentation
+            type: bullet-list
+            template: "- {{existing_docs_summary}}"
+          - id: constraints
+            title: Identified Constraints
+            type: bullet-list
+            template: "- {{constraint}}"
       - id: changelog
         title: Change Log
         type: table
-        columns: [Date, Version, Description, Author]
+        columns: [Change, Date, Version, Description, Author]
         instruction: Track document versions and changes
 
-  - id: frontend-tech-stack
-    title: Frontend Tech Stack
-    instruction: Extract from main architecture's Technology Stack Table. This section MUST remain synchronized with the main architecture document.
-    elicit: true
-    sections:
-      - id: tech-stack-table
-        title: Technology Stack Table
-        type: table
-        columns: [Category, Technology, Version, Purpose, Rationale]
-        instruction: Fill in appropriate technology choices based on the selected framework and project requirements.
-        rows:
-          - ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["UI Library", "{{ui_library}}", "{{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}}"]
-          - ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+  - id: enhancement-scope
+    title: Enhancement Scope and Integration Strategy
+    instruction: |
+      Define how the enhancement will integrate with the existing system:
 
-  - id: project-structure
-    title: Project Structure
-    instruction: Define exact directory structure for AI tools based on the chosen framework. Be specific about where each type of file goes. Generate a structure that follows the framework's best practices and conventions.
-    elicit: true
-    type: code
-    language: plaintext
+      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
 
-  - id: component-standards
-    title: Component Standards
-    instruction: Define exact patterns for component creation based on the chosen framework.
+      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:
-      - id: component-template
-        title: Component Template
-        instruction: Generate a minimal but complete component template following the framework's best practices. Include TypeScript types, proper imports, and basic structure.
-        type: code
-        language: typescript
-      - id: naming-conventions
-        title: Naming Conventions
-        instruction: Provide naming conventions specific to the chosen framework for components, files, services, state management, and other architectural elements.
+      - id: enhancement-overview
+        title: Enhancement Overview
+        template: |
+          **Enhancement Type:** {{enhancement_type}}
+          **Scope:** {{enhancement_scope}}
+          **Integration Impact:** {{integration_impact_level}}
+      - id: integration-approach
+        title: Integration Approach
+        template: |
+          **Code Integration Strategy:** {{code_integration_approach}}
+          **Database Integration:** {{database_integration_approach}}
+          **API Integration:** {{api_integration_approach}}
+          **UI Integration:** {{ui_integration_approach}}
+      - id: compatibility-requirements
+        title: Compatibility Requirements
+        template: |
+          - **Existing API Compatibility:** {{api_compatibility}}
+          - **Database Schema Compatibility:** {{db_compatibility}}
+          - **UI/UX Consistency:** {{ui_compatibility}}
+          - **Performance Impact:** {{performance_constraints}}
 
-  - id: state-management
-    title: State Management
-    instruction: Define state management patterns based on the chosen framework.
+  - id: tech-stack-alignment
+    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
+      4. Ensure version compatibility with existing dependencies
     elicit: true
     sections:
-      - id: store-structure
-        title: Store Structure
-        instruction: Generate the state management directory structure appropriate for the chosen framework and selected state management solution.
-        type: code
-        language: plaintext
-      - id: state-template
-        title: State Management Template
-        instruction: Provide a basic state management template/example following the framework's recommended patterns. Include TypeScript types and common operations like setting, updating, and clearing state.
-        type: code
-        language: typescript
+      - id: existing-stack
+        title: Existing Technology Stack
+        type: table
+        columns: [Category, Current Technology, Version, Usage in Enhancement, Notes]
+        instruction: Document the current stack that must be maintained or integrated with
+      - id: new-tech-additions
+        title: New Technology Additions
+        condition: Enhancement requires new technologies
+        type: table
+        columns: [Technology, Version, Purpose, Rationale, Integration Method]
+        instruction: Only include if new technologies are required for the enhancement
 
-  - id: api-integration
-    title: API Integration
-    instruction: Define API service patterns based on the chosen framework.
+  - id: data-models
+    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)
+      4. Ensure backward compatibility
     elicit: true
     sections:
-      - id: service-template
-        title: Service Template
-        instruction: Provide an API service template that follows the framework's conventions. Include proper TypeScript types, error handling, and async patterns.
-        type: code
-        language: typescript
-      - id: api-client-config
-        title: API Client Configuration
-        instruction: Show how to configure the HTTP client for the chosen framework, including authentication interceptors/middleware and error handling.
-        type: code
-        language: typescript
+      - id: new-models
+        title: New Data Models
+        repeatable: true
+        sections:
+          - id: model
+            title: "{{model_name}}"
+            template: |
+              **Purpose:** {{model_purpose}}
+              **Integration:** {{integration_with_existing}}
 
-  - id: routing
-    title: Routing
-    instruction: Define routing structure and patterns based on the chosen framework.
-    elicit: true
-    sections:
-      - id: route-configuration
-        title: Route Configuration
-        instruction: Provide routing configuration appropriate for the chosen framework. Include protected route patterns, lazy loading where applicable, and authentication guards/middleware.
-        type: code
-        language: typescript
+              **Key Attributes:**
+              - {{attribute_1}}: {{type_1}} - {{description_1}}
+              - {{attribute_2}}: {{type_2}} - {{description_2}}
 
-  - id: styling-guidelines
-    title: Styling Guidelines
-    instruction: Define styling approach based on the chosen framework.
-    elicit: true
-    sections:
-      - id: styling-approach
-        title: Styling Approach
-        instruction: Describe the styling methodology appropriate for the chosen framework (CSS Modules, Styled Components, Tailwind, etc.) and provide basic patterns.
-      - id: global-theme
-        title: Global Theme Variables
-        instruction: Provide a CSS custom properties (CSS variables) theme system that works across all frameworks. Include colors, spacing, typography, shadows, and dark mode support.
-        type: code
-        language: css
+              **Relationships:**
+              - **With Existing:** {{existing_relationships}}
+              - **With New:** {{new_relationships}}
+      - id: schema-integration
+        title: Schema Integration Strategy
+        template: |
+          **Database Changes Required:**
+          - **New Tables:** {{new_tables_list}}
+          - **Modified Tables:** {{modified_tables_list}}
+          - **New Indexes:** {{new_indexes_list}}
+          - **Migration Strategy:** {{migration_approach}}
 
-  - id: testing-requirements
-    title: Testing Requirements
-    instruction: Define minimal testing requirements based on the chosen framework.
+          **Backward Compatibility:**
+          - {{compatibility_measure_1}}
+          - {{compatibility_measure_2}}
+
+  - id: component-architecture
+    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:
-      - id: component-test-template
-        title: Component Test Template
-        instruction: Provide a basic component test template using the framework's recommended testing library. Include examples of rendering tests, user interaction tests, and mocking.
-        type: code
-        language: typescript
-      - id: testing-best-practices
-        title: Testing Best Practices
-        type: numbered-list
-        items:
-          - "**Unit Tests**: Test individual components in isolation"
-          - "**Integration Tests**: Test component interactions"
-          - "**E2E Tests**: Test critical user flows (using Cypress/Playwright)"
-          - "**Coverage Goals**: Aim for 80% code coverage"
-          - "**Test Structure**: Arrange-Act-Assert pattern"
-          - "**Mock External Dependencies**: API calls, routing, state management"
+      - id: new-components
+        title: New Components
+        repeatable: true
+        sections:
+          - id: component
+            title: "{{component_name}}"
+            template: |
+              **Responsibility:** {{component_description}}
+              **Integration Points:** {{integration_points}}
 
-  - id: environment-configuration
-    title: Environment Configuration
-    instruction: List required environment variables based on the chosen framework. Show the appropriate format and naming conventions for the framework.
+              **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
+        type: mermaid
+        mermaid_type: graph
+        instruction: Create Mermaid diagram showing how new components interact with existing ones
+
+  - id: api-design
+    title: API Design and Integration
+    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
+      4. Plan versioning strategy if needed
     elicit: true
+    sections:
+      - id: api-strategy
+        title: API Integration Strategy
+        template: |
+          **API Integration Strategy:** {{api_integration_strategy}}
+          **Authentication:** {{auth_integration}}
+          **Versioning:** {{versioning_approach}}
+      - id: new-endpoints
+        title: New API Endpoints
+        repeatable: true
+        sections:
+          - id: endpoint
+            title: "{{endpoint_name}}"
+            template: |
+              - **Method:** {{http_method}}
+              - **Endpoint:** {{endpoint_path}}
+              - **Purpose:** {{endpoint_purpose}}
+              - **Integration:** {{integration_with_existing}}
+            sections:
+              - id: request
+                title: Request
+                type: code
+                language: json
+                template: "{{request_schema}}"
+              - id: response
+                title: Response
+                type: code
+                language: json
+                template: "{{response_schema}}"
 
-  - id: frontend-developer-standards
-    title: Frontend Developer Standards
+  - id: external-api-integration
+    title: External API Integration
+    condition: Enhancement requires new external APIs
+    instruction: Document new external API integrations required for the enhancement
+    repeatable: true
     sections:
-      - id: critical-coding-rules
-        title: Critical Coding Rules
-        instruction: List essential rules that prevent common AI mistakes, including both universal rules and framework-specific ones.
-        elicit: true
-      - id: quick-reference
-        title: Quick Reference
-        instruction: |
-          Create a framework-specific cheat sheet with:
-          - Common commands (dev server, build, test)
-          - Key import patterns
-          - File naming conventions
-          - Project-specific patterns and utilities
-==================== END: .bmad-core/templates/front-end-architecture-tmpl.yaml ====================
+      - id: external-api
+        title: "{{api_name}} API"
+        template: |
+          - **Purpose:** {{api_purpose}}
+          - **Documentation:** {{api_docs_url}}
+          - **Base URL:** {{api_base_url}}
+          - **Authentication:** {{auth_method}}
+          - **Integration Method:** {{integration_approach}}
 
-==================== START: .bmad-core/templates/fullstack-architecture-tmpl.yaml ====================
-template:
-  id: fullstack-architecture-template-v2
-  name: Fullstack Architecture Document
-  version: 2.0
-  output:
-    format: markdown
-    filename: docs/architecture.md
-    title: "{{project_name}} Fullstack Architecture Document"
+          **Key Endpoints Used:**
+          - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
 
-workflow:
-  mode: interactive
-  elicitation: advanced-elicitation
+          **Error Handling:** {{error_handling_strategy}}
 
-sections:
-  - id: introduction
-    title: Introduction
+  - id: source-tree-integration
+    title: Source Tree Integration
     instruction: |
-      If available, review any provided relevant documents to gather all relevant context before beginning. At minimum, you should have access to docs/prd.md and docs/front-end-spec.md. Ask the user for any documents you need but cannot locate. This template creates a unified architecture that covers both backend and frontend concerns to guide AI-driven fullstack development.
-    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
-        type: table
-        columns: [Date, Version, Description, Author]
-        instruction: Track document versions and changes
+      Define how new code will integrate with existing project structure:
 
-  - id: high-level-architecture
-    title: High Level Architecture
-    instruction: This section contains multiple subsections that establish the foundation. Present all subsections together, then elicit feedback on the complete section.
+      1. Follow existing project organization patterns
+      2. Identify where new files/folders will be placed
+      3. Ensure consistency with existing naming conventions
+      4. Plan for minimal disruption to existing structure
     elicit: true
     sections:
-      - id: technical-summary
-        title: Technical Summary
-        instruction: |
-          Provide a comprehensive overview (4-6 sentences) covering:
-          - Overall architectural style and deployment approach
-          - Frontend framework and backend technology choices
-          - Key integration points between frontend and backend
-          - Infrastructure platform and services
-          - How this architecture achieves PRD goals
-      - id: platform-infrastructure
-        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.
+      - id: existing-structure
+        title: Existing Project Structure
+        type: code
+        language: plaintext
+        instruction: Document relevant parts of current structure
+        template: "{{existing_structure_relevant_parts}}"
+      - id: new-file-organization
+        title: New File Organization
+        type: code
+        language: plaintext
+        instruction: Show only new additions to existing structure
         template: |
-          **Platform:** {{selected_platform}}
-          **Key Services:** {{core_services_list}}
-          **Deployment Host and Regions:** {{regions}}
-      - id: repository-structure
-        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
-          4. Plan for shared code between frontend and backend
+          {{project-root}}/
+          ├── {{existing_structure_context}}
+          │   ├── {{new_folder_1}}/           # {{purpose_1}}
+          │   │   ├── {{new_file_1}}
+          │   │   └── {{new_file_2}}
+          │   ├── {{existing_folder}}/        # Existing folder with additions
+          │   │   ├── {{existing_file}}       # Existing file
+          │   │   └── {{new_file_3}}          # New addition
+          │   └── {{new_folder_2}}/           # {{purpose_2}}
+      - id: integration-guidelines
+        title: Integration Guidelines
         template: |
-          **Structure:** {{repo_structure_choice}}
-          **Monorepo Tool:** {{monorepo_tool_if_applicable}}
-          **Package Organization:** {{package_strategy}}
-      - id: architecture-diagram
-        title: High Level Architecture Diagram
-        type: mermaid
-        mermaid_type: graph
-        instruction: |
-          Create a Mermaid diagram showing the complete system architecture including:
-          - User entry points (web, mobile)
-          - Frontend application deployment
-          - API layer (REST/GraphQL)
-          - Backend services
-          - Databases and storage
-          - External integrations
-          - CDN and caching layers
-          
-          Use appropriate diagram type for clarity.
-      - id: architectural-patterns
-        title: Architectural Patterns
-        instruction: |
-          List patterns that will guide both frontend and backend development. Include patterns for:
-          - Overall architecture (e.g., Jamstack, Serverless, Microservices)
-          - 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}}"
-        examples:
-          - "**Jamstack Architecture:** Static site generation with serverless APIs - _Rationale:_ Optimal performance and scalability for content-heavy applications"
-          - "**Component-Based UI:** Reusable React components with TypeScript - _Rationale:_ Maintainability and type safety across large codebases"
-          - "**Repository Pattern:** Abstract data access logic - _Rationale:_ Enables testing and future database migration flexibility"
-          - "**API Gateway Pattern:** Single entry point for all API calls - _Rationale:_ Centralized auth, rate limiting, and monitoring"
+          - **File Naming:** {{file_naming_consistency}}
+          - **Folder Organization:** {{folder_organization_approach}}
+          - **Import/Export Patterns:** {{import_export_consistency}}
 
-  - id: tech-stack
-    title: Tech Stack
+  - id: infrastructure-deployment
+    title: Infrastructure and Deployment Integration
     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
-      - Authentication and authorization
-      - API approach
-      - Testing tools for both frontend and backend
-      - Build and deployment tools
-      - Monitoring and logging
-      
-      Upon render, elicit feedback immediately.
-    elicit: true
-    sections:
-      - id: tech-stack-table
-        title: Technology Stack Table
-        type: table
-        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}}"]
-          - ["State Management", "{{state_mgmt}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Backend Language", "{{be_language}}", "{{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}}"]
-          - ["File Storage", "{{storage}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Authentication", "{{auth}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Frontend Testing", "{{fe_test}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Backend Testing", "{{be_test}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["E2E Testing", "{{e2e_test}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Bundler", "{{bundler}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["IaC Tool", "{{iac_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["CI/CD", "{{cicd}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Monitoring", "{{monitoring}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Logging", "{{logging}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["CSS Framework", "{{css_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+      Define how the enhancement will be deployed alongside existing infrastructure:
 
-  - id: data-models
-    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.
+      1. Use existing deployment pipeline and infrastructure
+      2. Identify any infrastructure changes needed
+      3. Plan deployment strategy to minimize risk
+      4. Define rollback procedures
     elicit: true
-    repeatable: true
     sections:
-      - id: model
-        title: "{{model_name}}"
+      - id: existing-infrastructure
+        title: Existing Infrastructure
         template: |
-          **Purpose:** {{model_purpose}}
-          
-          **Key Attributes:**
-          - {{attribute_1}}: {{type_1}} - {{description_1}}
-          - {{attribute_2}}: {{type_2}} - {{description_2}}
-        sections:
-          - id: typescript-interface
-            title: TypeScript Interface
-            type: code
-            language: typescript
-            template: "{{model_interface}}"
-          - id: relationships
-            title: Relationships
-            type: bullet-list
-            template: "- {{relationship}}"
+          **Current Deployment:** {{existing_deployment_summary}}
+          **Infrastructure Tools:** {{existing_infrastructure_tools}}
+          **Environments:** {{existing_environments}}
+      - id: enhancement-deployment
+        title: Enhancement Deployment Strategy
+        template: |
+          **Deployment Approach:** {{deployment_approach}}
+          **Infrastructure Changes:** {{infrastructure_changes}}
+          **Pipeline Integration:** {{pipeline_integration}}
+      - id: rollback-strategy
+        title: Rollback Strategy
+        template: |
+          **Rollback Method:** {{rollback_method}}
+          **Risk Mitigation:** {{risk_mitigation}}
+          **Monitoring:** {{monitoring_approach}}
 
-  - id: api-spec
-    title: API Specification
+  - id: coding-standards
+    title: Coding Standards and Conventions
     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
-      4. Include all endpoints from epics/stories
-      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.
+      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
+      4. Define standards for new code organization
     elicit: true
     sections:
-      - id: rest-api
-        title: REST API Specification
-        condition: API style is REST
-        type: code
-        language: yaml
+      - id: existing-standards
+        title: Existing Standards Compliance
         template: |
-          openapi: 3.0.0
-          info:
-            title: {{api_title}}
-            version: {{api_version}}
-            description: {{api_description}}
-          servers:
-            - url: {{server_url}}
-              description: {{server_description}}
-      - id: graphql-api
-        title: GraphQL Schema
-        condition: API style is GraphQL
-        type: code
-        language: graphql
-        template: "{{graphql_schema}}"
-      - id: trpc-api
-        title: tRPC Router Definitions
-        condition: API style is tRPC
-        type: code
-        language: typescript
-        template: "{{trpc_routers}}"
+          **Code Style:** {{existing_code_style}}
+          **Linting Rules:** {{existing_linting}}
+          **Testing Patterns:** {{existing_test_patterns}}
+          **Documentation Style:** {{existing_doc_style}}
+      - id: enhancement-standards
+        title: Enhancement-Specific Standards
+        condition: New patterns needed for enhancement
+        repeatable: true
+        template: "- **{{standard_name}}:** {{standard_description}}"
+      - id: integration-rules
+        title: Critical Integration Rules
+        template: |
+          - **Existing API Compatibility:** {{api_compatibility_rule}}
+          - **Database Integration:** {{db_integration_rule}}
+          - **Error Handling:** {{error_handling_integration}}
+          - **Logging Consistency:** {{logging_consistency}}
 
-  - id: components
-    title: Components
+  - id: testing-strategy
+    title: Testing Strategy
     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
-      4. For each component, specify:
-      - Primary responsibility
-      - Key interfaces/APIs exposed
-      - Dependencies on other components
-      - Technology specifics based on tech stack choices
-      
-      5. Create component diagrams where helpful
+      Define testing approach for the enhancement:
+
+      1. Integrate with existing test suite
+      2. Ensure existing functionality remains intact
+      3. Plan for testing new features
+      4. Define integration testing approach
     elicit: true
     sections:
-      - id: component-list
-        repeatable: true
-        title: "{{component_name}}"
+      - id: existing-test-integration
+        title: Integration with Existing Tests
         template: |
-          **Responsibility:** {{component_description}}
-          
-          **Key Interfaces:**
-          - {{interface_1}}
-          - {{interface_2}}
-          
-          **Dependencies:** {{dependencies}}
-          
-          **Technology Stack:** {{component_tech_details}}
-      - id: component-diagrams
-        title: Component Diagrams
-        type: mermaid
-        instruction: |
-          Create Mermaid diagrams to visualize component relationships. Options:
-          - C4 Container diagram for high-level view
-          - Component diagram for detailed internal structure
-          - Sequence diagrams for complex interactions
-          Choose the most appropriate for clarity
+          **Existing Test Framework:** {{existing_test_framework}}
+          **Test Organization:** {{existing_test_organization}}
+          **Coverage Requirements:** {{existing_coverage_requirements}}
+      - id: new-testing
+        title: New Testing Requirements
+        sections:
+          - id: unit-tests
+            title: Unit Tests for New Components
+            template: |
+              - **Framework:** {{test_framework}}
+              - **Location:** {{test_location}}
+              - **Coverage Target:** {{coverage_target}}
+              - **Integration with Existing:** {{test_integration}}
+          - id: integration-tests
+            title: Integration Tests
+            template: |
+              - **Scope:** {{integration_test_scope}}
+              - **Existing System Verification:** {{existing_system_verification}}
+              - **New Feature Testing:** {{new_feature_testing}}
+          - id: regression-tests
+            title: Regression Testing
+            template: |
+              - **Existing Feature Verification:** {{regression_test_approach}}
+              - **Automated Regression Suite:** {{automated_regression}}
+              - **Manual Testing Requirements:** {{manual_testing_requirements}}
 
-  - id: external-apis
-    title: External APIs
-    condition: Project requires external API integrations
+  - id: security-integration
+    title: Security Integration
     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.
+      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
+      4. Define security testing for new components
     elicit: true
-    repeatable: true
     sections:
-      - id: api
-        title: "{{api_name}} API"
+      - id: existing-security
+        title: Existing Security Measures
         template: |
-          - **Purpose:** {{api_purpose}}
-          - **Documentation:** {{api_docs_url}}
-          - **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}}
+          **Authentication:** {{existing_auth}}
+          **Authorization:** {{existing_authz}}
+          **Data Protection:** {{existing_data_protection}}
+          **Security Tools:** {{existing_security_tools}}
+      - id: enhancement-security
+        title: Enhancement Security Requirements
+        template: |
+          **New Security Measures:** {{new_security_measures}}
+          **Integration Points:** {{security_integration_points}}
+          **Compliance Requirements:** {{compliance_requirements}}
+      - id: security-testing
+        title: Security Testing
+        template: |
+          **Existing Security Tests:** {{existing_security_tests}}
+          **New Security Test Requirements:** {{new_security_tests}}
+          **Penetration Testing:** {{pentest_requirements}}
 
-  - id: core-workflows
-    title: Core Workflows
-    type: mermaid
-    mermaid_type: sequence
+  - id: checklist-results
+    title: Checklist Results Report
+    instruction: Execute the architect-checklist and populate results here, focusing on brownfield-specific validation
+
+  - id: next-steps
+    title: Next Steps
     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
+      After completing the brownfield architecture:
 
-  - id: database-schema
-    title: Database Schema
+      1. Review integration points with existing system
+      2. Begin story implementation with Dev agent
+      3. Set up deployment pipeline integration
+      4. Plan rollback and monitoring procedures
+    sections:
+      - id: story-manager-handoff
+        title: Story Manager Handoff
+        instruction: |
+          Create a brief prompt for Story Manager to work with this brownfield enhancement. Include:
+          - Reference to this architecture document
+          - Key integration requirements validated with user
+          - Existing system constraints based on actual project analysis
+          - First story to implement with clear integration checkpoints
+          - Emphasis on maintaining existing system integrity throughout implementation
+      - id: developer-handoff
+        title: Developer Handoff
+        instruction: |
+          Create a brief prompt for developers starting implementation. Include:
+          - Reference to this architecture and existing coding standards analyzed from actual project
+          - Integration requirements with existing codebase validated with user
+          - Key technical decisions based on real project constraints
+          - Existing system compatibility requirements with specific verification steps
+          - Clear sequencing of implementation to minimize risk to existing functionality
+==================== END: .bmad-core/templates/brownfield-architecture-tmpl.yaml ====================
+
+==================== START: .bmad-core/templates/front-end-architecture-tmpl.yaml ====================
+template:
+  id: frontend-architecture-template-v2
+  name: Frontend Architecture Document
+  version: 2.0
+  output:
+    format: markdown
+    filename: docs/ui-architecture.md
+    title: "{{project_name}} Frontend Architecture Document"
+
+workflow:
+  mode: interactive
+  elicitation: advanced-elicitation
+
+sections:
+  - id: template-framework-selection
+    title: Template and Framework Selection
     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.)
+      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
+           - Upload/attach the project files (for small projects)
+           - Share a link to the project repository
+         - Analyze the starter/existing project to understand:
+           - Pre-installed dependencies and versions
+           - Folder structure and file organization
+           - Built-in components and utilities
+           - Styling approach (CSS modules, styled-components, Tailwind, etc.)
+           - State management setup (if any)
+           - Routing configuration
+           - 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
+           - Vue: Vue CLI, Nuxt.js, Vite + Vue
+           - 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
+        title: Change Log
+        type: table
+        columns: [Date, Version, Description, Author]
+        instruction: Track document versions and changes
+
+  - id: frontend-tech-stack
+    title: Frontend Tech Stack
+    instruction: Extract from main architecture's Technology Stack Table. This section MUST remain synchronized with the main architecture document.
     elicit: true
+    sections:
+      - id: tech-stack-table
+        title: Technology Stack Table
+        type: table
+        columns: [Category, Technology, Version, Purpose, Rationale]
+        instruction: Fill in appropriate technology choices based on the selected framework and project requirements.
+        rows:
+          - ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["UI Library", "{{ui_library}}", "{{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}}",
+            ]
+          - ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
 
-  - id: frontend-architecture
-    title: Frontend Architecture
-    instruction: Define frontend-specific architecture details. After each subsection, note if user wants to refine before continuing.
+  - id: project-structure
+    title: Project Structure
+    instruction: Define exact directory structure for AI tools based on the chosen framework. Be specific about where each type of file goes. Generate a structure that follows the framework's best practices and conventions.
+    elicit: true
+    type: code
+    language: plaintext
+
+  - id: component-standards
+    title: Component Standards
+    instruction: Define exact patterns for component creation based on the chosen framework.
     elicit: true
     sections:
-      - id: component-architecture
-        title: Component Architecture
-        instruction: Define component organization and patterns based on chosen framework.
-        sections:
-          - id: component-organization
-            title: Component Organization
-            type: code
-            language: text
-            template: "{{component_structure}}"
-          - id: component-template
-            title: Component Template
-            type: code
-            language: typescript
-            template: "{{component_template}}"
-      - id: state-management
-        title: State Management Architecture
-        instruction: Detail state management approach based on chosen solution.
-        sections:
-          - id: state-structure
-            title: State Structure
-            type: code
-            language: typescript
-            template: "{{state_structure}}"
-          - id: state-patterns
-            title: State Management Patterns
-            type: bullet-list
-            template: "- {{pattern}}"
-      - id: routing-architecture
-        title: Routing Architecture
-        instruction: Define routing structure based on framework choice.
-        sections:
-          - id: route-organization
-            title: Route Organization
-            type: code
-            language: text
-            template: "{{route_structure}}"
-          - id: protected-routes
-            title: Protected Route Pattern
-            type: code
-            language: typescript
-            template: "{{protected_route_example}}"
-      - id: frontend-services
-        title: Frontend Services Layer
-        instruction: Define how frontend communicates with backend.
-        sections:
-          - id: api-client-setup
-            title: API Client Setup
-            type: code
-            language: typescript
-            template: "{{api_client_setup}}"
-          - id: service-example
-            title: Service Example
-            type: code
-            language: typescript
-            template: "{{service_example}}"
+      - id: component-template
+        title: Component Template
+        instruction: Generate a minimal but complete component template following the framework's best practices. Include TypeScript types, proper imports, and basic structure.
+        type: code
+        language: typescript
+      - id: naming-conventions
+        title: Naming Conventions
+        instruction: Provide naming conventions specific to the chosen framework for components, files, services, state management, and other architectural elements.
 
-  - id: backend-architecture
-    title: Backend Architecture
-    instruction: Define backend-specific architecture details. Consider serverless vs traditional server approaches.
+  - id: state-management
+    title: State Management
+    instruction: Define state management patterns based on the chosen framework.
     elicit: true
     sections:
-      - id: service-architecture
-        title: Service Architecture
-        instruction: Based on platform choice, define service organization.
-        sections:
-          - id: serverless-architecture
-            condition: Serverless architecture chosen
-            sections:
-              - id: function-organization
-                title: Function Organization
-                type: code
-                language: text
-                template: "{{function_structure}}"
-              - id: function-template
-                title: Function Template
-                type: code
-                language: typescript
-                template: "{{function_template}}"
-          - id: traditional-server
-            condition: Traditional server architecture chosen
-            sections:
-              - id: controller-organization
-                title: Controller/Route Organization
-                type: code
-                language: text
-                template: "{{controller_structure}}"
-              - id: controller-template
-                title: Controller Template
-                type: code
-                language: typescript
-                template: "{{controller_template}}"
-      - id: database-architecture
-        title: Database Architecture
-        instruction: Define database schema and access patterns.
-        sections:
-          - id: schema-design
-            title: Schema Design
-            type: code
-            language: sql
-            template: "{{database_schema}}"
-          - id: data-access-layer
-            title: Data Access Layer
-            type: code
-            language: typescript
-            template: "{{repository_pattern}}"
-      - id: auth-architecture
-        title: Authentication and Authorization
-        instruction: Define auth implementation details.
-        sections:
-          - id: auth-flow
-            title: Auth Flow
-            type: mermaid
-            mermaid_type: sequence
-            template: "{{auth_flow_diagram}}"
-          - id: auth-middleware
-            title: Middleware/Guards
-            type: code
-            language: typescript
-            template: "{{auth_middleware}}"
+      - id: store-structure
+        title: Store Structure
+        instruction: Generate the state management directory structure appropriate for the chosen framework and selected state management solution.
+        type: code
+        language: plaintext
+      - id: state-template
+        title: State Management Template
+        instruction: Provide a basic state management template/example following the framework's recommended patterns. Include TypeScript types and common operations like setting, updating, and clearing state.
+        type: code
+        language: typescript
 
-  - id: unified-project-structure
-    title: Unified Project Structure
-    instruction: Create a monorepo structure that accommodates both frontend and backend. Adapt based on chosen tools and frameworks.
+  - id: api-integration
+    title: API Integration
+    instruction: Define API service patterns based on the chosen framework.
     elicit: true
-    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
+    sections:
+      - id: service-template
+        title: Service Template
+        instruction: Provide an API service template that follows the framework's conventions. Include proper TypeScript types, error handling, and async patterns.
+        type: code
+        language: typescript
+      - id: api-client-config
+        title: API Client Configuration
+        instruction: Show how to configure the HTTP client for the chosen framework, including authentication interceptors/middleware and error handling.
+        type: code
+        language: typescript
 
-  - id: development-workflow
-    title: Development Workflow
-    instruction: Define the development setup and workflow for the fullstack application.
+  - id: routing
+    title: Routing
+    instruction: Define routing structure and patterns based on the chosen framework.
     elicit: true
     sections:
-      - id: local-setup
-        title: Local Development Setup
-        sections:
-          - id: prerequisites
-            title: Prerequisites
-            type: code
-            language: bash
-            template: "{{prerequisites_commands}}"
-          - id: initial-setup
-            title: Initial Setup
-            type: code
-            language: bash
-            template: "{{setup_commands}}"
-          - id: dev-commands
-            title: Development Commands
-            type: code
-            language: bash
-            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
-        title: Environment Configuration
-        sections:
-          - id: env-vars
-            title: Required Environment Variables
-            type: code
-            language: bash
-            template: |
-              # Frontend (.env.local)
-              {{frontend_env_vars}}
-              
-              # Backend (.env)
-              {{backend_env_vars}}
-              
-              # Shared
-              {{shared_env_vars}}
+      - id: route-configuration
+        title: Route Configuration
+        instruction: Provide routing configuration appropriate for the chosen framework. Include protected route patterns, lazy loading where applicable, and authentication guards/middleware.
+        type: code
+        language: typescript
 
-  - id: deployment-architecture
-    title: Deployment Architecture
-    instruction: Define deployment strategy based on platform choice.
+  - id: styling-guidelines
+    title: Styling Guidelines
+    instruction: Define styling approach based on the chosen framework.
     elicit: true
     sections:
-      - id: deployment-strategy
-        title: Deployment Strategy
-        template: |
-          **Frontend Deployment:**
-          - **Platform:** {{frontend_deploy_platform}}
-          - **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}}
-          - **Deployment Method:** {{deployment_method}}
-      - id: cicd-pipeline
-        title: CI/CD Pipeline
+      - id: styling-approach
+        title: Styling Approach
+        instruction: Describe the styling methodology appropriate for the chosen framework (CSS Modules, Styled Components, Tailwind, etc.) and provide basic patterns.
+      - id: global-theme
+        title: Global Theme Variables
+        instruction: Provide a CSS custom properties (CSS variables) theme system that works across all frameworks. Include colors, spacing, typography, shadows, and dark mode support.
         type: code
-        language: yaml
-        template: "{{cicd_pipeline_config}}"
-      - id: environments
-        title: Environments
+        language: css
+
+  - id: testing-requirements
+    title: Testing Requirements
+    instruction: Define minimal testing requirements based on the chosen framework.
+    elicit: true
+    sections:
+      - id: component-test-template
+        title: Component Test Template
+        instruction: Provide a basic component test template using the framework's recommended testing library. Include examples of rendering tests, user interaction tests, and mocking.
+        type: code
+        language: typescript
+      - id: testing-best-practices
+        title: Testing Best Practices
+        type: numbered-list
+        items:
+          - "**Unit Tests**: Test individual components in isolation"
+          - "**Integration Tests**: Test component interactions"
+          - "**E2E Tests**: Test critical user flows (using Cypress/Playwright)"
+          - "**Coverage Goals**: Aim for 80% code coverage"
+          - "**Test Structure**: Arrange-Act-Assert pattern"
+          - "**Mock External Dependencies**: API calls, routing, state management"
+
+  - id: environment-configuration
+    title: Environment Configuration
+    instruction: List required environment variables based on the chosen framework. Show the appropriate format and naming conventions for the framework.
+    elicit: true
+
+  - id: frontend-developer-standards
+    title: Frontend Developer Standards
+    sections:
+      - id: critical-coding-rules
+        title: Critical Coding Rules
+        instruction: List essential rules that prevent common AI mistakes, including both universal rules and framework-specific ones.
+        elicit: true
+      - id: quick-reference
+        title: Quick Reference
+        instruction: |
+          Create a framework-specific cheat sheet with:
+          - Common commands (dev server, build, test)
+          - Key import patterns
+          - File naming conventions
+          - Project-specific patterns and utilities
+==================== END: .bmad-core/templates/front-end-architecture-tmpl.yaml ====================
+
+==================== START: .bmad-core/templates/fullstack-architecture-tmpl.yaml ====================
+template:
+  id: fullstack-architecture-template-v2
+  name: Fullstack Architecture Document
+  version: 2.0
+  output:
+    format: markdown
+    filename: docs/architecture.md
+    title: "{{project_name}} Fullstack Architecture Document"
+
+workflow:
+  mode: interactive
+  elicitation: advanced-elicitation
+
+sections:
+  - id: introduction
+    title: Introduction
+    instruction: |
+      If available, review any provided relevant documents to gather all relevant context before beginning. At minimum, you should have access to docs/prd.md and docs/front-end-spec.md. Ask the user for any documents you need but cannot locate. This template creates a unified architecture that covers both backend and frontend concerns to guide AI-driven fullstack development.
+    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
         type: table
-        columns: [Environment, Frontend URL, Backend URL, Purpose]
-        rows:
-          - ["Development", "{{dev_fe_url}}", "{{dev_be_url}}", "Local development"]
-          - ["Staging", "{{staging_fe_url}}", "{{staging_be_url}}", "Pre-production testing"]
-          - ["Production", "{{prod_fe_url}}", "{{prod_be_url}}", "Live environment"]
+        columns: [Date, Version, Description, Author]
+        instruction: Track document versions and changes
 
-  - id: security-performance
-    title: Security and Performance
-    instruction: Define security and performance considerations for the fullstack application.
+  - id: high-level-architecture
+    title: High Level Architecture
+    instruction: This section contains multiple subsections that establish the foundation. Present all subsections together, then elicit feedback on the complete section.
     elicit: true
     sections:
-      - id: security-requirements
-        title: Security Requirements
+      - id: technical-summary
+        title: Technical Summary
+        instruction: |
+          Provide a comprehensive overview (4-6 sentences) covering:
+          - Overall architectural style and deployment approach
+          - Frontend framework and backend technology choices
+          - Key integration points between frontend and backend
+          - Infrastructure platform and services
+          - How this architecture achieves PRD goals
+      - id: platform-infrastructure
+        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: |
-          **Frontend Security:**
-          - 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}}
-          - Password Policy: {{password_requirements}}
-      - id: performance-optimization
-        title: Performance Optimization
+          **Platform:** {{selected_platform}}
+          **Key Services:** {{core_services_list}}
+          **Deployment Host and Regions:** {{regions}}
+      - id: repository-structure
+        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
+          4. Plan for shared code between frontend and backend
         template: |
-          **Frontend Performance:**
-          - 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}}
-          - Caching Strategy: {{be_cache_strategy}}
+          **Structure:** {{repo_structure_choice}}
+          **Monorepo Tool:** {{monorepo_tool_if_applicable}}
+          **Package Organization:** {{package_strategy}}
+      - id: architecture-diagram
+        title: High Level Architecture Diagram
+        type: mermaid
+        mermaid_type: graph
+        instruction: |
+          Create a Mermaid diagram showing the complete system architecture including:
+          - User entry points (web, mobile)
+          - Frontend application deployment
+          - API layer (REST/GraphQL)
+          - Backend services
+          - Databases and storage
+          - External integrations
+          - CDN and caching layers
+
+          Use appropriate diagram type for clarity.
+      - id: architectural-patterns
+        title: Architectural Patterns
+        instruction: |
+          List patterns that will guide both frontend and backend development. Include patterns for:
+          - Overall architecture (e.g., Jamstack, Serverless, Microservices)
+          - 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}}"
+        examples:
+          - "**Jamstack Architecture:** Static site generation with serverless APIs - _Rationale:_ Optimal performance and scalability for content-heavy applications"
+          - "**Component-Based UI:** Reusable React components with TypeScript - _Rationale:_ Maintainability and type safety across large codebases"
+          - "**Repository Pattern:** Abstract data access logic - _Rationale:_ Enables testing and future database migration flexibility"
+          - "**API Gateway Pattern:** Single entry point for all API calls - _Rationale:_ Centralized auth, rate limiting, and monitoring"
+
+  - id: tech-stack
+    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
+      - Authentication and authorization
+      - API approach
+      - Testing tools for both frontend and backend
+      - Build and deployment tools
+      - Monitoring and logging
+
+      Upon render, elicit feedback immediately.
+    elicit: true
+    sections:
+      - id: tech-stack-table
+        title: Technology Stack Table
+        type: table
+        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}}",
+            ]
+          - ["State Management", "{{state_mgmt}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Backend Language", "{{be_language}}", "{{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}}"]
+          - ["File Storage", "{{storage}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Authentication", "{{auth}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Frontend Testing", "{{fe_test}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Backend Testing", "{{be_test}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["E2E Testing", "{{e2e_test}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Bundler", "{{bundler}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["IaC Tool", "{{iac_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["CI/CD", "{{cicd}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Monitoring", "{{monitoring}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["Logging", "{{logging}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["CSS Framework", "{{css_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
 
-  - id: testing-strategy
-    title: Testing Strategy
-    instruction: Define comprehensive testing approach for fullstack application.
+  - id: data-models
+    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
     sections:
-      - id: testing-pyramid
-        title: Testing Pyramid
-        type: code
-        language: text
+      - id: model
+        title: "{{model_name}}"
         template: |
-                  E2E Tests
-                 /        \
-            Integration Tests
-               /            \
-          Frontend Unit  Backend Unit
-      - id: test-organization
-        title: Test Organization
-        sections:
-          - id: frontend-tests
-            title: Frontend Tests
-            type: code
-            language: text
-            template: "{{frontend_test_structure}}"
-          - id: backend-tests
-            title: Backend Tests
-            type: code
-            language: text
-            template: "{{backend_test_structure}}"
-          - id: e2e-tests
-            title: E2E Tests
-            type: code
-            language: text
-            template: "{{e2e_test_structure}}"
-      - id: test-examples
-        title: Test Examples
+          **Purpose:** {{model_purpose}}
+
+          **Key Attributes:**
+          - {{attribute_1}}: {{type_1}} - {{description_1}}
+          - {{attribute_2}}: {{type_2}} - {{description_2}}
         sections:
-          - id: frontend-test
-            title: Frontend Component Test
-            type: code
-            language: typescript
-            template: "{{frontend_test_example}}"
-          - id: backend-test
-            title: Backend API Test
-            type: code
-            language: typescript
-            template: "{{backend_test_example}}"
-          - id: e2e-test
-            title: E2E Test
+          - id: typescript-interface
+            title: TypeScript Interface
             type: code
             language: typescript
-            template: "{{e2e_test_example}}"
+            template: "{{model_interface}}"
+          - id: relationships
+            title: Relationships
+            type: bullet-list
+            template: "- {{relationship}}"
 
-  - id: coding-standards
-    title: Coding Standards
-    instruction: Define MINIMAL but CRITICAL standards for AI agents. Focus only on project-specific rules that prevent common mistakes. These will be used by dev agents.
-    elicit: true
-    sections:
-      - id: critical-rules
-        title: Critical Fullstack Rules
-        repeatable: true
-        template: "- **{{rule_name}}:** {{rule_description}}"
-        examples:
-          - "**Type Sharing:** Always define types in packages/shared and import from there"
-          - "**API Calls:** Never make direct HTTP calls - use the service layer"
-          - "**Environment Variables:** Access only through config objects, never process.env directly"
-          - "**Error Handling:** All API routes must use the standard error handler"
-          - "**State Updates:** Never mutate state directly - use proper state management patterns"
-      - id: naming-conventions
-        title: Naming Conventions
-        type: table
-        columns: [Element, Frontend, Backend, Example]
-        rows:
-          - ["Components", "PascalCase", "-", "`UserProfile.tsx`"]
-          - ["Hooks", "camelCase with 'use'", "-", "`useAuth.ts`"]
-          - ["API Routes", "-", "kebab-case", "`/api/user-profile`"]
-          - ["Database Tables", "-", "snake_case", "`user_profiles`"]
+  - id: api-spec
+    title: API Specification
+    instruction: |
+      Based on the chosen API style from Tech Stack:
 
-  - id: error-handling
-    title: Error Handling Strategy
-    instruction: Define unified error handling across frontend and backend.
+      1. If REST API, create an OpenAPI 3.0 specification
+      2. If GraphQL, provide the GraphQL schema
+      3. If tRPC, show router definitions
+      4. Include all endpoints from epics/stories
+      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:
-      - id: error-flow
-        title: Error Flow
-        type: mermaid
-        mermaid_type: sequence
-        template: "{{error_flow_diagram}}"
-      - id: error-format
-        title: Error Response Format
+      - id: rest-api
+        title: REST API Specification
+        condition: API style is REST
         type: code
-        language: typescript
+        language: yaml
         template: |
-          interface ApiError {
-            error: {
-              code: string;
-              message: string;
-              details?: Record<string, any>;
-              timestamp: string;
-              requestId: string;
-            };
-          }
-      - id: frontend-error-handling
-        title: Frontend Error Handling
+          openapi: 3.0.0
+          info:
+            title: {{api_title}}
+            version: {{api_version}}
+            description: {{api_description}}
+          servers:
+            - url: {{server_url}}
+              description: {{server_description}}
+      - id: graphql-api
+        title: GraphQL Schema
+        condition: API style is GraphQL
         type: code
-        language: typescript
-        template: "{{frontend_error_handler}}"
-      - id: backend-error-handling
-        title: Backend Error Handling
+        language: graphql
+        template: "{{graphql_schema}}"
+      - id: trpc-api
+        title: tRPC Router Definitions
+        condition: API style is tRPC
         type: code
         language: typescript
-        template: "{{backend_error_handler}}"
+        template: "{{trpc_routers}}"
 
-  - id: monitoring
-    title: Monitoring and Observability
-    instruction: Define monitoring strategy for fullstack application.
+  - id: components
+    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
+      4. For each component, specify:
+      - Primary responsibility
+      - Key interfaces/APIs exposed
+      - Dependencies on other components
+      - Technology specifics based on tech stack choices
+
+      5. Create component diagrams where helpful
     elicit: true
     sections:
-      - id: monitoring-stack
-        title: Monitoring Stack
+      - id: component-list
+        repeatable: true
+        title: "{{component_name}}"
         template: |
-          - **Frontend Monitoring:** {{frontend_monitoring}}
-          - **Backend Monitoring:** {{backend_monitoring}}
-          - **Error Tracking:** {{error_tracking}}
-          - **Performance Monitoring:** {{perf_monitoring}}
-      - id: key-metrics
-        title: Key Metrics
+          **Responsibility:** {{component_description}}
+
+          **Key Interfaces:**
+          - {{interface_1}}
+          - {{interface_2}}
+
+          **Dependencies:** {{dependencies}}
+
+          **Technology Stack:** {{component_tech_details}}
+      - id: component-diagrams
+        title: Component Diagrams
+        type: mermaid
+        instruction: |
+          Create Mermaid diagrams to visualize component relationships. Options:
+          - C4 Container diagram for high-level view
+          - Component diagram for detailed internal structure
+          - Sequence diagrams for complex interactions
+          Choose the most appropriate for clarity
+
+  - id: external-apis
+    title: External APIs
+    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
+    sections:
+      - id: api
+        title: "{{api_name}} API"
         template: |
-          **Frontend Metrics:**
-          - Core Web Vitals
-          - JavaScript errors
-          - API response times
-          - User interactions
-          
-          **Backend Metrics:**
-          - Request rate
-          - Error rate
-          - Response time
-          - Database query performance
+          - **Purpose:** {{api_purpose}}
+          - **Documentation:** {{api_docs_url}}
+          - **Base URL(s):** {{api_base_url}}
+          - **Authentication:** {{auth_method}}
+          - **Rate Limits:** {{rate_limits}}
 
-  - id: checklist-results
-    title: Checklist Results Report
-    instruction: Before running the checklist, offer to output the full architecture document. Once user confirms, execute the architect-checklist and populate results here.
-==================== END: .bmad-core/templates/fullstack-architecture-tmpl.yaml ====================
+          **Key Endpoints Used:**
+          - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
+
+          **Integration Notes:** {{integration_considerations}}
+
+  - id: core-workflows
+    title: Core Workflows
+    type: mermaid
+    mermaid_type: sequence
+    instruction: |
+      Illustrate key system workflows using sequence diagrams:
 
-==================== START: .bmad-core/templates/brownfield-architecture-tmpl.yaml ====================
-template:
-  id: brownfield-architecture-template-v2
-  name: Brownfield Enhancement Architecture
-  version: 2.0
-  output:
-    format: markdown
-    filename: docs/architecture.md
-    title: "{{project_name}} Brownfield Enhancement Architecture"
+      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
 
-workflow:
-  mode: interactive
-  elicitation: advanced-elicitation
+      Focus on workflows that clarify architecture decisions or complex interactions.
+    elicit: true
 
-sections:
-  - id: introduction
-    title: Introduction
+  - id: database-schema
+    title: Database Schema
     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.
+      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
+
+  - id: frontend-architecture
+    title: Frontend Architecture
+    instruction: Define frontend-specific architecture details. After each subsection, note if user wants to refine before continuing.
     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
+      - id: component-architecture
+        title: Component Architecture
+        instruction: Define component organization and patterns based on chosen framework.
         sections:
-          - id: current-state
-            title: Current Project State
-            template: |
-              - **Primary Purpose:** {{existing_project_purpose}}
-              - **Current Tech Stack:** {{existing_tech_summary}}
-              - **Architecture Style:** {{existing_architecture_style}}
-              - **Deployment Method:** {{existing_deployment_approach}}
-          - id: available-docs
-            title: Available Documentation
-            type: bullet-list
-            template: "- {{existing_docs_summary}}"
-          - id: constraints
-            title: Identified Constraints
+          - id: component-organization
+            title: Component Organization
+            type: code
+            language: text
+            template: "{{component_structure}}"
+          - id: component-template
+            title: Component Template
+            type: code
+            language: typescript
+            template: "{{component_template}}"
+      - id: state-management
+        title: State Management Architecture
+        instruction: Detail state management approach based on chosen solution.
+        sections:
+          - id: state-structure
+            title: State Structure
+            type: code
+            language: typescript
+            template: "{{state_structure}}"
+          - id: state-patterns
+            title: State Management Patterns
             type: bullet-list
-            template: "- {{constraint}}"
-      - id: changelog
-        title: Change Log
-        type: table
-        columns: [Change, Date, Version, Description, Author]
-        instruction: Track document versions and changes
+            template: "- {{pattern}}"
+      - id: routing-architecture
+        title: Routing Architecture
+        instruction: Define routing structure based on framework choice.
+        sections:
+          - id: route-organization
+            title: Route Organization
+            type: code
+            language: text
+            template: "{{route_structure}}"
+          - id: protected-routes
+            title: Protected Route Pattern
+            type: code
+            language: typescript
+            template: "{{protected_route_example}}"
+      - id: frontend-services
+        title: Frontend Services Layer
+        instruction: Define how frontend communicates with backend.
+        sections:
+          - id: api-client-setup
+            title: API Client Setup
+            type: code
+            language: typescript
+            template: "{{api_client_setup}}"
+          - id: service-example
+            title: Service Example
+            type: code
+            language: typescript
+            template: "{{service_example}}"
 
-  - id: enhancement-scope
-    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?"
+  - id: backend-architecture
+    title: Backend Architecture
+    instruction: Define backend-specific architecture details. Consider serverless vs traditional server approaches.
     elicit: true
     sections:
-      - id: enhancement-overview
-        title: Enhancement Overview
-        template: |
-          **Enhancement Type:** {{enhancement_type}}
-          **Scope:** {{enhancement_scope}}
-          **Integration Impact:** {{integration_impact_level}}
-      - id: integration-approach
-        title: Integration Approach
-        template: |
-          **Code Integration Strategy:** {{code_integration_approach}}
-          **Database Integration:** {{database_integration_approach}}
-          **API Integration:** {{api_integration_approach}}
-          **UI Integration:** {{ui_integration_approach}}
-      - id: compatibility-requirements
-        title: Compatibility Requirements
-        template: |
-          - **Existing API Compatibility:** {{api_compatibility}}
-          - **Database Schema Compatibility:** {{db_compatibility}}
-          - **UI/UX Consistency:** {{ui_compatibility}}
-          - **Performance Impact:** {{performance_constraints}}
+      - id: service-architecture
+        title: Service Architecture
+        instruction: Based on platform choice, define service organization.
+        sections:
+          - id: serverless-architecture
+            condition: Serverless architecture chosen
+            sections:
+              - id: function-organization
+                title: Function Organization
+                type: code
+                language: text
+                template: "{{function_structure}}"
+              - id: function-template
+                title: Function Template
+                type: code
+                language: typescript
+                template: "{{function_template}}"
+          - id: traditional-server
+            condition: Traditional server architecture chosen
+            sections:
+              - id: controller-organization
+                title: Controller/Route Organization
+                type: code
+                language: text
+                template: "{{controller_structure}}"
+              - id: controller-template
+                title: Controller Template
+                type: code
+                language: typescript
+                template: "{{controller_template}}"
+      - id: database-architecture
+        title: Database Architecture
+        instruction: Define database schema and access patterns.
+        sections:
+          - id: schema-design
+            title: Schema Design
+            type: code
+            language: sql
+            template: "{{database_schema}}"
+          - id: data-access-layer
+            title: Data Access Layer
+            type: code
+            language: typescript
+            template: "{{repository_pattern}}"
+      - id: auth-architecture
+        title: Authentication and Authorization
+        instruction: Define auth implementation details.
+        sections:
+          - id: auth-flow
+            title: Auth Flow
+            type: mermaid
+            mermaid_type: sequence
+            template: "{{auth_flow_diagram}}"
+          - id: auth-middleware
+            title: Middleware/Guards
+            type: code
+            language: typescript
+            template: "{{auth_middleware}}"
 
-  - id: tech-stack-alignment
-    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
-      4. Ensure version compatibility with existing dependencies
+  - id: unified-project-structure
+    title: Unified Project Structure
+    instruction: Create a monorepo structure that accommodates both frontend and backend. Adapt based on chosen tools and frameworks.
     elicit: true
-    sections:
-      - id: existing-stack
-        title: Existing Technology Stack
-        type: table
-        columns: [Category, Current Technology, Version, Usage in Enhancement, Notes]
-        instruction: Document the current stack that must be maintained or integrated with
-      - id: new-tech-additions
-        title: New Technology Additions
-        condition: Enhancement requires new technologies
-        type: table
-        columns: [Technology, Version, Purpose, Rationale, Integration Method]
-        instruction: Only include if new technologies are required for the enhancement
+    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
 
-  - id: data-models
-    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)
-      4. Ensure backward compatibility
+  - id: development-workflow
+    title: Development Workflow
+    instruction: Define the development setup and workflow for the fullstack application.
     elicit: true
     sections:
-      - id: new-models
-        title: New Data Models
-        repeatable: true
+      - id: local-setup
+        title: Local Development Setup
         sections:
-          - id: model
-            title: "{{model_name}}"
+          - id: prerequisites
+            title: Prerequisites
+            type: code
+            language: bash
+            template: "{{prerequisites_commands}}"
+          - id: initial-setup
+            title: Initial Setup
+            type: code
+            language: bash
+            template: "{{setup_commands}}"
+          - id: dev-commands
+            title: Development Commands
+            type: code
+            language: bash
             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}}
-      - id: schema-integration
-        title: Schema Integration Strategy
-        template: |
-          **Database Changes Required:**
-          - **New Tables:** {{new_tables_list}}
-          - **Modified Tables:** {{modified_tables_list}}
-          - **New Indexes:** {{new_indexes_list}}
-          - **Migration Strategy:** {{migration_approach}}
-          
-          **Backward Compatibility:**
-          - {{compatibility_measure_1}}
-          - {{compatibility_measure_2}}
+              # Start all services
+              {{start_all_command}}
 
-  - id: component-architecture
-    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:
-      - id: new-components
-        title: New Components
-        repeatable: true
+              # Start frontend only
+              {{start_frontend_command}}
+
+              # Start backend only
+              {{start_backend_command}}
+
+              # Run tests
+              {{test_commands}}
+      - id: environment-config
+        title: Environment Configuration
         sections:
-          - id: component
-            title: "{{component_name}}"
+          - id: env-vars
+            title: Required Environment Variables
+            type: code
+            language: bash
             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
-        type: mermaid
-        mermaid_type: graph
-        instruction: Create Mermaid diagram showing how new components interact with existing ones
+              # Frontend (.env.local)
+              {{frontend_env_vars}}
 
-  - id: api-design
-    title: API Design and Integration
-    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
-      4. Plan versioning strategy if needed
+              # Backend (.env)
+              {{backend_env_vars}}
+
+              # Shared
+              {{shared_env_vars}}
+
+  - id: deployment-architecture
+    title: Deployment Architecture
+    instruction: Define deployment strategy based on platform choice.
     elicit: true
     sections:
-      - id: api-strategy
-        title: API Integration Strategy
+      - id: deployment-strategy
+        title: Deployment Strategy
         template: |
-          **API Integration Strategy:** {{api_integration_strategy}}
-          **Authentication:** {{auth_integration}}
-          **Versioning:** {{versioning_approach}}
-      - id: new-endpoints
-        title: New API Endpoints
-        repeatable: true
-        sections:
-          - id: endpoint
-            title: "{{endpoint_name}}"
-            template: |
-              - **Method:** {{http_method}}
-              - **Endpoint:** {{endpoint_path}}
-              - **Purpose:** {{endpoint_purpose}}
-              - **Integration:** {{integration_with_existing}}
-            sections:
-              - id: request
-                title: Request
-                type: code
-                language: json
-                template: "{{request_schema}}"
-              - id: response
-                title: Response
-                type: code
-                language: json
-                template: "{{response_schema}}"
+          **Frontend Deployment:**
+          - **Platform:** {{frontend_deploy_platform}}
+          - **Build Command:** {{frontend_build_command}}
+          - **Output Directory:** {{frontend_output_dir}}
+          - **CDN/Edge:** {{cdn_strategy}}
 
-  - id: external-api-integration
-    title: External API Integration
-    condition: Enhancement requires new external APIs
-    instruction: Document new external API integrations required for the enhancement
-    repeatable: true
-    sections:
-      - id: external-api
-        title: "{{api_name}} API"
-        template: |
-          - **Purpose:** {{api_purpose}}
-          - **Documentation:** {{api_docs_url}}
-          - **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}}
+          **Backend Deployment:**
+          - **Platform:** {{backend_deploy_platform}}
+          - **Build Command:** {{backend_build_command}}
+          - **Deployment Method:** {{deployment_method}}
+      - id: cicd-pipeline
+        title: CI/CD Pipeline
+        type: code
+        language: yaml
+        template: "{{cicd_pipeline_config}}"
+      - id: environments
+        title: Environments
+        type: table
+        columns: [Environment, Frontend URL, Backend URL, Purpose]
+        rows:
+          - ["Development", "{{dev_fe_url}}", "{{dev_be_url}}", "Local development"]
+          - ["Staging", "{{staging_fe_url}}", "{{staging_be_url}}", "Pre-production testing"]
+          - ["Production", "{{prod_fe_url}}", "{{prod_be_url}}", "Live environment"]
 
-  - 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
-      4. Plan for minimal disruption to existing structure
+  - id: security-performance
+    title: Security and Performance
+    instruction: Define security and performance considerations for the fullstack application.
     elicit: true
     sections:
-      - id: existing-structure
-        title: Existing Project Structure
-        type: code
-        language: plaintext
-        instruction: Document relevant parts of current structure
-        template: "{{existing_structure_relevant_parts}}"
-      - id: new-file-organization
-        title: New File Organization
-        type: code
-        language: plaintext
-        instruction: Show only new additions to existing structure
+      - id: security-requirements
+        title: Security Requirements
         template: |
-          {{project-root}}/
-          ├── {{existing_structure_context}}
-          │   ├── {{new_folder_1}}/           # {{purpose_1}}
-          │   │   ├── {{new_file_1}}
-          │   │   └── {{new_file_2}}
-          │   ├── {{existing_folder}}/        # Existing folder with additions
-          │   │   ├── {{existing_file}}       # Existing file
-          │   │   └── {{new_file_3}}          # New addition
-          │   └── {{new_folder_2}}/           # {{purpose_2}}
-      - id: integration-guidelines
-        title: Integration Guidelines
+          **Frontend Security:**
+          - 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}}
+          - Password Policy: {{password_requirements}}
+      - id: performance-optimization
+        title: Performance Optimization
         template: |
-          - **File Naming:** {{file_naming_consistency}}
-          - **Folder Organization:** {{folder_organization_approach}}
-          - **Import/Export Patterns:** {{import_export_consistency}}
+          **Frontend Performance:**
+          - Bundle Size Target: {{bundle_size}}
+          - Loading Strategy: {{loading_approach}}
+          - Caching Strategy: {{fe_cache_strategy}}
 
-  - id: infrastructure-deployment
-    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
-      4. Define rollback procedures
+          **Backend Performance:**
+          - Response Time Target: {{response_target}}
+          - Database Optimization: {{db_optimization}}
+          - Caching Strategy: {{be_cache_strategy}}
+
+  - id: testing-strategy
+    title: Testing Strategy
+    instruction: Define comprehensive testing approach for fullstack application.
     elicit: true
     sections:
-      - id: existing-infrastructure
-        title: Existing Infrastructure
-        template: |
-          **Current Deployment:** {{existing_deployment_summary}}
-          **Infrastructure Tools:** {{existing_infrastructure_tools}}
-          **Environments:** {{existing_environments}}
-      - id: enhancement-deployment
-        title: Enhancement Deployment Strategy
-        template: |
-          **Deployment Approach:** {{deployment_approach}}
-          **Infrastructure Changes:** {{infrastructure_changes}}
-          **Pipeline Integration:** {{pipeline_integration}}
-      - id: rollback-strategy
-        title: Rollback Strategy
+      - id: testing-pyramid
+        title: Testing Pyramid
+        type: code
+        language: text
         template: |
-          **Rollback Method:** {{rollback_method}}
-          **Risk Mitigation:** {{risk_mitigation}}
-          **Monitoring:** {{monitoring_approach}}
+          E2E Tests
+          /        \
+          Integration Tests
+          /            \
+          Frontend Unit  Backend Unit
+      - id: test-organization
+        title: Test Organization
+        sections:
+          - id: frontend-tests
+            title: Frontend Tests
+            type: code
+            language: text
+            template: "{{frontend_test_structure}}"
+          - id: backend-tests
+            title: Backend Tests
+            type: code
+            language: text
+            template: "{{backend_test_structure}}"
+          - id: e2e-tests
+            title: E2E Tests
+            type: code
+            language: text
+            template: "{{e2e_test_structure}}"
+      - id: test-examples
+        title: Test Examples
+        sections:
+          - id: frontend-test
+            title: Frontend Component Test
+            type: code
+            language: typescript
+            template: "{{frontend_test_example}}"
+          - id: backend-test
+            title: Backend API Test
+            type: code
+            language: typescript
+            template: "{{backend_test_example}}"
+          - id: e2e-test
+            title: E2E Test
+            type: code
+            language: typescript
+            template: "{{e2e_test_example}}"
 
   - id: coding-standards
-    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
-      4. Define standards for new code organization
+    title: Coding Standards
+    instruction: Define MINIMAL but CRITICAL standards for AI agents. Focus only on project-specific rules that prevent common mistakes. These will be used by dev agents.
     elicit: true
     sections:
-      - id: existing-standards
-        title: Existing Standards Compliance
-        template: |
-          **Code Style:** {{existing_code_style}}
-          **Linting Rules:** {{existing_linting}}
-          **Testing Patterns:** {{existing_test_patterns}}
-          **Documentation Style:** {{existing_doc_style}}
-      - id: enhancement-standards
-        title: Enhancement-Specific Standards
-        condition: New patterns needed for enhancement
+      - id: critical-rules
+        title: Critical Fullstack Rules
         repeatable: true
-        template: "- **{{standard_name}}:** {{standard_description}}"
-      - id: integration-rules
-        title: Critical Integration Rules
-        template: |
-          - **Existing API Compatibility:** {{api_compatibility_rule}}
-          - **Database Integration:** {{db_integration_rule}}
-          - **Error Handling:** {{error_handling_integration}}
-          - **Logging Consistency:** {{logging_consistency}}
+        template: "- **{{rule_name}}:** {{rule_description}}"
+        examples:
+          - "**Type Sharing:** Always define types in packages/shared and import from there"
+          - "**API Calls:** Never make direct HTTP calls - use the service layer"
+          - "**Environment Variables:** Access only through config objects, never process.env directly"
+          - "**Error Handling:** All API routes must use the standard error handler"
+          - "**State Updates:** Never mutate state directly - use proper state management patterns"
+      - id: naming-conventions
+        title: Naming Conventions
+        type: table
+        columns: [Element, Frontend, Backend, Example]
+        rows:
+          - ["Components", "PascalCase", "-", "`UserProfile.tsx`"]
+          - ["Hooks", "camelCase with 'use'", "-", "`useAuth.ts`"]
+          - ["API Routes", "-", "kebab-case", "`/api/user-profile`"]
+          - ["Database Tables", "-", "snake_case", "`user_profiles`"]
 
-  - id: testing-strategy
-    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
-      4. Define integration testing approach
+  - id: error-handling
+    title: Error Handling Strategy
+    instruction: Define unified error handling across frontend and backend.
     elicit: true
     sections:
-      - id: existing-test-integration
-        title: Integration with Existing Tests
+      - id: error-flow
+        title: Error Flow
+        type: mermaid
+        mermaid_type: sequence
+        template: "{{error_flow_diagram}}"
+      - id: error-format
+        title: Error Response Format
+        type: code
+        language: typescript
         template: |
-          **Existing Test Framework:** {{existing_test_framework}}
-          **Test Organization:** {{existing_test_organization}}
-          **Coverage Requirements:** {{existing_coverage_requirements}}
-      - id: new-testing
-        title: New Testing Requirements
-        sections:
-          - id: unit-tests
-            title: Unit Tests for New Components
-            template: |
-              - **Framework:** {{test_framework}}
-              - **Location:** {{test_location}}
-              - **Coverage Target:** {{coverage_target}}
-              - **Integration with Existing:** {{test_integration}}
-          - id: integration-tests
-            title: Integration Tests
-            template: |
-              - **Scope:** {{integration_test_scope}}
-              - **Existing System Verification:** {{existing_system_verification}}
-              - **New Feature Testing:** {{new_feature_testing}}
-          - id: regression-tests
-            title: Regression Testing
-            template: |
-              - **Existing Feature Verification:** {{regression_test_approach}}
-              - **Automated Regression Suite:** {{automated_regression}}
-              - **Manual Testing Requirements:** {{manual_testing_requirements}}
+          interface ApiError {
+            error: {
+              code: string;
+              message: string;
+              details?: Record<string, any>;
+              timestamp: string;
+              requestId: string;
+            };
+          }
+      - id: frontend-error-handling
+        title: Frontend Error Handling
+        type: code
+        language: typescript
+        template: "{{frontend_error_handler}}"
+      - id: backend-error-handling
+        title: Backend Error Handling
+        type: code
+        language: typescript
+        template: "{{backend_error_handler}}"
 
-  - id: security-integration
-    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
-      4. Define security testing for new components
+  - id: monitoring
+    title: Monitoring and Observability
+    instruction: Define monitoring strategy for fullstack application.
     elicit: true
     sections:
-      - id: existing-security
-        title: Existing Security Measures
-        template: |
-          **Authentication:** {{existing_auth}}
-          **Authorization:** {{existing_authz}}
-          **Data Protection:** {{existing_data_protection}}
-          **Security Tools:** {{existing_security_tools}}
-      - id: enhancement-security
-        title: Enhancement Security Requirements
+      - id: monitoring-stack
+        title: Monitoring Stack
         template: |
-          **New Security Measures:** {{new_security_measures}}
-          **Integration Points:** {{security_integration_points}}
-          **Compliance Requirements:** {{compliance_requirements}}
-      - id: security-testing
-        title: Security Testing
+          - **Frontend Monitoring:** {{frontend_monitoring}}
+          - **Backend Monitoring:** {{backend_monitoring}}
+          - **Error Tracking:** {{error_tracking}}
+          - **Performance Monitoring:** {{perf_monitoring}}
+      - id: key-metrics
+        title: Key Metrics
         template: |
-          **Existing Security Tests:** {{existing_security_tests}}
-          **New Security Test Requirements:** {{new_security_tests}}
-          **Penetration Testing:** {{pentest_requirements}}
+          **Frontend Metrics:**
+          - Core Web Vitals
+          - JavaScript errors
+          - API response times
+          - User interactions
+
+          **Backend Metrics:**
+          - Request rate
+          - Error rate
+          - Response time
+          - Database query performance
 
   - id: checklist-results
     title: Checklist Results Report
-    instruction: Execute the architect-checklist and populate results here, focusing on brownfield-specific validation
-
-  - id: next-steps
-    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
-      4. Plan rollback and monitoring procedures
-    sections:
-      - id: story-manager-handoff
-        title: Story Manager Handoff
-        instruction: |
-          Create a brief prompt for Story Manager to work with this brownfield enhancement. Include:
-          - Reference to this architecture document
-          - Key integration requirements validated with user
-          - Existing system constraints based on actual project analysis
-          - First story to implement with clear integration checkpoints
-          - Emphasis on maintaining existing system integrity throughout implementation
-      - id: developer-handoff
-        title: Developer Handoff
-        instruction: |
-          Create a brief prompt for developers starting implementation. Include:
-          - Reference to this architecture and existing coding standards analyzed from actual project
-          - Integration requirements with existing codebase validated with user
-          - Key technical decisions based on real project constraints
-          - Existing system compatibility requirements with specific verification steps
-          - Clear sequencing of implementation to minimize risk to existing functionality
-==================== END: .bmad-core/templates/brownfield-architecture-tmpl.yaml ====================
+    instruction: Before running the checklist, offer to output the full architecture document. Once user confirms, execute the architect-checklist and populate results here.
+==================== END: .bmad-core/templates/fullstack-architecture-tmpl.yaml ====================
 
 ==================== START: .bmad-core/checklists/architect-checklist.md ====================
 # Architect Solution Validation Checklist
@@ -3496,33 +3509,28 @@ Ask the user if they want to work through the checklist:
 Now that you've completed the checklist, generate a comprehensive validation report that includes:
 
 1. Executive Summary
-
    - Overall architecture readiness (High/Medium/Low)
    - Critical risks identified
    - Key strengths of the architecture
    - Project type (Full-stack/Frontend/Backend) and sections evaluated
 
 2. Section Analysis
-
    - Pass rate for each major section (percentage of items passed)
    - Most concerning failures or gaps
    - Sections requiring immediate attention
    - Note any sections skipped due to project type
 
 3. Risk Assessment
-
    - Top 5 risks by severity
    - Mitigation recommendations for each
    - Timeline impact of addressing issues
 
 4. Recommendations
-
    - Must-fix items before development
    - Should-fix items for better quality
    - Nice-to-have improvements
 
 5. AI Implementation Readiness
-
    - Specific concerns for AI agent implementation
    - Areas needing additional clarification
    - Complexity hotspots to address