bmad-method 6.0.0-alpha.3 → 6.0.0-alpha.5

package/src/modules/bmm/workflows/1-analysis/research/template-market.md

@@ -293,6 +293,40 @@
 
 ---
 
+## References and Sources
+
+**CRITICAL: All data in this report must be verifiable through the sources listed below**
+
+### Market Size and Growth Data Sources
+
+{{sources_market_size}}
+
+### Competitive Intelligence Sources
+
+{{sources_competitive}}
+
+### Customer Research Sources
+
+{{sources_customer}}
+
+### Industry Trends and Analysis Sources
+
+{{sources_trends}}
+
+### Additional References
+
+{{sources_additional}}
+
+### Source Quality Assessment
+
+- **High Credibility Sources (2+ corroborating):** {{high_confidence_count}} claims
+- **Medium Credibility (single source):** {{medium_confidence_count}} claims
+- **Low Credibility (needs verification):** {{low_confidence_count}} claims
+
+**Note:** Any claim marked [Low Confidence] or [Single source] should be independently verified before making critical business decisions.
+
+---
+
 ## Document Information
 
 **Workflow:** BMad Market Research Workflow v1.0
@@ -305,7 +339,9 @@
 - **Data Freshness:** Current as of {{date}}
 - **Source Reliability:** {{source_reliability_score}}
 - **Confidence Level:** {{confidence_level}}
+- **Total Sources Cited:** {{total_sources}}
+- **Web Searches Conducted:** {{search_count}}
 
 ---
 
-_This market research report was generated using the BMad Method Market Research Workflow, combining systematic analysis frameworks with real-time market intelligence gathering._
+_This market research report was generated using the BMad Method Market Research Workflow, combining systematic analysis frameworks with real-time market intelligence gathering. All factual claims are backed by cited sources with verification dates._

package/src/modules/bmm/workflows/1-analysis/research/template-technical.md

@@ -198,13 +198,48 @@
 
 ---
 
+## References and Sources
+
+**CRITICAL: All technical claims, versions, and benchmarks must be verifiable through sources below**
+
+### Official Documentation and Release Notes
+
+{{sources_official_docs}}
+
+### Performance Benchmarks and Comparisons
+
+{{sources_benchmarks}}
+
+### Community Experience and Reviews
+
+{{sources_community}}
+
+### Architecture Patterns and Best Practices
+
+{{sources_architecture}}
+
+### Additional Technical References
+
+{{sources_additional}}
+
+### Version Verification
+
+- **Technologies Researched:** {{technology_count}}
+- **Versions Verified ({{current_year}}):** {{verified_versions_count}}
+- **Sources Requiring Update:** {{outdated_sources_count}}
+
+**Note:** All version numbers were verified using current {{current_year}} sources. Versions may change - always verify latest stable release before implementation.
+
+---
+
 ## Document Information
 
 **Workflow:** BMad Research Workflow - Technical Research v2.0
 **Generated:** {{date}}
 **Research Type:** Technical/Architecture Research
 **Next Review:** [Date for review/update]
+**Total Sources Cited:** {{total_sources}}
 
 ---
 
-_This technical research report was generated using the BMad Method Research Workflow, combining systematic technology evaluation frameworks with real-time research and analysis._
+_This technical research report was generated using the BMad Method Research Workflow, combining systematic technology evaluation frameworks with real-time research and analysis. All version numbers and technical claims are backed by current {{current_year}} sources._

package/src/modules/bmm/workflows/1-analysis/research/workflow.yaml

@@ -11,6 +11,17 @@ communication_language: "{config_source}:communication_language"
 document_output_language: "{config_source}:document_output_language"
 user_skill_level: "{config_source}:user_skill_level"
 date: system-generated
+current_year: system-generated
+current_month: system-generated
+
+# Research behavior - WEB RESEARCH IS DEFAULT
+enable_web_research: true
+
+# Source tracking and verification - CRITICAL FOR ACCURACY
+require_citations: true
+require_source_urls: true
+minimum_sources_per_claim: 2
+fact_check_critical_data: true
 
 # Workflow components - ROUTER PATTERN
 installed_path: "{project-root}/bmad/bmm/workflows/1-analysis/research"
