bmad-method 4.27.0 → 4.27.2

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

@@ -50,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
@@ -71,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'
@@ -86,113 +84,99 @@ 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: .bmad-infrastructure-devops/agents/infra-devops-platform.md ====================
 
 ==================== START: .bmad-infrastructure-devops/tasks/create-doc.md ====================
-# 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.
+# Create Document from Template (YAML Driven)
 
-## CRITICAL RULES
+## CRITICAL: Mandatory Elicitation Format
 
-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
+**When `elicit: true`, ALWAYS use this exact format:**
 
-## Execution Flow
+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:"
 
-### 0. Check Workflow Plan (if configured)
+**NEVER ask yes/no questions or use any other format.**
 
-[[LLM: Check if plan tracking is enabled in core-config.yaml]]
+## Processing Flow
 
-- If `workflow.trackProgress: true`, check for active plan using .bmad-infrastructure-devops/utils/plan-management.md
-- 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
+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**
 
-### 1. Identify Template
+## Detailed Rationale Requirements
 
-- Load from `.bmad-infrastructure-devops/templates/*.md` or `.bmad-infrastructure-devops/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
+When presenting section content, ALWAYS include rationale that explains:
 
-### 2. Ask Interaction Mode
+- 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
 
-> 1. **Incremental** - Section by section with reviews
-> 2. **YOLO Mode** - Complete draft then review (user can type `/yolo` anytime to switch)
+## Elicitation Results Flow
 
-### 3. Execute Template
+After user selects elicitation method (2-9):
 
-- 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
+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**
 
-### 4. Key Execution Patterns
+## Agent Permissions
 
-**When you see:** `[[LLM: Draft X and immediately execute .bmad-infrastructure-devops/tasks/advanced-elicitation.md]]`
+When processing sections with agent permission fields:
 
-- Draft the content
-- Present it to user
-- IMMEDIATELY execute the task
-- Wait for completion before continuing
+- **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
 
-**When you see:** `[[LLM: After section completion, apply .bmad-infrastructure-devops/tasks/Y.md]]`
+**For sections with restricted access:**
 
-- Finish the section
-- STOP and execute the task
-- Wait for user input
+- 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)_"
 
-### 5. Validation & Final Presentation
+## YOLO Mode
 
-- 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
+User can type `#yolo` to toggle to YOLO mode (process all sections at once).
 
-### 6. Update Workflow Plan (if applicable)
+## CRITICAL REMINDERS
 
-[[LLM: After successful document creation]]
+**❌ NEVER:**
 
-- 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
+- Ask yes/no questions for elicitation
+- Use any format other than 1-9 numbered options
+- Create new elicitation methods
 
-## Common Mistakes to Avoid
+**✅ ALWAYS:**
 
-❌ Skipping elicitation tasks
-❌ Showing template markup to users
-❌ Continuing past STOP signals
-❌ Combining multiple review points
-
-✅ Execute ALL instructions in sequence
-✅ Present only clean, formatted content
-✅ Stop at every elicitation point
-✅ Wait for user confirmation when instructed
-
-## Remember
-
-Templates contain precise instructions for a reason. Follow them exactly to ensure document quality and completeness.
+- 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 ====================
 
 ==================== START: .bmad-infrastructure-devops/tasks/review-infrastructure.md ====================
@@ -515,1041 +499,1064 @@ After I perform the selected action, we can discuss the outcome and decide on an
 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: .bmad-infrastructure-devops/tasks/validate-infrastructure.md ====================
 
-==================== START: .bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.md ====================
-# {{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: .bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.md ====================
-
-==================== START: .bmad-infrastructure-devops/templates/infrastructure-platform-from-arch-tmpl.md ====================
-# {{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: .bmad-infrastructure-devops/templates/infrastructure-platform-from-arch-tmpl.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
@@ -2043,32 +2050,3 @@ This checklist serves as a comprehensive framework for validating infrastructure
 
 None Listed
 ==================== END: .bmad-infrastructure-devops/data/technical-preferences.md ====================
-
-==================== START: .bmad-infrastructure-devops/utils/template-format.md ====================
-# 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: .bmad-infrastructure-devops/utils/template-format.md ====================