bmad-method 5.0.0 → 5.0.1

package/docs/windsurf-guide.md

@@ -1,127 +0,0 @@
-# BMAD Method Guide for Windsurf
-
-This guide walks you through the complete BMAD workflow using Windsurf as your AI-powered IDE.
-
-## Step 1: Install BMAD in Your Project
-
-1. Navigate to your project directory
-2. Run the BMAD installer:
-   ```bash
-   npx bmad-method install
-   ```
-3. When prompted:
-   - **Installation Type**: Choose "Complete installation (recommended)"
-   - **IDE**: Select "Windsurf"
-
-This creates a `.bmad-core` folder with all agents and a `.windsurf/rules` folder with agent rules.
-
-## Step 2: Set Up Team Fullstack in Gemini
-
-For ideation and planning, use Google's Gemini with the team-fullstack configuration:
-
-1. Open [Google AI Studio (Gemini)](https://aistudio.google.com/)
-2. Create a new chat
-3. Copy the contents of `/Users/brianmadison/dev/BMAD-METHOD/.bmad-core/web-bundles/teams/team-fullstack.txt`
-4. Paste this content into Gemini to set up the team
-
-### Gemini Planning Phase
-
-In Gemini, ask the BMAD team to help you:
-
-- **Ideate** your project concept
-- **Brainstorm** features and requirements
-- **Create a PRD** (Product Requirements Document)
-- **Design the architecture**
-
-Ask questions like:
-
-- "Help me brainstorm a [type of application] that does [core functionality]"
-- "Create a comprehensive PRD for this concept"
-- "Design the technical architecture for this system"
-
-Copy the PRD and architecture documents that Gemini creates into your project's `docs/` folder:
-
-- `docs/prd.md`
-- `docs/architecture.md`
-
-## Step 3: Back to Windsurf - Document Sharding
-
-Once you have your PRD and architecture documents in the `docs/` folder:
-
-1. **Start a new chat in Windsurf**
-2. **Load the bmad-master agent**: Type `@bmad-master`
-3. **Shard the PRD**: Type `*shard-doc docs/prd.md prd`
-4. **Shard the architecture**: Type `*shard-doc docs/architecture.md architecture`
-
-This creates organized folders:
-
-- `docs/prd/` - Contains broken down PRD sections
-- `docs/architecture/` - Contains broken down architecture sections
-
-## Step 4: Story Development Cycle
-
-Now begin the iterative development cycle:
-
-### Create Stories (Scrum Master)
-
-1. **Start a new chat**
-2. **Load SM agent**: Type `@sm`
-3. **Create story**: Type `*create` (this runs the create-next-story task)
-4. **Review the generated story**
-5. **If approved**: Set story status to "Approved" in the story file
-
-### Implement Stories (Developer)
-
-1. **Start a new chat**
-2. **Load Dev agent**: Type `@dev`
-3. **The agent will ask which story to implement**
-4. **Follow the development tasks** the agent provides
-5. **When story is complete**: Mark status as "Done"
-
-### Repeat the Cycle
-
-1. **Start a new chat with SM agent** (`@sm`)
-2. **Create next story**: Type `*create`
-3. **Review and approve**
-4. **Start new chat with Dev agent** (`@dev`)
-5. **Implement the story**
-6. **Repeat until project complete**
-
-## Available Agent Rules in Windsurf
-
-All BMAD agents are available as Windsurf rules (use `@` prefix):
-
-- `@bmad-master` - Universal task executor
-- `@sm` - Scrum Master for story creation
-- `@dev` - Full-stack developer for implementation
-- `@architect` - Solution architect for design
-- `@pm` - Product manager for planning
-- `@analyst` - Business analyst for requirements
-- `@qa` - QA specialist for testing
-- `@po` - Product owner for prioritization
-- `@ux-expert` - UX specialist for design
-
-## Windsurf-Specific Features
-
-- **Agent rules are stored in**: `.windsurf/rules/` as `.md` files
-- **Rule activation**: Rules activate when you mention `@agent-name` in chat
-- **Collaborative workflow**: Windsurf's collaborative features work well with BMAD's agent-switching pattern
-- **Context awareness**: Agents have access to your project context
-
-## Key Workflow Principles
-
-1. **Always start new chats** when switching agents to avoid context confusion
-2. **Use Gemini for initial planning** and ideation with the team-fullstack bundle
-3. **Use bmad-master for document management** (sharding, templates, etc.)
-4. **Follow the SM → Dev cycle** for consistent story development
-5. **Review and approve stories** before implementation begins
-
-## Tips for Success
-
-- **Keep chats focused**: Each chat should have one agent and one primary task
-- **Use \*help command**: Every agent supports `*help` to see available commands
-- **Review generated content**: Always review and approve stories before marking them ready
-- **Maintain status updates**: Keep story statuses current (Draft → Approved → InProgress → Done)
-- **Leverage Windsurf's collaboration**: Use the collaborative features for team reviews
-
-This workflow ensures systematic, AI-assisted development following agile principles with clear handoffs between planning, story creation, and implementation phases.

package/expansion-packs/infrastructure-devops/manifest.yml

@@ -1,38 +0,0 @@
-name: infrastructure
-version: 1.0.0
-description: Infrastructure & DevOps expansion pack for BMAD Method
-author: BMAD Team
-files:
-  - source: agents/infra-devops-platform.yml
-    destination: .bmad-core/agents/infra-devops-platform.yml
-  - source: personas/infra-devops-platform.md
-    destination: .bmad-core/personas/infra-devops-platform.md
-  - source: ide-agents/infra-devops-platform.ide.md
-    destination: .bmad-core/ide-agents/infra-devops-platform.ide.md
-  - source: templates/infrastructure-architecture-tmpl.md
-    destination: .bmad-core/templates/infrastructure-architecture-tmpl.md
-  - source: templates/infrastructure-platform-from-arch-tmpl.md
-    destination: .bmad-core/templates/infrastructure-platform-from-arch-tmpl.md
-  - source: tasks/validate-infrastructure.md
-    destination: .bmad-core/tasks/validate-infrastructure.md
-  - source: tasks/review-infrastructure.md
-    destination: .bmad-core/tasks/review-infrastructure.md
-  - source: checklists/infrastructure-checklist.md
-    destination: .bmad-core/checklists/infrastructure-checklist.md
-team_updates:
-  - team: team-technical.yml
-    add_agent: infra-devops-platform
-  - team: team-all.yml
-    add_agent: infra-devops-platform
-dependencies:
-  - architect
-  - create-doc
-post_install_message: |
-  Infrastructure expansion pack installed successfully!
-
-  The DevOps agent is now available. To use:
-  - "For infrastructure architecture: Use architect agent with '*create-infrastructure"
-  - "For implementation: Use 'npm run agent devops"
-  - "For validation: Use devops agent with '*validate-infra"
-
-  Remember to configure your cloud credentials and technical preferences before use.

package/expansion-packs/infrastructure-devops/templates/infrastructure-architecture-tmpl.md

@@ -1,415 +0,0 @@
-# {{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}}_