feat(bmad-prd): funnel discipline, UJ depth, and UX reframing

Template discipline for downstream AI extraction:
- §3 Glossary: exact-use enforcement (FRs, UJs, SMs use Glossary terms verbatim)
- §4 Features: FRs now use "#### FR-N: Name" heading with Realizes UJ-X cross-reference, testable consequences, and optional per-FR Out of Scope
- §7 Success Metrics: SM-N / SM-CN numbering with Validates FR-X cross-reference

User journeys:
- §2.4 UJ format expanded from one-liner to named-persona mini-flow (persona, 3-5 steps, edge cases, optional capability surfacing); hobby can collapse to one-liners
- Strip "job of UX" / "not this PRD" gatekeeping from template; depth is the team's call
- Strengthen UX-as-input / UX-as-output patterns for bidirectional PRD <-> UX flow
- SKILL.md Discovery Posture: push for two to three named-persona UJs in non-trivial scope

Validation checklist:
- Q-3 Traceability tightened to require Realizes UJ-X on FRs and Validates FR-X on SMs
- Q-7 (new): FR testability — every FR has at least one testable consequence
- S-1 Glossary integrity: now covers FR descriptions, consequences, UJ flows, SM definitions
- S-2: SM added to ID continuity scope
- S-5 (new): UJ persona linkage — every UJ names a persona by exact §2 label
- STK-2 (new): UJ density gate — non-hobby scope needs at least two UJs

src/bmm-skills/2-plan-workflows/bmad-prd/SKILL.md

@@ -44,7 +44,11 @@ How every turn runs, regardless of intent.
 
 ### Posture
 
-Coach, do not quiz. Push hardest on PRD Discipline risks: unexamined assumptions, capability-vs-implementation confusion, term drift, scope creep, ambiguity for downstream readers. Suggest research if needed and have subagents use web search tools as needed. Load `references/probing.md` for the seven probing categories, critical-assumption scans, and the PRD / solution-design boundary; apply in Discovery and Update.
+Coach, do not quiz. Push hardest on PRD Discipline risks: unexamined assumptions, capability-vs-implementation confusion, term drift, scope creep, ambiguity for downstream readers. Suggest research if needed and have subagents use web search tools as needed.
+
+Push for two to three named-persona user journeys even when the user does not propose them. UJs are how teams discover persona gaps, scope ambiguity, and missed failure handling. Solo/hobby scope can drop to one or none.
+
+Load `references/probing.md` for the seven probing categories, critical-assumption scans, and the PRD / solution-design boundary; apply in Discovery and Update.
 
 ### Brain dump
 

src/bmm-skills/2-plan-workflows/bmad-prd/assets/prd-template.md

@@ -34,15 +34,29 @@ updated: {YYYY-MM-DD}
 [Who this is explicitly not for in v1.]
 
 ### 2.4 Key User Journeys
-*Named flows the product enables — one line each, numbered globally as UJ-1 through UJ-N for downstream traceability. Detailed flow design (steps, screens, edge flows) is the job of the UX workflow, not this PRD. Features in §4 may reference journeys by ID inline ("realizes UJ-3").*
+*Named-persona flows the product enables. Numbered globally as UJ-1 through UJ-N. FRs reference journeys by ID inline ("realizes UJ-3"); SMs may also cross-reference. Depth is the team's call — the default below carries enough detail for downstream extraction; PMs may go deeper, including full UX-level detail with screens and micro-interactions, if they choose. If a UX doc already exists, mirror its UJ IDs here and point to the source.*
 
-- **UJ-1** — [Named flow, one line: who does what, to what end.]
-- **UJ-2** — ...
+#### UJ-1: {Persona doing the thing}
 
-[For hobby/utility projects, 1-3 journeys may be enough. For complex multi-feature products (onboarding, checkout, multi-step approvals), expand. For libraries/CLIs with minimal flow, reduce to a single line or collapse into §2.2 JTBD.]
+**Persona:** {Name from §2.1, e.g. "Merchant Admin"}
+
+**Flow:**
+1. {step}
+2. {step}
+3. {step}
+
+**Edge cases:**
+- {real failure mode and what the user does next}
+
+**Capabilities surfaced:** *(optional)*
+- The system must {capability}. → FR-N
+
+#### UJ-2: ...
+
+[Hobby/solo scope can collapse each UJ to a one-liner ("UJ-1 — short flow description"). For complex products with onboarding, checkout, multi-step approvals, etc., expand further. For libraries/CLIs with minimal flow, reduce to a single line or collapse into §2.2 JTBD.]
 
 ## 3. Glossary
-*Downstream workflows and readers must use these terms exactly.*
+*Downstream workflows and readers must use these terms exactly. FRs, UJs, and SMs use Glossary terms verbatim; introducing a synonym anywhere in the PRD is a discipline violation. If §4 introduces a new domain noun, add it to the Glossary in the same pass.*
 
 - **Term** — Definition. Relationships to other Glossary terms. Cardinality where relevant.
 - **Term** — ...
