bmad-method 6.0.0-alpha.0 → 6.0.0-alpha.10

package/src/modules/bmm/workflows/2-plan/checklist.md

@@ -1,369 +0,0 @@
-# Project Planning Validation Checklist (Adaptive: All Levels)
-
-**Scope**: This checklist adapts based on project level (0-4) and field type (greenfield/brownfield)
-
-- **Level 0**: Tech-spec only validation
-- **Level 1-2**: PRD + Tech-spec + Epics validation
-- **Level 3-4**: PRD + Epics validation (no tech-spec)
-- **Greenfield**: Focus on setup sequencing and dependencies
-- **Brownfield**: Focus on integration risks and backward compatibility
-
-## User Intent Validation (Critical First Check)
-
-### Input Sources and User Need
-
-- [ ] Product brief or initial context was properly gathered (not just project name)
-- [ ] User's actual problem/need was identified through conversation (not assumed)
-- [ ] Technical preferences mentioned by user were captured separately
-- [ ] User confirmed the description accurately reflects their vision
-- [ ] The PRD addresses what the user asked for, not what we think they need
-
-### Alignment with User Goals
-
-- [ ] Goals directly address the user's stated problem
-- [ ] Context reflects actual user-provided information (not invented)
-- [ ] Requirements map to explicit user needs discussed
-- [ ] Nothing critical the user mentioned is missing
-
-## Document Structure
-
-- [ ] All required sections are present
-- [ ] No placeholder text remains (all {{variables}} replaced)
-- [ ] Proper formatting and organization throughout
-
-## Section 1: Description
-
-- [ ] Clear, concise description of what's being built
-- [ ] Matches user's actual request (not extrapolated)
-- [ ] Sets proper scope and expectations
-
-## Section 2: Goals (Step 2)
-
-- [ ] Level 3: Contains 3-5 primary goals
-- [ ] Level 4: Contains 5-7 strategic goals
-- [ ] Each goal is specific and measurable where possible
-- [ ] Goals focus on user and project outcomes
-- [ ] Goals represent what success looks like
-- [ ] Strategic objectives align with product scale
-
-## Section 3: Context (Step 3)
-
-- [ ] 1-2 short paragraphs explaining why this matters now
-- [ ] Context was gathered from user (not invented)
-- [ ] Explains actual problem being solved
-- [ ] Describes current situation or pain point
-- [ ] Connects to real-world impact
-
-## Section 4: Functional Requirements (Step 4)
-
-- [ ] Level 3: Contains 12-20 FRs
-- [ ] Level 4: Contains 20-30 FRs
-- [ ] Each has unique FR identifier (FR001, FR002, etc.)
-- [ ] Requirements describe capabilities, not implementation
-- [ ] Related features grouped logically while maintaining granularity
-- [ ] All FRs are testable user actions
-- [ ] User provided feedback on proposed FRs
-- [ ] Missing capabilities user expected were added
-- [ ] Priority order reflects user input
-- [ ] Coverage comprehensive for target product scale
-
-## Section 5: Non-Functional Requirements (Step 5 - Optional)
-
-- [ ] Only included if truly needed (not arbitrary targets)
-- [ ] Each has unique NFR identifier
-- [ ] Business justification provided for each NFR
-- [ ] Compliance requirements noted if regulated industry
-- [ ] Performance constraints tied to business needs
-- [ ] Typically 0-5 for MVP (not invented)
-
-## Section 6: User Journeys (Step 6)
-
-- [ ] Level 3: 2-3 detailed user journeys documented
-- [ ] Level 4: 3-5 comprehensive journeys for major segments
-- [ ] Each journey has named persona with context
-- [ ] Journey shows complete path through system via FRs
-- [ ] Specific FR references included (e.g., "signs up (FR001)")
-- [ ] Success criteria and pain points identified
-- [ ] Edge cases and alternative paths considered
-- [ ] Journeys validate comprehensive value delivery
-
-## Section 7: UX Principles (Step 7 - Optional)
-
-- [ ] Target users and sophistication level defined
-- [ ] Design values stated (simple vs powerful, playful vs professional)
-- [ ] Platform strategy specified (mobile-first, web, native)
-- [ ] Accessibility requirements noted if applicable
-- [ ] Sets direction without prescribing specific solutions
-
-## Section 8: Epics (Step 8)
-
-- [ ] Level 3: 3-5 epics defined (targeting 12-40 stories)
-- [ ] Level 4: 5-8 epics defined (targeting 40+ stories)
-- [ ] Each epic represents significant, deployable functionality
-- [ ] Epic format includes: Title, Goal, Capabilities, Success Criteria, Dependencies
-- [ ] Related FRs grouped into coherent capabilities
-- [ ] Each epic references specific FR numbers
-- [ ] Post-MVP epics listed separately with their FRs
-- [ ] Dependencies between epics clearly noted
-- [ ] Phased delivery strategy apparent
-
-## Section 9: Out of Scope (Step 9)
-
-- [ ] Ideas preserved with FR/NFR references
-- [ ] Format: description followed by (FR###, NFR###)
-- [ ] Prevents scope creep while capturing future possibilities
-- [ ] Clear distinction from MVP scope
-
-## Section 10: Assumptions and Dependencies (Step 10)
-
-- [ ] Only ACTUAL assumptions from user discussion (not invented)
-- [ ] Technical choices user explicitly mentioned captured
-- [ ] Dependencies identified in FRs/NFRs listed
-- [ ] User-stated constraints documented
-- [ ] If none exist, states "No critical assumptions identified yet"
-
-## Cross-References and Consistency
-
-- [ ] All FRs trace back to at least one goal
-- [ ] User journeys reference actual FR numbers
-- [ ] Epic capabilities cover all FRs
-- [ ] Terminology consistent throughout
-- [ ] No contradictions between sections
-- [ ] Technical details saved to technical_preferences (not in PRD)
-
-## Quality Checks
-
-- [ ] Requirements are strategic, not implementation-focused
-- [ ] Document maintains appropriate abstraction level
-- [ ] No premature technical decisions
-- [ ] Focus on WHAT, not HOW
-
-## Readiness for Next Phase
-
-- [ ] Sufficient detail for comprehensive architecture design
-- [ ] Clear enough for detailed solution design
-- [ ] Ready for epic breakdown into 12-40+ stories
-- [ ] Value delivery path supports phased releases
-- [ ] If UI exists, ready for UX expert collaboration
-- [ ] Scale and complexity match Level 3-4 requirements
-
-## Scale Validation
-
-- [ ] Project scope justifies PRD
-- [ ] Complexity matches Level 1-4 designation
-- [ ] Story estimate aligns with epic structure (12-40+)
-- [ ] Not over-engineered for actual needs
-
-## Final Validation
-
-- [ ] Document addresses user's original request completely
-- [ ] All user feedback incorporated
-- [ ] No critical user requirements missing
-- [ ] Ready for user final review and approval
-- [ ] File saved in correct location: {{output_folder}}/PRD.md
-
----
-
-# Cohesion Validation (All Levels)
-
-**Purpose**: Validate alignment between planning artifacts and readiness for implementation
-
-## Project Context Detection
-
-- [ ] Project level confirmed (0, 1, 2, 3, or 4)
-- [ ] Field type identified (greenfield or brownfield)
-- [ ] Appropriate validation sections applied based on context
-
-## Section A: Tech Spec Validation (Levels 0, 1, 2 only)
-
-### A.1 Tech Spec Completeness
-
-- [ ] All technical decisions are DEFINITIVE (no "Option A or B")
-- [ ] Specific versions specified for all frameworks/libraries
-- [ ] Source tree structure clearly defined
-- [ ] Technical approach precisely described
-- [ ] Implementation stack complete with exact tools
-- [ ] Testing approach clearly defined
-- [ ] Deployment strategy documented
-
-### A.2 Tech Spec - PRD Alignment (Levels 1-2 only)
-
-- [ ] Every functional requirement has technical solution
-- [ ] Non-functional requirements addressed in tech spec
-- [ ] Tech stack aligns with PRD constraints
-- [ ] Performance requirements achievable with chosen stack
-- [ ] Technical preferences from user incorporated
-
-## Section B: Greenfield-Specific Validation (if greenfield)
-
-### B.1 Project Setup Sequencing
-
-- [ ] Epic 0 or 1 includes project initialization steps
-- [ ] Repository setup precedes feature development
-- [ ] Development environment configuration included early
-- [ ] Core dependencies installed before use
-- [ ] Testing infrastructure set up before tests written
-
-### B.2 Infrastructure Before Features
-
-- [ ] Database setup before data operations
-- [ ] API framework before endpoint implementation
-- [ ] Authentication setup before protected features
-- [ ] CI/CD pipeline before deployment
-- [ ] Monitoring setup included
-
-### B.3 External Dependencies
-
-- [ ] Third-party account creation assigned to user
-- [ ] API keys acquisition process defined
-- [ ] Credential storage approach specified
-- [ ] External service setup sequenced properly
-- [ ] Fallback strategies for external failures
-
-## Section C: Brownfield-Specific Validation (if brownfield)
-
-### C.1 Existing System Integration
-
-- [ ] Current architecture analyzed and documented
-- [ ] Integration points with existing system identified
-- [ ] Existing functionality preservation validated
-- [ ] Database schema compatibility assessed
-- [ ] API contract compatibility verified
-
-### C.2 Risk Management
-
-- [ ] Breaking change risks identified and mitigated
-- [ ] Rollback procedures defined for each integration
-- [ ] Feature flags or toggles included where appropriate
-- [ ] Performance degradation risks assessed
-- [ ] User impact analysis completed
-
-### C.3 Backward Compatibility
-
-- [ ] Database migrations maintain backward compatibility
-- [ ] API changes don't break existing consumers
-- [ ] Authentication/authorization integration safe
-- [ ] Configuration changes non-breaking
-- [ ] Existing monitoring preserved or enhanced
-
-### C.4 Dependency Conflicts
-
-- [ ] New dependencies compatible with existing versions
-- [ ] No version conflicts introduced
-- [ ] Security vulnerabilities not introduced
-- [ ] License compatibility verified
-- [ ] Bundle size impact acceptable
-
-## Section D: Feature Sequencing (All Levels)
-
-### D.1 Functional Dependencies
-
-- [ ] Features depending on others sequenced correctly
-- [ ] Shared components built before consumers
-- [ ] User flows follow logical progression
-- [ ] Authentication precedes protected features
-
-### D.2 Technical Dependencies
-
-- [ ] Lower-level services before higher-level ones
-- [ ] Utilities and libraries created before use
-- [ ] Data models defined before operations
-- [ ] API endpoints before client consumption
-
-### D.3 Epic Dependencies
-
-- [ ] Later epics build on earlier epic functionality
-- [ ] No circular dependencies between epics
-- [ ] Infrastructure from early epics reused
-- [ ] Incremental value delivery maintained
-
-## Section E: UI/UX Cohesion (if UI components exist)
-
-### E.1 Design System (Greenfield)
-
-- [ ] UI framework selected and installed early
-- [ ] Design system or component library established
-- [ ] Styling approach defined
-- [ ] Responsive design strategy clear
-- [ ] Accessibility requirements defined
-
-### E.2 Design Consistency (Brownfield)
-
-- [ ] UI consistent with existing system
-- [ ] Component library updates non-breaking
-- [ ] Styling approach matches existing
-- [ ] Accessibility standards maintained
-- [ ] Existing user workflows preserved
-
-### E.3 UX Flow Validation
-
-- [ ] User journeys mapped completely
-- [ ] Navigation patterns defined
-- [ ] Error and loading states planned
-- [ ] Form validation patterns established
-
-## Section F: Responsibility Assignment (All Levels)
-
-### F.1 User vs Agent Clarity
-
-- [ ] Human-only tasks assigned to user
-- [ ] Account creation on external services → user
-- [ ] Payment/purchasing actions → user
-- [ ] All code tasks → developer agent
-- [ ] Configuration management properly assigned
-
-## Section G: Documentation Readiness (All Levels)
-
-### G.1 Developer Documentation
-
-- [ ] Setup instructions comprehensive
-- [ ] Technical decisions documented
-- [ ] Patterns and conventions clear
-- [ ] API documentation plan exists (if applicable)
-
-### G.2 Deployment Documentation (Brownfield)
-
-- [ ] Runbook updates planned
-- [ ] Incident response procedures updated
-- [ ] Rollback procedures documented and tested
-- [ ] Monitoring dashboard updates planned
-
-## Section H: Future-Proofing (All Levels)
-
-### H.1 Extensibility
-
-- [ ] Current scope vs future features clearly separated
-- [ ] Architecture supports planned enhancements
-- [ ] Technical debt considerations documented
-- [ ] Extensibility points identified
-
-### H.2 Observability
-
-- [ ] Monitoring strategy defined
-- [ ] Success metrics from planning captured
-- [ ] Analytics or tracking included if needed
-- [ ] Performance measurement approach clear
-
-## Cohesion Summary
-
-### Overall Readiness Assessment
-
-- [ ] **Ready for Development** - All critical items pass
-- [ ] **Needs Alignment** - Some gaps need addressing
-- [ ] **Too Risky** (brownfield only) - Integration risks too high
-
-### Critical Gaps Identified
-
-_List any blocking issues or unacceptable risks:_
-
-### Integration Risk Level (brownfield only)
-
-- [ ] Low - well-understood integration with good rollback
-- [ ] Medium - some unknowns but manageable
-- [ ] High - significant risks require mitigation
-
-### Recommendations
-
-_Specific actions to improve cohesion before development:_
-
----

package/src/modules/bmm/workflows/2-plan/gdd/README.md

@@ -1,222 +0,0 @@
-# Game Design Document (GDD) Workflow
-
-This folder contains the GDD workflow for game projects, replacing the traditional PRD approach with game-specific documentation.
-
-## Overview
-
-The GDD workflow creates a comprehensive Game Design Document that captures:
-
-- Core gameplay mechanics and pillars
-- Game type-specific elements (RPG systems, platformer movement, puzzle mechanics, etc.)
-- Level design framework
-- Art and audio direction
-- Technical specifications (platform-agnostic)
-- Development epics
-
-## Architecture
-
-### Universal Template
-
-`gdd-template.md` contains sections common to ALL game types:
-
-- Executive Summary
-- Goals & Context
-- Core Gameplay
-- Win/Loss Conditions
-- Progression & Balance
-- Level Design Framework
-- Art & Audio Direction
-- Technical Specs
-- Development Epics
-- Success Metrics
-
-### Game-Type-Specific Injection
-
-The template includes a `{{GAME_TYPE_SPECIFIC_SECTIONS}}` placeholder that gets replaced with game-type-specific content.
-
-### Game Types Registry
-
-`game-types.csv` defines 24+ game types with:
-
-- **id**: Unique identifier (e.g., `action-platformer`, `rpg`, `roguelike`)
-- **name**: Human-readable name
-- **description**: Brief description of the game type
-- **genre_tags**: Searchable tags
-- **fragment_file**: Path to type-specific template fragment
-
-### Game-Type Fragments
-
-Located in `game-types/` folder, these markdown files contain sections specific to each game type:
-
-**action-platformer.md**:
-
-- Movement System (jump mechanics, air control, special moves)
-- Combat System (attack types, combos, enemy AI)
-- Level Design Patterns (platforming challenges, combat arenas)
-- Player Abilities & Unlocks
-
-**rpg.md**:
-
-- Character System (stats, classes, leveling)
-- Inventory & Equipment
-- Quest System
-- World & Exploration
-- NPC & Dialogue
-- Combat System
-
-**puzzle.md**:
-
-- Core Puzzle Mechanics
-- Puzzle Progression
-- Level Structure
-- Player Assistance
-- Replayability
-
-**roguelike.md**:
-
-- Run Structure
-- Procedural Generation
-- Permadeath & Progression
-- Item & Upgrade System
-- Character Selection
-- Difficulty Modifiers
-
-...and 20+ more game types!
-
-## Workflow Flow
-
-1. **Router Detection** (instructions-router.md):
-   - Step 3 asks for project type
-   - If "Game" selected → sets `workflow_type = "gdd"`
-   - Skips standard level classification
-   - Jumps to GDD-specific assessment
-
-2. **Game Type Selection** (instructions-gdd.md Step 1):
-   - Presents 9 common game types + "Other"
-   - Maps selection to `game-types.csv`
-   - Loads corresponding fragment file
-   - Stores `game_type` for injection
-
-3. **Universal GDD Sections** (Steps 2-5, 7-13):
-   - Platform & target audience
-   - Goals & context
-   - Core gameplay (pillars, loop, win/loss)
-   - Mechanics & controls
-   - Progression & balance
-   - Level design
-   - Art & audio
-   - Technical specs
-   - Epics & metrics
-
-4. **Game-Type Injection** (Step 6):
-   - Loads fragment from `game-types/{game_type}.md`
-   - For each `{{placeholder}}` in fragment, elicits details
-   - Injects completed sections into `{{GAME_TYPE_SPECIFIC_SECTIONS}}`
-
-5. **Solutioning Handoff** (Step 14):
-   - Routes to `3-solutioning` workflow
-   - Platform/engine specifics handled by solutioning registry
-   - Game-\* entries in solutioning `registry.csv` provide engine-specific guidance
-
-## Platform vs. Game Type Separation
-
-**GDD (this workflow)**: Game-type specifics
-
-- What makes an RPG an RPG (stats, quests, inventory)
-- What makes a platformer a platformer (jump mechanics, level design)
-- Genre-defining mechanics and systems
-
-**Solutioning (3-solutioning workflow)**: Platform/engine specifics
-
-- Unity vs. Godot vs. Phaser vs. Unreal
-- 2D vs. 3D rendering
-- Physics engines
-- Input systems
-- Platform constraints (mobile, web, console)
-
-This separation allows:
-
-- Single universal GDD regardless of platform
-- Platform decisions made during architecture phase
-- Easy platform pivots without rewriting GDD
-
-## Output
-
-**GDD.md**: Complete game design document with:
-
-- All universal sections filled
-- Game-type-specific sections injected
-- Ready for solutioning handoff
-
-## Example Game Types
-
-| ID                | Name              | Key Sections                                      |
-| ----------------- | ----------------- | ------------------------------------------------- |
-| action-platformer | Action Platformer | Movement, Combat, Level Patterns, Abilities       |
-| rpg               | RPG               | Character System, Inventory, Quests, World, NPCs  |
-| puzzle            | Puzzle            | Puzzle Mechanics, Progression, Level Structure    |
-| roguelike         | Roguelike         | Run Structure, Procgen, Permadeath, Items         |
-| shooter           | Shooter           | Weapon Systems, Enemy AI, Arena Design            |
-| strategy          | Strategy          | Resources, Units, AI, Victory Conditions          |
-| metroidvania      | Metroidvania      | Interconnected World, Ability Gating, Exploration |
-| visual-novel      | Visual Novel      | Branching Story, Dialogue Trees, Choices          |
-| tower-defense     | Tower Defense     | Waves, Tower Types, Placement, Economy            |
-| card-game         | Card Game         | Deck Building, Card Mechanics, Turn System        |
-
-...and 14+ more!
-
-## Adding New Game Types
-
-1. Add row to `game-types.csv`:
-
-   ```csv
-   new-type,New Type Name,"Description",tags,new-type.md
-   ```
-
-2. Create `game-types/new-type.md`:
-
-   ```markdown
-   ## New Type Specific Elements
-
-   ### System Name
-
-   {{system_placeholder}}
-
-   **Details:**
-
-   - Element 1
-   - Element 2
-   ```
-
-3. The workflow automatically uses it!
-
-## Integration with Solutioning
-
-When a game project completes the GDD and moves to solutioning:
-
-1. Solutioning workflow reads `project_type == "game"`
-2. Loads GDD.md instead of PRD.md
-3. Matches game platforms to solutioning `registry.csv` game-\* entries
-4. Provides engine-specific guidance (Unity, Godot, Phaser, etc.)
-5. Generates solution-architecture.md with platform decisions
-6. Creates per-epic tech specs
-
-Example solutioning registry entries:
-
-- `game-unity-2d`: Unity 2D games
-- `game-godot-3d`: Godot 3D games
-- `game-phaser`: Phaser web games
-- `game-unreal-3d`: Unreal Engine games
-- `game-custom-3d-rust`: Custom Rust game engines
-
-## Philosophy
-
-**Game projects are fundamentally different from software products**:
-
-- Gameplay feel > feature lists
-- Playtesting > user testing
-- Game pillars > product goals
-- Mechanics > requirements
-- Fun > utility
-
-The GDD workflow respects these differences while maintaining BMAD Method rigor.