BMAD-METHOD/web-build-sample/tasks.txt

==================== START: advanced-elicitation ====================
# Advanced Elicitation Task

## Purpose

- Provide optional reflective and brainstorming actions to enhance content quality
- Enable deeper exploration of ideas through structured elicitation techniques
- Support iterative refinement through multiple analytical perspectives

## Task Instructions

### 1. Ask for review and Present Action List

[[LLM: Ask the user to review the {drafted document section, or context or document this protocol was executed from}. In the SAME message, inform them that they can suggest additions, removals, or modifications, OR they can select an action by number from the 'Advanced Reflective, Elicitation & Brainstorming Actions'. Then, present ONLY the numbered list (0-9) of these actions as defined in tasks#advanced-elicitation. Conclude by stating that selecting 9 will proceed to the next section. Await user selection. If an elicitation action (0-8) is chosen, execute it and then re-offer this combined review/elicitation choice. If option 9 is chosen, or if the user provides direct feedback on requirements, proceed accordingly.]]

**Present the numbered list (0-9) with this exact format:**

```
**Advanced Reflective, Elicitation & Brainstorming Actions**
Choose an action (0-9 - 9 to bypass - HELP for explanation of these options):

0. Expand or Contract for Audience
1. Explain Reasoning (CoT Step-by-Step)
2. Critique and Refine
3. Analyze Logical Flow and Dependencies
4. Assess Alignment with Overall Goals
5. Identify Potential Risks and Unforeseen Issues
6. Challenge from Critical Perspective (Self or Other Persona)
7. Explore Diverse Alternatives (ToT-Inspired)
8. Hindsight is 20/20: The 'If Only...' Reflection
9. Proceed / No Further Actions
```

### 2. Processing Guidelines

**Do NOT show:**

- The full protocol text with `[[LLM: ...]]` instructions
- Detailed explanations of each option unless executing or the user asks, when giving the definition you can modify to tie its relevance
- Any internal template markup

**After user selection from the list:**

- Execute the chosen action according to the protocol instructions below
- Ask if they want to select another action or proceed with option 9 once complete
- Continue until user selects option 9 or indicates completion

## Action Definitions

0. Expand or Contract for Audience
   [[LLM: Ask the user whether they want to 'expand' on the content (add more detail, elaborate) or 'contract' it (simplify, clarify, make more concise). Also, ask if there's a specific target audience they have in mind. Once clarified, perform the expansion or contraction from your current role's perspective, tailored to the specified audience if provided.]]

1. Explain Reasoning (CoT Step-by-Step)
   [[LLM: Explain the step-by-step thinking process, characteristic of your role, that you used to arrive at the current proposal for this content.]]

2. Critique and Refine
   [[LLM: From your current role's perspective, review your last output or the current section for flaws, inconsistencies, or areas for improvement, and then suggest a refined version reflecting your expertise.]]

3. Analyze Logical Flow and Dependencies
   [[LLM: From your role's standpoint, examine the content's structure for logical progression, internal consistency, and any relevant dependencies. Confirm if elements are presented in an effective order.]]

4. Assess Alignment with Overall Goals
   [[LLM: Evaluate how well the current content contributes to the stated overall goals of the document, interpreting this from your specific role's perspective and identifying any misalignments you perceive.]]

5. Identify Potential Risks and Unforeseen Issues
   [[LLM: Based on your role's expertise, brainstorm potential risks, overlooked edge cases, or unintended consequences related to the current content or proposal.]]

6. Challenge from Critical Perspective (Self or Other Persona)
   [[LLM: Adopt a critical perspective on the current content. If the user specifies another role or persona (e.g., 'as a customer', 'as [Another Persona Name]'), critique the content or play devil's advocate from that specified viewpoint. If no other role is specified, play devil's advocate from your own current persona's viewpoint, arguing against the proposal or current content and highlighting weaknesses or counterarguments specific to your concerns. This can also randomly include YAGNI when appropriate, such as when trimming the scope of an MVP, the perspective might challenge the need for something to cut MVP scope.]]

7. Explore Diverse Alternatives (ToT-Inspired)
   [[LLM: From your role's perspective, first broadly brainstorm a range of diverse approaches or solutions to the current topic. Then, from this wider exploration, select and present 2 distinct alternatives, detailing the pros, cons, and potential implications you foresee for each.]]

8. Hindsight is 20/20: The 'If Only...' Reflection
   [[LLM: In your current persona, imagine it's a retrospective for a project based on the current content. What's the one 'if only we had known/done X...' that your role would humorously or dramatically highlight, along with the imagined consequences?]]

9. Proceed / No Further Actions
   [[LLM: Acknowledge the user's choice to finalize the current work, accept the AI's last output as is, or move on to the next step without selecting another action from this list. Prepare to proceed accordingly.]]

==================== END: advanced-elicitation ====================


==================== START: checklist-mappings ====================
architect-checklist:
  checklist_file: docs/checklists/architect-checklist.md
  required_docs:
    - architecture.md
  default_locations:
    - docs/architecture.md

platform-engineer-checklist:
  checklist_file: docs/checklists/infrastructure-checklist.md
  required_docs:
    - platform-architecture.md
  default_locations:
    - docs/platform-architecture.md

frontend-architecture-checklist:
  checklist_file: docs/checklists/frontend-architecture-checklist.md
  required_docs:
    - frontend-architecture.md
  default_locations:
    - docs/frontend-architecture.md
    - docs/fe-architecture.md

pm-checklist:
  checklist_file: docs/checklists/pm-checklist.md
  required_docs:
    - prd.md
  default_locations:
    - docs/prd.md

po-master-checklist:
  checklist_file: docs/checklists/po-master-checklist.md
  required_docs:
    - prd.md
    - architecture.md
  optional_docs:
    - frontend-architecture.md
  default_locations:
    - docs/prd.md
    - docs/frontend-architecture.md
    - docs/architecture.md

story-draft-checklist:
  checklist_file: docs/checklists/story-draft-checklist.md
  required_docs:
    - story.md
  default_locations:
    - docs/stories/*.md

story-dod-checklist:
  checklist_file: docs/checklists/story-dod-checklist.md
  required_docs:
    - story.md
  default_locations:
    - docs/stories/*.md


==================== END: checklist-mappings ====================


==================== START: checklist-run-task ====================
# Checklist Validation Task

This task provides instructions for validating documentation against checklists. The agent should follow these instructions to ensure thorough and systematic validation of documents.

## Context

The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. The mapping between checklists and their required documents is defined in `checklist-mappings`. This allows for easy addition of new checklists without modifying this task.

## Instructions

1. **Initial Assessment**

   - Check `checklist-mappings` for available checklists
   - If user provides a checklist name:
     - Look for exact match in checklist-mappings.yml
     - If no exact match, try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
     - If multiple matches found, ask user to clarify
     - Once matched, use the checklist_file path from the mapping
   - If no checklist specified:
     - Ask the user which checklist they want to use
     - Present available options from checklist-mappings.yml
   - Confirm if they want to work through the checklist:
     - Section by section (interactive mode)
     - All at once (YOLO mode)

2. **Document Location**

   - Look up the required documents and default locations in `checklist-mappings`
   - For each required document:
     - Check all default locations specified in the mapping
     - If not found, ask the user for the document location
   - Verify all required documents are accessible

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
     - Check each item against the relevant documentation
     - Present findings for that section
     - Get user confirmation before proceeding to next section

   If in YOLO mode:

   - Process all sections at once
   - Create a comprehensive report of all findings
   - Present the complete analysis to the user

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
   - Mark items as:
     - ✅ PASS: Requirement clearly met
     - ❌ FAIL: Requirement not met or insufficient coverage
     - ⚠️ PARTIAL: Some aspects covered but needs improvement
     - N/A: Not applicable to this case

5. **Section Analysis**

   For each section:

   - Calculate pass rate
   - Identify common themes in failed items
   - Provide specific recommendations for improvement
   - In interactive mode, discuss findings with user
   - Document any user decisions or explanations

6. **Final Report**

   Prepare a summary that includes:

   - Overall checklist completion status
   - Pass rates by section
   - List of failed items with context
   - Specific recommendations for improvement
   - Any sections or items marked as N/A with justification

## Special Considerations

1. **Architecture Checklist**

   - Focus on technical completeness and clarity
   - Verify all system components are addressed
   - Check for security and scalability considerations
   - Ensure deployment and operational aspects are covered

2. **Frontend Architecture Checklist**

   - Validate UI/UX specifications
   - Check component structure and organization
   - Verify state management approach
   - Ensure responsive design considerations

3. **PM Checklist**

   - Focus on product requirements clarity
   - Verify user stories and acceptance criteria
   - Check market and user research coverage
   - Ensure technical feasibility is addressed

4. **Story Checklists**
   - Verify clear acceptance criteria
   - Check for technical context and dependencies
   - Ensure testability is addressed
   - Validate user value is clearly stated

## Success Criteria

The checklist validation is complete when:

1. All applicable items have been assessed
2. Clear pass/fail status for each item
3. Specific recommendations provided for failed items
4. User has reviewed and acknowledged findings
5. Final report documents all decisions and rationales

## Example Interaction

Agent: "Let me check the available checklists... According to checklist-mappings.yml, we have several options. Which would you like to use?"

User: "The architect checklist"

Agent: "Would you like to work through it section by section (interactive) or get a complete analysis all at once (YOLO mode)?"

User: "Interactive please"

Agent: "According to the mappings, I need to check for architecture.md. The default location is docs/architecture.md. Should I look there?"

[Continue interaction based on user responses...]

==================== END: checklist-run-task ====================


==================== START: core-dump ====================
# Core Dump Task

## Purpose

To create a concise memory recording file (`.ai/core-dump-n.md`) that captures the essential context of the current agent session, enabling seamless continuation of work in future agent sessions. This task ensures persistent context across agent conversations while maintaining minimal token usage for efficient context loading.

## Inputs for this Task

- Current session conversation history and accomplishments
- Files created, modified, or deleted during the session
- Key decisions made and procedures followed
- Current project state and next logical steps
- User requests and agent responses that shaped the session

## Task Execution Instructions

### 0. Check Existing Core Dump

Before proceeding, check if `.ai/core-dump.md` already exists:

- If file exists, ask user: "Core dump file exists. Should I: 1. Overwrite, 2. Update, 3. Append or 4. Create new?"
- **Overwrite**: Replace entire file with new content
- **Update**: Merge new session info with existing content, updating relevant sections
- **Append**: Add new session as a separate entry while preserving existing content
- **Create New**: Create a new file, appending the next possible -# to the file, such as core-dump-3.md if 1 and 2 already exist.
- If file doesn't exist, proceed with creation of `core-dump-1.md`

### 1. Analyze Session Context

- Review the entire conversation to identify key accomplishments
- Note any specific tasks, procedures, or workflows that were executed
- Identify important decisions made or problems solved
- Capture the user's working style and preferences observed during the session

### 2. Document What Was Accomplished

- **Primary Actions**: List the main tasks completed concisely
- **Story Progress**: For story work, use format "Tasks Complete: 1-6, 8. Next Task Pending: 7, 9"
- **Problem Solving**: Document any challenges encountered and how they were resolved
- **User Communications**: Summarize key user requests, preferences, and discussion points

### 3. Record File System Changes (Concise Format)

- **Files Created**: `filename.ext` (brief purpose/size)
- **Files Modified**: `filename.ext` (what changed)
- **Files Deleted**: `filename.ext` (why removed)
- Focus on essential details, avoid verbose descriptions

### 4. Capture Current Project State

- **Project Progress**: Where the project stands after this session
- **Current Issues**: Any blockers or problems that need resolution
- **Next Logical Steps**: What would be the natural next actions to take

### 5. Create/Update Core Dump File

Based on user's choice from step 0, handle the file accordingly:

### 6. Optimize for Minimal Context

- Keep descriptions concise but informative
- Use abbreviated formats where possible (file sizes, task numbers)
- Focus on actionable information rather than detailed explanations
- Avoid redundant information that can be found in project documentation
- Prioritize information that would be lost without this recording
- Ensure the file can be quickly scanned and understood

### 7. Validate Completeness

- Verify all significant session activities are captured
- Ensure a future agent could understand the current state
- Check that file changes are accurately recorded
- Confirm next steps are clear and actionable
- Verify user communication style and preferences are noted

==================== END: core-dump ====================


==================== START: correct-course ====================
# Correct Course Task

## Purpose

- Guide a structured response to a change trigger using the `change-checklist`.
- Analyze the impacts of the change on epics, project artifacts, and the MVP, guided by the checklist's structure.
- Explore potential solutions (e.g., adjust scope, rollback elements, rescope features) as prompted by the checklist.
- Draft specific, actionable proposed updates to any affected project artifacts (e.g., epics, user stories, PRD sections, architecture document sections) based on the analysis.
- Produce a consolidated "Sprint Change Proposal" document that contains the impact analysis and the clearly drafted proposed edits for user review and approval.
- Ensure a clear handoff path if the nature of the changes necessitates fundamental replanning by other core agents (like PM or Architect).

## Instructions

### 1. Initial Setup & Mode Selection

- **Acknowledge Task & Inputs:**
  - Confirm with the user that the "Correct Course Task" (Change Navigation & Integration) is being initiated.
  - Verify the change trigger and ensure you have the user's initial explanation of the issue and its perceived impact.
  - Confirm access to all relevant project artifacts (e.g., PRD, Epics/Stories, Architecture Documents, UI/UX Specifications) and, critically, the `change-checklist` (e.g., `change-checklist`).
- **Establish Interaction Mode:**
  - Ask the user their preferred interaction mode for this task:
    - **"Incrementally (Default & Recommended):** Shall we work through the `change-checklist` section by section, discussing findings and collaboratively drafting proposed changes for each relevant part before moving to the next? This allows for detailed, step-by-step refinement."
    - **"YOLO Mode (Batch Processing):** Or, would you prefer I conduct a more batched analysis based on the checklist and then present a consolidated set of findings and proposed changes for a broader review? This can be quicker for initial assessment but might require more extensive review of the combined proposals."
  - Request the user to select their preferred mode.
  - Once the user chooses, confirm the selected mode (e.g., "Okay, we will proceed in Incremental mode."). This chosen mode will govern how subsequent steps in this task are executed.
- **Explain Process:** Briefly inform the user: "We will now use the `change-checklist` to analyze the change and draft proposed updates. I will guide you through the checklist items based on our chosen interaction mode."
  <rule>When asking multiple questions or presenting multiple points for user input at once, number them clearly (e.g., 1., 2a., 2b.) to make it easier for the user to provide specific responses.</rule>

### 2. Execute Checklist Analysis (Iteratively or Batched, per Interaction Mode)

- Systematically work through Sections 1-4 of the `change-checklist` (typically covering Change Context, Epic/Story Impact Analysis, Artifact Conflict Resolution, and Path Evaluation/Recommendation).
- For each checklist item or logical group of items (depending on interaction mode):
  - Present the relevant prompt(s) or considerations from the checklist to the user.
  - Request necessary information and actively analyze the relevant project artifacts (PRD, epics, architecture documents, story history, etc.) to assess the impact.
  - Discuss your findings for each item with the user.
  - Record the status of each checklist item (e.g., `[x] Addressed`, `[N/A]`, `[!] Further Action Needed`) and any pertinent notes or decisions.
  - Collaboratively agree on the "Recommended Path Forward" as prompted by Section 4 of the checklist.

### 3. Draft Proposed Changes (Iteratively or Batched)

- Based on the completed checklist analysis (Sections 1-4) and the agreed "Recommended Path Forward" (excluding scenarios requiring fundamental replans that would necessitate immediate handoff to PM/Architect):
  - Identify the specific project artifacts that require updates (e.g., specific epics, user stories, PRD sections, architecture document components, diagrams).
  - **Draft the proposed changes directly and explicitly for each identified artifact.** Examples include:
    - Revising user story text, acceptance criteria, or priority.
    - Adding, removing, reordering, or splitting user stories within epics.
    - Proposing modified architecture diagram snippets (e.g., providing an updated Mermaid diagram block or a clear textual description of the change to an existing diagram).
    - Updating technology lists, configuration details, or specific sections within the PRD or architecture documents.
    - Drafting new, small supporting artifacts if necessary (e.g., a brief addendum for a specific decision).
  - If in "Incremental Mode," discuss and refine these proposed edits for each artifact or small group of related artifacts with the user as they are drafted.
  - If in "YOLO Mode," compile all drafted edits for presentation in the next step.

### 4. Generate "Sprint Change Proposal" with Edits

- Synthesize the complete `change-checklist` analysis (covering findings from Sections 1-4) and all the agreed-upon proposed edits (from Instruction 3) into a single document titled "Sprint Change Proposal." This proposal should align with the structure suggested by Section 5 of the `change-checklist` (Proposal Components).
- The proposal must clearly present:
  - **Analysis Summary:** A concise overview of the original issue, its analyzed impact (on epics, artifacts, MVP scope), and the rationale for the chosen path forward.
  - **Specific Proposed Edits:** For each affected artifact, clearly show or describe the exact changes (e.g., "Change Story X.Y from: [old text] To: [new text]", "Add new Acceptance Criterion to Story A.B: [new AC]", "Update Section 3.2 of Architecture Document as follows: [new/modified text or diagram description]").
- Present the complete draft of the "Sprint Change Proposal" to the user for final review and feedback. Incorporate any final adjustments requested by the user.

### 5. Finalize & Determine Next Steps

- Obtain explicit user approval for the "Sprint Change Proposal," including all the specific edits documented within it.
- Provide the finalized "Sprint Change Proposal" document to the user.
- **Based on the nature of the approved changes:**
  - **If the approved edits sufficiently address the change and can be implemented directly or organized by a PO/SM:** State that the "Correct Course Task" is complete regarding analysis and change proposal, and the user can now proceed with implementing or logging these changes (e.g., updating actual project documents, backlog items). Suggest handoff to a PO/SM agent for backlog organization if appropriate.
  - **If the analysis and proposed path (as per checklist Section 4 and potentially Section 6) indicate that the change requires a more fundamental replan (e.g., significant scope change, major architectural rework):** Clearly state this conclusion. Advise the user that the next step involves engaging the primary PM or Architect agents, using the "Sprint Change Proposal" as critical input and context for that deeper replanning effort.

## Output Deliverables

- **Primary:** A "Sprint Change Proposal" document (in markdown format). This document will contain:
  - A summary of the `change-checklist` analysis (issue, impact, rationale for the chosen path).
  - Specific, clearly drafted proposed edits for all affected project artifacts.
- **Implicit:** An annotated `change-checklist` (or the record of its completion) reflecting the discussions, findings, and decisions made during the process.

==================== END: correct-course ====================


==================== START: create-ai-frontend-prompt ====================
# Create AI Frontend Prompt Task

## Purpose

To generate a masterful, comprehensive, and optimized prompt that can be used with AI-driven frontend development tools (e.g., Lovable, Vercel v0, or similar) to scaffold or generate significant portions of the frontend application.

## Inputs

- Completed UI/UX Specification (`front-end-spec-tmpl`)
- Completed Frontend Architecture Document (`front-end-architecture`)
- Main System Architecture Document (`architecture` - for API contracts and tech stack)
- Primary Design Files (Figma, Sketch, etc. - for visual context if the tool can accept it or if descriptions are needed)

## Key Activities & Instructions

1. **Confirm Target AI Generation Platform:**

    - Ask the user to specify which AI frontend generation tool/platform they intend to use (e.g., "Lovable.ai", "Vercel v0", "GPT-4 with direct code generation instructions", etc.).
    - Explain that prompt optimization might differ slightly based on the platform's capabilities and preferred input format.

2. **Synthesize Inputs into a Structured Prompt:**

    - **Overall Project Context:**
      - Briefly state the project's purpose (from brief/PRD).
      - Specify the chosen frontend framework, core libraries, and UI component library (from `front-end-architecture` and main `architecture`).
      - Mention the styling approach (e.g., Tailwind CSS, CSS Modules).
    - **Design System & Visuals:**
      - Reference the primary design files (e.g., Figma link).
      - If the tool doesn't directly ingest design files, describe the overall visual style, color palette, typography, and key branding elements (from `front-end-spec-tmpl`).
      - List any global UI components or design tokens that should be defined or adhered to.
    - **Application Structure & Routing:**
      - Describe the main pages/views and their routes (from `front-end-architecture` - Routing Strategy).
      - Outline the navigation structure (from `front-end-spec-tmpl`).
    - **Key User Flows & Page-Level Interactions:**
      - For a few critical user flows (from `front-end-spec-tmpl`):
        - Describe the sequence of user actions and expected UI changes on each relevant page.
        - Specify API calls to be made (referencing API endpoints from the main `architecture`) and how data should be displayed or used.
    - **Component Generation Instructions (Iterative or Key Components):**
      - Based on the chosen AI tool's capabilities, decide on a strategy:
        - **Option 1 (Scaffolding):** Prompt for the generation of main page structures, layouts, and placeholders for components.
        - **Option 2 (Key Component Generation):** Select a few critical or complex components from the `front-end-architecture` (Component Breakdown) and provide detailed specifications for them (props, state, basic behavior, key UI elements).
        - **Option 3 (Holistic, if tool supports):** Attempt to describe the entire application structure and key components more broadly.
      - <important_note>Advise the user that generating an entire complex application perfectly in one go is rare. Iterative prompting or focusing on sections/key components is often more effective.</important_note>
    - **State Management (High-Level Pointers):**
      - Mention the chosen state management solution (e.g., "Use Redux Toolkit").
      - For key pieces of data, indicate if they should be managed in global state.
    - **API Integration Points:**
      - For pages/components that fetch or submit data, clearly state the relevant API endpoints (from `architecture`) and the expected data shapes (can reference schemas in `data-models` or `api-reference` sections of the architecture doc).
    - **Critical "Don'ts" or Constraints:**
      - e.g., "Do not use deprecated libraries." "Ensure all forms have basic client-side validation."
    - **Platform-Specific Optimizations:**
      - If the chosen AI tool has known best practices for prompting (e.g., specific keywords, structure, level of detail), incorporate them. (This might require the agent to have some general knowledge or to ask the user if they know any such specific prompt modifiers for their chosen tool).

3. **Present and Refine the Master Prompt:**
    - Output the generated prompt in a clear, copy-pasteable format (e.g., a large code block).
    - Explain the structure of the prompt and why certain information was included.
    - Work with the user to refine the prompt based on their knowledge of the target AI tool and any specific nuances they want to emphasize.
    - <important_note>Remind the user that the generated code from the AI tool will likely require review, testing, and further refinement by developers.</important_note>

==================== END: create-ai-frontend-prompt ====================


==================== START: create-architecture ====================
# Architecture Creation Task

## Purpose

- To design a complete, robust, and well-documented technical architecture based on the project requirements (PRD, epics, brief), research findings, and user input.
- To make definitive technology choices and articulate the rationale behind them, leveraging the architecture template as a structural guide.
- To produce all necessary technical artifacts, ensuring the architecture is optimized for efficient implementation, particularly by AI developer agents, and validated against the `architect-checklist`.

## Instructions

1. **Input Analysis & Dialogue Establishment:**

    - Ensure you have all necessary inputs: PRD document (specifically checking for the 'Technical Assumptions' and 'Initial Architect Prompt' sections for the decided repository and service architecture), project brief, any deep research reports, and optionally a `technical-preferences.md`. Request any missing critical documents.
    - Thoroughly review all inputs.
    - Summarize key technical requirements, constraints, NFRs (Non-Functional Requirements), and the decided repository/service architecture derived from the inputs. Present this summary to the user for confirmation and to ensure mutual understanding.
    - Share initial architectural observations, potential challenges, or areas needing clarification based on the inputs.
      **Establish Interaction Mode for Architecture Creation:**
      - Ask the user: "How would you like to proceed with creating the architecture for this project? We can work:
        A. **Incrementally (Default & Recommended):** We'll go through each architectural decision, document section, or design point step-by-step. I'll present drafts, and we'll seek your feedback and confirmation before moving to the next part. This is best for complex decisions and detailed refinement.
        B. **"YOLO" Mode:** I can produce a more comprehensive initial draft of the architecture (or significant portions) for you to review more broadly first. We can then iterate on specific sections based on your feedback. This can be quicker for generating initial ideas but is generally not recommended if detailed collaboration at each step is preferred."
      - Request the user to select their preferred mode (e.g., "Please let me know if you'd prefer A or B.").
      - Once the user chooses, confirm the selected mode (e.g., "Okay, we will proceed in Incremental mode."). This chosen mode will govern how subsequent steps in this task are executed.

2. **Resolve Ambiguities & Gather Missing Information:**

    - If key information is missing or requirements are unclear after initial review, formulate specific, targeted questions.
    - **External API Details:** If the project involves integration with external APIs, especially those that are less common or where you lack high confidence in your training data regarding their specific request/response schemas, and if a "Deep Research" phase was not conducted for these APIs:
      - Proactively ask the user to provide precise details. This includes:
        - Links to the official API documentation.
        - Example request structures (e.g., cURL commands, JSON payloads).
        - Example response structures (e.g., JSON responses for typical scenarios, including error responses).
      - Explain that this information is crucial for accurately defining API interaction contracts within the architecture, for creating robust facades/adapters, and for enabling accurate technical planning (e.g., for technical stories or epic refinements).
    - Present questions to the user (batched logically if multiple) and await their input.
    - Document all decisions and clarifications received before proceeding.

3. **Iterative Technology Selection & Design (Interactive, if not YOLO mode):**

    - For each major architectural component or decision point (e.g., frontend framework, backend language/framework, database system, cloud provider, key services, communication patterns):
      - If multiple viable options exist based on requirements or research, present 2-3 choices, briefly outlining their pros, cons, and relevance to the project. Consider any preferences stated in `technical-preferences.md` when formulating these options and your recommendation.
      - State your recommended choice, providing a clear rationale based on requirements, research findings, user preferences (if known), and best practices (e.g., scalability, cost, team familiarity, ecosystem).
      - Ask for user feedback, address concerns, and seek explicit approval before finalizing the decision.
      - Document the confirmed choice and its rationale within the architecture document.
    - **Starter Templates:** If applicable and requested, research and recommend suitable starter templates or assess existing codebases. Explain alignment with project goals and seek user confirmation.

4. **Create Technical Artifacts (Incrementally, unless YOLO mode, guided by `architecture-tmpl`):**

    - For each artifact or section of the main Architecture Document:

      - **Explain Purpose:** Briefly describe the artifact/section's importance and what it will cover.
      - **Draft Section-by-Section:** Present a draft of one logical section at a time.
        - Ensure the 'High-Level Overview' and 'Component View' sections accurately reflect and detail the repository/service architecture decided in the PRD.
        - Ensure that documented Coding Standards (either as a dedicated section or referenced) and the 'Testing Strategy' section clearly define:
          - The convention for unit test file location (e.g., co-located with source files, or in a separate folder like `tests/` or `__tests__/`).
          - The naming convention for unit test files (e.g., `*.test.js`, `*.spec.ts`, `test_*.py`).
        - When discussing Coding Standards, inform the user that these will serve as firm rules for the AI developer agent. Emphasize that these standards should be kept to the minimum necessary to prevent undesirable or messy code from the agent. Guide the user to understand that overly prescriptive or obvious standards (e.g., "use SOLID principles," which well-trained LLMs should already know) should be avoided, as the user, knowing the specific agents and tools they will employ, can best judge the appropriate level of detail.
        - **Incorporate Feedback:** Discuss the draft with the user, incorporate their feedback, and iterate as needed.
        - [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)
        - **Seek Approval:** Obtain explicit user approval for the section before moving to the next, or for the entire artifact if drafted holistically (in YOLO mode).

5. **Identify Missing Technical Stories / Refine Epics (Interactive):**

    - Based on the designed architecture, identify any necessary technical stories/tasks that are not yet captured in the PRD or epics (e.g., "Set up CI/CD pipeline for frontend deployment," "Implement authentication module using JWT," "Create base Docker images for backend services," "Configure initial database schema based on data models").
    - Explain the importance of these technical stories for enabling the functional requirements and successful project execution.
    - Collaborate with the user to refine these stories (clear description, acceptance criteria) and suggest adding them to the project backlog or relevant epics.
    - Review existing epics/stories from the PRD and suggest technical considerations or acceptance criteria refinements to ensure they are implementable based on the chosen architecture. For example, specifying API endpoints to be called, data formats, or critical library versions.
    - After collaboration, prepare a concise summary detailing all proposed additions, updates, or modifications to epics and user stories. If no changes are identified, explicitly state this.

6. **Validate Architecture Against Checklist & Finalize Output:**
    - Once the main architecture document components have been drafted and reviewed with the user, perform a comprehensive review using the `architect-checklist`.
    - Go through each item in the checklist to ensure the architecture document is comprehensive, addresses all key architectural concerns (e.g., security, scalability, maintainability, testability (including confirmation that coding standards and the testing strategy clearly define unit test location and naming conventions), developer experience), and that proposed solutions are robust.
    - For each checklist item, confirm its status (e.g., \[x] Completed, \[ ] N/A, \[!] Needs Attention).
    - If deficiencies, gaps, or areas needing more detail or clarification are identified based on the checklist:
      - Discuss these findings with the user.
      - Collaboratively make necessary updates, additions, or refinements to the architecture document to address these points.
    - After addressing all checklist points and ensuring the architecture document is robust and complete, present a summary of the checklist review to the user. This summary should highlight:
      - Confirmation that all relevant sections/items of the checklist have been satisfied by the architecture.
      - Any items marked N/A, with a brief justification.
      - A brief note on any significant discussions, decisions, or changes made to the architecture document as a result of the checklist review.
    - **Offer Design Architect Prompt (If Applicable):**
      - If the architecture includes UI components, ask the user if they would like to include a dedicated prompt for a "Design Architect" at the end of the main architecture document.
      - Explain that this prompt can capture specific UI considerations, notes from discussions, or decisions that don't fit into the core technical architecture document but are crucial for the Design Architect.
      - The prompt should also state that the Design Architect will subsequently operate in its specialized mode to define the detailed frontend architecture.
      - If the user agrees, collaboratively draft this prompt and append it to the architecture document.
    - Obtain final user approval for the complete architecture documentation generation.
    - **Recommend Next Steps for UI (If Applicable):**
      - After the main architecture document is finalized and approved:
      - If the project involves a user interface (as should be evident from the input PRD and potentially the architecture document itself mentioning UI components or referencing outputs from a Design Architect's UI/UX Specification phase):
        - Strongly recommend to the user that the next critical step for the UI is to engage the **Design Architect** agent.
        - Specifically, advise them to use the Design Architect's **'Frontend Architecture Mode'**.
        - Explain that the Design Architect will use the now-completed main Architecture Document and the detailed UI/UX specifications (e.g., `front-end-spec-tmpl.txt` or enriched PRD) as primary inputs to define the specific frontend architecture, select frontend libraries/frameworks (if not already decided), structure frontend components, and detail interaction patterns.

### Output Deliverables for Architecture Creation Phase

- A comprehensive Architecture Document, structured according to the `architecture-tmpl` (which is all markdown) or an agreed-upon format, including all sections detailed above.
- Clear Mermaid diagrams for architecture overview, data models, etc.
- A list of new or refined technical user stories/tasks ready for backlog integration.
- A summary of any identified changes (additions, updates, modifications) required for existing epics or user stories, or an explicit confirmation if no such changes are needed.
- A completed `architect-checklist` (or a summary of its validation).
- Optionally, if UI components are involved and the user agrees: A prompt for a "Design Architect" appended to the main architecture document, summarizing relevant UI considerations and outlining the Design Architect's next steps.

## Offer Advanced Self-Refinement & Elicitation Options

(This section is called when needed prior to this)

Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.

"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):

**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**

{Instruction for AI Agent: Display the title of each numbered item below. If the user asks what a specific option means, provide a brief explanation of the action you will take, drawing from detailed descriptions tailored for the context.}

1. **Critical Self-Review & User Goal Alignment**
2. **Generate & Evaluate Alternative Design Solutions**
3. **User Journey & Interaction Stress Test (Conceptual)**
4. **Deep Dive into Design Assumptions & Constraints**
5. **Usability & Accessibility Audit Review & Probing Questions**
6. **Collaborative Ideation & UI Feature Brainstorming**
7. **Elicit 'Unforeseen User Needs' & Future Interaction Questions**
8. **Finalize this Section and Proceed.**

After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."

REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNIT the user indicates it is time to proceed ot the next section (or selects #8)

==================== END: create-architecture ====================


==================== START: create-deep-research-prompt ====================
# Deep Research Phase

Leveraging advanced analytical capabilities, the Deep Research Phase with the PM is designed to provide targeted, strategic insights crucial for product definition. Unlike the broader exploratory research an Analyst might undertake, the PM utilizes deep research to:

- **Validate Product Hypotheses:** Rigorously test assumptions about market need, user problems, and the viability of specific product concepts.
- **Refine Target Audience & Value Proposition:** Gain a nuanced understanding of specific user segments, their precise pain points, and how the proposed product delivers unique value to them.
- **Focused Competitive Analysis:** Analyze competitors through the lens of a specific product idea to identify differentiation opportunities, feature gaps to exploit, and potential market positioning challenges.
- **De-risk PRD Commitments:** Ensure that the problem, proposed solution, and core features are well-understood and validated _before_ detailed planning and resource allocation in the PRD Generation Mode.

Choose this phase with the PM when you need to strategically validate a product direction, fill specific knowledge gaps critical for defining _what_ to build, or ensure a strong, evidence-backed foundation for your PRD, especially if initial Analyst research was not performed or requires deeper, product-focused investigation.

## Purpose

- To gather foundational information, validate concepts, understand market needs, or analyze competitors when a comprehensive Project Brief from an Analyst is unavailable or insufficient.
- To ensure the PM has a solid, data-informed basis for defining a valuable and viable product before committing to PRD specifics.
- To de-risk product decisions by grounding them in targeted research, especially if the user is engaging the PM directly without prior Analyst work or if the initial brief lacks necessary depth.

## Instructions

<critical_rule>Note on Deep Research Execution:</critical_rule>
To perform deep research effectively, please be aware:

- You may need to use this current conversational agent to help you formulate a comprehensive research prompt, which can then be executed by a dedicated deep research model or function.
- Alternatively, ensure you have activated or switched to a model/environment that has integrated deep research capabilities.
  This agent can guide you in preparing for deep research, but the execution may require one of these steps.

1. **Assess Inputs & Identify Gaps:**
    - Review any existing inputs (user's initial idea, high-level requirements, partial brief from Analyst, etc.).
    - Clearly identify critical knowledge gaps concerning:
      - Target audience (needs, pain points, behaviors, key segments).
      - Market landscape (size, trends, opportunities, potential saturation).
      - Competitive analysis (key direct/indirect competitors, their offerings, strengths, weaknesses, market positioning, potential differentiators for this product).
      - Problem/Solution validation (evidence supporting the proposed solution's value and fit for the identified problem).
      - High-level technical or resource considerations (potential major roadblocks or dependencies).
2. **Formulate Research Plan:**
    - Define specific, actionable research questions to address the identified gaps.
    - Propose targeted research activities (e.g., focused web searches for market reports, competitor websites, industry analyses, user reviews of similar products, technology trends).
    - <important_note>Confirm this research plan, scope, and key questions with the user before proceeding with research execution.</important_note>
3. **Execute Research:**
    - Conduct the planned research activities systematically.
    - Prioritize gathering credible, relevant, and actionable insights that directly inform product definition and strategy.
4. **Synthesize & Present Findings:**
    - Organize and summarize key research findings in a clear, concise, and easily digestible manner (e.g., bullet points, brief summaries per research question).
    - Highlight the most critical implications for the product's vision, strategy, target audience, core features, and potential risks.
    - Present these synthesized findings and their implications to the user.
5. **Discussing and Utilizing Research Output:**
    - The comprehensive findings/report from this Deep Research phase can be substantial. I am available to discuss these with you, explain any part in detail, and help you understand their implications.
    - **Options for Utilizing These Findings for PRD Generation:**
      1. **Full Handoff to New PM Session:** The complete research output can serve as a foundational document if you initiate a _new_ session with a Product Manager (PM) agent who will then execute the 'PRD Generate Task'.
      2. **Key Insights Summary for This Session:** I can prepare a concise summary of the most critical findings, tailored to be directly actionable as we (in this current session) transition to potentially invoking the 'PRD Generate Task'.
    - <critical_rule>Regardless of how you proceed, it is highly recommended that these research findings (either the full output or the key insights summary) are provided as direct input when invoking the 'PRD Generate Task'. This ensures the PRD is built upon a solid, evidence-based foundation.</critical_rule>
6. **Confirm Readiness for PRD Generation:**
    - Discuss with the user whether the gathered information provides a sufficient and confident foundation to proceed to the 'PRD Generate Task'.
    - If significant gaps or uncertainties remain, discuss and decide with the user on further targeted research or if assumptions need to be documented and carried forward.
    - Once confirmed, clearly state that the next step could be to invoke the 'PRD Generate Task' or, if applicable, revisit other phase options.

==================== END: create-deep-research-prompt ====================


==================== START: create-doc-from-template ====================
# Create Document from Template Task

## Purpose

- Generate documents from any specified template following embedded instructions
- Support multiple document types through template-driven approach
- Enable any persona to create consistent, well-structured documents

## Instructions

### 1. Identify Template and Context

- Determine which template to use (user-provided or list available for selection to user)

  - agent-config specific agents will list what docs they have available under this task, for each item consider it a unique task. So if the user had for example:

    @{example}

  - tasks:

  - [Create Document](tasks#create-doc-from-template):

    - [Prd](templates#prd-tmpl)

    - [Architecture](templates#architecture-tmpl)

    @{/example}

    you would list `Create Document PRD` and `Create Document Architecture` as tasks the agent could perform.

- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
- Understand the document purpose and target audience

### 2. Determine Interaction Mode

Confirm with the user their preferred interaction style:

- **Incremental:** Work through chunks of the document.
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)

### 3. Execute Template

- Load specified template from `templates#*` or the /templates directory
- Follow ALL embedded LLM instructions within the template
- Process template markup according to `templates#template-format` conventions

### 4. Template Processing Rules

**CRITICAL: Never display template markup, LLM instructions, or examples to users**

- Replace all {{placeholders}} with actual content
- Execute all [[LLM: instructions]] internally
- Process <<REPEAT>> sections as needed
- Evaluate ^^CONDITION^^ blocks and include only if applicable
- Use @{examples} for guidance but never output them

### 5. Content Generation

- **Incremental Mode**: Present each major section for review before proceeding
- **YOLO Mode**: Generate all sections, then review complete document with user
- Apply any elicitation protocols specified in template
- Incorporate user feedback and iterate as needed

### 6. Validation

If template specifies a checklist:

- Run the appropriate checklist against completed document
- Document completion status for each item
- Address any deficiencies found
- Present validation summary to user

### 7. Final Presentation

- Present clean, formatted content only
- Ensure all sections are complete
- DO NOT truncate or summarize content
- Begin directly with document content (no preamble)
- Include any handoff prompts specified in template

## Key Resources

- **Template Format:** `templates#template-format`
- **Available Templates:** All files in `templates#` directory
- **Checklists:** As specified by template or persona
- **User Preferences:** `data#technical-preferences`

## Important Notes

- This task is template and persona agnostic
- All specific instructions are embedded in templates
- Focus on faithful template execution and clean output
- Template markup is for AI processing only - never expose to users

==================== END: create-doc-from-template ====================


==================== START: create-frontend-architecture ====================
# Create Frontend Architecture Task

## Purpose

To define the technical architecture for the frontend application. This includes selecting appropriate patterns, structuring the codebase, defining component strategy, planning state management, outlining API interactions, and setting up testing and deployment approaches, all while adhering to the guidelines in `front-end-architecture-tmpl` template.

## Inputs

- Product Requirements Document (PRD) (`prd-tmpl` or equivalent)
- Completed UI/UX Specification (`front-end-spec-tmpl` or equivalent)
- Main System Architecture Document (`architecture` or equivalent) - The agent executing this task should particularly note the overall system structure (Monorepo/Polyrepo, backend service architecture) detailed here, as it influences frontend patterns.
- Primary Design Files (Figma, Sketch, etc., linked from UI/UX Spec)

## Key Activities & Instructions

### 1. Confirm Interaction Mode

- Ask the user: "How would you like to proceed with creating the frontend architecture? We can work:
  A. **Incrementally (Default & Recommended):** We'll go through each architectural decision and document section step-by-step. I'll present drafts, and we'll seek your feedback and confirmation before moving to the next part. This is best for complex decisions and detailed refinement.
  B. **"YOLO" Mode:** I can produce a more comprehensive initial draft of the frontend architecture for you to review more broadly first. We can then iterate on specific sections based on your feedback. This can be quicker for generating initial ideas but is generally not recommended if detailed collaboration at each step is preferred."
- Request the user to select their preferred mode (e.g., "Please let me know if you'd prefer A or B.").
- Once the user chooses, confirm the selected mode (e.g., "Okay, we will proceed in Incremental mode."). This chosen mode will govern how subsequent steps are executed.

### 2. Review Inputs & Establish Context

- Thoroughly review the inputs, including the UI/UX Specification and the main Architecture Document (especially "Definitive Tech Stack Selections", API contracts, and the documented overall system structure like monorepo/polyrepo choices).
- Ask clarifying questions to bridge any gaps between the UI/UX vision and the overall system architecture.

### 3. Define Overall Frontend Philosophy & Patterns (for `front-end-architecture`)

- Based on the main architecture's tech stack and overall system structure (monorepo/polyrepo, backend service details), confirm and detail:
  - Framework & Core Libraries choices.
  - High-level Component Architecture strategy.
  - High-level State Management Strategy.
  - Data Flow principles.
  - Styling Approach.
  - Key Design Patterns to be employed.

### 4. Specify Detailed Frontend Directory Structure (for `front-end-architecture`)

- Collaboratively define or refine the frontend-specific directory structure, ensuring it aligns with the chosen framework and promotes modularity and scalability.

### 5. Outline Component Strategy & Conventions (for `front-end-architecture`)

- Define Component Naming & Organization conventions.
- Establish the "Template for Component Specification" (as per `front-end-architecture`), emphasizing that most components will be detailed emergently but must follow this template.
- Optionally, specify a few absolutely foundational/shared UI components (e.g., a generic Button or Modal wrapper if the chosen UI library needs one, or if no UI library is used).

### 6. Detail State Management Setup & Conventions (for `front-end-architecture`)

- Based on the high-level strategy, detail:
  - Chosen Solution and core setup.
  - Conventions for Store Structure / Slices (e.g., "feature-based slices"). Define any genuinely global/core slices (e.g., session/auth).
  - Conventions for Selectors and Actions/Reducers/Thunks. Provide templates or examples.

### 7. Plan API Interaction Layer (for `front-end-architecture`)

- Define the HTTP Client Setup.
- Establish patterns for Service Definitions (how API calls will be encapsulated).
- Outline frontend Error Handling & Retry strategies for API calls.

### 8. Define Routing Strategy (for `front-end-architecture`)

- Confirm the Routing Library.
- Collaboratively define the main Route Definitions and any Route Guards.

### 9. Specify Build, Bundling, and Deployment Details (for `front-end-architecture`)

- Outline the frontend-specific Build Process & Scripts.
- Discuss and document Key Bundling Optimizations.
- Confirm Deployment to CDN/Hosting details relevant to the frontend.

### 10. Refine Frontend Testing Strategy (for `front-end-architecture`)

- Elaborate on the main testing strategy with specifics for: Component Testing, UI Integration/Flow Testing, and E2E UI Testing scope and tools.

### 11. Outline Performance Considerations (for `front-end-architecture`)

- List key frontend-specific performance strategies to be employed.

### 12. Document Drafting & Confirmation (Guided by `front-end-architecture-tmpl`)

- **If "Incremental Mode" was selected:**

  - For each relevant section of the `front-end-architecture` (as outlined in steps 3-11 above, covering topics from Overall Philosophy to Performance Considerations):

    - **a. Explain Purpose & Draft Section:** Explain the purpose of the section and present a draft for that section.
    - **b. Initial Discussion & Feedback:** Discuss the draft with the user, incorporate their feedback, and iterate as needed for initial revisions.
    - **c. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**

    - **d. Final Approval & Documentation:** Obtain explicit user approval for the section. Ensure all placeholder links and references are correctly noted within each section. Then proceed to the next section.

  - Once all sections are individually approved through this process, confirm with the user that the overall `front-end-architecture` document is populated and ready for Step 13 (Epic/Story Impacts) and then the checklist review (Step 14).

- **If "YOLO Mode" was selected:**
  - Collaboratively populate all relevant sections of the `front-end-architecture-tmpl` (as outlined in steps 3-11 above) to create a comprehensive first draft.
  - Present the complete draft of `front-end-architecture` to the user for a holistic review.
  - <important_note>After presenting the full draft in YOLO mode, you MAY still offer a condensed version of the 'Advanced Reflective & Elicitation Options' menu, perhaps focused on a few key overarching review actions (e.g., overall requirements alignment, major risk assessment) if the user wishes to perform a structured deep dive before detailed section-by-section feedback.</important_note>
  - Obtain explicit user approval for the entire `front-end-architecture` document before proceeding to Step 13 (Epic/Story Impacts) and then the checklist review (Step 14).

### 13. Identify & Summarize Epic/Story Impacts (Frontend Focus)

- After the `front-end-architecture` is confirmed, review it in context of existing epics and user stories (if provided or known).
- Identify any frontend-specific technical tasks that might need to be added as new stories or sub-tasks (e.g., "Implement responsive layout for product details page based on defined breakpoints," "Set up X state management slice for user profile," "Develop reusable Y component as per specification").
- Identify if any existing user stories require refinement of their acceptance criteria due to frontend architectural decisions (e.g., specifying interaction details, component usage, or performance considerations for UI elements).
- Collaborate with the user to define these additions or refinements.
- Prepare a concise summary detailing all proposed additions, updates, or modifications to epics and user stories related to the frontend. If no changes are identified, explicitly state this (e.g., "No direct impacts on existing epics/stories were identified from the frontend architecture").

### 14. Checklist Review and Finalization

- Once the `front-end-architecture` has been populated and reviewed with the user, and epic/story impacts have been summarized, use the `frontend-architecture-checklist`.
- Go through each item in the checklist to ensure the `front-end-architecture` is comprehensive and all sections are adequately addressed - for each checklist item you MUST consider if it is really complete or deficient.
- For each checklist section, confirm its status (e.g., \[x] Completed, \[ ] N/A, \[!] Needs Attention).
- If deficiencies or areas needing more detail are identified with a section:
  - Discuss these with the user.
  - Collaboratively make necessary updates or additions to the `front-end-architecture`.
- After addressing all points and ensuring the document is robust, present a summary of the checklist review to the user. This summary should highlight:
  - Confirmation that all relevant sections of the checklist have been satisfied.
  - Any items marked N/A and a brief reason.
  - A brief note on any significant discussions or changes made as a result of the checklist review.
- The goal is to ensure the `front-end-architecture` is a complete and actionable document.

## Offer Advanced Self-Refinement & Elicitation Options

(This section is called when needed prior to this)

Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.

"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):

**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**

{Instruction for AI Agent: Display the title of each numbered item below. If the user asks what a specific option means, provide a brief explanation of the action you will take, drawing from detailed descriptions tailored for the context.}

1. **Critical Self-Review & User Goal Alignment**
2. **Generate & Evaluate Alternative Design Solutions**
3. **User Journey & Interaction Stress Test (Conceptual)**
4. **Deep Dive into Design Assumptions & Constraints**
5. **Usability & Accessibility Audit Review & Probing Questions**
6. **Collaborative Ideation & UI Feature Brainstorming**
7. **Elicit 'Unforeseen User Needs' & Future Interaction Questions**
8. **Finalize this Section and Proceed.**

After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."

REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNIT the user indicates it is time to proceed ot the next section (or selects #8)

==================== END: create-frontend-architecture ====================


==================== START: create-infrastructure-architecture ====================
# Infrastructure Architecture Creation Task

## Purpose

To design a comprehensive infrastructure architecture that defines all aspects of the technical infrastructure strategy, from cloud platform selection to deployment patterns. This architecture will serve as the definitive blueprint for the DevOps/Platform Engineering team to implement, ensuring consistency, security, and operational excellence across all infrastructure components.

## Inputs

- Product Requirements Document (PRD)
- Main System Architecture Document
- Technology Stack Document (`docs/tech-stack.md`)
- Infrastructure Guidelines (`docs/infrastructure/guidelines.md`)
- Any existing infrastructure documentation

## Key Activities & Instructions

### 1. Confirm Interaction Mode

- Ask the user: "How would you like to proceed with creating the infrastructure architecture? We can work:
  A. **Incrementally (Default & Recommended):** We'll go through each architectural decision and document section step-by-step. I'll present drafts, and we'll seek your feedback before moving to the next part. This is best for complex infrastructure designs.
  B. **"YOLO" Mode:** I can produce a comprehensive initial draft of the infrastructure architecture for you to review more broadly first. We can then iterate on specific sections based on your feedback."
- Request the user to select their preferred mode and proceed accordingly.

### 2. Gather Infrastructure Requirements

- Review the product requirements document to understand business needs and scale requirements
- Analyze the main system architecture to identify infrastructure dependencies
- Document non-functional requirements (performance, scalability, reliability, security)
- Identify compliance and regulatory requirements affecting infrastructure
- Map application architecture patterns to infrastructure needs
- <critical_rule>Cross-reference with PRD Technical Assumptions to ensure alignment with repository and service architecture decisions</critical_rule>

### 3. Design Infrastructure Architecture Strategy

- **If "Incremental Mode" was selected:**
  - For each major infrastructure domain:
    - **a. Present Domain Purpose:** Explain what this infrastructure domain provides and its strategic importance
    - **b. Present Strategic Options:** Provide 2-3 viable approaches with architectural pros and cons
    - **c. Make Strategic Recommendation:** Recommend the best approach with clear architectural rationale
    - **d. Incorporate Feedback:** Discuss with user and iterate based on feedback
    - **e. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
    - **f. Document Architectural Decision:** Record the final strategic choice with justification

- **If "YOLO Mode" was selected:**
  - Design strategic approaches for all major infrastructure domains
  - Document architectural decisions and rationales
  - Present comprehensive infrastructure strategy for review
  - Iterate based on feedback

### 4. Document Infrastructure Architecture Blueprint

- Populate all sections of the infrastructure architecture template:
  - **Cloud Strategy & Platform Selection** - Multi-cloud vs single cloud, platform rationale
  - **Network Architecture Patterns** - VPC design, connectivity strategies, security zones
  - **Compute Architecture Strategy** - Container vs serverless vs VM strategies, scaling patterns
  - **Data Architecture & Storage Strategy** - Database selection, data tier strategies, backup approaches
  - **Security Architecture Framework** - Zero-trust patterns, identity strategies, encryption approaches
  - **Observability Architecture** - Monitoring strategies, logging patterns, alerting frameworks
  - **CI/CD Architecture Patterns** - Pipeline strategies, deployment patterns, environment promotion
  - **Disaster Recovery Architecture** - RTO/RPO strategies, failover patterns, business continuity
  - **Cost Optimization Framework** - Resource optimization strategies, cost allocation patterns
  - **Environment Strategy** - Dev/staging/prod patterns, environment isolation approaches
  - **Infrastructure Evolution Strategy** - Technology migration paths, scaling roadmaps
  - **Cross-team Collaboration Model** - Integration with development teams, handoff protocols

### 5. Implementation Feasibility Review & Collaboration

- **Architect → DevOps/Platform Feedback Loop:**
  - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review
  - Request specific feedback on:
    - **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
    - **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
    - **Security Implementation:** Are security patterns achievable with current security toolchain?
    - **Operational Overhead:** Will the proposed architecture create excessive operational burden?
    - **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
  - Document all feasibility feedback and concerns raised by DevOps/Platform Engineering Agent
  - Iterate on architectural decisions based on operational constraints and feedback
  - <critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation</critical_rule>

### 6. Create Infrastructure Architecture Diagrams

- Develop high-level infrastructure strategy diagrams using Mermaid
- Create network topology architecture diagrams
- Document data flow and integration architecture diagrams
- Illustrate deployment pipeline architecture patterns
- Visualize environment relationship and promotion strategies
- Design security architecture and trust boundary diagrams

### 7. Define Implementation Handoff Strategy

- Create clear specifications for DevOps/Platform Engineering implementation
- Define architectural constraints and non-negotiable requirements
- Specify technology selections with version requirements where critical
- Document architectural patterns that must be followed during implementation
- Create implementation validation criteria
- Prepare architectural decision records (ADRs) for key infrastructure choices

### 8. BMAD Integration Architecture

- Design infrastructure architecture to support other BMAD agents:
  - **Development Environment Architecture** - Local development patterns, testing infrastructure
  - **Deployment Architecture** - How applications from Frontend/Backend agents will be deployed
  - **Integration Architecture** - How infrastructure supports cross-service communication
  - Document infrastructure requirements for each BMAD agent workflow

### 9. Architecture Review and Finalization

- Review architecture against system architecture for alignment
- Validate infrastructure architecture supports all application requirements
- Ensure architectural decisions are implementable within project constraints
- Address any architectural gaps or inconsistencies
- Prepare comprehensive architecture handoff documentation for implementation team

## Output

A comprehensive infrastructure architecture document that provides:

1. **Strategic Infrastructure Blueprint** - High-level architecture strategy and patterns
2. **Technology Selection Rationale** - Justified technology choices and architectural decisions
3. **Implementation Specifications** - Clear guidance for DevOps/Platform Engineering implementation
4. **Architectural Constraints** - Non-negotiable requirements and patterns
5. **Integration Architecture** - How infrastructure supports application architecture
6. **BMAD Workflow Support** - Infrastructure architecture supporting all agent workflows
7. **Feasibility Validation** - Documented operational feedback and constraint resolution

**Output file**: `docs/infrastructure-architecture.md`

## Offer Advanced Self-Refinement & Elicitation Options

Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.

"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):

**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**

1. **Alternative Architecture Strategy Evaluation**
2. **Scalability & Performance Architecture Stress Test (Theoretical)**
3. **Security Architecture & Compliance Deep Dive**
4. **Cost Architecture Analysis & Optimization Strategy Review**
5. **Operational Excellence & Reliability Architecture Assessment**
6. **Cross-Functional Integration & BMAD Workflow Analysis**
7. **Future Technology & Migration Architecture Path Exploration**
8. **Finalize this Section and Proceed.**

After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."

REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)

==================== END: create-infrastructure-architecture ====================


==================== START: create-next-story-task ====================
# Create Next Story Task

## Purpose

To identify the next logical story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Story Template`. This task ensures the story is enriched with all necessary technical context, requirements, and acceptance criteria, making it ready for efficient implementation by a Developer Agent with minimal need for additional research.

## Inputs for this Task

- Access to the project's documentation repository, specifically:
  - `docs/index.md` (hereafter "Index Doc")
  - All Epic files (e.g., `docs/epic-{n}.md` - hereafter "Epic Files")
  - Existing story files in `docs/stories/`
  - Main PRD (hereafter "PRD Doc")
  - Main Architecture Document (hereafter "Main Arch Doc")
  - Frontend Architecture Document (hereafter "Frontend Arch Doc," if relevant)
  - Project Structure Guide (`docs/project-structure.md`)
  - Operational Guidelines Document (`docs/operational-guidelines.md`)
  - Technology Stack Document (`docs/tech-stack.md`)
  - Data Models Document (as referenced in Index Doc)
  - API Reference Document (as referenced in Index Doc)
  - UI/UX Specifications, Style Guides, Component Guides (if relevant, as referenced in Index Doc)
- The `bmad-agent/templates/story-tmpl.md` (hereafter "Story Template")
- The `bmad-agent/checklists/story-draft-checklist.md` (hereafter "Story Draft Checklist")
- User confirmation to proceed with story identification and, if needed, to override warnings about incomplete prerequisite stories.

## Task Execution Instructions

### 1. Identify Next Story for Preparation

- Review `docs/stories/` to find the highest-numbered story file.
- **If a highest story file exists (`{lastEpicNum}.{lastStoryNum}.story.md`):**

  - Verify its `Status` is 'Done' (or equivalent).
  - If not 'Done', present an alert to the user:

    ```plaintext
    ALERT: Found incomplete story:
    File: {lastEpicNum}.{lastStoryNum}.story.md
    Status: [current status]

    Would you like to:
    1. View the incomplete story details (instructs user to do so, agent does not display)
    2. Cancel new story creation at this time
    3. Accept risk & Override to create the next story in draft

    Please choose an option (1/2/3):
    ```

  - Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
  - If proceeding: Check the Epic File for `{lastEpicNum}` for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
  - Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., `docs/epic-{lastEpicNum + 1}.md`, then `{lastEpicNum + 2}.md`, etc.) whose prerequisites are met.

- **If no story files exist in `docs/stories/`:**
  - The next story is the first story in `docs/epic-1.md` (then `docs/epic-2.md`, etc.) whose prerequisites are met.
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".

### 2. Gather Core Story Requirements (from Epic File)

- For the identified story, open its parent Epic File.
- Extract: Exact Title, full Goal/User Story statement, initial list of Requirements, all Acceptance Criteria (ACs), and any predefined high-level Tasks.
- Keep a record of this original epic-defined scope for later deviation analysis.

### 3. Gather & Synthesize In-Depth Technical Context for Dev Agent

- <critical_rule>Systematically use the Index Doc (`docs/index.md`) as your primary guide to discover paths to ALL detailed documentation relevant to the current story's implementation needs.</critical_rule>
- Thoroughly review the PRD Doc, Main Arch Doc, and Frontend Arch Doc (if a UI story).
- Guided by the Index Doc and the story's needs, locate, analyze, and synthesize specific, relevant information from sources such as:
  - Data Models Doc (structure, validation rules).
  - API Reference Doc (endpoints, request/response schemas, auth).
  - Applicable architectural patterns or component designs from Arch Docs.
  - UI/UX Specs, Style Guides, Component Guides (for UI stories).
  - Specifics from Tech Stack Doc if versions or configurations are key for this story.
  - Relevant sections of the Operational Guidelines Doc (e.g., story-specific error handling nuances, security considerations for data handled in this story).
- The goal is to collect all necessary details the Dev Agent would need, to avoid them having to search extensively. Note any discrepancies between the epic and these details for "Deviation Analysis."

### 4. Verify Project Structure Alignment

- Cross-reference the story's requirements and anticipated file manipulations with the Project Structure Guide (and frontend structure if applicable).
- Ensure any file paths, component locations, or module names implied by the story align with defined structures.
- Document any structural conflicts, necessary clarifications, or undefined components/paths in a "Project Structure Notes" section within the story draft.

### 5. Populate Story Template with Full Context

- Create a new story file: `docs/stories/{epicNum}.{storyNum}.story.md`.
- Use the Story Template to structure the file.
- Fill in:
  - Story `{EpicNum}.{StoryNum}: {Short Title Copied from Epic File}`
  - `Status: Draft`
  - `Story` (User Story statement from Epic)
  - `Acceptance Criteria (ACs)` (from Epic, to be refined if needed based on context)
- **`Dev Technical Guidance` section (CRITICAL):**
  - Based on all context gathered (Step 3 & 4), embed concise but critical snippets of information, specific data structures, API endpoint details, precise references to _specific sections_ in other documents (e.g., "See `Data Models Doc#User-Schema-ValidationRules` for details"), or brief explanations of how architectural patterns apply to _this story_.
  - If UI story, provide specific references to Component/Style Guides relevant to _this story's elements_.
  - The aim is to make this section the Dev Agent's primary source for _story-specific_ technical context.
- **`Tasks / Subtasks` section:**
  - Generate a detailed, sequential list of technical tasks and subtasks the Dev Agent must perform to complete the story, informed by the gathered context.
  - Link tasks to ACs where applicable (e.g., `Task 1 (AC: 1, 3)`).
- Add notes on project structure alignment or discrepancies found in Step 4.
- Prepare content for the "Deviation Analysis" based on discrepancies noted in Step 3.

==================== END: create-next-story-task ====================


==================== START: create-platform-infrastructure ====================
# Platform Infrastructure Implementation Task

## Purpose

To implement a comprehensive platform infrastructure stack based on the Infrastructure Architecture Document, including foundation infrastructure, container orchestration, GitOps workflows, service mesh, and developer experience platforms. This integrated approach ensures all platform components work synergistically to provide a complete, secure, and operationally excellent platform foundation.

## Inputs

- **Infrastructure Architecture Document** (`docs/infrastructure-architecture.md` - from Architect Agent)
- Infrastructure Change Request (`docs/infrastructure/{ticketNumber}.change.md`)
- Infrastructure Guidelines (`docs/infrastructure/guidelines.md`)
- Technology Stack Document (`docs/tech-stack.md`)
- `infrastructure-checklist.md` (for validation)

## Key Activities & Instructions

### 1. Confirm Interaction Mode

- Ask the user: "How would you like to proceed with platform infrastructure implementation? We can work:
  A. **Incrementally (Default & Recommended):** We'll implement each platform layer step-by-step (Foundation → Container Platform → GitOps → Service Mesh → Developer Experience), validating integration at each stage. This ensures thorough testing and operational readiness.
  B. **"YOLO" Mode:** I'll implement the complete platform stack in logical groups, with validation at major integration milestones. This is faster but requires comprehensive end-to-end testing."
- Request the user to select their preferred mode and proceed accordingly.

### 2. Architecture Review & Implementation Planning

- Review Infrastructure Architecture Document for complete platform specifications
- Validate platform requirements against application architecture and business needs
- Create integrated implementation roadmap with proper dependency sequencing
- Plan resource allocation, security policies, and operational procedures across all platform layers
- Document rollback procedures and risk mitigation strategies for the entire platform
- <critical_rule>Verify the infrastructure change request is approved before beginning implementation. If not, HALT and inform the user.</critical_rule>

### 3. Joint Implementation Planning Session

- **Architect ↔ DevOps/Platform Collaborative Planning:**
  - **Architecture Alignment Review:**
    - Confirm understanding of architectural decisions and rationale with Architect Agent
    - Validate interpretation of infrastructure architecture document
    - Clarify any ambiguous or unclear architectural specifications
    - Document agreed-upon implementation approach for each architectural component
  - **Implementation Strategy Collaboration:**
    - **Technology Implementation Planning:** Collaborate on specific technology versions, configurations, and deployment patterns
    - **Security Implementation Planning:** Align on security control implementation approach and validation methods
    - **Integration Planning:** Plan component integration sequence and validation checkpoints
    - **Operational Considerations:** Discuss operational patterns, monitoring strategies, and maintenance approaches
    - **Resource Planning:** Confirm resource allocation, sizing, and optimization strategies
  - **Risk & Constraint Discussion:**
    - Identify potential implementation risks and mitigation strategies
    - Document operational constraints that may impact architectural implementation
    - Plan contingency approaches for high-risk implementation areas
    - Establish escalation triggers for implementation issues requiring architectural input
  - **Implementation Validation Planning:**
    - Define validation criteria for each platform component and integration point
    - Plan testing strategies and acceptance criteria with Architect input
    - Establish quality gates and review checkpoints throughout implementation
    - Document success metrics and performance benchmarks
  - **Documentation & Knowledge Transfer Planning:**
    - Plan documentation approach and knowledge transfer requirements
    - Define operational runbooks and troubleshooting guide requirements
    - Establish ongoing collaboration points for implementation support
- <critical_rule>Complete joint planning session before beginning platform implementation. Document all planning outcomes and agreements.</critical_rule>

### 4. Foundation Infrastructure Implementation

- **If "Incremental Mode" was selected:**
  - **a. Foundation Infrastructure Setup:**
    - Present foundation infrastructure scope and its role in the platform stack
    - Implement core cloud resources, networking, storage, and security foundations
    - Configure basic monitoring, logging, and operational tooling
    - Validate foundation readiness for platform components
    - [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)

- **If "YOLO Mode" was selected:**
  - Implement complete foundation infrastructure per architecture specifications
  - Prepare foundation for all platform components simultaneously

### 5. Container Platform Implementation

- **If "Incremental Mode" was selected:**
  - **b. Container Orchestration Platform:**
    - Present container platform scope and integration with foundation infrastructure
    - Install and configure container orchestration platform (Kubernetes/AKS/EKS/GKE)
    - Implement RBAC, security policies, and resource management
    - Configure networking, storage classes, and operational tooling
    - Validate container platform functionality and readiness for applications
    - [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)

- **If "YOLO Mode" was selected:**
  - Deploy complete container platform integrated with foundation infrastructure

### 6. GitOps Workflows Implementation

- **If "Incremental Mode" was selected:**
  - **c. GitOps Configuration Management:**
    - Present GitOps scope and integration with container platform
    - Implement GitOps operators and configuration management systems
    - Configure repository structures, sync policies, and environment promotion
    - Set up policy enforcement and drift detection
    - Validate GitOps workflows and configuration management
    - [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)

- **If "YOLO Mode" was selected:**
  - Deploy complete GitOps stack integrated with container and foundation platforms

### 7. Service Mesh Implementation

- **If "Incremental Mode" was selected:**
  - **d. Service Communication Platform:**
    - Present service mesh scope and integration with existing platform layers
    - Install and configure service mesh control and data planes
    - Implement traffic management, security policies, and observability
    - Configure service discovery, load balancing, and communication policies
    - Validate service mesh functionality and inter-service communication
    - [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)

- **If "YOLO Mode" was selected:**
  - Deploy complete service mesh integrated with all platform components

### 8. Developer Experience Platform Implementation

- **If "Incremental Mode" was selected:**
  - **e. Developer Experience Platform:**
    - Present developer platform scope and integration with complete platform stack
    - Implement developer portals, self-service capabilities, and golden path templates
    - Configure platform APIs, automation workflows, and productivity tooling
    - Set up developer onboarding and documentation systems
    - Validate developer experience and workflow integration
    - [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)

- **If "YOLO Mode" was selected:**
  - Deploy complete developer experience platform integrated with all infrastructure

### 9. Platform Integration & Security Hardening

- Implement end-to-end security policies across all platform layers
- Configure integrated monitoring and observability for the complete platform stack
- Set up platform-wide backup, disaster recovery, and business continuity procedures
- Implement cost optimization and resource management across all platform components
- Configure platform-wide compliance monitoring and audit logging
- Validate complete platform security posture and operational readiness

### 10. Platform Operations & Automation

- Set up comprehensive platform monitoring, alerting, and operational dashboards
- Implement automated platform maintenance, updates, and lifecycle management
- Configure platform health checks, performance optimization, and capacity planning
- Set up incident response procedures and operational runbooks for the complete platform
- Implement platform SLA monitoring and service level management
- Validate operational excellence and platform reliability

### 11. BMAD Workflow Integration

- Verify complete platform supports all BMAD agent workflows:
  - **Frontend/Backend Development** - Test complete application development and deployment workflows
  - **Infrastructure Development** - Validate infrastructure-as-code development and deployment
  - **Cross-Agent Collaboration** - Ensure seamless collaboration between all agent types
  - **CI/CD Integration** - Test complete continuous integration and deployment pipelines
  - **Monitoring & Observability** - Verify complete application and infrastructure monitoring
- Document comprehensive integration verification results and workflow optimizations

### 12. Platform Validation & Knowledge Transfer

- Execute comprehensive platform testing with realistic workloads and scenarios
- Validate against all sections of infrastructure checklist for complete platform
- Perform security scanning, compliance verification, and performance testing
- Test complete platform disaster recovery and resilience procedures
- Complete comprehensive knowledge transfer to operations and development teams
- Document complete platform configuration, operational procedures, and troubleshooting guides
- <critical_rule>Update infrastructure change request status to reflect completion</critical_rule>

### 13. Implementation Review & Architect Collaboration

- **Post-Implementation Collaboration with Architect:**
  - **Implementation Validation Review:**
    - Present implementation outcomes against architectural specifications
    - Document any deviations from original architecture and rationale
    - Validate that implemented platform meets architectural intent and requirements
  - **Lessons Learned & Architecture Feedback:**
    - Provide feedback to Architect Agent on implementation experience
    - Document implementation challenges and successful patterns
    - Recommend architectural improvements for future implementations
    - Share operational insights that could influence future architectural decisions
  - **Knowledge Transfer & Documentation Review:**
    - Review operational documentation with Architect for completeness and accuracy
    - Ensure architectural decisions are properly documented in operational guides
    - Plan ongoing collaboration for platform evolution and maintenance
- Document collaboration outcomes and recommendations for future architecture-implementation cycles

### 14. Platform Handover & Continuous Improvement

- Establish platform monitoring and continuous improvement processes
- Set up feedback loops with development teams and platform users
- Plan platform evolution roadmap and technology upgrade strategies
- Implement platform metrics and KPI tracking for operational excellence
- Create platform governance and change management procedures
- Establish platform support and maintenance responsibilities

## Output

Fully operational and integrated platform infrastructure with:

1. **Complete Foundation Infrastructure** - Cloud resources, networking, storage, and security foundations
2. **Production-Ready Container Platform** - Orchestration with proper security, monitoring, and resource management
3. **Operational GitOps Workflows** - Version-controlled operations with automated sync and policy enforcement
4. **Service Mesh Communication Platform** - Advanced service communication with security and observability
5. **Developer Experience Platform** - Self-service capabilities with productivity tooling and golden paths
6. **Integrated Platform Operations** - Comprehensive monitoring, automation, and operational excellence
7. **BMAD Workflow Support** - Verified integration supporting all agent development and deployment patterns
8. **Platform Documentation** - Complete operational guides, troubleshooting resources, and developer documentation
9. **Joint Planning Documentation** - Collaborative planning outcomes and architectural alignment records
10. **Implementation Review Results** - Post-implementation validation and architect collaboration outcomes

## Offer Advanced Self-Refinement & Elicitation Options

Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current platform layer before finalizing it and moving to the next. The user can select an action by number, or choose to skip this and proceed.

"To ensure the quality of the current platform layer: **[Specific Platform Layer Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):

**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**

1. **Platform Layer Security Hardening & Integration Review**
2. **Performance Optimization & Resource Efficiency Analysis**
3. **Operational Excellence & Automation Enhancement**
4. **Platform Integration & Dependency Validation**
5. **Developer Experience & Workflow Optimization**
6. **Disaster Recovery & Platform Resilience Testing (Theoretical)**
7. **BMAD Agent Workflow Integration & Cross-Platform Testing**
8. **Finalize this Platform Layer and Proceed.**

After I perform the selected action, we can discuss the outcome and decide on any further improvements for this platform layer."

REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next platform layer (or selects #8)

==================== END: create-platform-infrastructure ====================


==================== START: create-prd ====================
# PRD Generate Task

## Purpose

- Transform inputs into core product definition documents conforming to a PRD template
- Define clear MVP scope focused on essential functionality
- Provide foundation for Architect and Design Architect to help create technical artifacts which will in turn later draft further details for very junior engineers or simple dev ai agents.

## Instructions

### 1. Review Inputs

Review all provided inputs including project brief, research documents, prd template and user ideas to guide PRD generation.

### 2. Determine Interaction Mode

Confirm with the user their preferred interaction style:

- **Incremental:** Work through sections one at a time via chat messages as defined in the template.

- **YOLO Mode:** Draft the complete PRD making assumptions as necessary. Present full document at once, noting which sections required assumptions.

### 3. Execute Template

- Use the `prd-tmpl` template (or user-specified alternative template)
- Follow all embedded LLM instructions within the template
- Template contains section-specific guidance and examples

### 4. Template Processing Notes

- **Incremental Mode**: Present each section for review before proceeding
- **YOLO Mode**: Generate all sections, then review with user

Process all template elements according to `templates#template-format` conventions.

**CRITICAL: Never display or output template markup formatting, LLM instructions or examples - they MUST be used by you the agent only, AND NEVER shown to users in chat or document output**

**Content Presentation Guidelines:**

- Present only the final, clean content to users
- Replace template variables with actual project-specific content
- Process all conditional logic internally - show only relevant sections
- For Canvas mode: Update the document with clean, formatted content only

### 7. Prepare Handoffs

Based on PRD content, prepare appropriate next-step prompts:

**If UI Component Exists:**

1. Add Design Architect prompt in designated template section
2. Recommend: User engages Design Architect first for UI/UX Specification
3. Then proceed to Architect with enriched PRD

**If No UI Component:**

- Add Architect prompt in designated template section
- Recommend proceeding directly to Architect

### 8. Validate with Checklist

- Run the `pm-checklist` against completed PRD
- Document completion status for each checklist item
- Present summary by section, address any deficiencies
- Generate final checklist report with findings and resolutions

### 9. Final Presentation

**General Guidelines:**

- Present complete documents in clean, full format
- DO NOT truncate unchanged information
- Begin directly with content (no introductory text needed)
- Ensure all template sections are properly filled
- **NEVER show template markup, instructions, or processing directives to users**

## Key Resources

- **Default Template:** `templates#prd-tmpl`
- **Validation:** `checklists#pm-checklist`
- **User Preferences:** `data#technical-preferences`
- **Elicitation Protocol:** `tasks#advanced-elicitation`

## Important Notes

- This task is template-agnostic - users may specify custom templates
- All detailed instructions are embedded in templates, not this task file
- Focus on orchestration and workflow
- **Template markup is for AI processing only - users should never see output indicators from templates#template-format**

==================== END: create-prd ====================


==================== START: create-uxui-spec ====================
# Create UI/UX Specification Task

## Purpose

To collaboratively work with the user to define and document the User Interface (UI) and User Experience (UX) specifications for the project. This involves understanding user needs, defining information architecture, outlining user flows, and ensuring a solid foundation for visual design and frontend development. The output will populate a new document called `front-end-spec.md` following the `front-end-spec-tmpl` template.

## Inputs

- Project Brief (`project-brief.md` or equivalent)
- Product Requirements Document (PRD) (`prd.md` or equivalent)
- User feedback or research (if available)

## Key Activities & Instructions

### 1. Understand Core Requirements

- Review Project Brief and PRD to grasp project goals, target audience, key features, and any existing constraints.
- Ask clarifying questions about user needs, pain points, and desired outcomes.

### 2. Define Overall UX Goals & Principles (for `front-end-spec-tmpl`)

- Collaboratively establish and document:
  - Target User Personas (elicit details or confirm existing ones).
  - Key Usability Goals.
  - Core Design Principles for the project.

### 3. Develop Information Architecture (IA) (for `front-end-spec-tmpl`)

- Work with the user to create a Site Map or Screen Inventory.
- Define the primary and secondary Navigation Structure.
- Use Mermaid diagrams or lists as appropriate for the template.

### 4. Outline Key User Flows (for `front-end-spec-tmpl`)

- Identify critical user tasks from the PRD/brief.
- For each flow:
  - Define the user's goal.
  - Collaboratively map out the steps (use Mermaid diagrams or detailed step-by-step descriptions).
  - Consider edge cases and error states.

### 5. Discuss Wireframes & Mockups Strategy (for `front-end-spec-tmpl`)

- Clarify where detailed visual designs will be created (e.g., Figma, Sketch) and ensure the `front-end-spec-tmpl` correctly links to these primary design files.
- If low-fidelity wireframes are needed first, offer to help conceptualize layouts for key screens.

### 6. Define Component Library / Design System Approach (for `front-end-spec-tmpl`)

- Discuss if an existing design system will be used or if a new one needs to be developed.
- If new, identify a few foundational components to start with (e.g., Button, Input, Card) and their key states/behaviors at a high level. Detailed technical specs will be in `front-end-architecture`.

### 7. Establish Branding & Style Guide Basics (for `front-end-spec-tmpl`)

- If a style guide exists, link to it.
- If not, collaboratively define placeholders for: Color Palette, Typography, Iconography, Spacing.

### 8. Specify Accessibility (AX) Requirements (for `front-end-spec-tmpl`)

- Determine the target compliance level (e.g., WCAG 2.1 AA).
- List any known specific AX requirements.

### 9. Define Responsiveness Strategy (for `front-end-spec-tmpl`)

- Discuss and document key Breakpoints.
- Describe the general Adaptation Strategy.

### 10. Output Generation & Iterative Refinement (Guided by `front-end-spec-tmpl`)

- **a. Draft Section:** Incrementally populate one logical section of the `front-end-spec-tmpl` file based on your discussions.
- **b. Present & Incorporate Initial Feedback:** Present the drafted section to the user for review. Discuss, explain and incorporate their initial feedback and revisions directly.
- **c. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**

## Offer Advanced Self-Refinement & Elicitation Options

(This section is called when needed prior to this)

Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.

"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):

**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**

{Instruction for AI Agent: Display the title of each numbered item below. If the user asks what a specific option means, provide a brief explanation of the action you will take, drawing from detailed descriptions tailored for the context.}

1.  **Critical Self-Review & User Goal Alignment**
2.  **Generate & Evaluate Alternative Design Solutions**
3.  **User Journey & Interaction Stress Test (Conceptual)**
4.  **Deep Dive into Design Assumptions & Constraints**
5.  **Usability & Accessibility Audit Review & Probing Questions**
6.  **Collaborative Ideation & UI Feature Brainstorming**
7.  **Elicit 'Unforeseen User Needs' & Future Interaction Questions**
8.  **Finalize this Section and Proceed.**

After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."

REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNIT the user indicates it is time to proceed ot the next section (or selects #8)

==================== END: create-uxui-spec ====================


==================== START: doc-sharding-task ====================
# Doc Sharding Task

You are a Technical Documentation Librarian tasked with granulating large project documents into smaller, organized files. Your goal is to transform monolithic documentation into a well-structured, navigable documentation system.

## Your Task

Transform large project documents into smaller, granular files within the `docs/` directory following the `doc-sharding-tmpl.txt` plan. Create and maintain `docs/index.md` as a central catalog for easier reference and context injection.

## Execution Process

1. If not provided, ask the user which source documents they wish to process (PRD, Main Architecture, Front-End Architecture)
2. Validate prerequisites:

   - Provided `doc-sharding-tmpl.txt` or access to `bmad-agent/doc-sharding-tmpl.txt`
   - Location of source documents to process
   - Write access to the `docs/` directory
   - Output method (file system or chat interface)

3. For each selected document:

   - Follow the structure in `doc-sharding-tmpl.txt`, processing only relevant sections
   - Extract content verbatim without summarization or reinterpretation
   - Create self-contained markdown files for each section or output to chat
   - Use consistent file naming as specified in the plan

4. For `docs/index.md` when working with the file system:

   - Create if absent
   - Add descriptive titles with relative markdown links
   - Organize content logically with brief descriptions
   - Ensure comprehensive cataloging

5. Maintain creation log and provide final report

## Rules

1. Never modify source content during extraction
2. Create files exactly as specified in the sharding plan
3. Seek approval when consolidating content from multiple sources
4. Maintain original context and meaning
5. Keep file names consistent with the plan
6. Update `index.md` for every new file

## Required Input

1. **Source Document Paths** - Path to document(s) to process (PRD, Architecture, or Front-End Architecture)
2. **Documents to Process** - Which documents to shard in this session
3. **Sharding Plan** - Confirm `docs/templates/doc-sharding-tmpl.txt` exists or `doc-sharding-tmpl.txt` has been provided
4. **Output Location** - Confirm Target directory (default: `docs/`) and index.md or in memory chat output

Would you like to proceed with document sharding? Please provide the required input.

==================== END: doc-sharding-task ====================


==================== START: library-indexing-task ====================
# Library Indexing Task

## Purpose

This task maintains the integrity and completeness of the `docs/index.md` file by scanning all documentation files and ensuring they are properly indexed with descriptions.

## Task Instructions

You are now operating as a Documentation Indexer. Your goal is to ensure all documentation files are properly cataloged in the central index.

### Required Steps

1. First, locate and scan:

   - The `docs/` directory and all subdirectories
   - The existing `docs/index.md` file (create if absent)
   - All markdown (`.md`) and text (`.txt`) files in the documentation structure

2. For the existing `docs/index.md`:

   - Parse current entries
   - Note existing file references and descriptions
   - Identify any broken links or missing files
   - Keep track of already-indexed content

3. For each documentation file found:

   - Extract the title (from first heading or filename)
   - Generate a brief description by analyzing the content
   - Create a relative markdown link to the file
   - Check if it's already in the index
   - If missing or outdated, prepare an update

4. For any missing or non-existent files found in index:

   - Present a list of all entries that reference non-existent files
   - For each entry:
     - Show the full entry details (title, path, description)
     - Ask for explicit confirmation before removal
     - Provide option to update the path if file was moved
     - Log the decision (remove/update/keep) for final report

5. Update `docs/index.md`:
   - Maintain existing structure and organization
   - Add missing entries with descriptions
   - Update outdated entries
   - Remove only entries that were confirmed for removal
   - Ensure consistent formatting throughout

### Index Entry Format

Each entry in `docs/index.md` should follow this format:

```markdown
### [Document Title](relative/path/to/file.md)

Brief description of the document's purpose and contents.
```

### Rules of Operation

1. NEVER modify the content of indexed files
2. Preserve existing descriptions in index.md when they are adequate
3. Maintain any existing categorization or grouping in the index
4. Use relative paths for all links
5. Ensure descriptions are concise but informative
6. NEVER remove entries without explicit confirmation
7. Report any broken links or inconsistencies found
8. Allow path updates for moved files before considering removal

### Process Output

The task will provide:

1. A summary of changes made to index.md
2. List of newly indexed files
3. List of updated entries
4. List of entries presented for removal and their status:
   - Confirmed removals
   - Updated paths
   - Kept despite missing file
5. Any other issues or inconsistencies found

### Handling Missing Files

For each file referenced in the index but not found in the filesystem:

1. Present the entry:

   ```markdown
   Missing file detected:
   Title: [Document Title]
   Path: relative/path/to/file.md
   Description: Existing description

   Options:

   1. Remove this entry
   2. Update the file path
   3. Keep entry (mark as temporarily unavailable)

   Please choose an option (1/2/3):
   ```

2. Wait for user confirmation before taking any action
3. Log the decision for the final report

## Required Input

Please provide:

1. Location of the `docs/` directory
2. Confirmation of write access to `docs/index.md`
3. Any specific categorization preferences
4. Any files or directories to exclude from indexing

Would you like to proceed with library indexing? Please provide the required input above.

==================== END: library-indexing-task ====================


==================== START: review-infrastructure ====================
# Infrastructure Review Task

## Purpose

To conduct a thorough review of existing infrastructure to identify improvement opportunities, security concerns, and alignment with best practices. This task helps maintain infrastructure health, optimize costs, and ensure continued alignment with organizational requirements.

## Inputs

- Current infrastructure documentation
- Monitoring and logging data
- Recent incident reports
- Cost and performance metrics
- `infrastructure-checklist.md` (primary review framework)

## Key Activities & Instructions

### 1. Confirm Interaction Mode

- Ask the user: "How would you like to proceed with the infrastructure review? We can work:
  A. **Incrementally (Default & Recommended):** We'll work through each section of the checklist methodically, documenting findings for each item before moving to the next section. This provides a thorough review.
  B. **"YOLO" Mode:** I can perform a rapid assessment of all infrastructure components and present a comprehensive findings report. This is faster but may miss nuanced details."
- Request the user to select their preferred mode and proceed accordingly.

### 2. Prepare for Review

- Gather and organize current infrastructure documentation
- Access monitoring and logging systems for operational data
- Review recent incident reports for recurring issues
- Collect cost and performance metrics
- <critical_rule>Establish review scope and boundaries with the user before proceeding</critical_rule>

### 3. Conduct Systematic Review

- **If "Incremental Mode" was selected:**
  - For each section of the infrastructure checklist:
    - **a. Present Section Focus:** Explain what aspects of infrastructure this section reviews
    - **b. Work Through Items:** Examine each checklist item against current infrastructure
    - **c. Document Current State:** Record how current implementation addresses or fails to address each item
    - **d. Identify Gaps:** Document improvement opportunities with specific recommendations
    - **e. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
    - **f. Section Summary:** Provide an assessment summary before moving to the next section

- **If "YOLO Mode" was selected:**
  - Rapidly assess all infrastructure components
  - Document key findings and improvement opportunities
  - Present a comprehensive review report
  - <important_note>After presenting the full review in YOLO mode, you MAY still offer the 'Advanced Reflective & Elicitation Options' menu for deeper investigation of specific areas with issues.</important_note>

### 4. Generate Findings Report

- Summarize review findings by category (Security, Performance, Cost, Reliability, etc.)
- Prioritize identified issues (Critical, High, Medium, Low)
- Document recommendations with estimated effort and impact
- Create an improvement roadmap with suggested timelines
- Highlight cost optimization opportunities

### 5. BMAD Integration Assessment

- Evaluate how current infrastructure supports other BMAD agents:
  - **Development Support:** Assess how infrastructure enables Frontend Dev (Mira), Backend Dev (Enrique), and Full Stack Dev workflows
  - **Product Alignment:** Verify infrastructure supports PRD requirements from Product Owner (Oli)
  - **Architecture Compliance:** Check if implementation follows Architect (Alphonse) decisions
  - Document any gaps in BMAD integration

### 6. Architectural Escalation Assessment

- **DevOps/Platform → Architect Escalation Review:**
  - Evaluate review findings for issues requiring architectural intervention:
    - **Technical Debt Escalation:**
      - Identify infrastructure technical debt that impacts system architecture
      - Document technical debt items that require architectural redesign vs. operational fixes
      - Assess cumulative technical debt impact on system maintainability and scalability
    - **Performance/Security Issue Escalation:**
      - Identify performance bottlenecks that require architectural solutions (not just operational tuning)
      - Document security vulnerabilities that need architectural security pattern changes
      - Assess capacity and scalability issues requiring architectural scaling strategy revision
    - **Technology Evolution Escalation:**
      - Identify outdated technologies that need architectural migration planning
      - Document new technology opportunities that could improve system architecture
      - Assess technology compatibility issues requiring architectural integration strategy changes
  - **Escalation Decision Matrix:**
    - **Critical Architectural Issues:** Require immediate Architect Agent involvement for system redesign
    - **Significant Architectural Concerns:** Recommend Architect Agent review for potential architecture evolution
    - **Operational Issues:** Can be addressed through operational improvements without architectural changes
    - **Unclear/Ambiguous Issues:** When escalation level is uncertain, consult with user for guidance and decision
  - Document escalation recommendations with clear justification and impact assessment
  - <critical_rule>If escalation classification is unclear or ambiguous, HALT and ask user for guidance on appropriate escalation level and approach</critical_rule>

### 7. Present and Plan

- Prepare an executive summary of key findings
- Create detailed technical documentation for implementation teams
- Develop an action plan for critical and high-priority items
- **Prepare Architectural Escalation Report** (if applicable):
  - Document all findings requiring Architect Agent attention
  - Provide specific recommendations for architectural changes or reviews
  - Include impact assessment and priority levels for architectural work
  - Prepare escalation summary for Architect Agent collaboration
- Schedule follow-up reviews for specific areas
- <important_note>Present findings in a way that enables clear decision-making on next steps and escalation needs.</important_note>

### 8. Execute Escalation Protocol

- **If Critical Architectural Issues Identified:**
  - **Immediate Escalation to Architect Agent:**
    - Present architectural escalation report with critical findings
    - Request architectural review and potential redesign for identified issues
    - Collaborate with Architect Agent on priority and timeline for architectural changes
    - Document escalation outcomes and planned architectural work
- **If Significant Architectural Concerns Identified:**
  - **Scheduled Architectural Review:**
    - Prepare detailed technical findings for Architect Agent review
    - Request architectural assessment of identified concerns
    - Schedule collaborative planning session for potential architectural evolution
    - Document architectural recommendations and planned follow-up
- **If Only Operational Issues Identified:**
  - Proceed with operational improvement planning without architectural escalation
  - Monitor for future architectural implications of operational changes
- **If Unclear/Ambiguous Escalation Needed:**
  - **User Consultation Required:**
    - Present unclear findings and escalation options to user
    - Request user guidance on appropriate escalation level and approach
    - Document user decision and rationale for escalation approach
    - Proceed with user-directed escalation path
- <critical_rule>All critical architectural escalations must be documented and acknowledged by Architect Agent before proceeding with implementation</critical_rule>

## Output

A comprehensive infrastructure review report that includes:

1. **Current state assessment** for each infrastructure component
2. **Prioritized findings** with severity ratings
3. **Detailed recommendations** with effort/impact estimates
4. **Cost optimization opportunities**
5. **BMAD integration assessment**
6. **Architectural escalation assessment** with clear escalation recommendations
7. **Action plan** for critical improvements and architectural work
8. **Escalation documentation** for Architect Agent collaboration (if applicable)

## Offer Advanced Self-Refinement & Elicitation Options

Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.

"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):

**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**

1. **Root Cause Analysis & Pattern Recognition**
2. **Industry Best Practice Comparison**
3. **Future Scalability & Growth Impact Assessment**
4. **Security Vulnerability & Threat Model Analysis**
5. **Operational Efficiency & Automation Opportunities**
6. **Cost Structure Analysis & Optimization Strategy**
7. **Compliance & Governance Gap Assessment**
8. **Finalize this Section and Proceed.**

After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."

REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)

==================== END: review-infrastructure ====================


==================== START: validate-infrastructure ====================
# Infrastructure Validation Task

## Purpose

To comprehensively validate platform infrastructure changes against security, reliability, operational, and compliance requirements before deployment. This task ensures all platform infrastructure meets organizational standards, follows best practices, and properly integrates with the broader BMAD ecosystem.

## Inputs

- Infrastructure Change Request (`docs/infrastructure/{ticketNumber}.change.md`)
- **Infrastructure Architecture Document** (`docs/infrastructure-architecture.md` - from Architect Agent)
- Infrastructure Guidelines (`docs/infrastructure/guidelines.md`)
- Technology Stack Document (`docs/tech-stack.md`)
- `infrastructure-checklist.md` (primary validation framework - 16 comprehensive sections)

## Key Activities & Instructions

### 1. Confirm Interaction Mode

- Ask the user: "How would you like to proceed with platform infrastructure validation? We can work:
  A. **Incrementally (Default & Recommended):** We'll work through each section of the checklist step-by-step, documenting compliance or gaps for each item before moving to the next section. This is best for thorough validation and detailed documentation of the complete platform stack.
  B. **"YOLO" Mode:** I can perform a rapid assessment of all checklist items and present a comprehensive validation report for review. This is faster but may miss nuanced details that would be caught in the incremental approach."
- Request the user to select their preferred mode (e.g., "Please let me know if you'd prefer A or B.").
- Once the user chooses, confirm the selected mode and proceed accordingly.

### 2. Initialize Platform Validation

- Review the infrastructure change documentation to understand platform implementation scope and purpose
- Analyze the infrastructure architecture document for platform design patterns and compliance requirements
- Examine infrastructure guidelines for organizational standards across all platform components
- Prepare the validation environment and tools for comprehensive platform testing
- <critical_rule>Verify the infrastructure change request is approved for validation. If not, HALT and inform the user.</critical_rule>

### 3. Architecture Design Review Gate

- **DevOps/Platform → Architect Design Review:**
  - Conduct systematic review of infrastructure architecture document for implementability
  - Evaluate architectural decisions against operational constraints and capabilities:
    - **Implementation Complexity:** Assess if proposed architecture can be implemented with available tools and expertise
    - **Operational Feasibility:** Validate that operational patterns are achievable within current organizational maturity
    - **Resource Availability:** Confirm required infrastructure resources are available and within budget constraints
    - **Technology Compatibility:** Verify selected technologies integrate properly with existing infrastructure
    - **Security Implementation:** Validate that security patterns can be implemented with current security toolchain
    - **Maintenance Overhead:** Assess ongoing operational burden and maintenance requirements
  - Document design review findings and recommendations:
    - **Approved Aspects:** Document architectural decisions that are implementable as designed
    - **Implementation Concerns:** Identify architectural decisions that may face implementation challenges
    - **Required Modifications:** Recommend specific changes needed to make architecture implementable
    - **Alternative Approaches:** Suggest alternative implementation patterns where needed
  - **Collaboration Decision Point:**
    - If **critical implementation blockers** identified: HALT validation and escalate to Architect Agent for architectural revision
    - If **minor concerns** identified: Document concerns and proceed with validation, noting required implementation adjustments
    - If **architecture approved**: Proceed with comprehensive platform validation
  - <critical_rule>All critical design review issues must be resolved before proceeding to detailed validation</critical_rule>

### 4. Execute Comprehensive Platform Validation Process

- **If "Incremental Mode" was selected:**
  - For each section of the infrastructure checklist (Sections 1-16):
    - **a. Present Section Purpose:** Explain what this section validates and why it's important for platform operations
    - **b. Work Through Items:** Present each checklist item, guide the user through validation, and document compliance or gaps
    - **c. Evidence Collection:** For each compliant item, document how compliance was verified
    - **d. Gap Documentation:** For each non-compliant item, document specific issues and proposed remediation
    - **e. Platform Integration Testing:** For platform engineering sections (13-16), validate integration between platform components
    - **f. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
    - **g. Section Summary:** Provide a compliance percentage and highlight critical findings before moving to the next section

- **If "YOLO Mode" was selected:**
  - Work through all checklist sections rapidly (foundation infrastructure sections 1-12 + platform engineering sections 13-16)
  - Document compliance status for each item across all platform components
  - Identify and document critical non-compliance issues affecting platform operations
  - Present a comprehensive validation report for all sections
  - <important_note>After presenting the full validation report in YOLO mode, you MAY still offer the 'Advanced Reflective & Elicitation Options' menu for deeper investigation of specific sections with issues.</important_note>

### 5. Generate Comprehensive Platform Validation Report

- Summarize validation findings by section across all 16 checklist areas
- Calculate and present overall compliance percentage for complete platform stack
- Clearly document all non-compliant items with remediation plans prioritized by platform impact
- Highlight critical security or operational risks affecting platform reliability
- Include design review findings and architectural implementation recommendations
- Provide validation signoff recommendation based on complete platform assessment
- Document platform component integration validation results

### 6. BMAD Integration Assessment

- Review how platform infrastructure changes support other BMAD agents:
  - **Development Agent Alignment:** Verify platform infrastructure supports Frontend Dev, Backend Dev, and Full Stack Dev requirements including:
    - Container platform development environment provisioning
    - GitOps workflows for application deployment
    - Service mesh integration for development testing
    - Developer experience platform self-service capabilities
  - **Product Alignment:** Ensure platform infrastructure implements PRD requirements from Product Owner including:
    - Scalability and performance requirements through container platform
    - Deployment automation through GitOps workflows
    - Service reliability through service mesh implementation
  - **Architecture Alignment:** Validate that platform implementation aligns with architecture decisions including:
    - Technology selections implemented correctly across all platform components
    - Security architecture implemented in container platform, service mesh, and GitOps
    - Integration patterns properly implemented between platform components
  - Document all integration points and potential impacts on other agents' workflows

### 7. Next Steps Recommendation

- If validation successful:
  - Prepare platform deployment recommendation with component dependencies
  - Outline monitoring requirements for complete platform stack
  - Suggest knowledge transfer activities for platform operations
  - Document platform readiness certification
- If validation failed:
  - Prioritize remediation actions by platform component and integration impact
  - Recommend blockers vs. non-blockers for platform deployment
  - Schedule follow-up validation with focus on failed platform components
  - Document platform risks and mitigation strategies
- If design review identified architectural issues:
  - **Escalate to Architect Agent** for architectural revision and re-design
  - Document specific architectural changes required for implementability
  - Schedule follow-up design review after architectural modifications
- Update documentation with validation results across all platform components
- <important_note>Always ensure the Infrastructure Change Request status is updated to reflect the platform validation outcome.</important_note>

## Output

A comprehensive platform validation report documenting:

1. **Architecture Design Review Results** - Implementability assessment and architectural recommendations
2. **Compliance percentage by checklist section** (all 16 sections including platform engineering)
3. **Detailed findings for each non-compliant item** across foundation and platform components
4. **Platform integration validation results** documenting component interoperability
5. **Remediation recommendations with priority levels** based on platform impact
6. **BMAD integration assessment results** for complete platform stack
7. **Clear signoff recommendation** for platform deployment readiness or architectural revision requirements
8. **Next steps for implementation or remediation** prioritized by platform dependencies

## Offer Advanced Self-Refinement & Elicitation Options

Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.

"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):

**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**

1. **Critical Security Assessment & Risk Analysis**
2. **Platform Integration & Component Compatibility Evaluation**
3. **Cross-Environment Consistency Review**
4. **Technical Debt & Maintainability Analysis**
5. **Compliance & Regulatory Alignment Deep Dive**
6. **Cost Optimization & Resource Efficiency Analysis**
7. **Operational Resilience & Platform Failure Mode Testing (Theoretical)**
8. **Finalize this Section and Proceed.**

After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."

REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)

==================== END: validate-infrastructure ====================