Node 20, installer improvements, agent improvements and Expansion Pack for game dev (#232)
* feat: add expansion pack installation system with game dev and infrastructure expansion packs - Added expansion pack discovery and installation to BMAD installer - Supports interactive and CLI installation of expansion packs - Expansion pack files install to destination root (.bmad-core) - Added game development expansion pack (.bmad-2d-phaser-game-dev) - Game designer, developer, and scrum master agents - Game-specific templates, tasks, workflows, and guidelines - Specialized for Phaser 3 + TypeScript development - Added infrastructure devops expansion pack (.bmad-infrastructure-devops) - Platform engineering agent and infrastructure templates - Expansion pack agents automatically integrate with IDE rules - Added list:expansions command and --expansion-packs CLI option 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com> * alpha expansion packs and installer update to support installing expansion packs optionally * node20 --------- Co-authored-by: Brian Madison <brianmadison@Brians-MacBook-Pro.local> Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
441
bmad-core/checklists/po-master-checklist.md
Normal file
441
bmad-core/checklists/po-master-checklist.md
Normal file
@@ -0,0 +1,441 @@
|
||||
# Product Owner (PO) Master Validation Checklist
|
||||
|
||||
This checklist serves as a comprehensive framework for the Product Owner to validate project plans before development execution. It adapts intelligently based on project type (greenfield vs brownfield) and includes UI/UX considerations when applicable.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST
|
||||
|
||||
PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
|
||||
1. Is this a GREENFIELD project (new from scratch)?
|
||||
|
||||
- Look for: New project initialization, no existing codebase references
|
||||
- Check for: prd.md, architecture.md, new project setup stories
|
||||
|
||||
2. Is this a BROWNFIELD project (enhancing existing system)?
|
||||
|
||||
- Look for: References to existing codebase, enhancement/modification language
|
||||
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
||||
|
||||
3. Does the project include UI/UX components?
|
||||
- Check for: frontend-architecture.md, UI/UX specifications, design files
|
||||
- Look for: Frontend stories, component specifications, user interface mentions
|
||||
|
||||
DOCUMENT REQUIREMENTS:
|
||||
Based on project type, ensure you have access to:
|
||||
|
||||
For GREENFIELD projects:
|
||||
|
||||
- prd.md - The Product Requirements Document
|
||||
- architecture.md - The system architecture
|
||||
- frontend-architecture.md - If UI/UX is involved
|
||||
- All epic and story definitions
|
||||
|
||||
For BROWNFIELD projects:
|
||||
|
||||
- brownfield-prd.md - The brownfield enhancement requirements
|
||||
- brownfield-architecture.md - The enhancement architecture
|
||||
- Existing project codebase access (CRITICAL - cannot proceed without this)
|
||||
- Current deployment configuration and infrastructure details
|
||||
- Database schemas, API documentation, monitoring setup
|
||||
|
||||
SKIP INSTRUCTIONS:
|
||||
|
||||
- Skip sections marked [[BROWNFIELD ONLY]] for greenfield projects
|
||||
- Skip sections marked [[GREENFIELD ONLY]] for brownfield projects
|
||||
- Skip sections marked [[UI/UX ONLY]] for backend-only projects
|
||||
- Note all skipped sections in your final report
|
||||
|
||||
VALIDATION APPROACH:
|
||||
|
||||
1. Deep Analysis - Thoroughly analyze each item against documentation
|
||||
2. Evidence-Based - Cite specific sections or code when validating
|
||||
3. Critical Thinking - Question assumptions and identify gaps
|
||||
4. Risk Assessment - Consider what could go wrong with each decision
|
||||
|
||||
EXECUTION MODE:
|
||||
Ask the user if they want to work through the checklist:
|
||||
|
||||
- Section by section (interactive mode) - Review each section, get confirmation before proceeding
|
||||
- All at once (comprehensive mode) - Complete full analysis and present report at end]]
|
||||
|
||||
## 1. PROJECT SETUP & INITIALIZATION
|
||||
|
||||
[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
|
||||
|
||||
### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
|
||||
|
||||
- [ ] Epic 1 includes explicit steps for project creation/initialization
|
||||
- [ ] If using a starter template, steps for cloning/setup are included
|
||||
- [ ] If building from scratch, all necessary scaffolding steps are defined
|
||||
- [ ] Initial README or documentation setup is included
|
||||
- [ ] Repository setup and initial commit processes are defined
|
||||
|
||||
### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
|
||||
|
||||
- [ ] Existing project analysis has been completed and documented
|
||||
- [ ] Integration points with current system are identified
|
||||
- [ ] Development environment preserves existing functionality
|
||||
- [ ] Local testing approach validated for existing features
|
||||
- [ ] Rollback procedures defined for each integration point
|
||||
|
||||
### 1.3 Development Environment
|
||||
|
||||
- [ ] Local development environment setup is clearly defined
|
||||
- [ ] Required tools and versions are specified
|
||||
- [ ] Steps for installing dependencies are included
|
||||
- [ ] Configuration files are addressed appropriately
|
||||
- [ ] Development server setup is included
|
||||
|
||||
### 1.4 Core Dependencies
|
||||
|
||||
- [ ] All critical packages/libraries are installed early
|
||||
- [ ] Package management is properly addressed
|
||||
- [ ] Version specifications are appropriately defined
|
||||
- [ ] Dependency conflicts or special requirements are noted
|
||||
- [ ] [[BROWNFIELD ONLY]] Version compatibility with existing stack verified
|
||||
|
||||
## 2. INFRASTRUCTURE & DEPLOYMENT
|
||||
|
||||
[[LLM: Infrastructure must exist before use. For brownfield, must integrate with existing infrastructure without breaking it.]]
|
||||
|
||||
### 2.1 Database & Data Store Setup
|
||||
|
||||
- [ ] Database selection/setup occurs before any operations
|
||||
- [ ] Schema definitions are created before data operations
|
||||
- [ ] Migration strategies are defined if applicable
|
||||
- [ ] Seed data or initial data setup is included if needed
|
||||
- [ ] [[BROWNFIELD ONLY]] Database migration risks identified and mitigated
|
||||
- [ ] [[BROWNFIELD ONLY]] Backward compatibility ensured
|
||||
|
||||
### 2.2 API & Service Configuration
|
||||
|
||||
- [ ] API frameworks are set up before implementing endpoints
|
||||
- [ ] Service architecture is established before implementing services
|
||||
- [ ] Authentication framework is set up before protected routes
|
||||
- [ ] Middleware and common utilities are created before use
|
||||
- [ ] [[BROWNFIELD ONLY]] API compatibility with existing system maintained
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration with existing authentication preserved
|
||||
|
||||
### 2.3 Deployment Pipeline
|
||||
|
||||
- [ ] CI/CD pipeline is established before deployment actions
|
||||
- [ ] Infrastructure as Code (IaC) is set up before use
|
||||
- [ ] Environment configurations are defined early
|
||||
- [ ] Deployment strategies are defined before implementation
|
||||
- [ ] [[BROWNFIELD ONLY]] Deployment minimizes downtime
|
||||
- [ ] [[BROWNFIELD ONLY]] Blue-green or canary deployment implemented
|
||||
|
||||
### 2.4 Testing Infrastructure
|
||||
|
||||
- [ ] Testing frameworks are installed before writing tests
|
||||
- [ ] Test environment setup precedes test implementation
|
||||
- [ ] Mock services or data are defined before testing
|
||||
- [ ] [[BROWNFIELD ONLY]] Regression testing covers existing functionality
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration testing validates new-to-existing connections
|
||||
|
||||
## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
|
||||
|
||||
[[LLM: External dependencies often block progress. For brownfield, ensure new dependencies don't conflict with existing ones.]]
|
||||
|
||||
### 3.1 Third-Party Services
|
||||
|
||||
- [ ] Account creation steps are identified for required services
|
||||
- [ ] API key acquisition processes are defined
|
||||
- [ ] Steps for securely storing credentials are included
|
||||
- [ ] Fallback or offline development options are considered
|
||||
- [ ] [[BROWNFIELD ONLY]] Compatibility with existing services verified
|
||||
- [ ] [[BROWNFIELD ONLY]] Impact on existing integrations assessed
|
||||
|
||||
### 3.2 External APIs
|
||||
|
||||
- [ ] Integration points with external APIs are clearly identified
|
||||
- [ ] Authentication with external services is properly sequenced
|
||||
- [ ] API limits or constraints are acknowledged
|
||||
- [ ] Backup strategies for API failures are considered
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing API dependencies maintained
|
||||
|
||||
### 3.3 Infrastructure Services
|
||||
|
||||
- [ ] Cloud resource provisioning is properly sequenced
|
||||
- [ ] DNS or domain registration needs are identified
|
||||
- [ ] Email or messaging service setup is included if needed
|
||||
- [ ] CDN or static asset hosting setup precedes their use
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing infrastructure services preserved
|
||||
|
||||
## 4. UI/UX CONSIDERATIONS [[UI/UX ONLY]]
|
||||
|
||||
[[LLM: Only evaluate this section if the project includes user interface components. Skip entirely for backend-only projects.]]
|
||||
|
||||
### 4.1 Design System Setup
|
||||
|
||||
- [ ] UI framework and libraries are selected and installed early
|
||||
- [ ] Design system or component library is established
|
||||
- [ ] Styling approach (CSS modules, styled-components, etc.) is defined
|
||||
- [ ] Responsive design strategy is established
|
||||
- [ ] Accessibility requirements are defined upfront
|
||||
|
||||
### 4.2 Frontend Infrastructure
|
||||
|
||||
- [ ] Frontend build pipeline is configured before development
|
||||
- [ ] Asset optimization strategy is defined
|
||||
- [ ] Frontend testing framework is set up
|
||||
- [ ] Component development workflow is established
|
||||
- [ ] [[BROWNFIELD ONLY]] UI consistency with existing system maintained
|
||||
|
||||
### 4.3 User Experience Flow
|
||||
|
||||
- [ ] User journeys are mapped before implementation
|
||||
- [ ] Navigation patterns are defined early
|
||||
- [ ] Error states and loading states are planned
|
||||
- [ ] Form validation patterns are established
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing user workflows preserved or migrated
|
||||
|
||||
## 5. USER/AGENT RESPONSIBILITY
|
||||
|
||||
[[LLM: Clear ownership prevents confusion. Ensure tasks are assigned appropriately based on what only humans can do.]]
|
||||
|
||||
### 5.1 User Actions
|
||||
|
||||
- [ ] User responsibilities limited to human-only tasks
|
||||
- [ ] Account creation on external services assigned to users
|
||||
- [ ] Purchasing or payment actions assigned to users
|
||||
- [ ] Credential provision appropriately assigned to users
|
||||
|
||||
### 5.2 Developer Agent Actions
|
||||
|
||||
- [ ] All code-related tasks assigned to developer agents
|
||||
- [ ] Automated processes identified as agent responsibilities
|
||||
- [ ] Configuration management properly assigned
|
||||
- [ ] Testing and validation assigned to appropriate agents
|
||||
|
||||
## 6. FEATURE SEQUENCING & DEPENDENCIES
|
||||
|
||||
[[LLM: Dependencies create the critical path. For brownfield, ensure new features don't break existing ones.]]
|
||||
|
||||
### 6.1 Functional Dependencies
|
||||
|
||||
- [ ] Features depending on others are sequenced correctly
|
||||
- [ ] Shared components are built before their use
|
||||
- [ ] User flows follow logical progression
|
||||
- [ ] Authentication features precede protected features
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing functionality preserved throughout
|
||||
|
||||
### 6.2 Technical Dependencies
|
||||
|
||||
- [ ] Lower-level services built before higher-level ones
|
||||
- [ ] Libraries and utilities created before their use
|
||||
- [ ] Data models defined before operations on them
|
||||
- [ ] API endpoints defined before client consumption
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration points tested at each step
|
||||
|
||||
### 6.3 Cross-Epic Dependencies
|
||||
|
||||
- [ ] Later epics build upon earlier epic functionality
|
||||
- [ ] No epic requires functionality from later epics
|
||||
- [ ] Infrastructure from early epics utilized consistently
|
||||
- [ ] Incremental value delivery maintained
|
||||
- [ ] [[BROWNFIELD ONLY]] Each epic maintains system integrity
|
||||
|
||||
## 7. RISK MANAGEMENT [[BROWNFIELD ONLY]]
|
||||
|
||||
[[LLM: This section is CRITICAL for brownfield projects. Think pessimistically about what could break.]]
|
||||
|
||||
### 7.1 Breaking Change Risks
|
||||
|
||||
- [ ] Risk of breaking existing functionality assessed
|
||||
- [ ] Database migration risks identified and mitigated
|
||||
- [ ] API breaking change risks evaluated
|
||||
- [ ] Performance degradation risks identified
|
||||
- [ ] Security vulnerability risks evaluated
|
||||
|
||||
### 7.2 Rollback Strategy
|
||||
|
||||
- [ ] Rollback procedures clearly defined per story
|
||||
- [ ] Feature flag strategy implemented
|
||||
- [ ] Backup and recovery procedures updated
|
||||
- [ ] Monitoring enhanced for new components
|
||||
- [ ] Rollback triggers and thresholds defined
|
||||
|
||||
### 7.3 User Impact Mitigation
|
||||
|
||||
- [ ] Existing user workflows analyzed for impact
|
||||
- [ ] User communication plan developed
|
||||
- [ ] Training materials updated
|
||||
- [ ] Support documentation comprehensive
|
||||
- [ ] Migration path for user data validated
|
||||
|
||||
## 8. MVP SCOPE ALIGNMENT
|
||||
|
||||
[[LLM: MVP means MINIMUM viable product. For brownfield, ensure enhancements are truly necessary.]]
|
||||
|
||||
### 8.1 Core Goals Alignment
|
||||
|
||||
- [ ] All core goals from PRD are addressed
|
||||
- [ ] Features directly support MVP goals
|
||||
- [ ] No extraneous features beyond MVP scope
|
||||
- [ ] Critical features prioritized appropriately
|
||||
- [ ] [[BROWNFIELD ONLY]] Enhancement complexity justified
|
||||
|
||||
### 8.2 User Journey Completeness
|
||||
|
||||
- [ ] All critical user journeys fully implemented
|
||||
- [ ] Edge cases and error scenarios addressed
|
||||
- [ ] User experience considerations included
|
||||
- [ ] [[UI/UX ONLY]] Accessibility requirements incorporated
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing workflows preserved or improved
|
||||
|
||||
### 8.3 Technical Requirements
|
||||
|
||||
- [ ] All technical constraints from PRD addressed
|
||||
- [ ] Non-functional requirements incorporated
|
||||
- [ ] Architecture decisions align with constraints
|
||||
- [ ] Performance considerations addressed
|
||||
- [ ] [[BROWNFIELD ONLY]] Compatibility requirements met
|
||||
|
||||
## 9. DOCUMENTATION & HANDOFF
|
||||
|
||||
[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
|
||||
|
||||
### 9.1 Developer Documentation
|
||||
|
||||
- [ ] API documentation created alongside implementation
|
||||
- [ ] Setup instructions are comprehensive
|
||||
- [ ] Architecture decisions documented
|
||||
- [ ] Patterns and conventions documented
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
|
||||
|
||||
### 9.2 User Documentation
|
||||
|
||||
- [ ] User guides or help documentation included if required
|
||||
- [ ] Error messages and user feedback considered
|
||||
- [ ] Onboarding flows fully specified
|
||||
- [ ] [[BROWNFIELD ONLY]] Changes to existing features documented
|
||||
|
||||
### 9.3 Knowledge Transfer
|
||||
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
|
||||
- [ ] Code review knowledge sharing planned
|
||||
- [ ] Deployment knowledge transferred to operations
|
||||
- [ ] Historical context preserved
|
||||
|
||||
## 10. POST-MVP CONSIDERATIONS
|
||||
|
||||
[[LLM: Planning for success prevents technical debt. For brownfield, ensure enhancements don't limit future growth.]]
|
||||
|
||||
### 10.1 Future Enhancements
|
||||
|
||||
- [ ] Clear separation between MVP and future features
|
||||
- [ ] Architecture supports planned enhancements
|
||||
- [ ] Technical debt considerations documented
|
||||
- [ ] Extensibility points identified
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration patterns reusable
|
||||
|
||||
### 10.2 Monitoring & Feedback
|
||||
|
||||
- [ ] Analytics or usage tracking included if required
|
||||
- [ ] User feedback collection considered
|
||||
- [ ] Monitoring and alerting addressed
|
||||
- [ ] Performance measurement incorporated
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing monitoring preserved/enhanced
|
||||
|
||||
## VALIDATION SUMMARY
|
||||
|
||||
[[LLM: FINAL PO VALIDATION REPORT GENERATION
|
||||
|
||||
Generate a comprehensive validation report that adapts to project type:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
||||
- Overall readiness (percentage)
|
||||
- Go/No-Go recommendation
|
||||
- Critical blocking issues count
|
||||
- Sections skipped due to project type
|
||||
|
||||
2. Project-Specific Analysis
|
||||
|
||||
FOR GREENFIELD:
|
||||
|
||||
- Setup completeness
|
||||
- Dependency sequencing
|
||||
- MVP scope appropriateness
|
||||
- Development timeline feasibility
|
||||
|
||||
FOR BROWNFIELD:
|
||||
|
||||
- Integration risk level (High/Medium/Low)
|
||||
- Existing system impact assessment
|
||||
- Rollback readiness
|
||||
- User disruption potential
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations
|
||||
- Timeline impact of addressing issues
|
||||
- [BROWNFIELD] Specific integration risks
|
||||
|
||||
4. MVP Completeness
|
||||
|
||||
- Core features coverage
|
||||
- Missing essential functionality
|
||||
- Scope creep identified
|
||||
- True MVP vs over-engineering
|
||||
|
||||
5. Implementation Readiness
|
||||
|
||||
- Developer clarity score (1-10)
|
||||
- Ambiguous requirements count
|
||||
- Missing technical details
|
||||
- [BROWNFIELD] Integration point clarity
|
||||
|
||||
6. Recommendations
|
||||
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
- Post-MVP deferrals
|
||||
|
||||
7. [BROWNFIELD ONLY] Integration Confidence
|
||||
- Confidence in preserving existing functionality
|
||||
- Rollback procedure completeness
|
||||
- Monitoring coverage for integration points
|
||||
- Support team readiness
|
||||
|
||||
After presenting the report, ask if the user wants:
|
||||
|
||||
- Detailed analysis of any failed sections
|
||||
- Specific story reordering suggestions
|
||||
- Risk mitigation strategies
|
||||
- [BROWNFIELD] Integration risk deep-dive]]
|
||||
|
||||
### Category Statuses
|
||||
|
||||
| Category | Status | Critical Issues |
|
||||
| --------------------------------------- | ------ | --------------- |
|
||||
| 1. Project Setup & Initialization | _TBD_ | |
|
||||
| 2. Infrastructure & Deployment | _TBD_ | |
|
||||
| 3. External Dependencies & Integrations | _TBD_ | |
|
||||
| 4. UI/UX Considerations | _TBD_ | |
|
||||
| 5. User/Agent Responsibility | _TBD_ | |
|
||||
| 6. Feature Sequencing & Dependencies | _TBD_ | |
|
||||
| 7. Risk Management (Brownfield) | _TBD_ | |
|
||||
| 8. MVP Scope Alignment | _TBD_ | |
|
||||
| 9. Documentation & Handoff | _TBD_ | |
|
||||
| 10. Post-MVP Considerations | _TBD_ | |
|
||||
|
||||
### Critical Deficiencies
|
||||
|
||||
(To be populated during validation)
|
||||
|
||||
### Recommendations
|
||||
|
||||
(To be populated during validation)
|
||||
|
||||
### Final Decision
|
||||
|
||||
- **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
|
||||
- **CONDITIONAL**: The plan requires specific adjustments before proceeding.
|
||||
- **REJECTED**: The plan requires significant revision to address critical deficiencies.
|
||||
Reference in New Issue
Block a user