@zeyue0329/xiaoma-cli 1.0.8 → 1.0.10

package/expansion-packs/bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.yaml

@@ -0,0 +1,425 @@
+# <!-- Powered by BMAD™ Core -->
+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}}_