@@ -47,3 +58,5 @@ web_bundle:
     - "bmad/bmm/workflows/1-analysis/research/template-deep-prompt.md"
     - "bmad/bmm/workflows/1-analysis/research/template-technical.md"
     - "bmad/bmm/workflows/1-analysis/research/checklist.md"
+    - "bmad/bmm/workflows/1-analysis/research/checklist-deep-prompt.md"
+    - "bmad/bmm/workflows/1-analysis/research/checklist-technical.md"

package/src/modules/bmm/workflows/2-plan-workflows/create-ux-design/instructions.md

@@ -9,8 +9,8 @@
 <critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical>
 <critical>Generate all documents in {document_output_language}</critical>
 <critical>SAVE PROGRESS after each major step - use <template-output> tags throughout</critical>
-
 <critical>DOCUMENT OUTPUT: Professional, specific, actionable UX design decisions WITH RATIONALE. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
+<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
 
 <step n="0" goal="Validate workflow readiness" tag="workflow-status">
 <action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>

package/src/modules/bmm/workflows/2-plan-workflows/create-ux-design/workflow.yaml

@@ -23,6 +23,28 @@ prd_file: "{output_folder}/bmm-PRD.md or PRD.md or product-requirements.md"
 brief_file: "{output_folder}/product-brief.md or brief.md or project-brief.md"
 brainstorm_file: "{output_folder}/brainstorming.md or brainstorm.md or ideation.md"
 
+# Smart input file references - handles both whole docs and sharded docs
+# Priority: Whole document first, then sharded version
+input_file_patterns:
+  prd:
+    whole: "{output_folder}/*prd*.md"
+    sharded: "{output_folder}/*prd*/index.md"
+
+  product_brief:
+    whole: "{output_folder}/*brief*.md"
+    sharded: "{output_folder}/*brief*/index.md"
+
+  epics:
+    whole: "{output_folder}/*epic*.md"
+    sharded: "{output_folder}/*epic*/index.md"
+
+  brainstorming:
+    whole: "{output_folder}/*brainstorm*.md"
+    sharded: "{output_folder}/*brainstorm*/index.md"
+
+  document_project:
+    sharded: "{output_folder}/docs/index.md"
+
 # Module path and component files
 installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/create-ux-design"
 instructions: "{installed_path}/instructions.md"

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

@@ -14,6 +14,24 @@
 
 <critical>DOCUMENT OUTPUT: Concise, clear, actionable game design specs. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
 
