fix(prd): require explicit user confirmation before de-scoping requirements or inventing phases

Author: sunilp

src/bmm-skills/2-plan-workflows/bmad-create-prd/steps-c/step-08-scoping.md

@@ -12,6 +12,8 @@
 - 📋 YOU ARE A FACILITATOR, not a content generator
 - 💬 FOCUS on strategic scope decisions that keep projects viable
 - 🎯 EMPHASIZE lean MVP thinking while preserving long-term vision
+- ⚠️ NEVER de-scope, defer, or phase out requirements that the user explicitly included in their input documents without asking first
+- ⚠️ NEVER invent phasing (MVP/Growth/Vision) unless the user requests phased delivery — if input documents define all components as core requirements, they are ALL in scope
 - ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
 - ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
 
@@ -75,10 +77,23 @@ Use structured decision-making for scope:
   - Advanced functionality that builds on MVP
 - Ask what features could be added in versions 2, 3, etc.
 
+**⚠️ SCOPE CHANGE CONFIRMATION GATE:**
+- If you believe any user-specified requirement should be deferred or de-scoped, you MUST present this to the user and get explicit confirmation BEFORE removing it from scope
+- Frame it as a recommendation, not a decision: "I'd recommend deferring X because [reason]. Do you agree, or should it stay in scope?"
+- NEVER silently move user requirements to a later phase or exclude them from MVP
+
 ### 4. Progressive Feature Roadmap
 
-Create phased development approach:
-- Guide mapping of features across development phases
+**CRITICAL: Phasing is NOT automatic. Check the user's input first.**
+
+Before proposing any phased approach, review the user's input documents:
+
+- **If the input documents define all components as core requirements with no mention of phases:** Present all requirements as a single release scope. Do NOT invent phases or move requirements to fabricated future phases.
+- **If the input documents explicitly request phased delivery:** Guide mapping of features across the phases the user defined.
+- **If scope is unclear:** ASK the user whether they want phased delivery or a single release before proceeding.
+
+**When the user wants phased delivery**, guide mapping of features across development phases:
+
 - Structure as Phase 1 (MVP), Phase 2 (Growth), Phase 3 (Vision)
 - Ensure clear progression and dependencies
 
@@ -98,6 +113,12 @@ Create phased development approach:
 - Platform features
 - New markets or use cases
 
+**When the user wants a single release**, define the complete scope:
+
+- All user-specified requirements are in scope
+- Focus must-have vs nice-to-have analysis on what ships in this release
+- Do NOT create phases — use must-have/nice-to-have priority within the single release
+
 **Where does your current vision fit in this development sequence?**"
 
 ### 5. Risk-Based Scoping
@@ -129,6 +150,8 @@ Prepare comprehensive scoping section:
 
 #### Content Structure:
 
+**If user chose phased delivery:**
+
 ```markdown
 ## Project Scoping & Phased Development
 
@@ -160,6 +183,34 @@ Prepare comprehensive scoping section:
 **Resource Risks:** {{contingency_approach}}
 ```
 
+**If user chose single release (no phasing):**
+
+```markdown
+## Project Scoping
+
+### Strategy & Philosophy
+
+**Approach:** {{chosen_approach}}
+**Resource Requirements:** {{team_size_and_skills}}
+
+### Complete Feature Set
+
+**Core User Journeys Supported:**
+{{all_journeys}}
+
+**Must-Have Capabilities:**
+{{list_of_must_have_features}}
+
+**Nice-to-Have Capabilities:**
+{{list_of_nice_to_have_features}}
+
+### Risk Mitigation Strategy
+
+**Technical Risks:** {{mitigation_approach}}
+**Market Risks:** {{validation_approach}}
+**Resource Risks:** {{contingency_approach}}
+```
+
 ### 7. Present MENU OPTIONS
 
 Present the scoping decisions for review, then display menu:
@@ -189,8 +240,9 @@ When user selects 'C', append the content directly to the document using the str
 
 ✅ Complete PRD document analyzed for scope implications
 ✅ Strategic MVP approach defined and justified
-✅ Clear MVP feature boundaries established
-✅ Phased development roadmap created
+✅ Clear feature boundaries established (phased or single-release, per user preference)
+✅ All user-specified requirements accounted for — none silently removed or deferred
+✅ Any scope reduction recommendations presented to user with rationale and explicit confirmation obtained
 ✅ Key risks identified and mitigation strategies defined
 ✅ User explicitly agrees to scope decisions
 ✅ A/P/C menu presented and handled correctly
@@ -202,8 +254,10 @@ When user selects 'C', append the content directly to the document using the str
 ❌ Making scope decisions without strategic rationale
 ❌ Not getting explicit user agreement on MVP boundaries
 ❌ Missing critical risk analysis
-❌ Not creating clear phased development approach
 ❌ Not presenting A/P/C menu after content generation
+❌ **CRITICAL**: Silently de-scoping or deferring requirements that the user explicitly included in their input documents
+❌ **CRITICAL**: Inventing phasing (MVP/Growth/Vision) when the user did not request phased delivery
+❌ **CRITICAL**: Making consequential scoping decisions (what is in/out of scope) without explicit user confirmation
 
 ❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
 ❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file

src/bmm-skills/2-plan-workflows/bmad-create-prd/steps-c/step-11-polish.md

@@ -138,7 +138,7 @@ Make targeted improvements:
 - All user success criteria
 - All functional requirements (capability contract)
 - All user journey narratives
-- All scope decisions (MVP, Growth, Vision)
+- All scope decisions (whether phased or single-release)
 - All non-functional requirements
 - Product differentiator and vision
 - Domain-specific requirements