feat(bmm): enhance PRD workflow with brownfield project support (#1047)

- Add three-branch conditional logic for document-based discovery:
  - PATH A: Has Product Brief (any project type)
  - PATH B: No Brief + Has Project Docs (brownfield)
  - PATH C: No Documents (greenfield from scratch)
- Add YAML frontmatter to all 12 PRD step files
- Add documentCounts to frontmatter for state tracking
- Fix step count (11 steps, not 10) and path typos
- Remove non-existent workflow references (story-context, validate-architecture)
- Update workflow chains and glossary definitions

Key insight: Branch based on DOCUMENT TYPE, not PROJECT TYPE.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-authored-by: Claude <noreply@anthropic.com>

src/modules/bmm/docs/agents-guide.md

@@ -144,7 +144,6 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
 
 - `workflow-status` - Check what to do next
 - `create-architecture` - Produce a Scale Adaptive Architecture
-- `validate-architecture` - Validate architecture document
 - `implementation-readiness` - Validate PRD + Architecture + Epics + UX (optional)
 
 **Communication Style:** Comprehensive yet pragmatic. Uses architectural metaphors. Balances technical depth with accessibility. Connects decisions to business value.
@@ -644,7 +643,6 @@ Many workflows have optional validation workflows that perform independent revie
 | Validation                 | Agent       | Validates                                  |
 | -------------------------- | ----------- | ------------------------------------------ |
 | `implementation-readiness` | Architect   | PRD + Architecture + Epics + UX (optional) |
-| `validate-architecture`    | Architect   | Architecture document                      |
 | `validate-design`          | UX Designer | UX specification and artifacts             |
 | `validate-create-story`    | SM          | Story draft                                |
 
@@ -976,7 +974,7 @@ Quick reference for agent selection:
 | **PM**                  | 📋   | 2 (Planning)            | prd, tech-spec, epics-stories                 | Planning, requirements docs             |
 | **UX Designer**         | 🎨   | 2 (Planning)            | create-ux-design, validate-design             | UX-heavy projects, design               |
 | **Architect**           | 🏗️   | 3 (Solutioning)         | architecture, implementation-readiness        | Technical design, architecture          |
-| **SM**                  | 🏃   | 4 (Implementation)      | sprint-planning, create-story, story-context  | Story management, sprint coordination   |
+| **SM**                  | 🏃   | 4 (Implementation)      | sprint-planning, create-story                 | Story management, sprint coordination   |
 | **DEV**                 | 💻   | 4 (Implementation)      | develop-story, code-review                    | Implementation, coding                  |
 | **TEA**                 | 🧪   | All Phases              | framework, atdd, automate, trace, ci          | Testing, quality assurance              |
 | **Paige (Tech Writer)** | 📚   | All Phases              | document-project, diagrams, validation        | Documentation, diagrams                 |

src/modules/bmm/docs/brownfield-guide.md

@@ -250,8 +250,8 @@ Without AI-optimized documentation, workflows fail:
 
 - **tech-spec** (Quick Flow) can't auto-detect stack/patterns → Makes wrong assumptions
 - **PRD** (BMad Method) can't reference existing code → Designs incompatible features
-- **architecture** can't build on existing structure → Suggests conflicting patterns
-- **story-context** can't inject existing patterns → Dev agent rewrites working code
+- **create-architecture** can't build on existing structure → Suggests conflicting patterns
+- **create-story** can't provide existing pattern context → Stories lack integration guidance
 - **dev-story** invents implementations → Breaks existing integrations
 
 ### Key Principle
@@ -370,7 +370,7 @@ When workflow-init asks about your work:
 
 ### 4. Respect Existing Patterns
 
-Tech-spec and story-context will detect conventions. Follow them unless explicitly modernizing.
+Tech-spec and create-story workflows will detect conventions from existing documentation. Follow them unless explicitly modernizing.
 
 ### 5. Plan Integration Points Explicitly
 
@@ -446,7 +446,7 @@ Document in tech-spec/architecture:
    - Analyzes existing auth patterns
    - Confirms conventions
    - Creates tech-spec.md + epic + 3-5 stories
-3. **Implement:** Load SM → `sprint-planning` → `create-story` → `story-context`
+3. **Implement:** Load SM → `sprint-planning` → `create-story`
    Load DEV → `dev-story` for each story
 4. **Review:** Load DEV → `code-review`
 
@@ -512,12 +512,9 @@ Document in tech-spec/architecture:
    - `product-brief` - Strategic document
 3. **Plan:** Load PM → `prd` (comprehensive FRs/NFRs)
 4. **Solution:**
-   - `create-architecture` - Full system architecture
-   - `integration-planning` - Phased migration strategy
-   - `create-architecture` - Multi-tenancy architecture
-   - `validate-architecture` - External review
+   - `create-architecture` - Full system architecture including multi-tenancy design
    - `create-epics-and-stories` - Create epics and stories
-   - `implementation-readiness` - Executive approval
+   - `implementation-readiness` - Final validation before implementation
 5. **Implement:** Phased sprint-based (50+ stories)
 
 **Time:** 3-6 months
@@ -564,7 +561,7 @@ Document in tech-spec/architecture:
 **Solution:**
 
 1. Ensure `document-project` captured existing architecture
-2. Check `story-context` - should document integration points
+2. Check story files created by `create-story` - should include integration context
 3. In tech-spec/architecture - explicitly document:
    - Which existing modules to modify
    - What APIs/services to integrate with
@@ -597,7 +594,7 @@ Document in tech-spec/architecture:
 
 1. Check convention detection (Quick Spec Flow should detect patterns)
 2. Review documentation - ensure `document-project` captured patterns
-3. Use `story-context` - injects pattern guidance
+3. Use `create-story` workflow - it loads context from existing documentation
 4. Add to code-review checklist: pattern adherence, convention consistency
 5. Run retrospective to identify deviations early
 
@@ -626,9 +623,9 @@ prd                     # BMad Method/Enterprise tracks
 
 # Phase 3: Solutioning (BMad Method/Enterprise)
 # Architect agent:
-architecture                 # Create/extend architecture
+create-architecture          # Create/extend architecture
 create-epics-and-stories     # Create epics and stories (after architecture)
-implementation-readiness       # Final validation
+implementation-readiness     # Final validation
 
 # Phase 4: Implementation (All Tracks)
 # SM agent:

src/modules/bmm/docs/faq.md

@@ -193,15 +193,9 @@ PRDs are for Level 2-4 projects with multiple features requiring product-level c
 
 ## Implementation
 
-### Q: Do I need story-context for every story?
+### Q: Does create-story include implementation context?
 
-**A:** Technically no, but it's recommended. story-context provides implementation-specific guidance, references existing patterns, and injects expertise. Skip it only if:
-
-- Very simple story (self-explanatory)
-- You're already expert in the area
-- Time is extremely limited
-
-For Level 0-1 using tech-spec, story-context is less critical because tech-spec is already comprehensive.
+**A:** Yes! The create-story workflow generates story files that include implementation-specific guidance, references existing patterns from your documentation, and provides technical context. The workflow loads your architecture, PRD, and existing project documentation to create comprehensive stories. For Quick Flow projects using tech-spec, the tech-spec itself is already comprehensive, so stories can be simpler.
 
 ### Q: How do I mark a story as done?
 

src/modules/bmm/docs/glossary.md

@@ -187,7 +187,7 @@ backlog → drafted → ready-for-dev → in-progress → review → done
 
 - **backlog** - Story exists in epic but not yet drafted
 - **drafted** - Story file created by SM via create-story
-- **ready-for-dev** - Story has context, ready for DEV via story-context
+- **ready-for-dev** - Story drafted and reviewed, ready for DEV
 - **in-progress** - DEV is implementing via dev-story
 - **review** - Implementation complete, awaiting code-review
 - **done** - Completed with DoD met
@@ -238,7 +238,7 @@ Markdown file containing story details: description, acceptance criteria, techni
 
 ### Story Context
 
-Technical guidance document created via story-context workflow that provides implementation-specific context, references existing patterns, suggests approaches, and injects expertise for the specific story.
+Implementation guidance embedded within story files during the create-story workflow. Provides implementation-specific context, references existing patterns, suggests approaches, and helps maintain consistency with established codebase conventions.
 
 ### Sprint Planning
 

src/modules/bmm/docs/quick-start.md

@@ -313,11 +313,10 @@ flowchart LR
         direction TB
         D1[Per Epic:<br/>epic context]
         D2[Per Story:<br/>create-story]
-        D3[story-context]
-        D4[dev-story]
-        D5[code-review]
-        D6[SM, DEV]
-        D1 ~~~ D2 ~~~ D3 ~~~ D4 ~~~ D5 ~~~ D6
+        D3[dev-story]
+        D4[code-review]
+        D5[SM, DEV]
+        D1 ~~~ D2 ~~~ D3 ~~~ D4 ~~~ D5
     end
 
     P1 --> P2

src/modules/bmm/docs/workflows-implementation.md

@@ -70,7 +70,7 @@ For a visual representation of the complete workflow, see: [workflow-method-gree
 Stories move through these states in the sprint status file:
 
 1. **TODO** - Story identified but not started
-2. **IN PROGRESS** - Story being implemented (create-story → story-context → dev-story)
+2. **IN PROGRESS** - Story being implemented (create-story → dev-story)
 3. **READY FOR REVIEW** - Implementation complete, awaiting code review
 4. **DONE** - Accepted and complete