@@ -53,11 +67,22 @@ updated: {YYYY-MM-DD}
 *Each subsection is a coherent feature: behavioral description first, FRs nested under it, optional feature-specific NFRs and notes. FRs are numbered globally (FR-1 through FR-N) so downstream artifacts have stable references even if features get reorganized. Reference user journeys by ID inline ("realizes UJ-2") where the chain matters.*
 
 ### 4.1 {Feature Name}
-**Description:** [Behavioral narrative — how this feature works, who uses it, the user experience, edge cases. Use Glossary terms exactly. Embed inline `[ASSUMPTION: ...]` tags where you inferred without confirmation.]
+**Description:** [Behavioral narrative — how this feature works, who uses it, the user experience, edge cases. Realizes UJ-X, UJ-Y. Use Glossary terms exactly. Embed inline `[ASSUMPTION: ...]` tags where you inferred without confirmation.]
 
 **Functional Requirements:**
-- **FR-1** — [Actor] can [capability] [under conditions / with measurement].
-- **FR-2** — ...
+
+#### FR-1: {Short capability name}
+
+[Actor] can [capability] [under conditions]. Realizes UJ-X.
+
+**Consequences (testable):**
+- {Specific testable condition, e.g. "System returns HTTP 429 when request rate exceeds 100/sec per merchant."}
+- {Another testable condition.}
+
+**Out of Scope:** *(optional — what this FR explicitly does NOT cover)*
+- {bound}
+
+#### FR-2: ...
 
 **Feature-specific NFRs:** *(only if any apply uniquely to this feature)*
 - Performance / security / accessibility / etc. specific to this feature.
@@ -80,14 +105,16 @@ updated: {YYYY-MM-DD}
 
 ## 7. Success Metrics
 
+*Each SM cross-references the FR(s) it validates. Counter-metrics counterbalance specific primary or secondary metrics.*
+
 **Primary**
-- Metric — definition, target.
+- **SM-1**: Metric — definition, target. Validates FR-X, FR-Y.
 
 **Secondary**
-- Metric — definition, target.
+- **SM-2**: Metric — definition, target. Validates FR-Z.
 
 **Counter-metrics (do not optimize)**
-- Metric — why this should *not* be optimized.
+- **SM-C1**: Metric — why this should *not* be optimized. Counterbalances SM-1.
 
 [Length scales with stakes. Hobby/utility PRD: a single sentence may be enough ("Success: I use this weekly and don't abandon it after a month"). Public launch / enterprise: full quantitative breakdown with measurement methods. Counter-metrics are as load-bearing as primary metrics — they prevent the architect from optimizing the wrong thing and the dev from gaming the wrong target.]
 
@@ -148,11 +175,11 @@ updated: {YYYY-MM-DD}
 
 - **The essential spine is the floor, not the ceiling.** A hobby PRD might keep all ten sections short. An enterprise PRD layers many clusters from the adapt-in menu.
 - **§3 Glossary before §4 Features.** Mechanics never introduce a new domain noun without adding it to the Glossary in the same pass. Persona, JTBD, and Journeys may use Glossary terms before §3 formally defines them — context is inferable; the Glossary is for downstream anchoring.
-- **§2.4 Key User Journeys are brief.** One line each. Numbered globally (UJ-1 through UJ-N) so architecture, epics, stories, and tickets can reference them by stable ID. Detailed flow design happens in the UX workflow — not here.
-- **§4 Features pattern at every scale.** Description → FRs nested → optional NFRs → optional notes. Hobby PRD: one short paragraph and three FRs per feature. Enterprise feature: multi-paragraph description, fifteen FRs, several feature-specific NFRs, open questions. Same shape, different depth.
+- **§2.4 Key User Journeys carry signal.** Default shape is named-persona mini-flow (persona, 3-5 steps, edge cases, optional capability surfacing). PMs can go deeper, including full UX-level detail, if they choose. Hobby/solo scope can collapse to one-liners. UJs are how teams discover persona gaps, scope ambiguity, and missed failure handling — push for two to three in any non-trivial scope.
+- **§4 Features pattern at every scale.** Description → FRs nested (each as `#### FR-N: Name` with testable consequences and optional per-FR Out of Scope) → optional feature-specific NFRs → optional notes. Hobby PRD: one short paragraph and three FRs per feature. Enterprise feature: multi-paragraph description, fifteen FRs, several feature-specific NFRs, open questions. Same shape, different depth.
 - **`[ASSUMPTION]`, `[NON-GOAL]`, `[v2 — out of MVP]`, `[NOTE FOR PM]` callouts are first-class.** They signal to downstream readers and the next session of work. Every `[ASSUMPTION]` lands in §9 Assumptions Index.
