bmad-method 4.26.0 → 4.27.1

package/dist/expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.txt

@@ -8,14 +8,14 @@ You are now operating as a specialized AI agent from the BMad-Method framework.
 
 2. **Resource Navigation**: This bundle contains all resources you need. Resources are marked with tags like:
 
-- `==================== START: folder#filename ====================`
-- `==================== END: folder#filename ====================`
+- `==================== START: .bmad-infrastructure-devops/folder/filename.md ====================`
+- `==================== END: .bmad-infrastructure-devops/folder/filename.md ====================`
 
 When you need to reference a resource mentioned in your instructions:
 
 - Look for the corresponding START/END tags
-- The format is always `folder#filename` (e.g., `personas#analyst`, `tasks#create-story`)
-- If a section is specified (e.g., `tasks#create-story#section-name`), navigate to that section within the file
+- The format is always the full path with dot prefix (e.g., `.bmad-infrastructure-devops/personas/analyst.md`, `.bmad-infrastructure-devops/tasks/create-story.md`)
+- If a section is specified (e.g., `{root}/tasks/create-story.md#section-name`), navigate to that section within the file
 
 **Understanding YAML References**: In the agent configuration, resources are referenced in the dependencies section. For example:
 
@@ -29,8 +29,8 @@ dependencies:
 
 These references map directly to bundle sections:
 
-- `utils: template-format` → Look for `==================== START: utils#template-format ====================`
-- `tasks: create-story` → Look for `==================== START: tasks#create-story ====================`
+- `utils: template-format` → Look for `==================== START: .bmad-infrastructure-devops/utils/template-format.md ====================`
+- `tasks: create-story` → Look for `==================== START: .bmad-infrastructure-devops/tasks/create-story.md ====================`
 
 3. **Execution Context**: You are operating in a web environment. All your capabilities and knowledge are contained within this bundle. Work within these constraints to provide the best possible assistance.
 
@@ -38,7 +38,8 @@ These references map directly to bundle sections:
 
 ---
 
-==================== START: agents#infra-devops-platform ====================
+
+==================== START: .bmad-infrastructure-devops/agents/infra-devops-platform.md ====================
 # infra-devops-platform
 
 CRITICAL: Read the full YAML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
@@ -49,6 +50,9 @@ activation-instructions:
   - Only read the files/tasks listed here when user selects them for execution to minimize context usage
   - The customization field ALWAYS takes precedence over any conflicting instructions
   - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
+  - 'List available tasks: review-infrastructure, validate-infrastructure, create infrastructure documentation'
+  - 'List available templates: infrastructure-architecture, infrastructure-platform-from-arch'
+  - Execute selected task or stay in persona to help guided by Core DevOps Principles
 agent:
   name: Alex
   id: infra-devops-platform
@@ -70,11 +74,6 @@ persona:
     - CI/CD Excellence - Build robust pipelines for fast, safe, reliable software delivery through automation and testing
     - Disaster Recovery - Plan for worst-case scenarios with backup strategies and regularly tested recovery procedures
     - Collaborative Operations - Work closely with development teams fostering shared responsibility for system reliability
-startup:
-  - Announce: Hey! I'm Alex, your DevOps Infrastructure Specialist. I love when things run secure, stable, reliable and performant. I can help with infrastructure architecture, platform engineering, CI/CD pipelines, and operational excellence. What infrastructure challenge can I help you with today?
-  - 'List available tasks: review-infrastructure, validate-infrastructure, create infrastructure documentation'
-  - 'List available templates: infrastructure-architecture, infrastructure-platform-from-arch'
-  - Execute selected task or stay in persona to help guided by Core DevOps Principles
 commands:
   - '*help" - Show: numbered list of the following commands to allow selection'
   - '*chat-mode" - (Default) Conversational mode for infrastructure and DevOps guidance'
@@ -85,116 +84,102 @@ commands:
   - '*exit" - Say goodbye as Alex, the DevOps Infrastructure Specialist, and then abandon inhabiting this persona'
 dependencies:
   tasks:
-    - create-doc
-    - review-infrastructure
-    - validate-infrastructure
+    - create-doc.md
+    - review-infrastructure.md
+    - validate-infrastructure.md
   templates:
-    - infrastructure-architecture-tmpl
-    - infrastructure-platform-from-arch-tmpl
+    - infrastructure-architecture-tmpl.yaml
+    - infrastructure-platform-from-arch-tmpl.yaml
   checklists:
-    - infrastructure-checklist
+    - infrastructure-checklist.md
   data:
-    - technical-preferences
-  utils:
-    - template-format
+    - technical-preferences.md
 ```
-==================== END: agents#infra-devops-platform ====================
-
-==================== START: tasks#create-doc ====================
-# Create Document from Template Task
-
-## Purpose
-
-Generate documents from templates by EXECUTING (not just reading) embedded instructions from the perspective of the selected agent persona.
-
-## CRITICAL RULES
+==================== END: .bmad-infrastructure-devops/agents/infra-devops-platform.md ====================
 
-1. **Templates are PROGRAMS** - Execute every [[LLM:]] instruction exactly as written
-2. **NEVER show markup** - Hide all [[LLM:]], {{placeholders}}, @{examples}, and template syntax
-3. **STOP and EXECUTE** - When you see "apply tasks#" or "execute tasks#", STOP and run that task immediately
-4. **WAIT for user input** - At review points and after elicitation tasks
+==================== START: .bmad-infrastructure-devops/tasks/create-doc.md ====================
+# Create Document from Template (YAML Driven)
 
-## Execution Flow
+## CRITICAL: Mandatory Elicitation Format
 
-### 0. Check Workflow Plan (if configured)
+**When `elicit: true`, ALWAYS use this exact format:**
 
-[[LLM: Check if plan tracking is enabled in core-config.yaml]]
+1. Present section content
+2. Provide detailed rationale (explain trade-offs, assumptions, decisions made)
+3. Present numbered options 1-9:
+   - **Option 1:** Always "Proceed to next section"
+   - **Options 2-9:** Select 8 methods from data/elicitation-methods
+   - End with: "Select 1-9 or just type your question/feedback:"
 
-- If `workflow.trackProgress: true`, check for active plan using utils#plan-management
-- If plan exists and this document creation is part of the plan:
-  - Verify this is the expected next step
-  - If out of sequence and `enforceSequence: true`, warn user and halt without user override
-  - If out of sequence and `enforceSequence: false`, ask for confirmation
-- Continue with normal execution after plan check
+**NEVER ask yes/no questions or use any other format.**
 
-### 1. Identify Template
+## Processing Flow
 
-- Load from `templates#*` or `{root}/templates directory`
-- Agent-specific templates are listed in agent's dependencies
-- If agent has `templates: [prd-tmpl, architecture-tmpl]` for example, then offer to create "PRD" and "Architecture" documents
+1. **Parse YAML template** - Load template metadata and sections
+2. **Set preferences** - Show current mode (Interactive), confirm output file
+3. **Process each section:**
+   - Skip if condition unmet
+   - Check agent permissions (owner/editors) - note if section is restricted to specific agents
+   - Draft content using section instruction
+   - Present content + detailed rationale
+   - **IF elicit: true** → MANDATORY 1-9 options format
+   - Save to file if possible
+4. **Continue until complete**
 
-### 2. Ask Interaction Mode
+## Detailed Rationale Requirements
 
-> 1. **Incremental** - Section by section with reviews
-> 2. **YOLO Mode** - Complete draft then review (user can type `/yolo` anytime to switch)
+When presenting section content, ALWAYS include rationale that explains:
 
-### 3. Execute Template
+- Trade-offs and choices made (what was chosen over alternatives and why)
+- Key assumptions made during drafting
+- Interesting or questionable decisions that need user attention
+- Areas that might need validation
 
-- Replace {{placeholders}} with real content
-- Execute [[LLM:]] instructions as you encounter them
-- Process <<REPEAT>> loops and ^^CONDITIONS^^
-- Use @{examples} for guidance but never output them
+## Elicitation Results Flow
 
-### 4. Key Execution Patterns
+After user selects elicitation method (2-9):
 
-**When you see:** `[[LLM: Draft X and immediately execute tasks#advanced-elicitation]]`
+1. Execute method from data/elicitation-methods
+2. Present results with insights
+3. Offer options:
+   - **1. Apply changes and update section**
+   - **2. Return to elicitation menu**
+   - **3. Ask any questions or engage further with this elicitation**
 
-- Draft the content
-- Present it to user
-- IMMEDIATELY execute the task
-- Wait for completion before continuing
+## Agent Permissions
 
-**When you see:** `[[LLM: After section completion, apply tasks#Y]]`
+When processing sections with agent permission fields:
 
-- Finish the section
-- STOP and execute the task
-- Wait for user input
+- **owner**: Note which agent role initially creates/populates the section
+- **editors**: List agent roles allowed to modify the section
+- **readonly**: Mark sections that cannot be modified after creation
 
-### 5. Validation & Final Presentation
+**For sections with restricted access:**
 
-- Run any specified checklists
-- Present clean, formatted content only
-- No truncation or summarization
-- Begin directly with content (no preamble)
-- Include any handoff prompts from template
+- Include a note in the generated document indicating the responsible agent
+- Example: "_(This section is owned by dev-agent and can only be modified by dev-agent)_"
 
-### 6. Update Workflow Plan (if applicable)
+## YOLO Mode
 
-[[LLM: After successful document creation]]
+User can type `#yolo` to toggle to YOLO mode (process all sections at once).
 
