Merge 8bb2615561 into 1198c8b9b7

Add bmad-method-audit-standards-enterprise to external-official-modules.yaml
so it can be discovered and installed via the BMM CLI installer.

Module code: audit | defaultSelected: false

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

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