-- **When UX is *input* to the PRD** (journeys already designed elsewhere): §2.4 names the journeys by ID and points to the existing UX doc. Reference, do not duplicate.
-- **When UX is *output* of the PRD** (no UX work yet — downstream `bmad-create-ux-design` will produce it): §2.4 captures the PM's intent on which journeys exist; UX elaborates them into detailed flows downstream.
+- **When UX is *input* to the PRD** (journeys already designed elsewhere): §2.4 mirrors the UX UJ IDs and points to the source doc. The PRD references, does not duplicate. Personas in §2.1 also mirror what the UX doc defined.
+- **When UX is *output* of the PRD** (no UX work yet, may go to `bmad-create-ux-design` later): §2.4 carries the PM's understanding of the journeys with enough flow detail to be extractable downstream. UX elaboration adds screens, IA, and micro-interactions on top.
 - **§7 Success Metrics scales with stakes** but is always present. Counter-metrics matter as much as primary metrics — they shape what NOT to optimize.
 - **Small-scope all-inclusive option.** When scope is genuinely 1-2 stories and the user wants a single artifact instead of running a separate `bmad-create-story` workflow, add the adapt-in *Stories* cluster: lean §1-§6 plus inline §Stories at the end. The whole doc fits on a page or two. This is a valid PRD shape for tiny work — don't apologize for it.
 - **Adapt the section numbering.** The spine uses 0-9; adapt-in additions slot in wherever they read best (e.g., Aesthetic & Tone before §3 if branding is foundational, Compliance after §5 Non-Goals, Constraints & Guardrails between Features and Non-Goals, Stories at the very end after Assumptions Index).

src/bmm-skills/2-plan-workflows/bmad-prd/assets/prd-validation-checklist.md

@@ -6,10 +6,11 @@ Loaded by the PRD validator subagent. For each item, return `{id, status: pass|f
 
 - **Q-1. Information density.** Sentences carry weight. Flag filler, hedging, and conversational padding.
 - **Q-2. Measurability.** Where measurement matters, FRs and Success Metrics are measurable; subjective adjectives flagged. Counter-metrics named when Success Metrics exist.
-- **Q-3. Traceability.** Where the chain matters, FRs name their link to a user journey or success criterion inline.
+- **Q-3. Traceability.** Every FR includes `Realizes UJ-X` referencing a UJ in §2.4. Every SM includes `Validates FR-X` referencing one or more FRs. Cross-references resolve.
 - **Q-4. Vision and JTBDs concrete.** Vision is specific and stands alone — not a generic feature list. JTBDs are audience-grounded, not abstract.
 - **Q-5. Non-Goals explicit.** A Non-Goals section is present where it would do real work; inline `[NON-GOAL]` and `[v2]` callouts where omissions would otherwise be silently assumed.
 - **Q-6. Dual-audience and self-contained.** Each section makes sense pulled out alone (cross-references via Glossary terms, not "see above"); the PRD is readable by humans and structured cleanly for downstream source-extraction by UX, architecture, and story-creation workflows.
+- **Q-7. FR testability.** Every FR has at least one testable consequence (verifiable condition with measurable outcome). Flag hand-waves like "system handles X gracefully" or "reasonable performance."
 
 ## Discipline
 
@@ -20,11 +21,13 @@ Loaded by the PRD validator subagent. For each item, return `{id, status: pass|f
 
 ## Structural integrity
 
-- **S-1. Glossary integrity.** Every domain noun is defined in the Glossary and used identically throughout. Flag drift (case, plural, synonyms) and candidate missing-term entries.
-- **S-2. ID continuity.** FR / UJ / Story IDs are contiguous, unique, and cross-references resolve.
+- **S-1. Glossary integrity.** Every domain noun is defined in the Glossary and used identically throughout — including in FR descriptions, consequences, UJ flows, and SM definitions. Flag drift (case, plural, synonyms) and candidate missing-term entries.
+- **S-2. ID continuity.** FR / UJ / SM / Story IDs are contiguous, unique, and cross-references resolve.
 - **S-3. Assumptions Index.** Every inline `[ASSUMPTION: ...]` appears in the Assumptions Index and vice versa.
 - **S-4. Open-items density.** Count Open Questions + `[ASSUMPTION]` + `[NOTE FOR PM]`. Red flag if density is high relative to the agreed stakes.
+- **S-5. UJ persona linkage.** Every UJ names a persona from §2 by exact label. Flag floating UJs that don't tie to a defined persona.
 
 ## Stakes-gated
 
 - **STK-1. Required sections.** The PRD includes the sections the agreed stakes and product type warrant.
+- **STK-2. UJ density.** For non-hobby/non-solo scope, at least two named-persona UJs present in §2.4. Hobby/solo scope is exempt.