-- If plan tracking is enabled and document was part of plan:
-  - Call update-workflow-plan task to mark step complete
-  - Parameters: task: create-doc, step_id: {from plan}, status: complete
-  - Show next recommended step from plan
+## CRITICAL REMINDERS
 
-## Common Mistakes to Avoid
+**❌ NEVER:**
 
-❌ Skipping elicitation tasks
-❌ Showing template markup to users
-❌ Continuing past STOP signals
-❌ Combining multiple review points
+- Ask yes/no questions for elicitation
+- Use any format other than 1-9 numbered options
+- Create new elicitation methods
 
-✅ Execute ALL instructions in sequence
-✅ Present only clean, formatted content
-✅ Stop at every elicitation point
-✅ Wait for user confirmation when instructed
+**✅ ALWAYS:**
 
-## Remember
+- Use exact 1-9 format when elicit: true
+- Select options 2-9 from data/elicitation-methods only
+- Provide detailed rationale explaining decisions
+- End with "Select 1-9 or just type your question/feedback:"
+==================== END: .bmad-infrastructure-devops/tasks/create-doc.md ====================
 
-Templates contain precise instructions for a reason. Follow them exactly to ensure document quality and completeness.
-==================== END: tasks#create-doc ====================
-
-==================== START: tasks#review-infrastructure ====================
+==================== START: .bmad-infrastructure-devops/tasks/review-infrastructure.md ====================
 # Infrastructure Review Task
 
 ## Purpose
@@ -355,9 +340,9 @@ Present the user with the following list of 'Advanced Reflective, Elicitation &
 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: tasks#review-infrastructure ====================
+==================== END: .bmad-infrastructure-devops/tasks/review-infrastructure.md ====================
 
-==================== START: tasks#validate-infrastructure ====================
+==================== START: .bmad-infrastructure-devops/tasks/validate-infrastructure.md ====================
 # Infrastructure Validation Task
 
 ## Purpose
@@ -512,1045 +497,1068 @@ Present the user with the following list of 'Advanced Reflective, Elicitation &
 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: tasks#validate-infrastructure ====================