+## Input Document Discovery
+
+This workflow requires: game brief, and may reference market research or brownfield project documentation.
+
+**Discovery Process** (execute for each referenced document):
+
+1. **Search for whole document first** - Use fuzzy file matching to find the complete document
+2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
+3. **If sharded version found**:
+   - Read `index.md` to understand the document structure
+   - Read ALL section files listed in the index
+   - Treat the combined content as if it were a single document
+4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md`
+
+**Priority**: If both whole and sharded versions exist, use the whole document.
+
+**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions.
+
 <step n="0" goal="Validate workflow and extract project configuration">
 
 <invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">

package/src/modules/bmm/workflows/2-plan-workflows/gdd/workflow.yaml

@@ -30,6 +30,20 @@ recommended_inputs:
   - narrative_design: "{output_folder}/narrative-design.md"
   - market_research: "{output_folder}/market-research.md"
 
+# Smart input file references - handles both whole docs and sharded docs
+# Priority: Whole document first, then sharded version
+input_file_patterns:
+  game_brief:
+    whole: "{output_folder}/*game-brief*.md"
+    sharded: "{output_folder}/*game-brief*/index.md"
+
+  research:
+    whole: "{output_folder}/*research*.md"
+    sharded: "{output_folder}/*research*/index.md"
+
+  document_project:
+    sharded: "{output_folder}/docs/index.md"
+
 standalone: true
 
 web_bundle:

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

@@ -1,117 +1,350 @@
-# PRD Workflow Validation Checklist
+# PRD + Epics + Stories Validation Checklist
 
-**Purpose**: Validate PRD workflow outputs are complete, consistent, and ready for next phase.
+**Purpose**: Comprehensive validation that PRD, epics, and stories form a complete, implementable product plan.
 
-**Scope**: Levels 2-4 software projects
+**Scope**: Validates the complete planning output (PRD.md + epics.md) for Levels 2-4 software projects
 
-**Expected Outputs**: PRD.md, epics.md, updated bmm-workflow-status.md
+**Expected Outputs**:
+
+- PRD.md with complete requirements
+- epics.md with detailed epic and story breakdown
+- Updated bmm-workflow-status.yaml
 
 ---
 
-## 1. Output Files Exist
+## 1. PRD Document Completeness
+
+### Core Sections Present
+
+- [ ] Executive Summary with vision alignment
+- [ ] Product magic essence clearly articulated
+- [ ] Project classification (type, domain, complexity)
+- [ ] Success criteria defined
+- [ ] Product scope (MVP, Growth, Vision) clearly delineated
+- [ ] Functional requirements comprehensive and numbered
+- [ ] Non-functional requirements (when applicable)
+- [ ] References section with source documents
+
+### Project-Specific Sections
 
-- [ ] PRD.md created in output folder
-- [ ] epics.md created in output folder (separate file)
-- [ ] bmm-workflow-status.md updated
-- [ ] No unfilled {{template_variables}}
+- [ ] **If complex domain:** Domain context and considerations documented
+- [ ] **If innovation:** Innovation patterns and validation approach documented
+- [ ] **If API/Backend:** Endpoint specification and authentication model included
+- [ ] **If Mobile:** Platform requirements and device features documented
+- [ ] **If SaaS B2B:** Tenant model and permission matrix included
+- [ ] **If UI exists:** UX principles and key interactions documented
+
+### Quality Checks
+
+- [ ] No unfilled template variables ({{variable}})
+- [ ] All variables properly populated with meaningful content
+- [ ] Product magic woven throughout (not just stated once)
+- [ ] Language is clear, specific, and measurable
+- [ ] Project type correctly identified and sections match
+- [ ] Domain complexity appropriately addressed
 
 ---
 
-## 2. PRD.md Core Quality
+## 2. Functional Requirements Quality
 
-### Requirements Coverage
+### FR Format and Structure
 
-- [ ] Functional requirements describe WHAT capabilities (not HOW to implement)
-- [ ] Each FR has unique identifier (FR001, FR002, etc.)
-- [ ] Non-functional requirements (if any) have business justification
-- [ ] Requirements are testable and verifiable
+- [ ] Each FR has unique identifier (FR-001, FR-002, etc.)
+- [ ] FRs describe WHAT capabilities, not HOW to implement
+- [ ] FRs are specific and measurable
+- [ ] FRs are testable and verifiable
+- [ ] FRs focus on user/business value
+- [ ] No technical implementation details in FRs (those belong in architecture)
 
-### User Journeys
+### FR Completeness
 
-- [ ] User journeys reference specific FR numbers
-- [ ] Journeys show complete user paths through system
-- [ ] Success outcomes are clear
+- [ ] All MVP scope features have corresponding FRs
+- [ ] Growth features documented (even if deferred)
+- [ ] Vision features captured for future reference
+- [ ] Domain-mandated requirements included
+- [ ] Innovation requirements captured with validation needs
+- [ ] Project-type specific requirements complete
 
-### Strategic Focus
+### FR Organization
 
-- [ ] PRD focuses on WHAT and WHY (not technical HOW)
-- [ ] No specific technology choices in PRD (those belong in technical-decisions.md)
-- [ ] Goals are outcome-focused, not implementation-focused
+- [ ] FRs organized by capability/feature area (not by tech stack)
+- [ ] Related FRs grouped logically
+- [ ] Dependencies between FRs noted when critical
+- [ ] Priority/phase indicated (MVP vs Growth vs Vision)
 
 ---
 
-## 3. epics.md Story Quality
+## 3. Epics Document Completeness
+
+### Required Files
+
+- [ ] epics.md exists in output folder
+- [ ] Epic list in PRD.md matches epics in epics.md (titles and count)
+- [ ] All epics have detailed breakdown sections
 
-### Story Format
+### Epic Quality
 
-- [ ] All stories follow user story format: "As a [role], I want [capability], so that [benefit]"
+- [ ] Each epic has clear goal and value proposition
+- [ ] Each epic includes complete story breakdown
+- [ ] Stories follow proper user story format: "As a [role], I want [goal], so that [benefit]"
 - [ ] Each story has numbered acceptance criteria
-- [ ] Prerequisites/dependencies explicitly stated
+- [ ] Prerequisites/dependencies explicitly stated per story
+- [ ] Stories are AI-agent sized (completable in 2-4 hour session)
+
+---
 
-### Story Sequencing (CRITICAL)
+## 4. FR Coverage Validation (CRITICAL)
 
-- [ ] **Epic 1 establishes foundation** (infrastructure, initial deployable functionality)
-  - Exception noted if adding to existing app
-- [ ] **Vertical slices**: Each story delivers complete, testable functionality (not horizontal layers)
-- [ ] **No forward dependencies**: No story depends on work from a LATER story or epic
-- [ ] Stories are sequentially ordered within each epic
-- [ ] Each story leaves system in working state
+### Complete Traceability
 
-### Coverage
+- [ ] **Every FR from PRD.md is covered by at least one story in epics.md**
+- [ ] Each story references relevant FR numbers
+- [ ] No orphaned FRs (requirements without stories)
+- [ ] No orphaned stories (stories without FR connection)
+- [ ] Coverage matrix verified (can trace FR → Epic → Stories)
 
-- [ ] All FRs from PRD.md are covered by stories in epics.md
-- [ ] Epic list in PRD.md matches epics in epics.md (titles and count)
+### Coverage Quality
+
+- [ ] Stories sufficiently decompose FRs into implementable units
+- [ ] Complex FRs broken into multiple stories appropriately
+- [ ] Simple FRs have appropriately scoped single stories
+- [ ] Non-functional requirements reflected in story acceptance criteria
+- [ ] Domain requirements embedded in relevant stories
+
+---
+
+## 5. Story Sequencing Validation (CRITICAL)
+
+### Epic 1 Foundation Check
+
+- [ ] **Epic 1 establishes foundational infrastructure**
+- [ ] Epic 1 delivers initial deployable functionality
+- [ ] Epic 1 creates baseline for subsequent epics
+- [ ] Exception: If adding to existing app, foundation requirement adapted appropriately
+
+### Vertical Slicing
+
+- [ ] **Each story delivers complete, testable functionality** (not horizontal layers)
+- [ ] No "build database" or "create UI" stories in isolation
+- [ ] Stories integrate across stack (data + logic + presentation when applicable)
+- [ ] Each story leaves system in working/deployable state
+
+### No Forward Dependencies
+
+- [ ] **No story depends on work from a LATER story or epic**
+- [ ] Stories within each epic are sequentially ordered
+- [ ] Each story builds only on previous work
+- [ ] Dependencies flow backward only (can reference earlier stories)
+- [ ] Parallel tracks clearly indicated if stories are independent
+
+### Value Delivery Path
+
+- [ ] Each epic delivers significant end-to-end value
+- [ ] Epic sequence shows logical product evolution
+- [ ] User can see value after each epic completion
+- [ ] MVP scope clearly achieved by end of designated epics
+
+---
+
+## 6. Scope Management
+
+### MVP Discipline
+
+- [ ] MVP scope is genuinely minimal and viable
+- [ ] Core features list contains only true must-haves
+- [ ] Each MVP feature has clear rationale for inclusion
+- [ ] No obvious scope creep in "must-have" list
+
+### Future Work Captured
+
+- [ ] Growth features documented for post-MVP
+- [ ] Vision features captured to maintain long-term direction
+- [ ] Out-of-scope items explicitly listed
+- [ ] Deferred features have clear reasoning for deferral
+
+### Clear Boundaries
+
+- [ ] Stories marked as MVP vs Growth vs Vision
+- [ ] Epic sequencing aligns with MVP → Growth progression
+- [ ] No confusion about what's in vs out of initial scope
+
+---
+
+## 7. Research and Context Integration
+
+### Source Document Integration
+
+- [ ] **If product brief exists:** Key insights incorporated into PRD
+- [ ] **If domain brief exists:** Domain requirements reflected in FRs and stories
+- [ ] **If research documents exist:** Research findings inform requirements
+- [ ] **If competitive analysis exists:** Differentiation strategy clear in PRD
+- [ ] All source documents referenced in PRD References section
+
+### Research Continuity to Architecture
+
+- [ ] Domain complexity considerations documented for architects
+- [ ] Technical constraints from research captured
+- [ ] Regulatory/compliance requirements clearly stated
+- [ ] Integration requirements with existing systems documented
+- [ ] Performance/scale requirements informed by research data
+
+### Information Completeness for Next Phase
+
+- [ ] PRD provides sufficient context for architecture decisions
+- [ ] Epics provide sufficient detail for technical design
+- [ ] Stories have enough acceptance criteria for implementation
+- [ ] Non-obvious business rules documented
+- [ ] Edge cases and special scenarios captured
 
 ---
 
-## 4. Cross-Document Consistency
+## 8. Cross-Document Consistency
 
-- [ ] Epic titles consistent between PRD.md and epics.md
-- [ ] FR references in user journeys exist in requirements section
-- [ ] Terminology consistent across documents
+### Terminology Consistency
+
+- [ ] Same terms used across PRD and epics for concepts
+- [ ] Feature names consistent between documents
+- [ ] Epic titles match between PRD and epics.md
 - [ ] No contradictions between PRD and epics
 
+### Alignment Checks
+
+- [ ] Success metrics in PRD align with story outcomes
+- [ ] Product magic articulated in PRD reflected in epic goals
+- [ ] Technical preferences in PRD align with story implementation hints
+- [ ] Scope boundaries consistent across all documents
+
+---
+
+## 9. Readiness for Implementation
+
+### Architecture Readiness (Next Phase)
+
+- [ ] PRD provides sufficient context for architecture workflow
+- [ ] Technical constraints and preferences documented
+- [ ] Integration points identified
+- [ ] Performance/scale requirements specified
+- [ ] Security and compliance needs clear
+
+### Development Readiness
+
+- [ ] Stories are specific enough to estimate
+- [ ] Acceptance criteria are testable
+- [ ] Technical unknowns identified and flagged
+- [ ] Dependencies on external systems documented
+- [ ] Data requirements specified
+
+### Track-Appropriate Detail
+
+**If BMad Method:**
+
+- [ ] PRD supports full architecture workflow
+- [ ] Epic structure supports phased delivery
+- [ ] Scope appropriate for product/platform development
+- [ ] Clear value delivery through epic sequence
+
+**If Enterprise Method:**
+
+- [ ] PRD addresses enterprise requirements (security, compliance, multi-tenancy)
+- [ ] Epic structure supports extended planning phases
+- [ ] Scope includes security, devops, and test strategy considerations
+- [ ] Clear value delivery with enterprise gates
+
 ---
 
-## 5. Readiness for Next Phase
+## 10. Quality and Polish
+
+### Writing Quality
 
-**Adapt based on project level from bmm-workflow-status.md:**
+- [ ] Language is clear and free of jargon (or jargon is defined)
+- [ ] Sentences are concise and specific
+- [ ] No vague statements ("should be fast", "user-friendly")
+- [ ] Measurable criteria used throughout
+- [ ] Professional tone appropriate for stakeholder review
 
-### If Level 2:
+### Document Structure
 
-- [ ] PRD provides sufficient context for tech-spec workflow (lightweight solutioning)
-- [ ] Epic structure supports 5-15 story implementation scope
+- [ ] Sections flow logically
+- [ ] Headers and numbering consistent
+- [ ] Cross-references accurate (FR numbers, section references)
+- [ ] Formatting consistent throughout
+- [ ] Tables/lists formatted properly
 
-### If Level 3-4:
+### Completeness Indicators
 
-- [ ] PRD provides sufficient context for create-architecture workflow
-- [ ] Epic structure supports phased delivery approach
-- [ ] Clear value delivery path through epic sequence
+- [ ] No [TODO] or [TBD] markers remain
+- [ ] No placeholder text
+- [ ] All sections have substantive content
+- [ ] Optional sections either complete or omitted (not half-done)
 
 ---
 
-## 6. Critical Failures (Auto-Fail)
+## Critical Failures (Auto-Fail)
 
-- [ ] ❌ **No epics.md file** (two-file output is required)
-- [ ] ❌ **Epic 1 doesn't establish foundation** (violates core principle)
-- [ ] ❌ **Stories have forward dependencies** (would break sequential implementation)
+If ANY of these are true, validation FAILS:
+
+- [ ] ❌ **No epics.md file exists** (two-file output required)
+- [ ] ❌ **Epic 1 doesn't establish foundation** (violates core sequencing principle)
+- [ ] ❌ **Stories have forward dependencies** (breaks sequential implementation)
 - [ ] ❌ **Stories not vertically sliced** (horizontal layers block value delivery)
-- [ ] ❌ **Technical decisions in PRD** (should be in technical-decisions.md)
 - [ ] ❌ **Epics don't cover all FRs** (orphaned requirements)
-- [ ] ❌ **User journeys don't reference FR numbers** (missing traceability)
+- [ ] ❌ **FRs contain technical implementation details** (should be in architecture)
+- [ ] ❌ **No FR traceability to stories** (can't validate coverage)
+- [ ] ❌ **Template variables unfilled** (incomplete document)
 
 ---
 
-## Validation Notes
+## Validation Summary
+
+**Total Validation Points:** ~85
 
-**Document any findings:**
+### Scoring Guide
 
-- Strengths:
-- Issues to address:
-- Recommended actions:
+- **Pass Rate ≥ 95% (81+/85):** ✅ EXCELLENT - Ready for architecture phase
+- **Pass Rate 85-94% (72-80/85):** ⚠️ GOOD - Minor fixes needed
+- **Pass Rate 70-84% (60-71/85):** ⚠️ FAIR - Important issues to address
+- **Pass Rate < 70% (<60/85):** ❌ POOR - Significant rework required
+
+### Critical Issue Threshold
+
+- **0 Critical Failures:** Proceed to fixes
+- **1+ Critical Failures:** STOP - Must fix critical issues first
+
+---
 
-**Ready for next phase?** [Yes / No - explain]
+## Validation Execution Notes
+
+**When validating:**
+
+1. **Load ALL documents:**
+   - PRD.md (required)
+   - epics.md (required)
+   - product-brief.md (if exists)
+   - domain-brief.md (if exists)
+   - research documents (if referenced)
+
+2. **Validate in order:**
+   - Check critical failures first (immediate stop if any found)
+   - Verify PRD completeness
+   - Verify epics completeness
+   - Cross-reference FR coverage (most important)
+   - Check sequencing (second most important)
+   - Validate research integration
+   - Check polish and quality
+
+3. **Report findings:**
+   - List critical failures prominently
+   - Group issues by severity
+   - Provide specific line numbers/sections
+   - Suggest concrete fixes
+   - Highlight what's working well
+
+4. **Provide actionable next steps:**
+   - If validation passes: "Ready for architecture workflow"
+   - If minor issues: "Fix [X] items then re-validate"
+   - If major issues: "Rework [sections] then re-validate"
+   - If critical failures: "Must fix critical items before proceeding"
 
 ---
 
-_Adapt this checklist based on actual outputs. Not all sections may apply to every project._
+**Remember:** This validation ensures the entire planning phase is complete and the implementation phase has everything needed to succeed. Be thorough but fair - the goal is quality, not perfection.