Merge 8bb2615561 into 454b19a125

The PRD workflow step-02 was refactored to be discovery-only with
forward references to steps 2b and 2c, but those files were never
created. This left a gap where the workflow jumped from classification
directly to success criteria with no executive summary generation.

- Add step-02b-vision.md: collaborative vision/differentiator discovery
- Add step-02c-executive-summary.md: generate and append exec summary
- Update step-02 nextStepFile to chain through 02b instead of skipping to 03

src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-02-discovery.md

@@ -3,7 +3,7 @@ name: 'step-02-discovery'
 description: 'Discover project type, domain, and context through collaborative dialogue'
 
 # File References
-nextStepFile: './step-03-success.md'
+nextStepFile: './step-02b-vision.md'
 outputFile: '{planning_artifacts}/prd.md'
 
 # Data Files

src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-02b-vision.md

@@ -0,0 +1,154 @@
+---
+name: 'step-02b-vision'
+description: 'Discover the product vision and differentiator through collaborative dialogue'
+
+# File References
+nextStepFile: './step-02c-executive-summary.md'
+outputFile: '{planning_artifacts}/prd.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 2b: Product Vision Discovery
+
+**Progress: Step 2b of 13** - Next: Executive Summary
+
+## STEP GOAL:
+
+Discover what makes this product special and understand the product vision through collaborative conversation. No content generation — facilitation only.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
+- ✅ ALWAYS treat this as collaborative discovery between PM peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a product-focused PM facilitator collaborating with an expert peer
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring structured thinking and facilitation skills, while the user brings domain expertise and product vision
+
+### Step-Specific Rules:
+
+- 🎯 Focus on discovering vision and differentiator — no content generation yet
+- 🚫 FORBIDDEN to generate executive summary content (that's the next step)
+- 🚫 FORBIDDEN to append anything to the document in this step
+- 💬 APPROACH: Natural conversation to understand what makes this product special
+- 🎯 BUILD ON classification insights from step 2
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after vision discovery is complete
+- 📖 Update frontmatter, adding this step to the end of the list of stepsCompleted
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## CONTEXT BOUNDARIES:
+
+- Current document and frontmatter from steps 1 and 2 are available
+- Project classification exists from step 2 (project type, domain, complexity, context)
+- Input documents already loaded are in memory (product briefs, research, brainstorming, project docs)
+- No executive summary content yet (that's step 2c)
+- This step ONLY discovers — it does NOT write to the document
+
+## YOUR TASK:
+
+Discover the product vision and differentiator through natural conversation. Understand what makes this product unique and valuable before any content is written.
+
+## VISION DISCOVERY SEQUENCE:
+
+### 1. Acknowledge Classification Context
+
+Reference the classification from step 2 and use it to frame the vision conversation:
+
+"We've established this is a {{projectType}} in the {{domain}} domain with {{complexityLevel}} complexity. Now let's explore what makes this product special."
+
+### 2. Explore What Makes It Special
+
+Guide the conversation to uncover the product's unique value:
+
+- **User delight:** "What would make users say 'this is exactly what I needed'?"
+- **Differentiation moment:** "What's the moment where users realize this is different or better than alternatives?"
+- **Core insight:** "What insight or approach makes this product possible or unique?"
+- **Value proposition:** "If you had one sentence to explain why someone should use this over anything else, what would it be?"
+
+### 3. Understand the Vision
+
+Dig deeper into the product vision:
+
+- **Problem framing:** "What's the real problem you're solving — not the surface symptom, but the deeper need?"
+- **Future state:** "When this product is successful, what does the world look like for your users?"
+- **Why now:** "Why is this the right time to build this?"
+
+### 4. Validate Understanding
+
+Reflect back what you've heard and confirm:
+
+"Here's what I'm hearing about your vision and differentiator:
+
+**Vision:** {{summarized_vision}}
+**What Makes It Special:** {{summarized_differentiator}}
+**Core Insight:** {{summarized_insight}}
+
+Does this capture it? Anything I'm missing?"
+
+Let the user confirm or refine your understanding.
+
+### N. Present MENU OPTIONS
+
+Present your understanding of the product vision for review, then display menu:
+
+"Based on our conversation, I have a clear picture of your product vision and what makes it special. I'll use these insights to draft the Executive Summary in the next step.
+
+**What would you like to do?**"
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Executive Summary (Step 2c of 13)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow: {advancedElicitationTask} with the current vision insights, process the enhanced insights that come back, ask user if they accept the improvements, if yes update understanding then redisplay menu, if no keep original understanding then redisplay menu
+- IF P: Read fully and follow: {partyModeWorkflow} with the current vision insights, process the collaborative insights, ask user if they accept the changes, if yes update understanding then redisplay menu, if no keep original understanding then redisplay menu
+- IF C: Update {outputFile} frontmatter by adding this step name to the end of stepsCompleted array, then read fully and follow: {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN [C continue option] is selected and [stepsCompleted updated], will you then read fully and follow: `{nextStepFile}` to generate the Executive Summary.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Classification context from step 2 acknowledged and built upon
+- Natural conversation to understand product vision and differentiator
+- User's existing documents (briefs, research, brainstorming) leveraged for vision insights
+- Vision and differentiator validated with user before proceeding
+- Clear understanding established that will inform Executive Summary generation
+- Frontmatter updated with stepsCompleted when C selected
+
+### ❌ SYSTEM FAILURE:
+
+- Generating executive summary or any document content (that's step 2c!)
+- Appending anything to the PRD document
+- Not building on classification from step 2
+- Being prescriptive instead of having natural conversation
+- Proceeding without user selecting 'C'
+
+❌ **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
+
+**Master Rule:** This step is vision discovery only. No content generation, no document writing. Have natural conversations, build on what you know from classification, and establish the vision that will feed into the Executive Summary.

src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-02c-executive-summary.md

@@ -0,0 +1,170 @@
+---
+name: 'step-02c-executive-summary'
+description: 'Generate and append the Executive Summary section to the PRD document'
+
+# File References
+nextStepFile: './step-03-success.md'
+outputFile: '{planning_artifacts}/prd.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 2c: Executive Summary Generation
+
+**Progress: Step 2c of 13** - Next: Success Criteria
+
+## STEP GOAL:
+
+Generate the Executive Summary content using insights from classification (step 2) and vision discovery (step 2b), then append it to the PRD document.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read
+- ✅ ALWAYS treat this as collaborative discovery between PM peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are a product-focused PM facilitator collaborating with an expert peer
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ Content is drafted collaboratively — present for review before saving
+
+### Step-Specific Rules:
+
+- 🎯 Generate Executive Summary content based on discovered insights
+- 💬 Present draft content for user review and refinement before appending
+- 🚫 FORBIDDEN to append content without user approval via 'C'
+- 🎯 Content must be dense, precise, and zero-fluff (PRD quality standards)
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating executive summary content
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update output file frontmatter, adding this step name to the end of the list of stepsCompleted
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## CONTEXT BOUNDARIES:
+
+- Current document and frontmatter from steps 1, 2, and 2b are available
+- Project classification exists from step 2 (project type, domain, complexity, context)
+- Vision and differentiator insights exist from step 2b
+- Input documents from step 1 are available (product briefs, research, brainstorming, project docs)
+- This step generates and appends the first substantive content to the PRD
+
+## YOUR TASK:
+
+Draft the Executive Summary section using all discovered insights, present it for user review, and append it to the PRD document when approved.
+
+## EXECUTIVE SUMMARY GENERATION SEQUENCE:
+
+### 1. Synthesize Available Context
+
+Review all available context before drafting:
+- Classification from step 2: project type, domain, complexity, project context
+- Vision and differentiator from step 2b: what makes this special, core insight
+- Input documents: product briefs, research, brainstorming, project docs
+
+### 2. Draft Executive Summary Content
+
+Generate the Executive Summary section using the content structure below. Apply PRD quality standards:
+- High information density — every sentence carries weight
+- Zero fluff — no filler phrases or vague language
+- Precise and actionable — clear, specific statements
+- Dual-audience optimized — readable by humans, consumable by LLMs
+
+### 3. Present Draft for Review
+
+Present the drafted content to the user for review:
+
+"Here's the Executive Summary I've drafted based on our discovery work. Please review and let me know if you'd like any changes:"
+
+Show the full drafted content using the structure from the Content Structure section below.
+
+Allow the user to:
+- Request specific changes to any section
+- Add missing information
+- Refine the language or emphasis
+- Approve as-is
+
+### N. Present MENU OPTIONS
+
+Present the executive summary content for user review, then display menu:
+
+"Here's the Executive Summary for your PRD. Review the content above and let me know what you'd like to do."
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Success Criteria (Step 3 of 13)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow: {advancedElicitationTask} with the current executive summary content, process the enhanced content that comes back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF P: Read fully and follow: {partyModeWorkflow} with the current executive summary content, process the collaborative improvements, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After other menu items execution, return to this menu
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', append the following content structure directly to the document:
+
+```markdown
+## Executive Summary
+
+{vision_alignment_content}
+
+### What Makes This Special
+
+{product_differentiator_content}
+
+## Project Classification
+
+{project_classification_content}
+```
+
+Where:
+- `{vision_alignment_content}` — Product vision, target users, and the problem being solved. Dense, precise summary drawn from step 2b vision discovery.
+- `{product_differentiator_content}` — What makes this product unique, the core insight, and why users will choose it over alternatives. Drawn from step 2b differentiator discovery.
+- `{project_classification_content}` — Project type, domain, complexity level, and project context (greenfield/brownfield). Drawn from step 2 classification.
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN [C continue option] is selected and [content appended to document], will you then read fully and follow: `{nextStepFile}` to define success criteria.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Executive Summary drafted using insights from steps 2 and 2b
+- Content meets PRD quality standards (dense, precise, zero-fluff)
+- Draft presented to user for review before saving
+- User given opportunity to refine content
+- Content properly appended to document when C selected
+- A/P/C menu presented and handled correctly
+- Frontmatter updated with stepsCompleted when C selected
+
+### ❌ SYSTEM FAILURE:
+
+- Generating content without incorporating discovered vision and classification
+- Appending content without user selecting 'C'
+- Producing vague, fluffy, or low-density content
+- Not presenting draft for user review
+- Not presenting A/P/C menu after content generation
+- Skipping directly to next step without appending content
+
+❌ **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
+❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
+
+**Master Rule:** Generate high-quality Executive Summary content from discovered insights. Present for review, refine collaboratively, and only save when the user approves. This is the first substantive content in the PRD — it sets the quality bar for everything that follows.

src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-01-init.md

@@ -64,7 +64,9 @@ Also - when searching - documents can be a single markdown file, or a folder wit
 
 Try to discover the following:
 - Product Brief (`*brief*.md`)
-- Research Documents (`*prd*.md`)
+- PRD (`*prd*.md`) - PRIMARY input: contains FRs and NFRs the UX must address
+- Architecture Document (`*architecture*.md`) - Contains technical constraints that affect UX decisions (API limits, platform requirements, performance budgets)
+- StRS (`*strs*.md`) - Enterprise track: contains user profiles and operational scenarios
 - Project Documentation (generally multiple documents might be found for this in the `{product_knowledge}` or `docs` folder.)
 - Project Context (`**/project-context.md`)
 
@@ -98,8 +100,10 @@ Report what was found:
 
 **Documents Found:**
 
-- PRD: {number of PRD files loaded or "None found"}
+- PRD: {number of PRD files loaded or "None found"} ← Key: FRs define what UX must address
 - Product brief: {number of brief files loaded or "None found"}
+- Architecture: {found or "None found"} ← Key: Technical constraints that affect UX
+- StRS: {found or "None found"} ← Enterprise: User profiles and scenarios
 - Other context: {number of other files loaded or "None found"}
 
 **Files loaded:** {list of specific file names or "No additional documents found"}

src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13-responsive-accessibility.md

@@ -227,7 +227,7 @@ Show the generated responsive and accessibility content and present choices:
 
 - Append the final content to `{planning_artifacts}/ux-design-specification.md`
 - Update frontmatter: append step to end of stepsCompleted array
-- Load `./step-14-complete.md`
+- Load `./step-13b-requirements-validation.md`
 
 ## APPEND TO DOCUMENT:
 
@@ -259,6 +259,6 @@ When user selects 'C', append the content directly to the document using the str
 
 ## NEXT STEP:
 
-After user selects 'C' and content is saved to document, load `./step-14-complete.md` to finalize the UX design workflow.
+After user selects 'C' and content is saved to document, load `./step-13b-requirements-validation.md` to finalize the UX design workflow.
 
 Remember: Do NOT proceed to step-14 until user explicitly selects 'C' from the A/P/C menu and content is saved!

src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13b-requirements-validation.md

@@ -0,0 +1,176 @@
+# Step 13b: Requirements Validation & Handoff Checklist
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 📖 CRITICAL: ALWAYS read the complete step file before taking any action
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- 🎯 This step validates UX design completeness against PRD requirements
+- 📋 YOU ARE A VALIDATION FACILITATOR for this step
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Load PRD and validate requirements coverage
+- 🎯 Load Architecture document and check constraint alignment
+- ⚠️ Present findings with A/P/C menu
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update output file frontmatter, adding this step to stepsCompleted
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## CONTEXT BOUNDARIES:
+
+- Complete UX design specification from all previous steps is available
+- PRD (if loaded at init) contains FRs/NFRs that UX must address
+- Architecture (if loaded at init) contains technical constraints
+- Focus on validating coverage and creating handoff artifacts
+
+## YOUR TASK:
+
+Validate that the UX design addresses PRD requirements, respects architecture constraints, and prepare handoff artifacts for downstream workflows (Architecture, Epics & Stories).
+
+## VALIDATION & HANDOFF SEQUENCE:
+
+### 1. Requirements Coverage Validation
+
+If PRD was loaded during initialization:
+
+**Extract PRD Functional Requirements:**
+- Load the PRD and find all FRs
+- For each FR, determine if the UX design addresses it
+
+**Create Coverage Matrix:**
+- Map each FR to UX design elements (user journeys, components, patterns)
+- Identify FRs NOT addressed by UX design
+- For unaddressed FRs, determine if they are:
+  - Non-UI FRs (backend-only, no UX needed) → Mark as N/A
+  - Missing from UX design → Flag as GAP
+
+**Present to user:**
+"I've validated your UX design against the PRD requirements:
+
+**FR Coverage:**
+
+| FR | Description | UX Element | Status |
+|----|-------------|-----------|--------|
+| FR1 | [desc] | [journey/component/pattern] | ✅ Covered |
+| FR5 | [desc] | - | ⚠️ Gap (UI feature) |
+| FR8 | [desc] | N/A | ➖ Backend only |
+
+**Coverage: [X]% of UI-relevant FRs addressed**
+**Gaps found: [count]**"
+
+If PRD was NOT loaded:
+- Note that requirements validation could not be performed
+- Recommend running this check later when PRD is available
+
+### 2. Architecture Constraint Alignment
+
+If Architecture document was loaded:
+
+**Check for conflicts:**
+- API constraints vs. UX interaction patterns (e.g., real-time updates vs. REST-only API)
+- Platform constraints vs. responsive strategy
+- Performance budgets vs. animation/interaction complexity
+- Data model constraints vs. information architecture
+
+**Present any conflicts found:**
+- Conflict description
+- UX design assumption
+- Architecture constraint
+- Suggested resolution
+
+If Architecture was NOT loaded:
+- Note that constraint validation could not be performed
+
+### 3. Downstream Handoff Checklist
+
+Create handoff information for downstream workflows:
+
+**For Architecture Workflow (Winston):**
+- [ ] UX interaction patterns that require specific API design
+- [ ] Real-time requirements identified in UX (WebSocket, SSE, polling)
+- [ ] Data requirements from form designs and user flows
+- [ ] Performance requirements from animation/interaction specs
+
+**For Epics & Stories Workflow (John):**
+- [ ] User journey → FR mapping (which journeys implement which FRs)
+- [ ] Component complexity estimates (simple, moderate, complex)
+- [ ] Design dependencies between components
+- [ ] Phasing recommendations (what can be MVP vs. later)
+
+**Design Decision Rationale:**
+- Key design decisions and WHY they were made
+- Alternatives considered and rejected (with reasons)
+- Assumptions made during design
+
+### 4. Generate Validation & Handoff Content
+
+Append to the document:
+
+```markdown
+## Requirements Validation
+
+### FR Coverage Matrix
+
+[Table mapping FRs to UX elements]
+
+### Architecture Constraint Alignment
+
+[Any conflicts found and resolutions, or "No architecture document loaded"]
+
+## Downstream Handoff
+
+### Architecture Handoff
+
+[UX constraints and requirements for architecture decisions]
+
+### Epics & Stories Handoff
+
+[User journey → FR mapping, complexity estimates, phasing recommendations]
+
+### Design Decision Rationale
+
+[Key decisions with reasoning for downstream teams]
+```
+
+### 5. Present MENU OPTIONS
+
+Present the validation findings and handoff checklist, then display menu:
+- Show coverage matrix highlights
+- Show any architecture conflicts
+- Show handoff readiness
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Complete Workflow (Step 14)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow Advanced Elicitation, process, ask acceptance, update or keep, redisplay
+- IF P: Read fully and follow Party Mode, process, ask acceptance, update or keep, redisplay
+- IF C: Append to output document, update frontmatter, then read fully and follow: `./step-14-complete.md`
+- IF Any other: help user respond, then redisplay menu
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', append the content directly to the document.
+
+## SUCCESS METRICS:
+
+✅ PRD FR coverage validated (if PRD available)
+✅ Architecture constraints checked (if architecture available)
+✅ FR → UX element mapping created
+✅ Gaps identified with clear categorization
+✅ Handoff checklist prepared for Architecture and Epics workflows
+✅ Design decision rationale documented
+✅ A/P/C menu presented and handled correctly
+
+## FAILURE MODES:
+
+❌ Not loading PRD for validation when it was discovered at init
+❌ Claiming full coverage without systematic check
+❌ Not creating handoff artifacts for downstream workflows
+❌ Not documenting design decision rationale
+❌ Marking non-UI FRs as gaps (they should be N/A)
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load `./step-14-complete.md` to complete the workflow.
+
+Remember: Do NOT proceed to step-14 until user explicitly selects 'C'!

src/bmm/workflows/qa/automate/checklist.md

@@ -8,6 +8,12 @@
 - [ ] Tests cover happy path
 - [ ] Tests cover 1-2 critical error cases
 
+## Requirements Traceability (All Tracks)
+
+- [ ] Each acceptance criterion has at least one test
+- [ ] Each FR has at least one test scenario defined
+- [ ] Test descriptions reference the FR or acceptance criterion they verify
+
 ## Test Quality
 
 - [ ] All generated tests run successfully

src/bmm/workflows/shared/templates/requirement-quality-checklist.md

@@ -0,0 +1,122 @@
+# Per-Requirement Quality Checklist (ISO 29148)
+
+Apply this checklist to EVERY individual requirement in StRS, SyRS, and PRD/SRS documents. Each requirement must satisfy all 9 quality criteria.
+
+## The 9 Quality Criteria
+
+### 1. Necessary
+
+- [ ] The requirement traces to a real stakeholder need or business objective
+- [ ] Removing this requirement would leave a stakeholder need unmet
+- [ ] The requirement is not gold-plating (adding unnecessary complexity)
+
+**Test:** "If we remove this requirement, would a stakeholder's need go unmet?"
+
+### 2. Implementation-Free
+
+- [ ] The requirement states WHAT is needed, not HOW to build it
+- [ ] No technology choices are embedded (unless it IS a design constraint)
+- [ ] No UI/UX specifics are included (unless it IS an interface requirement)
+- [ ] The requirement could be implemented in multiple different ways
+
+**Test:** "Could an architect choose from 3+ different implementation approaches?"
+
+### 3. Unambiguous
+
+- [ ] The requirement has only ONE possible interpretation
+- [ ] No vague adjectives (good, fast, easy, user-friendly, intuitive, robust)
+- [ ] Measurable criteria are used where applicable
+- [ ] Terms are defined in the glossary or are industry-standard
+
+**Test:** "Would 5 different engineers interpret this the same way?"
+
+### 4. Consistent
+
+- [ ] The requirement does NOT contradict any other requirement
+- [ ] Terminology is consistent with the rest of the document
+- [ ] Scope aligns with the product vision and boundaries
+- [ ] No conflicting quality attribute targets (e.g., maximum security AND minimal latency)
+
+**Test:** "Does this requirement peacefully coexist with all other requirements?"
+
+### 5. Complete
+
+- [ ] The requirement contains enough detail to design and test against
+- [ ] All conditions and constraints are specified
+- [ ] Edge cases and boundary conditions are addressed (or explicitly deferred)
+- [ ] No TBD, TBC, or placeholder values remain
+
+**Test:** "Could a developer implement this without asking clarifying questions?"
+
+### 6. Singular
+
+- [ ] The requirement expresses exactly ONE capability or constraint
+- [ ] No compound requirements joined by "and" or "or" (split if needed)
+- [ ] The requirement can be independently verified
+- [ ] The requirement can be independently prioritized
+
+**Test:** "Can I assign a single pass/fail verdict to this requirement?"
+
+### 7. Feasible
+
+- [ ] The requirement is technically achievable with known technology
+- [ ] The requirement is achievable within the project's constraints (budget, timeline, team)
+- [ ] No physical impossibilities or contradictions with laws of physics/math
+- [ ] Required third-party capabilities or services are available
+
+**Test:** "Can the team actually build this within the project constraints?"
+
+### 8. Traceable
+
+- [ ] The requirement has a unique identifier (ID)
+- [ ] The requirement's source is documented (stakeholder, regulation, business objective)
+- [ ] The requirement can be linked to downstream artifacts (design, code, tests)
+- [ ] The requirement can be linked to upstream sources (StRS, business needs)
+
+**Test:** "Can I follow this requirement from origin to implementation to test?"
+
+### 9. Verifiable
+
+- [ ] There exists a method to prove the requirement is satisfied
+- [ ] The verification method is identified (Test, Analysis, Demonstration, Inspection)
+- [ ] Acceptance criteria are clear and objective
+- [ ] The verification can be performed within project constraints
+
+**Test:** "Can I write a test or create a verification procedure for this?"
+
+---
+
+## Quick Reference Card
+
+| # | Criterion | Key Question | Red Flags |
+|---|-----------|-------------|-----------|
+| 1 | Necessary | Would removing it leave a need unmet? | Gold-plating, nice-to-have disguised as must-have |
+| 2 | Implementation-Free | Can it be built 3+ ways? | Technology names, UI specifics, algorithm choices |
+| 3 | Unambiguous | Would 5 engineers agree? | "Good", "fast", "easy", "user-friendly", "robust" |
+| 4 | Consistent | Does it conflict with others? | Contradicting metrics, overlapping scope |
+| 5 | Complete | Can dev build without questions? | TBD, TBC, "details to follow", missing conditions |
+| 6 | Singular | Can I give one pass/fail? | "and", "or" joining two capabilities |
+| 7 | Feasible | Can the team actually build it? | Unrealistic targets, unavailable technology |
+| 8 | Traceable | Can I follow origin → test? | Missing ID, no source reference |
+| 9 | Verifiable | Can I test/prove it? | Subjective criteria, unmeasurable quality |
+
+## Usage
+
+**When to Apply:**
+- During PRD/SRS creation (Step 9: FR synthesis, Step 10: NFR synthesis)
+- During PRD validation (validation workflow)
+- During StRS and SyRS review steps
+- During change management (new or modified requirements)
+
+**How to Apply:**
+1. Select a requirement
+2. Walk through all 9 criteria
+3. Mark any failures
+4. Fix failures before proceeding or flag for review
+5. A requirement that fails ANY criterion needs attention
+
+**Scoring:**
+- 9/9: Requirement is high quality
+- 7-8/9: Minor issues, address if time permits
+- 5-6/9: Significant issues, must address before approval
+- <5/9: Requirement needs rewrite

tools/cli/external-official-modules.yaml

@@ -32,6 +32,16 @@ modules:
     type: bmad-org
     npmPackage: bmad-game-dev-studio
 
+  bmad-method-audit-standards-enterprise:
+    url: https://github.com/bmad-code-org/bmad-method-audit-standards-enterprise
+    module-definition: src/module.yaml
+    code: audit
+    name: "Audit Standards Enterprise"
+    description: "Standards Auditor for compliance, security auditing, traceability, and multi-standard governance"
+    defaultSelected: false
+    type: bmad-org
+    npmPackage: bmad-method-audit-standards-enterprise
+
   bmad-method-test-architecture-enterprise:
     url: https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise
     module-definition: src/module.yaml