-
-==================== START: templates#infrastructure-architecture-tmpl ====================
-# {{Project Name}} Infrastructure Architecture
-
-[[LLM: Initial Setup
-
-1. Replace {{Project Name}} with the actual project name throughout the document
-2. Gather and review required inputs:
-   - Product Requirements Document (PRD) - Required for business needs and scale requirements
-   - Main System Architecture - Required for infrastructure dependencies
-   - Technical Preferences/Tech Stack Document - Required for technology choices
-   - PRD Technical Assumptions - Required for cross-referencing repository and service architecture
-
-If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
-
-3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
-
-Output file location: `docs/infrastructure-architecture.md`]]
-
-## Infrastructure Overview
-
-[[LLM: 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). Cross-reference with PRD Technical Assumptions to ensure alignment with repository and service architecture decisions.]]
-
-- Cloud Provider(s)
-- Core Services & Resources
-- Regional Architecture
-- Multi-environment Strategy
-
-@{example: cloud_strategy}
-
-- **Cloud Provider:** AWS (primary), with multi-cloud capability for critical services
-- **Core Services:** EKS for container orchestration, RDS for databases, S3 for storage, CloudFront for CDN
-- **Regional Architecture:** Multi-region active-passive with primary in us-east-1, DR in us-west-2
-- **Multi-environment Strategy:** Development, Staging, UAT, Production with identical infrastructure patterns
-
-@{/example}
-
-[[LLM: Infrastructure Elicitation Options
-Present user with domain-specific elicitation options:
-"For the Infrastructure Overview section, I can explore:
-
-1. **Multi-Cloud Strategy Analysis** - Evaluate cloud provider options and vendor lock-in considerations
-2. **Regional Distribution Planning** - Analyze latency requirements and data residency needs
-3. **Environment Isolation Strategy** - Design security boundaries and resource segregation
-4. **Scalability Patterns Review** - Assess auto-scaling needs and traffic patterns
-5. **Compliance Requirements Analysis** - Review regulatory and security compliance needs
-6. **Cost-Benefit Analysis** - Compare infrastructure options and TCO
-7. **Proceed to next section**
-
-Select an option (1-7):"]]
-
-## Infrastructure as Code (IaC)
-
-[[LLM: Define IaC approach based on technical preferences and existing patterns. Consider team expertise, tooling ecosystem, and maintenance requirements.]]
-
-- Tools & Frameworks
-- Repository Structure
-- State Management
-- Dependency Management
-
-<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
-
-## Environment Configuration
-
-[[LLM: Design environment strategy that supports the development workflow while maintaining security and cost efficiency. Reference the Environment Transition Strategy section for promotion details.]]
-
-- Environment Promotion Strategy
-- Configuration Management
-- Secret Management
-- Feature Flag Integration
-
-<<REPEAT: environment>>
-
-### {{environment_name}} Environment
-
-- **Purpose:** {{environment_purpose}}
-- **Resources:** {{environment_resources}}
-- **Access Control:** {{environment_access}}
-- **Data Classification:** {{environment_data_class}}
-
-<</REPEAT>>
-
-## Environment Transition Strategy
-
-[[LLM: Detail the complete lifecycle of code and configuration changes from development to production. Include governance, testing gates, and rollback procedures.]]
-
-- Development to Production Pipeline
-- Deployment Stages and Gates
-- Approval Workflows and Authorities
-- Rollback Procedures
-- Change Cadence and Release Windows
-- Environment-Specific Configuration Management
-
-## Network Architecture
-
-[[LLM: Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
-
-Create Mermaid diagram showing:
-
-- VPC/Network structure
-- Security zones and boundaries
-- Traffic flow patterns
-- Load balancer placement
-- Service mesh topology (if applicable)]]
-
-- VPC/VNET Design
-- Subnet Strategy
-- Security Groups & NACLs
-- Load Balancers & API Gateways
-- Service Mesh (if applicable)
-
-```mermaid
-graph TB
-    subgraph "Production VPC"
-        subgraph "Public Subnets"
-            ALB[Application Load Balancer]
-        end
-        subgraph "Private Subnets"
-            EKS[EKS Cluster]
-            RDS[(RDS Database)]
-        end
-    end
-    Internet((Internet)) --> ALB
-    ALB --> EKS
-    EKS --> RDS
-```
-
-^^CONDITION: uses_service_mesh^^
-
-### Service Mesh Architecture
-
-- **Mesh Technology:** {{service_mesh_tech}}
-- **Traffic Management:** {{traffic_policies}}
-- **Security Policies:** {{mesh_security}}
-- **Observability Integration:** {{mesh_observability}}
-
-^^/CONDITION: uses_service_mesh^^
-
-## Compute Resources
-
-[[LLM: Select compute strategy based on application architecture (microservices, serverless, monolithic). Consider cost, scalability, and operational complexity.]]
-
-- Container Strategy
-- Serverless Architecture
-- VM/Instance Configuration
-- Auto-scaling Approach
-
-^^CONDITION: uses_kubernetes^^
-
-### Kubernetes Architecture
-
-- **Cluster Configuration:** {{k8s_cluster_config}}
-- **Node Groups:** {{k8s_node_groups}}
-- **Networking:** {{k8s_networking}}
-- **Storage Classes:** {{k8s_storage}}
-- **Security Policies:** {{k8s_security}}
-
-^^/CONDITION: uses_kubernetes^^
-
-## Data Resources
-
-[[LLM: Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
-
-Create data flow diagram showing:
-
-- Database topology
-- Replication patterns
-- Backup flows
-- Data migration paths]]
-
-- Database Deployment Strategy
-- Backup & Recovery
-- Replication & Failover
-- Data Migration Strategy
-
-## Security Architecture
-
-[[LLM: Implement defense-in-depth strategy. Reference security requirements from PRD and compliance needs. Consider zero-trust principles where applicable.]]
-
-- IAM & Authentication
-- Network Security
-- Data Encryption
-- Compliance Controls
-- Security Scanning & Monitoring
-
-<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
-
-## Shared Responsibility Model
-
-[[LLM: Clearly define boundaries between cloud provider, platform team, development team, and security team responsibilities. This is critical for operational success.]]
-
-- Cloud Provider Responsibilities
-- Platform Team Responsibilities
-- Development Team Responsibilities
-- Security Team Responsibilities
-- Operational Monitoring Ownership
-- Incident Response Accountability Matrix
-
-@{example: responsibility_matrix}
-
-| Component            | Cloud Provider | Platform Team | Dev Team       | Security Team |
-| -------------------- | -------------- | ------------- | -------------- | ------------- |
-| Physical Security    | ✓              | -             | -              | Audit         |
-| Network Security     | Partial        | ✓             | Config         | Audit         |
-| Application Security | -              | Tools         | ✓              | Review        |
-| Data Encryption      | Engine         | Config        | Implementation | Standards     |
-
-@{/example}
-
-## Monitoring & Observability
-
-[[LLM: Design comprehensive observability strategy covering metrics, logs, traces, and business KPIs. Ensure alignment with SLA/SLO requirements.]]
-
-- Metrics Collection
-- Logging Strategy
-- Tracing Implementation
-- Alerting & Incident Response
-- Dashboards & Visualization
-
-## CI/CD Pipeline
-
-[[LLM: Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
-
-Create pipeline diagram showing:
-
-- Build stages
-- Test gates
-- Deployment stages
-- Approval points
-- Rollback triggers]]
-
-- Pipeline Architecture
-- Build Process
-- Deployment Strategy
-- Rollback Procedures
-- Approval Gates
-
-^^CONDITION: uses_progressive_deployment^^
-
-### Progressive Deployment Strategy
-
-- **Canary Deployment:** {{canary_config}}
-- **Blue-Green Deployment:** {{blue_green_config}}
-- **Feature Flags:** {{feature_flag_integration}}
-- **Traffic Splitting:** {{traffic_split_rules}}
-
-^^/CONDITION: uses_progressive_deployment^^
-
-## Disaster Recovery
-
-[[LLM: Design DR strategy based on business continuity requirements. Define clear RTO/RPO targets and ensure they align with business needs.]]
-
-- Backup Strategy
-- Recovery Procedures
-- RTO & RPO Targets
-- DR Testing Approach
-
-<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
-
-## Cost Optimization
-
-[[LLM: Balance cost efficiency with performance and reliability requirements. Include both immediate optimizations and long-term strategies.]]
-
-- Resource Sizing Strategy
-- Reserved Instances/Commitments
-- Cost Monitoring & Reporting
-- Optimization Recommendations
-
-## BMad Integration Architecture
-
-[[LLM: Design infrastructure to specifically support other BMad agents and their workflows. This ensures the infrastructure enables the entire BMad methodology.]]
-
-### Development Agent Support
-
-- Container platform for development environments
-- GitOps workflows for application deployment
-- Service mesh integration for development testing
-- Developer self-service platform capabilities
-
-### Product & Architecture Alignment
-
-- Infrastructure implementing PRD scalability requirements
-- Deployment automation supporting product iteration speed
-- Service reliability meeting product SLAs
-- Architecture patterns properly implemented in infrastructure
-
-### Cross-Agent Integration Points
-
-- CI/CD pipelines supporting Frontend, Backend, and Full Stack development workflows
-- Monitoring and observability data accessible to QA and DevOps agents
-- Infrastructure enabling Design Architect's UI/UX performance requirements
-- Platform supporting Analyst's data collection and analysis needs
-
-## DevOps/Platform Feasibility Review
-
-[[LLM: CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
-
-- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
-- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
-- **Security Implementation:** Are security patterns achievable with current security toolchain?
-- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
-- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
-
-Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
-
-<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>]]
-
-### Feasibility Assessment Results
-
-- **Green Light Items:** {{feasible_items}}
-- **Yellow Light Items:** {{items_needing_adjustment}}
-- **Red Light Items:** {{items_requiring_redesign}}
-- **Mitigation Strategies:** {{mitigation_plans}}
-
-## Infrastructure Verification
-
-### Validation Framework
-
-This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
-
-- Completeness of architecture documentation
-- Consistency with broader system architecture
-- Appropriate level of detail for different stakeholders
-- Clear implementation guidance
-- Future evolution considerations
-
-### Validation Process
-
-The architecture documentation validation should be performed:
-
-- After initial architecture development
-- After significant architecture changes
-- Before major implementation phases
-- During periodic architecture reviews
-
-The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
-
-## Implementation Handoff
-
-[[LLM: Create structured handoff documentation for implementation team. This ensures architecture decisions are properly communicated and implemented.]]
-
-### Architecture Decision Records (ADRs)
-
-Create ADRs for key infrastructure decisions:
-
-- Cloud provider selection rationale
-- Container orchestration platform choice
-- Networking architecture decisions
-- Security implementation choices
-- Cost optimization trade-offs
-
-### Implementation Validation Criteria
-
-Define specific criteria for validating correct implementation:
-
-- Infrastructure as Code quality gates
-- Security compliance checkpoints
-- Performance benchmarks
-- Cost targets
-- Operational readiness criteria
-
-### Knowledge Transfer Requirements
-
-- Technical documentation for operations team
-- Runbook creation requirements
-- Training needs for platform team
-- Handoff meeting agenda items
-
-## Infrastructure Evolution
-
-[[LLM: Document the long-term vision and evolution path for the infrastructure. Consider technology trends, anticipated growth, and technical debt management.]]
-
-- Technical Debt Inventory
-- Planned Upgrades and Migrations
-- Deprecation Schedule
-- Technology Roadmap
-- Capacity Planning
-- Scalability Considerations
-
-## Integration with Application Architecture
-
-[[LLM: Map infrastructure components to application services. Ensure infrastructure design supports application requirements and patterns defined in main architecture.]]
-
-- Service-to-Infrastructure Mapping
-- Application Dependency Matrix
-- Performance Requirements Implementation
-- Security Requirements Implementation
-- Data Flow to Infrastructure Correlation
-- API Gateway and Service Mesh Integration
-
-## Cross-Team Collaboration
-
-[[LLM: Define clear interfaces and communication patterns between teams. This section is critical for operational success and should include specific touchpoints and escalation paths.]]
-
-- Platform Engineer and Developer Touchpoints
-- Frontend/Backend Integration Requirements
-- Product Requirements to Infrastructure Mapping
-- Architecture Decision Impact Analysis
-- Design Architect UI/UX Infrastructure Requirements
-- Analyst Research Integration
-
-## Infrastructure Change Management
-
-[[LLM: Define structured process for infrastructure changes. Include risk assessment, testing requirements, and rollback procedures.]]
-
-- Change Request Process
-- Risk Assessment
-- Testing Strategy
-- Validation Procedures
-
-[[LLM: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.]]
-
----
-
-_Document Version: 1.0_
-_Last Updated: {{current_date}}_
-_Next Review: {{review_date}}_
-==================== END: templates#infrastructure-architecture-tmpl ====================
-
-==================== START: templates#infrastructure-platform-from-arch-tmpl ====================
-# {{Project Name}} Platform Infrastructure Implementation
-
-[[LLM: Initial Setup
-
-1. Replace {{Project Name}} with the actual project name throughout the document
-2. Gather and review required inputs:
-
-   - **Infrastructure Architecture Document** (Primary input - REQUIRED)
-   - Infrastructure Change Request (if applicable)
-   - Infrastructure Guidelines
-   - Technology Stack Document
-   - Infrastructure Checklist
-   - NOTE: If Infrastructure Architecture Document is missing, HALT and request: "I need the Infrastructure Architecture Document to proceed with platform implementation. This document defines the infrastructure design that we'll be implementing."
-
-3. Validate that the infrastructure architecture has been reviewed and approved
-4. <critical_rule>All platform implementation must align with the approved infrastructure architecture. Any deviations require architect approval.</critical_rule>
-
-Output file location: `docs/platform-infrastructure/platform-implementation.md`]]
-
-## Executive Summary
-
-[[LLM: Provide a high-level overview of the platform infrastructure being implemented, referencing the infrastructure architecture document's key decisions and requirements.]]
-
-- Platform implementation scope and objectives
-- Key architectural decisions being implemented
-- Expected outcomes and benefits
-- Timeline and milestones
-
-## Joint Planning Session with Architect
-
-[[LLM: Document the collaborative planning session between DevOps/Platform Engineer and Architect. This ensures alignment before implementation begins.]]
-
-### Architecture Alignment Review
-
-- Review of infrastructure architecture document
-- Confirmation of design decisions
-- Identification of any ambiguities or gaps
-- Agreement on implementation approach
-
-### Implementation Strategy Collaboration
-
-- Platform layer sequencing
-- Technology stack validation
-- Integration approach between layers
-- Testing and validation strategy
-
-### Risk & Constraint Discussion
-
-- Technical risks and mitigation strategies
-- Resource constraints and workarounds
-- Timeline considerations
-- Compliance and security requirements
-
-### Implementation Validation Planning
-
-- Success criteria for each platform layer
-- Testing approach and acceptance criteria
-- Rollback strategies
-- Communication plan
-
-### Documentation & Knowledge Transfer Planning
-
-- Documentation requirements
-- Knowledge transfer approach
-- Training needs identification
-- Handoff procedures
-
-## Foundation Infrastructure Layer
-
-[[LLM: Implement the base infrastructure layer based on the infrastructure architecture. This forms the foundation for all platform services.]]
-
-### Cloud Provider Setup
-
-- Account/Subscription configuration
-- Region selection and setup
-- Resource group/organizational structure
-- Cost management setup
-
-### Network Foundation
-
-```hcl
-# Example Terraform for VPC setup
-module "vpc" {
-  source = "./modules/vpc"
-
-  cidr_block = "{{vpc_cidr}}"
-  availability_zones = {{availability_zones}}
-  public_subnets = {{public_subnets}}
-  private_subnets = {{private_subnets}}
-}
-```
-
-### Security Foundation
-
-- IAM roles and policies
-- Security groups and NACLs
-- Encryption keys (KMS/Key Vault)
-- Compliance controls
-
-### Core Services
-
-- DNS configuration
-- Certificate management
-- Logging infrastructure
-- Monitoring foundation
-
-[[LLM: Platform Layer Elicitation
-After implementing foundation infrastructure, present:
-"For the Foundation Infrastructure layer, I can explore:
-
-1. **Platform Layer Security Hardening** - Additional security controls and compliance validation
-2. **Performance Optimization** - Network and resource optimization
-3. **Operational Excellence Enhancement** - Automation and monitoring improvements
-4. **Platform Integration Validation** - Verify foundation supports upper layers
-5. **Developer Experience Analysis** - Foundation impact on developer workflows
-6. **Disaster Recovery Testing** - Foundation resilience validation
-7. **BMAD Workflow Integration** - Cross-agent support verification
-8. **Finalize and Proceed to Container Platform**
-
-Select an option (1-8):"]]
-
-## Container Platform Implementation
-
-[[LLM: Build the container orchestration platform on top of the foundation infrastructure, following the architecture's container strategy.]]
-
-### Kubernetes Cluster Setup
-
-^^CONDITION: uses_eks^^
-
-```bash
-# EKS Cluster Configuration
-eksctl create cluster \
-  --name {{cluster_name}} \
-  --region {{aws_region}} \
-  --nodegroup-name {{nodegroup_name}} \
-  --node-type {{instance_type}} \
-  --nodes {{node_count}}
-```
-
-^^/CONDITION: uses_eks^^
-
-^^CONDITION: uses_aks^^
-
-```bash
-# AKS Cluster Configuration
-az aks create \
-  --resource-group {{resource_group}} \
-  --name {{cluster_name}} \
-  --node-count {{node_count}} \
-  --node-vm-size {{vm_size}} \
-  --network-plugin azure
-```
-
-^^/CONDITION: uses_aks^^
-
-### Node Configuration
-
-- Node groups/pools setup
-- Autoscaling configuration
-- Node security hardening
-- Resource quotas and limits
-
-### Cluster Services
-
-- CoreDNS configuration
-- Ingress controller setup
-- Certificate management
-- Storage classes
-
-### Security & RBAC
-
-- RBAC policies
-- Pod security policies/standards
-- Network policies
-- Secrets management
-
-[[LLM: Present container platform elicitation options similar to foundation layer]]
-
-## GitOps Workflow Implementation
-
-[[LLM: Implement GitOps patterns for declarative infrastructure and application management as defined in the architecture.]]
-
-### GitOps Tooling Setup
-
-^^CONDITION: uses_argocd^^
-
-```yaml
-apiVersion: argoproj.io/v1alpha1
-kind: Application
-metadata:
-  name: argocd
-  namespace: argocd
-spec:
-  source:
-    repoURL:
-      "[object Object]": null
-    targetRevision:
-      "[object Object]": null
-    path:
-      "[object Object]": null
-```
-
-^^/CONDITION: uses_argocd^^
-
-^^CONDITION: uses_flux^^
-
-```yaml
-apiVersion: source.toolkit.fluxcd.io/v1beta2
-kind: GitRepository
-metadata:
-  name: flux-system
-  namespace: flux-system
-spec:
-  interval: 1m
-  ref:
-    branch:
-      "[object Object]": null
-  url:
-    "[object Object]": null
-```
-
-^^/CONDITION: uses_flux^^
-
-### Repository Structure
-
-```text
-platform-gitops/
- clusters/
-    production/
-    staging/
-    development/
- infrastructure/
-    base/
-    overlays/
- applications/
-     base/
-     overlays/
-```
-
-### Deployment Workflows
-
-- Application deployment patterns
-- Progressive delivery setup
-- Rollback procedures
-- Multi-environment promotion
-
-### Access Control
-
-- Git repository permissions
-- GitOps tool RBAC
-- Secret management integration
-- Audit logging
-
-## Service Mesh Implementation
-
-[[LLM: Deploy service mesh for advanced traffic management, security, and observability as specified in the architecture.]]
-
-^^CONDITION: uses_istio^^
-
-### Istio Service Mesh
-
-```bash
-# Istio Installation
-istioctl install --set profile={{istio_profile}} \
-  --set values.gateways.istio-ingressgateway.type={{ingress_type}}
-```
-
-- Control plane configuration
-- Data plane injection
-- Gateway configuration
-- Observability integration
-  ^^/CONDITION: uses_istio^^
-
-^^CONDITION: uses_linkerd^^
-
-### Linkerd Service Mesh
-
-```bash
-# Linkerd Installation
-linkerd install --cluster-name={{cluster_name}} | kubectl apply -f -
-linkerd viz install | kubectl apply -f -
-```
-
-- Control plane setup
-- Proxy injection
-- Traffic policies
-- Metrics collection
-  ^^/CONDITION: uses_linkerd^^
-
-### Traffic Management
-
-- Load balancing policies
-- Circuit breakers
-- Retry policies
-- Canary deployments
-
-### Security Policies
-
-- mTLS configuration
-- Authorization policies
-- Rate limiting
-- Network segmentation
-
-## Developer Experience Platform
-
-[[LLM: Build the developer self-service platform to enable efficient development workflows as outlined in the architecture.]]
-
-### Developer Portal
-
-- Service catalog setup
-- API documentation
-- Self-service workflows
-- Resource provisioning
-
-### CI/CD Integration
-
-```yaml
-apiVersion: tekton.dev/v1beta1
-kind: Pipeline
-metadata:
-  name: platform-pipeline
-spec:
-  tasks:
-    - name: build
-      taskRef:
-        name: build-task
-    - name: test
-      taskRef:
-        name: test-task
-    - name: deploy
-      taskRef:
-        name: gitops-deploy
-```
-
-### Development Tools
-
-- Local development setup
-- Remote development environments
-- Testing frameworks
-- Debugging tools
-
-### Self-Service Capabilities
-
-- Environment provisioning
-- Database creation
-- Feature flag management
-- Configuration management
-
-## Platform Integration & Security Hardening
-
-[[LLM: Implement comprehensive platform-wide integration and security controls across all layers.]]
-
-### End-to-End Security
-
-- Platform-wide security policies
-- Cross-layer authentication
-- Encryption in transit and at rest
-- Compliance validation
-
-### Integrated Monitoring
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: prometheus-config
-data:
-  prometheus.yaml: |
-    global:
-      scrape_interval: {{scrape_interval}}
-    scrape_configs:
-      - job_name: 'kubernetes-pods'
-        kubernetes_sd_configs:
-          - role: pod
-```
-
-### Platform Observability
-
-- Metrics aggregation
-- Log collection and analysis
-- Distributed tracing
-- Dashboard creation
-
-### Backup & Disaster Recovery
-
-- Platform backup strategy
-- Disaster recovery procedures
-- RTO/RPO validation
-- Recovery testing
-
-## Platform Operations & Automation
-
-[[LLM: Establish operational procedures and automation for platform management.]]
-
-### Monitoring & Alerting
-
-- SLA/SLO monitoring
-- Alert routing
-- Incident response
-- Performance baselines
-
-### Automation Framework
-
-```yaml
-apiVersion: operators.coreos.com/v1alpha1
-kind: ClusterServiceVersion
-metadata:
-  name: platform-operator
-spec:
-  customresourcedefinitions:
-    owned:
-      - name: platformconfigs.platform.io
-        version: v1alpha1
-```
-
-### Maintenance Procedures
-
-- Upgrade procedures
-- Patch management
-- Certificate rotation
-- Capacity management
-
-### Operational Runbooks
-
-- Common operational tasks
-- Troubleshooting guides
-- Emergency procedures
-- Recovery playbooks
-
-## BMAD Workflow Integration
-
-[[LLM: Validate that the platform supports all BMAD agent workflows and cross-functional requirements.]]
-
-### Development Agent Support
-
-- Frontend development workflows
-- Backend development workflows
-- Full-stack integration
-- Local development experience
-
-### Infrastructure-as-Code Development
-
-- IaC development workflows
-- Testing frameworks
-- Deployment automation
-- Version control integration
-
-### Cross-Agent Collaboration
-
-- Shared services access
-- Communication patterns
-- Data sharing mechanisms
-- Security boundaries
-
-### CI/CD Integration
-
-```yaml
-stages:
-  - analyze
-  - plan
-  - architect
-  - develop
-  - test
-  - deploy
-```
-
-## Platform Validation & Testing
-
-[[LLM: Execute comprehensive validation to ensure the platform meets all requirements.]]
-
-### Functional Testing
-
-- Component testing
-- Integration testing
-- End-to-end testing
-- Performance testing
-
-### Security Validation
-
-- Penetration testing
-- Compliance scanning
-- Vulnerability assessment
-- Access control validation
-
-### Disaster Recovery Testing
-
-- Backup restoration
-- Failover procedures
-- Recovery time validation
-- Data integrity checks
-
-### Load Testing
-
-```typescript
-// K6 Load Test Example
-import http from 'k6/http';
-import { check } from 'k6';
-
-export let options = {
-  stages: [
-    { duration: '5m', target: {{target_users}} },
-    { duration: '10m', target: {{target_users}} },
-    { duration: '5m', target: 0 },
-  ],
-};
-```
-
-## Knowledge Transfer & Documentation
-
-[[LLM: Prepare comprehensive documentation and knowledge transfer materials.]]
-
-### Platform Documentation
-
-- Architecture documentation
-- Operational procedures
-- Configuration reference
-- API documentation
-
-### Training Materials
-
-- Developer guides
-- Operations training
-- Security best practices
-- Troubleshooting guides
-
-### Handoff Procedures
-
-- Team responsibilities
-- Escalation procedures
-- Support model
-- Knowledge base
-
-## Implementation Review with Architect
-
-[[LLM: Document the post-implementation review session with the Architect to validate alignment and capture learnings.]]
-
-### Implementation Validation
-
-- Architecture alignment verification
-- Deviation documentation
-- Performance validation
-- Security review
-
-### Lessons Learned
-
-- What went well
-- Challenges encountered
-- Process improvements
-- Technical insights
-
-### Future Evolution
-
-- Enhancement opportunities
-- Technical debt items
-- Upgrade planning
-- Capacity planning
-
-### Sign-off & Acceptance
-
-- Architect approval
-- Stakeholder acceptance
-- Go-live authorization
-- Support transition
-
-## Platform Metrics & KPIs
-
-[[LLM: Define and implement key performance indicators for platform success measurement.]]
-
-### Technical Metrics
-
-- Platform availability: {{availability_target}}
-- Response time: {{response_time_target}}
-- Resource utilization: {{utilization_target}}
-- Error rates: {{error_rate_target}}
-
-### Business Metrics
-
-- Developer productivity
-- Deployment frequency
-- Lead time for changes
-- Mean time to recovery
-
-### Operational Metrics
-
-- Incident response time
-- Patch compliance
-- Cost per workload
-- Resource efficiency
-
-## Appendices
-
-### A. Configuration Reference
-
-[[LLM: Document all configuration parameters and their values used in the platform implementation.]]
-
-### B. Troubleshooting Guide
-
-[[LLM: Provide common issues and their resolutions for platform operations.]]
-
-### C. Security Controls Matrix
-
-[[LLM: Map implemented security controls to compliance requirements.]]
-
-### D. Integration Points
-
-[[LLM: Document all integration points with external systems and services.]]
-
-[[LLM: Final Review - Ensure all platform layers are properly implemented, integrated, and documented. Verify that the implementation fully supports the BMAD methodology and all agent workflows. Confirm successful validation against the infrastructure checklist.]]
-
----
-
-_Platform Version: 1.0_
-_Implementation Date: {{implementation_date}}_
-_Next Review: {{review_date}}_
-_Approved by: {{architect_name}} (Architect), {{devops_name}} (DevOps/Platform Engineer)_
-==================== END: templates#infrastructure-platform-from-arch-tmpl ====================
-
-==================== START: checklists#infrastructure-checklist ====================
+==================== END: .bmad-infrastructure-devops/tasks/validate-infrastructure.md ====================
+
+==================== START: .bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.yaml ====================
+template:
+  id: infrastructure-architecture-template-v2
+  name: Infrastructure Architecture
+  version: 2.0
+  output:
+    format: markdown
+    filename: docs/infrastructure-architecture.md
+    title: "{{project_name}} Infrastructure Architecture"
+
+workflow:
+  mode: interactive
+  elicitation: advanced-elicitation
+  custom_elicitation:
+    title: "Infrastructure Architecture Elicitation Actions"
+    sections:
+      - id: infrastructure-overview
+        options:
+          - "Multi-Cloud Strategy Analysis - Evaluate cloud provider options and vendor lock-in considerations"
+          - "Regional Distribution Planning - Analyze latency requirements and data residency needs"
+          - "Environment Isolation Strategy - Design security boundaries and resource segregation"
+          - "Scalability Patterns Review - Assess auto-scaling needs and traffic patterns"
+          - "Compliance Requirements Analysis - Review regulatory and security compliance needs"
+          - "Cost-Benefit Analysis - Compare infrastructure options and TCO"
+          - "Proceed to next section"
+
+sections:
+  - id: initial-setup
+    instruction: |
+      Initial Setup
+      
+      1. Replace {{project_name}} with the actual project name throughout the document
+      2. Gather and review required inputs:
+         - Product Requirements Document (PRD) - Required for business needs and scale requirements
+         - Main System Architecture - Required for infrastructure dependencies
+         - Technical Preferences/Tech Stack Document - Required for technology choices
+         - PRD Technical Assumptions - Required for cross-referencing repository and service architecture
+      
+      If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
+      
+      3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
+      
+      Output file location: `docs/infrastructure-architecture.md`
+
+  - id: infrastructure-overview
+    title: Infrastructure Overview
+    instruction: |
+      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). Cross-reference with PRD Technical Assumptions to ensure alignment with repository and service architecture decisions.
+    elicit: true
+    custom_elicitation: infrastructure-overview
+    template: |
+      - Cloud Provider(s)
+      - Core Services & Resources
+      - Regional Architecture
+      - Multi-environment Strategy
+    examples:
+      - |
+        - **Cloud Provider:** AWS (primary), with multi-cloud capability for critical services
+        - **Core Services:** EKS for container orchestration, RDS for databases, S3 for storage, CloudFront for CDN
+        - **Regional Architecture:** Multi-region active-passive with primary in us-east-1, DR in us-west-2
+        - **Multi-environment Strategy:** Development, Staging, UAT, Production with identical infrastructure patterns
+
+  - id: iac
+    title: Infrastructure as Code (IaC)
+    instruction: Define IaC approach based on technical preferences and existing patterns. Consider team expertise, tooling ecosystem, and maintenance requirements.
+    template: |
+      - Tools & Frameworks
+      - Repository Structure
+      - State Management
+      - Dependency Management
+      
+      <critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
+
+  - id: environment-configuration
+    title: Environment Configuration
+    instruction: Design environment strategy that supports the development workflow while maintaining security and cost efficiency. Reference the Environment Transition Strategy section for promotion details.
+    template: |
+      - Environment Promotion Strategy
+      - Configuration Management
+      - Secret Management
+      - Feature Flag Integration
+    sections:
+      - id: environments
+        repeatable: true
+        title: "{{environment_name}} Environment"
+        template: |
+          - **Purpose:** {{environment_purpose}}
+          - **Resources:** {{environment_resources}}
+          - **Access Control:** {{environment_access}}
+          - **Data Classification:** {{environment_data_class}}
+
+  - id: environment-transition
+    title: Environment Transition Strategy
+    instruction: Detail the complete lifecycle of code and configuration changes from development to production. Include governance, testing gates, and rollback procedures.
+    template: |
+      - Development to Production Pipeline
+      - Deployment Stages and Gates
+      - Approval Workflows and Authorities
+      - Rollback Procedures
+      - Change Cadence and Release Windows
+      - Environment-Specific Configuration Management
+
+  - id: network-architecture
+    title: Network Architecture
+    instruction: |
+      Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
+      
+      Create Mermaid diagram showing:
+      - VPC/Network structure
+      - Security zones and boundaries
+      - Traffic flow patterns
+      - Load balancer placement
+      - Service mesh topology (if applicable)
+    template: |
+      - VPC/VNET Design
+      - Subnet Strategy
+      - Security Groups & NACLs
+      - Load Balancers & API Gateways
+      - Service Mesh (if applicable)
+    sections:
+      - id: network-diagram
+        type: mermaid
+        mermaid_type: graph
+        template: |
+          graph TB
+              subgraph "Production VPC"
+                  subgraph "Public Subnets"
+                      ALB[Application Load Balancer]
+                  end
+                  subgraph "Private Subnets"
+                      EKS[EKS Cluster]
+                      RDS[(RDS Database)]
+                  end
+              end
+              Internet((Internet)) --> ALB
+              ALB --> EKS
+              EKS --> RDS
+      - id: service-mesh
+        title: Service Mesh Architecture
+        condition: Uses service mesh
+        template: |
+          - **Mesh Technology:** {{service_mesh_tech}}
+          - **Traffic Management:** {{traffic_policies}}
+          - **Security Policies:** {{mesh_security}}
+          - **Observability Integration:** {{mesh_observability}}
+
+  - id: compute-resources
+    title: Compute Resources
+    instruction: Select compute strategy based on application architecture (microservices, serverless, monolithic). Consider cost, scalability, and operational complexity.
+    template: |
+      - Container Strategy
+      - Serverless Architecture
+      - VM/Instance Configuration
+      - Auto-scaling Approach
+    sections:
+      - id: kubernetes
+        title: Kubernetes Architecture
+        condition: Uses Kubernetes
+        template: |
+          - **Cluster Configuration:** {{k8s_cluster_config}}
+          - **Node Groups:** {{k8s_node_groups}}
+          - **Networking:** {{k8s_networking}}
+          - **Storage Classes:** {{k8s_storage}}
+          - **Security Policies:** {{k8s_security}}
+
+  - id: data-resources
+    title: Data Resources
+    instruction: |
+      Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
+      
+      Create data flow diagram showing:
+      - Database topology
+      - Replication patterns
+      - Backup flows
+      - Data migration paths
+    template: |
+      - Database Deployment Strategy
+      - Backup & Recovery
+      - Replication & Failover
+      - Data Migration Strategy
+
+  - id: security-architecture
+    title: Security Architecture
+    instruction: Implement defense-in-depth strategy. Reference security requirements from PRD and compliance needs. Consider zero-trust principles where applicable.
+    template: |
+      - IAM & Authentication
+      - Network Security
+      - Data Encryption
+      - Compliance Controls
+      - Security Scanning & Monitoring
+      
+      <critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
+
+  - id: shared-responsibility
+    title: Shared Responsibility Model
+    instruction: Clearly define boundaries between cloud provider, platform team, development team, and security team responsibilities. This is critical for operational success.
+    template: |
+      - Cloud Provider Responsibilities
+      - Platform Team Responsibilities
+      - Development Team Responsibilities
+      - Security Team Responsibilities
+      - Operational Monitoring Ownership
+      - Incident Response Accountability Matrix
+    examples:
+      - |
+        | Component            | Cloud Provider | Platform Team | Dev Team       | Security Team |
+        | -------------------- | -------------- | ------------- | -------------- | ------------- |
+        | Physical Security    | ✓              | -             | -              | Audit         |
+        | Network Security     | Partial        | ✓             | Config         | Audit         |
+        | Application Security | -              | Tools         | ✓              | Review        |
+        | Data Encryption      | Engine         | Config        | Implementation | Standards     |
+
+  - id: monitoring-observability
+    title: Monitoring & Observability
+    instruction: Design comprehensive observability strategy covering metrics, logs, traces, and business KPIs. Ensure alignment with SLA/SLO requirements.
+    template: |
+      - Metrics Collection
+      - Logging Strategy
+      - Tracing Implementation
+      - Alerting & Incident Response
+      - Dashboards & Visualization
+
+  - id: cicd-pipeline
+    title: CI/CD Pipeline
+    instruction: |
+      Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
+      
+      Create pipeline diagram showing:
+      - Build stages
+      - Test gates
+      - Deployment stages
+      - Approval points
+      - Rollback triggers
+    template: |
+      - Pipeline Architecture
+      - Build Process
+      - Deployment Strategy
+      - Rollback Procedures
+      - Approval Gates
+    sections:
+      - id: progressive-deployment
+        title: Progressive Deployment Strategy
+        condition: Uses progressive deployment
+        template: |
+          - **Canary Deployment:** {{canary_config}}
+          - **Blue-Green Deployment:** {{blue_green_config}}
+          - **Feature Flags:** {{feature_flag_integration}}
+          - **Traffic Splitting:** {{traffic_split_rules}}
+
+  - id: disaster-recovery
+    title: Disaster Recovery
+    instruction: Design DR strategy based on business continuity requirements. Define clear RTO/RPO targets and ensure they align with business needs.
+    template: |
+      - Backup Strategy
+      - Recovery Procedures
+      - RTO & RPO Targets
+      - DR Testing Approach
+      
+      <critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
+
+  - id: cost-optimization
+    title: Cost Optimization
+    instruction: Balance cost efficiency with performance and reliability requirements. Include both immediate optimizations and long-term strategies.
+    template: |
+      - Resource Sizing Strategy
+      - Reserved Instances/Commitments
+      - Cost Monitoring & Reporting
+      - Optimization Recommendations
+
+  - id: bmad-integration
+    title: BMad Integration Architecture
+    instruction: Design infrastructure to specifically support other BMad agents and their workflows. This ensures the infrastructure enables the entire BMad methodology.
+    sections:
+      - id: dev-agent-support
+        title: Development Agent Support
+        template: |
+          - Container platform for development environments
+          - GitOps workflows for application deployment
+          - Service mesh integration for development testing
+          - Developer self-service platform capabilities
+      - id: product-architecture-alignment
+        title: Product & Architecture Alignment
+        template: |
+          - Infrastructure implementing PRD scalability requirements
+          - Deployment automation supporting product iteration speed
+          - Service reliability meeting product SLAs
+          - Architecture patterns properly implemented in infrastructure
+      - id: cross-agent-integration
+        title: Cross-Agent Integration Points
+        template: |
+          - CI/CD pipelines supporting Frontend, Backend, and Full Stack development workflows
+          - Monitoring and observability data accessible to QA and DevOps agents
+          - Infrastructure enabling Design Architect's UI/UX performance requirements
+          - Platform supporting Analyst's data collection and analysis needs
+
+  - id: feasibility-review
+    title: DevOps/Platform Feasibility Review
+    instruction: |
+      CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
+      
+      - **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
+      - **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
+      - **Security Implementation:** Are security patterns achievable with current security toolchain?
+      - **Operational Overhead:** Will the proposed architecture create excessive operational burden?
+      - **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
+      
+      Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
+      
+      <critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>
+    sections:
+      - id: feasibility-results
+        title: Feasibility Assessment Results
+        template: |
+          - **Green Light Items:** {{feasible_items}}
+          - **Yellow Light Items:** {{items_needing_adjustment}}
+          - **Red Light Items:** {{items_requiring_redesign}}
+          - **Mitigation Strategies:** {{mitigation_plans}}
+
+  - id: infrastructure-verification
+    title: Infrastructure Verification
+    sections:
+      - id: validation-framework
+        title: Validation Framework
+        content: |
+          This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
+          
+          - Completeness of architecture documentation
+          - Consistency with broader system architecture
+          - Appropriate level of detail for different stakeholders
+          - Clear implementation guidance
+          - Future evolution considerations
+      - id: validation-process
+        title: Validation Process
+        content: |
+          The architecture documentation validation should be performed:
+          
+          - After initial architecture development
+          - After significant architecture changes
+          - Before major implementation phases
+          - During periodic architecture reviews
+          
+          The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
+
+  - id: implementation-handoff
+    title: Implementation Handoff
+    instruction: Create structured handoff documentation for implementation team. This ensures architecture decisions are properly communicated and implemented.
+    sections:
+      - id: adrs
+        title: Architecture Decision Records (ADRs)
+        content: |
+          Create ADRs for key infrastructure decisions:
+          
+          - Cloud provider selection rationale
+          - Container orchestration platform choice
+          - Networking architecture decisions
+          - Security implementation choices
+          - Cost optimization trade-offs
+      - id: implementation-validation
+        title: Implementation Validation Criteria
+        content: |
+          Define specific criteria for validating correct implementation:
+          
+          - Infrastructure as Code quality gates
+          - Security compliance checkpoints
+          - Performance benchmarks
+          - Cost targets
+          - Operational readiness criteria
+      - id: knowledge-transfer
+        title: Knowledge Transfer Requirements
+        template: |
+          - Technical documentation for operations team
+          - Runbook creation requirements
+          - Training needs for platform team
+          - Handoff meeting agenda items
+
+  - id: infrastructure-evolution
+    title: Infrastructure Evolution
+    instruction: Document the long-term vision and evolution path for the infrastructure. Consider technology trends, anticipated growth, and technical debt management.
+    template: |
+      - Technical Debt Inventory
+      - Planned Upgrades and Migrations
+      - Deprecation Schedule
+      - Technology Roadmap
+      - Capacity Planning
+      - Scalability Considerations
+
+  - id: app-integration
+    title: Integration with Application Architecture
+    instruction: Map infrastructure components to application services. Ensure infrastructure design supports application requirements and patterns defined in main architecture.
+    template: |
+      - Service-to-Infrastructure Mapping
+      - Application Dependency Matrix
+      - Performance Requirements Implementation
+      - Security Requirements Implementation
+      - Data Flow to Infrastructure Correlation
+      - API Gateway and Service Mesh Integration
+
+  - id: cross-team-collaboration
+    title: Cross-Team Collaboration
+    instruction: Define clear interfaces and communication patterns between teams. This section is critical for operational success and should include specific touchpoints and escalation paths.
+    template: |
+      - Platform Engineer and Developer Touchpoints
+      - Frontend/Backend Integration Requirements
+      - Product Requirements to Infrastructure Mapping
+      - Architecture Decision Impact Analysis
+      - Design Architect UI/UX Infrastructure Requirements
+      - Analyst Research Integration
+
+  - id: change-management
+    title: Infrastructure Change Management
+    instruction: Define structured process for infrastructure changes. Include risk assessment, testing requirements, and rollback procedures.
+    template: |
+      - Change Request Process
+      - Risk Assessment
+      - Testing Strategy
+      - Validation Procedures
+
+  - id: final-review
+    instruction: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.
+    content: |
+      ---
+      
+      _Document Version: 1.0_
+      _Last Updated: {{current_date}}_
+      _Next Review: {{review_date}}_
+==================== END: .bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.yaml ====================
+
+==================== START: .bmad-infrastructure-devops/templates/infrastructure-platform-from-arch-tmpl.yaml ====================
+template:
+  id: infrastructure-platform-template-v2
+  name: Platform Infrastructure Implementation
+  version: 2.0
+  output:
+    format: markdown
+    filename: docs/platform-infrastructure/platform-implementation.md
+    title: "{{project_name}} Platform Infrastructure Implementation"
+
+workflow:
+  mode: interactive
+  elicitation: advanced-elicitation
+  custom_elicitation:
+    title: "Platform Implementation Elicitation Actions"
+    sections:
+      - id: foundation-infrastructure
+        options:
+          - "Platform Layer Security Hardening - Additional security controls and compliance validation"
+          - "Performance Optimization - Network and resource optimization"
+          - "Operational Excellence Enhancement - Automation and monitoring improvements"
+          - "Platform Integration Validation - Verify foundation supports upper layers"
+          - "Developer Experience Analysis - Foundation impact on developer workflows"
+          - "Disaster Recovery Testing - Foundation resilience validation"
+          - "BMAD Workflow Integration - Cross-agent support verification"
+          - "Finalize and Proceed to Container Platform"
+
+sections:
+  - id: initial-setup
+    instruction: |
+      Initial Setup
+      
+      1. Replace {{project_name}} with the actual project name throughout the document
+      2. Gather and review required inputs:
+         - **Infrastructure Architecture Document** (Primary input - REQUIRED)
+         - Infrastructure Change Request (if applicable)
+         - Infrastructure Guidelines
+         - Technology Stack Document
+         - Infrastructure Checklist
+         - NOTE: If Infrastructure Architecture Document is missing, HALT and request: "I need the Infrastructure Architecture Document to proceed with platform implementation. This document defines the infrastructure design that we'll be implementing."
+      
+      3. Validate that the infrastructure architecture has been reviewed and approved
+      4. <critical_rule>All platform implementation must align with the approved infrastructure architecture. Any deviations require architect approval.</critical_rule>
+      
+      Output file location: `docs/platform-infrastructure/platform-implementation.md`
+
+  - id: executive-summary
+    title: Executive Summary
+    instruction: Provide a high-level overview of the platform infrastructure being implemented, referencing the infrastructure architecture document's key decisions and requirements.
+    template: |
+      - Platform implementation scope and objectives
+      - Key architectural decisions being implemented
+      - Expected outcomes and benefits
+      - Timeline and milestones
+
+  - id: joint-planning
+    title: Joint Planning Session with Architect
+    instruction: Document the collaborative planning session between DevOps/Platform Engineer and Architect. This ensures alignment before implementation begins.
+    sections:
+      - id: architecture-alignment
+        title: Architecture Alignment Review
+        template: |
+          - Review of infrastructure architecture document
+          - Confirmation of design decisions
+          - Identification of any ambiguities or gaps
+          - Agreement on implementation approach
+      - id: implementation-strategy
+        title: Implementation Strategy Collaboration
+        template: |
+          - Platform layer sequencing
+          - Technology stack validation
+          - Integration approach between layers
+          - Testing and validation strategy
+      - id: risk-constraint
+        title: Risk & Constraint Discussion
+        template: |
+          - Technical risks and mitigation strategies
+          - Resource constraints and workarounds
+          - Timeline considerations
+          - Compliance and security requirements
+      - id: validation-planning
+        title: Implementation Validation Planning
+        template: |
+          - Success criteria for each platform layer
+          - Testing approach and acceptance criteria
+          - Rollback strategies
+          - Communication plan
+      - id: documentation-planning
+        title: Documentation & Knowledge Transfer Planning
+        template: |
+          - Documentation requirements
+          - Knowledge transfer approach
+          - Training needs identification
+          - Handoff procedures
+
+  - id: foundation-infrastructure
+    title: Foundation Infrastructure Layer
+    instruction: Implement the base infrastructure layer based on the infrastructure architecture. This forms the foundation for all platform services.
+    elicit: true
+    custom_elicitation: foundation-infrastructure
+    sections:
+      - id: cloud-provider-setup
+        title: Cloud Provider Setup
+        template: |
+          - Account/Subscription configuration
+          - Region selection and setup
+          - Resource group/organizational structure
+          - Cost management setup
+      - id: network-foundation
+        title: Network Foundation
+        type: code
+        language: hcl
+        template: |
+          # Example Terraform for VPC setup
+          module "vpc" {
+            source = "./modules/vpc"
+          
+            cidr_block = "{{vpc_cidr}}"
+            availability_zones = {{availability_zones}}
+            public_subnets = {{public_subnets}}
+            private_subnets = {{private_subnets}}
+          }
+      - id: security-foundation
+        title: Security Foundation
+        template: |
+          - IAM roles and policies
+          - Security groups and NACLs
+          - Encryption keys (KMS/Key Vault)
+          - Compliance controls
+      - id: core-services
+        title: Core Services
+        template: |
+          - DNS configuration
+          - Certificate management
+          - Logging infrastructure
+          - Monitoring foundation
+
+  - id: container-platform
+    title: Container Platform Implementation
+    instruction: Build the container orchestration platform on top of the foundation infrastructure, following the architecture's container strategy.
+    sections:
+      - id: kubernetes-setup
+        title: Kubernetes Cluster Setup
+        sections:
+          - id: eks-setup
+            condition: Uses EKS
+            type: code
+            language: bash
+            template: |
+              # EKS Cluster Configuration
+              eksctl create cluster \
+                --name {{cluster_name}} \
+                --region {{aws_region}} \
+                --nodegroup-name {{nodegroup_name}} \
+                --node-type {{instance_type}} \
+                --nodes {{node_count}}
+          - id: aks-setup
+            condition: Uses AKS
+            type: code
+            language: bash
+            template: |
+              # AKS Cluster Configuration
+              az aks create \
+                --resource-group {{resource_group}} \
+                --name {{cluster_name}} \
+                --node-count {{node_count}} \
+                --node-vm-size {{vm_size}} \
+                --network-plugin azure
+      - id: node-configuration
+        title: Node Configuration
+        template: |
+          - Node groups/pools setup
+          - Autoscaling configuration
+          - Node security hardening
+          - Resource quotas and limits
+      - id: cluster-services
+        title: Cluster Services
+        template: |
+          - CoreDNS configuration
+          - Ingress controller setup
+          - Certificate management
+          - Storage classes
+      - id: security-rbac
+        title: Security & RBAC
+        template: |
+          - RBAC policies
+          - Pod security policies/standards
+          - Network policies
+          - Secrets management
+
+  - id: gitops-workflow
+    title: GitOps Workflow Implementation
+    instruction: Implement GitOps patterns for declarative infrastructure and application management as defined in the architecture.
+    sections:
+      - id: gitops-tooling
+        title: GitOps Tooling Setup
+        sections:
+          - id: argocd-setup
+            condition: Uses ArgoCD
+            type: code
+            language: yaml
+            template: |
+              apiVersion: argoproj.io/v1alpha1
+              kind: Application
+              metadata:
+                name: argocd
+                namespace: argocd
+              spec:
+                source:
+                  repoURL: {{repo_url}}
+                  targetRevision: {{target_revision}}
+                  path: {{path}}
+          - id: flux-setup
+            condition: Uses Flux
+            type: code
+            language: yaml
+            template: |
+              apiVersion: source.toolkit.fluxcd.io/v1beta2
+              kind: GitRepository
+              metadata:
+                name: flux-system
+                namespace: flux-system
+              spec:
+                interval: 1m
+                ref:
+                  branch: {{branch}}
+                url: {{git_url}}
+      - id: repository-structure
+        title: Repository Structure
+        type: code
+        language: text
+        template: |
+          platform-gitops/
+             clusters/
+                production/
+                staging/
+                development/
+             infrastructure/
+                base/
+                overlays/
+             applications/
+                 base/
+                 overlays/
+      - id: deployment-workflows
+        title: Deployment Workflows
+        template: |
+          - Application deployment patterns
+          - Progressive delivery setup
+          - Rollback procedures
+          - Multi-environment promotion
+      - id: access-control
+        title: Access Control
+        template: |
+          - Git repository permissions
+          - GitOps tool RBAC
+          - Secret management integration
+          - Audit logging
+
+  - id: service-mesh
+    title: Service Mesh Implementation
+    instruction: Deploy service mesh for advanced traffic management, security, and observability as specified in the architecture.
+    sections:
+      - id: istio-mesh
+        title: Istio Service Mesh
+        condition: Uses Istio
+        sections:
+          - id: istio-install
+            type: code
+            language: bash
+            template: |
+              # Istio Installation
+              istioctl install --set profile={{istio_profile}} \
+                --set values.gateways.istio-ingressgateway.type={{ingress_type}}
+          - id: istio-config
+            template: |
+              - Control plane configuration
+              - Data plane injection
+              - Gateway configuration
+              - Observability integration
+      - id: linkerd-mesh
+        title: Linkerd Service Mesh
+        condition: Uses Linkerd
+        sections:
+          - id: linkerd-install
+            type: code
+            language: bash
+            template: |
+              # Linkerd Installation
+              linkerd install --cluster-name={{cluster_name}} | kubectl apply -f -
+              linkerd viz install | kubectl apply -f -
+          - id: linkerd-config
+            template: |
+              - Control plane setup
+              - Proxy injection
+              - Traffic policies
+              - Metrics collection
+      - id: traffic-management
+        title: Traffic Management
+        template: |
+          - Load balancing policies
+          - Circuit breakers
+          - Retry policies
+          - Canary deployments
+      - id: security-policies
+        title: Security Policies
+        template: |
+          - mTLS configuration
+          - Authorization policies
+          - Rate limiting
+          - Network segmentation
+
+  - id: developer-experience
+    title: Developer Experience Platform
+    instruction: Build the developer self-service platform to enable efficient development workflows as outlined in the architecture.
+    sections:
+      - id: developer-portal
+        title: Developer Portal
+        template: |
+          - Service catalog setup
+          - API documentation
+          - Self-service workflows
+          - Resource provisioning
+      - id: cicd-integration
+        title: CI/CD Integration
+        type: code
+        language: yaml
+        template: |
+          apiVersion: tekton.dev/v1beta1
+          kind: Pipeline
+          metadata:
+            name: platform-pipeline
+          spec:
+            tasks:
+              - name: build
+                taskRef:
+                  name: build-task
+              - name: test
+                taskRef:
+                  name: test-task
+              - name: deploy
+                taskRef:
+                  name: gitops-deploy
+      - id: development-tools
+        title: Development Tools
+        template: |
+          - Local development setup
+          - Remote development environments
+          - Testing frameworks
+          - Debugging tools
+      - id: self-service
+        title: Self-Service Capabilities
+        template: |
+          - Environment provisioning
+          - Database creation
+          - Feature flag management
+          - Configuration management
+
+  - id: platform-integration
+    title: Platform Integration & Security Hardening
+    instruction: Implement comprehensive platform-wide integration and security controls across all layers.
+    sections:
+      - id: end-to-end-security
+        title: End-to-End Security
+        template: |
+          - Platform-wide security policies
+          - Cross-layer authentication
+          - Encryption in transit and at rest
+          - Compliance validation
+      - id: integrated-monitoring
+        title: Integrated Monitoring
+        type: code
+        language: yaml
+        template: |
+          apiVersion: v1
+          kind: ConfigMap
+          metadata:
+            name: prometheus-config
+          data:
+            prometheus.yaml: |
+              global:
+                scrape_interval: {{scrape_interval}}
+              scrape_configs:
+                - job_name: 'kubernetes-pods'
+                  kubernetes_sd_configs:
+                    - role: pod
+      - id: platform-observability
+        title: Platform Observability
+        template: |
+          - Metrics aggregation
+          - Log collection and analysis
+          - Distributed tracing
+          - Dashboard creation
+      - id: backup-dr
+        title: Backup & Disaster Recovery
+        template: |
+          - Platform backup strategy
+          - Disaster recovery procedures
+          - RTO/RPO validation
+          - Recovery testing
+
+  - id: platform-operations
+    title: Platform Operations & Automation
+    instruction: Establish operational procedures and automation for platform management.
+    sections:
+      - id: monitoring-alerting
+        title: Monitoring & Alerting
+        template: |
+          - SLA/SLO monitoring
+          - Alert routing
+          - Incident response
+          - Performance baselines
+      - id: automation-framework
+        title: Automation Framework
+        type: code
+        language: yaml
+        template: |
+          apiVersion: operators.coreos.com/v1alpha1
+          kind: ClusterServiceVersion
+          metadata:
+            name: platform-operator
+          spec:
+            customresourcedefinitions:
+              owned:
+                - name: platformconfigs.platform.io
+                  version: v1alpha1
+      - id: maintenance-procedures
+        title: Maintenance Procedures
+        template: |
+          - Upgrade procedures
+          - Patch management
+          - Certificate rotation
+          - Capacity management
+      - id: operational-runbooks
+        title: Operational Runbooks
+        template: |
+          - Common operational tasks
+          - Troubleshooting guides
+          - Emergency procedures
+          - Recovery playbooks
+
+  - id: bmad-workflow-integration
+    title: BMAD Workflow Integration
+    instruction: Validate that the platform supports all BMAD agent workflows and cross-functional requirements.
+    sections:
+      - id: development-agent-support
+        title: Development Agent Support
+        template: |
+          - Frontend development workflows
+          - Backend development workflows
+          - Full-stack integration
+          - Local development experience
+      - id: iac-development
+        title: Infrastructure-as-Code Development
+        template: |
+          - IaC development workflows
+          - Testing frameworks
+          - Deployment automation
+          - Version control integration
+      - id: cross-agent-collaboration
+        title: Cross-Agent Collaboration
+        template: |
+          - Shared services access
+          - Communication patterns
+          - Data sharing mechanisms
+          - Security boundaries
+      - id: cicd-integration-workflow
+        title: CI/CD Integration
+        type: code
+        language: yaml
+        template: |
+          stages:
+            - analyze
+            - plan
+            - architect
+            - develop
+            - test
+            - deploy
+
+  - id: platform-validation
+    title: Platform Validation & Testing
+    instruction: Execute comprehensive validation to ensure the platform meets all requirements.
+    sections:
+      - id: functional-testing
+        title: Functional Testing
+        template: |
+          - Component testing
+          - Integration testing
+          - End-to-end testing
+          - Performance testing
+      - id: security-validation
+        title: Security Validation
+        template: |
+          - Penetration testing
+          - Compliance scanning
+          - Vulnerability assessment
+          - Access control validation
+      - id: dr-testing
+        title: Disaster Recovery Testing
+        template: |
+          - Backup restoration
+          - Failover procedures
+          - Recovery time validation
+          - Data integrity checks
+      - id: load-testing
+        title: Load Testing
+        type: code
+        language: typescript
+        template: |
+          // K6 Load Test Example
+          import http from 'k6/http';
+          import { check } from 'k6';
+          
+          export let options = {
+            stages: [
+              { duration: '5m', target: {{target_users}} },
+              { duration: '10m', target: {{target_users}} },
+              { duration: '5m', target: 0 },
+            ],
+          };
+
+  - id: knowledge-transfer
+    title: Knowledge Transfer & Documentation
+    instruction: Prepare comprehensive documentation and knowledge transfer materials.
+    sections:
+      - id: platform-documentation
+        title: Platform Documentation
+        template: |
+          - Architecture documentation
+          - Operational procedures
+          - Configuration reference
+          - API documentation
+      - id: training-materials
+        title: Training Materials
+        template: |
+          - Developer guides
+          - Operations training
+          - Security best practices
+          - Troubleshooting guides
+      - id: handoff-procedures
+        title: Handoff Procedures
+        template: |
+          - Team responsibilities
+          - Escalation procedures
+          - Support model
+          - Knowledge base
+
+  - id: implementation-review
+    title: Implementation Review with Architect
+    instruction: Document the post-implementation review session with the Architect to validate alignment and capture learnings.
+    sections:
+      - id: implementation-validation
+        title: Implementation Validation
+        template: |
+          - Architecture alignment verification
+          - Deviation documentation
+          - Performance validation
+          - Security review
+      - id: lessons-learned
+        title: Lessons Learned
+        template: |
+          - What went well
+          - Challenges encountered
+          - Process improvements
+          - Technical insights
+      - id: future-evolution
+        title: Future Evolution
+        template: |
+          - Enhancement opportunities
+          - Technical debt items
+          - Upgrade planning
+          - Capacity planning
+      - id: sign-off
+        title: Sign-off & Acceptance
+        template: |
+          - Architect approval
+          - Stakeholder acceptance
+          - Go-live authorization
+          - Support transition
+
+  - id: platform-metrics
+    title: Platform Metrics & KPIs
+    instruction: Define and implement key performance indicators for platform success measurement.
+    sections:
+      - id: technical-metrics
+        title: Technical Metrics
+        template: |
+          - Platform availability: {{availability_target}}
+          - Response time: {{response_time_target}}
+          - Resource utilization: {{utilization_target}}
+          - Error rates: {{error_rate_target}}
+      - id: business-metrics
+        title: Business Metrics
+        template: |
+          - Developer productivity
+          - Deployment frequency
+          - Lead time for changes
+          - Mean time to recovery
+      - id: operational-metrics
+        title: Operational Metrics
+        template: |
+          - Incident response time
+          - Patch compliance
+          - Cost per workload
+          - Resource efficiency
+
+  - id: appendices
+    title: Appendices
+    sections:
+      - id: config-reference
+        title: A. Configuration Reference
+        instruction: Document all configuration parameters and their values used in the platform implementation.
+      - id: troubleshooting
+        title: B. Troubleshooting Guide
+        instruction: Provide common issues and their resolutions for platform operations.
+      - id: security-controls
+        title: C. Security Controls Matrix
+        instruction: Map implemented security controls to compliance requirements.
+      - id: integration-points
+        title: D. Integration Points
+        instruction: Document all integration points with external systems and services.
+
+  - id: final-review
+    instruction: Final Review - Ensure all platform layers are properly implemented, integrated, and documented. Verify that the implementation fully supports the BMAD methodology and all agent workflows. Confirm successful validation against the infrastructure checklist.
+    content: |
+      ---
+      
+      _Platform Version: 1.0_
+      _Implementation Date: {{implementation_date}}_
+      _Next Review: {{review_date}}_
+      _Approved by: {{architect_name}} (Architect), {{devops_name}} (DevOps/Platform Engineer)_
+==================== END: .bmad-infrastructure-devops/templates/infrastructure-platform-from-arch-tmpl.yaml ====================
+
+==================== START: .bmad-infrastructure-devops/checklists/infrastructure-checklist.md ====================
 # Infrastructure Change Validation Checklist
 
 This checklist serves as a comprehensive framework for validating infrastructure changes before deployment to production. The DevOps/Platform Engineer should systematically work through each item, ensuring the infrastructure is secure, compliant, resilient, and properly implemented according to organizational standards.
@@ -2035,39 +2043,10 @@ This checklist serves as a comprehensive framework for validating infrastructure
 - [ ] Local development environment compatibility verified
 - [ ] Platform component integration validated
 - [ ] Cross-platform functionality tested and verified
-==================== END: checklists#infrastructure-checklist ====================
+==================== END: .bmad-infrastructure-devops/checklists/infrastructure-checklist.md ====================
 
-==================== START: data#technical-preferences ====================
+==================== START: .bmad-infrastructure-devops/data/technical-preferences.md ====================
 # User-Defined Preferred Patterns and Preferences
 
 None Listed
-==================== END: data#technical-preferences ====================
-
-==================== START: utils#template-format ====================
-# Template Format Conventions
-
-Templates in the BMad method use standardized markup for AI processing. These conventions ensure consistent document generation.
-
-## Template Markup Elements
-
-- **{{placeholders}}**: Variables to be replaced with actual content
-- **[[LLM: instructions]]**: Internal processing instructions for AI agents (never shown to users)
-- **REPEAT** sections: Content blocks that may be repeated as needed
-- **^^CONDITION^^** blocks: Conditional content included only if criteria are met
-- **@{examples}**: Example content for guidance (never output to users)
-
-## Processing Rules
-
-- Replace all {{placeholders}} with project-specific content
-- Execute all [[LLM: instructions]] internally without showing users
-- Process conditional and repeat blocks as specified
-- Use examples for guidance but never include them in final output
-- Present only clean, formatted content to users
-
-## Critical Guidelines
-
-- **NEVER display template markup, LLM instructions, or examples to users**
-- Template elements are for AI processing only
-- Focus on faithful template execution and clean output
-- All template-specific instructions are embedded within templates
-==================== END: utils#template-format ====================
+==================== END: .bmad-infrastructure-devops/data/technical-preferences.md ====================