appiq-solution 1.3.2 → 1.4.2

package/#Tools/APPIQ-METHOD/deployment/build/expansion-packs/bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.yaml

@@ -1,424 +0,0 @@
-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}}_