feat(prd): add ISO 29148 Clause 9 sections to PRD workflow

Update PRD template and workflow for ISO 29148 SRS compliance:
- Add track and version fields to PRD template frontmatter
- Update step-09 (FR) with Enterprise format including requirement
  attributes (priority, source, rationale, verification, risk)
- Update step-10 (NFR) with Enterprise format and attributes
- Add step-10b: External Interface Requirements (user, hardware,
  software, communication) per ISO 29148 Clause 9.3.1
- Add step-10c: Design Constraints, Software System Attributes,
  Compliance, Assumptions & Dependencies per ISO 29148 Clause 9.3.6-9.3.8
- Add step-10d: Verification Plan per ISO 29148 Clause 9.4
- Update step-11 (polish) to preserve new sections and add glossary check

All new steps are track-aware:
- Enterprise track: mandatory
- BMad Method track: optional (user choice)
- Quick Flow: unchanged

Part of ISO 29148 compliance initiative (Wave 1).

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

src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-09-functional.md

@@ -103,12 +103,25 @@ Group FRs by logical capability areas (NOT by technology or layer):
 
 Create complete functional requirements using this format:
 
-**Format:**
+**Standard Format (Quick Flow / BMad Method tracks):**
 
 - FR#: [Actor] can [capability] [context/constraint if needed]
 - Number sequentially (FR1, FR2, FR3...)
 - Aim for 20-50 FRs for typical projects
 
+**Enterprise Format (ISO 29148 compliant - when Enterprise track is configured):**
+
+For Enterprise track, each FR should include additional attributes:
+
+- **FR-[Area]-###**: [Actor] can [capability] [context/constraint if needed]
+  - **Priority:** Must / Should / Could / Won't (MoSCoW)
+  - **Source:** [StRS reference or stakeholder]
+  - **Rationale:** [Why this requirement exists]
+  - **Verification:** Inspection | Analysis | Demonstration | Test
+  - **Risk:** High | Medium | Low
+
+Note: If not on Enterprise track, use the standard format above. The Enterprise attributes are optional for BMad Method track.
+
 **Altitude Check:**
 Each FR should answer "WHAT capability exists?" NOT "HOW it's implemented?"
 
@@ -150,6 +163,8 @@ Prepare the content to append to the document:
 
 When saving to document, append these Level 2 and Level 3 sections:
 
+**Standard Format:**
+
 ```markdown
 ## Functional Requirements
 
@@ -167,6 +182,23 @@ When saving to document, append these Level 2 and Level 3 sections:
 [Continue for all capability areas discovered in conversation]
 ```
 
+**Enterprise Format (when Enterprise track is active):**
+
+```markdown
+## Functional Requirements
+
+### [Capability Area Name]
+
+- **FR-[AREA]-001**: [Specific Actor] can [specific capability]
+  - Priority: Must | Should | Could | Won't
+  - Source: [StRS-XXX or stakeholder name]
+  - Rationale: [Why this requirement exists]
+  - Verification: Test | Demonstration | Analysis | Inspection
+  - Risk: High | Medium | Low
+
+[Continue for all capability areas with full attributes]
+```
+
 ### 7. Present MENU OPTIONS
 
 Present the functional requirements for review, then display menu:

src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-10-nonfunctional.md

@@ -3,7 +3,7 @@ name: 'step-10-nonfunctional'
 description: 'Define quality attributes that matter for this specific product'
 
 # File References
-nextStepFile: './step-11-polish.md'
+nextStepFile: './step-10b-interfaces.md'
 outputFile: '{planning_artifacts}/prd.md'
 
 # Task References
@@ -132,6 +132,8 @@ Prepare the content to append to the document:
 
 When saving to document, append these Level 2 and Level 3 sections (only include sections that are relevant):
 
+**Standard Format:**
+
 ```markdown
 ## Non-Functional Requirements
 
@@ -156,6 +158,24 @@ When saving to document, append these Level 2 and Level 3 sections (only include
 [Integration requirements based on conversation - only include if relevant]
 ```
 
+**Enterprise Format (when Enterprise track is active):**
+
+```markdown
+## Non-Functional Requirements
+
+### Performance
+
+- **NFR-PERF-001**: [Specific, measurable performance requirement]
+  - Priority: Must | Should | Could | Won't
+  - Source: [StRS-XXX or stakeholder name]
+  - Rationale: [Why this quality attribute matters]
+  - Verification: Test | Analysis | Demonstration | Inspection
+  - Risk: High | Medium | Low
+  - Metric: [Measurable target value]
+
+[Continue with full attributes for each NFR category]
+```
+
 ### 6. Present MENU OPTIONS
 
 Present the non-functional requirements for review, then display menu:
@@ -165,7 +185,7 @@ Present the non-functional requirements for review, then display menu:
 - Ask if they'd like to refine further, get other perspectives, or proceed
 - Present menu options naturally as part of conversation
 
-Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Polish Document (Step 11 of 12)"
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Interface Requirements (Step 10b)"
 
 #### Menu Handling Logic:
 - IF A: Read fully and follow: {advancedElicitationTask} with the current NFR content, process the enhanced quality attribute insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
@@ -237,6 +257,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 {nextStepFile} to finalize the PRD and complete the workflow.
+After user selects 'C' and content is saved to document, load {nextStepFile} to define interface requirements.
 
-Remember: Do NOT proceed to step-11 until user explicitly selects 'C' from the A/P/C menu and content is saved!
+Remember: Do NOT proceed to step-10b until user explicitly selects 'C' from the A/P/C menu and content is saved!

src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-10b-interfaces.md

@@ -0,0 +1,169 @@
+---
+name: 'step-10b-interfaces'
+description: 'Define external interface requirements (user, hardware, software, communication) - ISO 29148 Clause 9.3.1'
+
+# File References
+nextStepFile: './step-10c-constraints.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 10b: External Interface Requirements
+
+**Progress: Step 10b** - Next: Design Constraints
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: ALWAYS 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
+- 💬 FOCUS on external interfaces the system must support
+- 🎯 This step is REQUIRED for Enterprise track, OPTIONAL for BMad Method track
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## TRACK-AWARE EXECUTION:
+
+**Check the document frontmatter for `track` value:**
+- If `track: 'enterprise'` → This step is MANDATORY, explore all interface categories
+- If `track: 'bmad'` or not set → This step is OPTIONAL, ask user if they want to define interfaces
+- If user on non-Enterprise track declines → Skip to {nextStepFile} immediately
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating interface 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:
+
+- Functional and non-functional requirements from previous steps inform interface needs
+- Architecture document (if loaded) informs technical interfaces
+- Focus on EXTERNAL interfaces (what the system connects to), not internal design
+- ISO 29148 Clause 9 Section 3.1: External Interface Requirements
+
+## INTERFACE REQUIREMENTS SEQUENCE:
+
+### 1. Explain Interface Requirements Purpose
+
+**Purpose:**
+External interface requirements define how the system interacts with the outside world - users, hardware, other software systems, and communication networks. Clear interface definitions prevent integration failures and misunderstandings.
+
+**Interface Categories (ISO 29148):**
+- User Interfaces
+- Hardware Interfaces
+- Software Interfaces
+- Communication Interfaces
+
+### 2. User Interface Requirements
+
+Explore user-facing interface needs:
+
+**Key Questions:**
+- "What types of user interfaces are needed (web, mobile, CLI, API)?"
+- "Are there specific UI framework or design system requirements?"
+- "What screen sizes and devices must be supported?"
+- "Are there specific input/output formats users expect?"
+- "What accessibility interface requirements exist?"
+
+### 3. Hardware Interface Requirements
+
+Explore hardware interaction needs:
+
+**Key Questions:**
+- "Does the system interact with any hardware devices (sensors, printers, scanners)?"
+- "What server or hosting hardware requirements exist?"
+- "Are there specific hardware compatibility requirements?"
+- "Does the system need to support specific hardware protocols?"
+
+Note: For many software-only projects, this section may be minimal or N/A.
+
+### 4. Software Interface Requirements
+
+Explore software integration needs:
+
+**Key Questions:**
+- "What external APIs or services must the system integrate with?"
+- "What databases or data stores are required?"
+- "What operating system compatibility is needed?"
+- "Are there specific library, framework, or SDK dependencies?"
+- "What authentication/authorization systems must be integrated?"
+- "Are there message queue or event streaming requirements?"
+
+### 5. Communication Interface Requirements
+
+Explore network and communication needs:
+
+**Key Questions:**
+- "What network protocols are required (HTTP/HTTPS, WebSocket, gRPC)?"
+- "Are there specific bandwidth or latency requirements for communication?"
+- "What data exchange formats are required (JSON, XML, Protocol Buffers)?"
+- "Are there encryption or secure communication requirements?"
+- "Are there email, SMS, or push notification requirements?"
+
+### 6. Generate Interface Content
+
+Prepare the content to append to the document:
+
+#### Content Structure:
+
+```markdown
+## External Interface Requirements
+
+### User Interfaces
+
+[User interface requirements - platforms, frameworks, accessibility, responsive design]
+
+### Hardware Interfaces
+
+[Hardware interface requirements - devices, protocols, compatibility. "N/A" if software-only]
+
+### Software Interfaces
+
+[Software interface requirements - APIs, databases, OS, libraries, integrations]
+
+### Communication Interfaces
+
+[Communication interface requirements - protocols, data formats, encryption, notifications]
+```
+
+### 7. Present MENU OPTIONS
+
+Present the interface requirements for review, then display menu.
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Design Constraints (Step 10c)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow: {advancedElicitationTask}, process enhanced insights, ask user acceptance, update or keep, redisplay
+- IF P: Read fully and follow: {partyModeWorkflow}, process collaborative validation, ask user acceptance, update or keep, redisplay
+- 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
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', append the content directly to the document using the structure from step 6.
+
+## SUCCESS METRICS:
+
+✅ All four interface categories explored
+✅ Software interfaces clearly define external integration points
+✅ Communication protocols and data formats specified
+✅ Track-appropriate depth (Enterprise=comprehensive, BMad=optional)
+✅ ISO 29148 Clause 9 Section 3.1 requirements addressed
+
+## FAILURE MODES:
+
+❌ Skipping software interface definition for a system with integrations
+❌ Not identifying communication protocols
+❌ Confusing external interfaces with internal system design
+❌ Not respecting track configuration (forcing Enterprise on BMad track)
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load {nextStepFile} to define design constraints.

src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-10c-constraints.md

@@ -0,0 +1,172 @@
+---
+name: 'step-10c-constraints'
+description: 'Define design constraints, assumptions, and dependencies - ISO 29148 Clause 9.3.6 and Appendix A'
+
+# File References
+nextStepFile: './step-10d-verification.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 10c: Design Constraints & Assumptions
+
+**Progress: Step 10c** - Next: Verification Plan
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: ALWAYS 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
+- 💬 FOCUS on constraints that limit design choices and assumptions that must hold true
+- 🎯 This step is REQUIRED for Enterprise track, OPTIONAL for BMad Method track
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## TRACK-AWARE EXECUTION:
+
+**Check the document frontmatter for `track` value:**
+- If `track: 'enterprise'` → This step is MANDATORY
+- If `track: 'bmad'` or not set → This step is OPTIONAL, ask user if they want to define constraints
+- If user on non-Enterprise track declines → Skip to {nextStepFile} immediately
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating constraints 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:
+
+- All previous PRD content informs constraint discovery
+- StRS project constraints (if available) are the primary source
+- Focus on constraints that limit HOW the system can be designed
+- ISO 29148 Clause 9 Section 3.6: Design Constraints + Appendix A
+
+## CONSTRAINTS SEQUENCE:
+
+### 1. Explain Constraints and Assumptions Purpose
+
+**Purpose:**
+Design constraints limit the choices available to architects and developers. Assumptions are conditions believed to be true that, if invalidated, could impact the project. Both must be explicitly documented to prevent costly surprises.
+
+**Categories:**
+- Design Constraints (technology, standards, regulatory)
+- Software System Attributes (reliability, availability, security, maintainability, portability)
+- Compliance Requirements
+- Assumptions
+- Dependencies
+
+### 2. Design Constraints Discovery
+
+**Key Questions:**
+- "Are there mandated technology choices (languages, frameworks, platforms)?"
+- "Are there coding standards or development practices that must be followed?"
+- "Are there database or storage technology constraints?"
+- "Are there hosting or deployment constraints (on-premise, specific cloud provider)?"
+- "Are there regulatory constraints that affect design (data residency, encryption standards)?"
+- "Are there backward compatibility requirements?"
+
+### 3. Software System Attributes (ISO 29148 Clause 9.3.7)
+
+Explore quality attributes that constrain design:
+
+**Reliability:** Mean time between failures, error handling, recovery
+**Availability:** Uptime requirements, maintenance windows
+**Security:** Authentication, authorization, data protection, audit
+**Maintainability:** Code standards, documentation, modularity
+**Portability:** Platform independence, migration requirements
+
+### 4. Compliance Requirements (ISO 29148 Clause 9.3.8)
+
+**Key Questions:**
+- "What industry standards must be met?"
+- "What regulatory compliance is required?"
+- "Are there certification requirements?"
+- "What audit trail requirements exist?"
+
+### 5. Assumptions and Dependencies
+
+**Key Questions:**
+- "What conditions are we assuming to be true?"
+- "What external systems or services are we depending on?"
+- "What team skills or availability are we assuming?"
+- "What timeline assumptions are we making?"
+- "If any of these assumptions prove false, what is the impact?"
+
+### 6. Generate Constraints Content
+
+#### Content Structure:
+
+```markdown
+## Design Constraints
+
+### Technology Constraints
+
+[Mandated technology choices and standards]
+
+### Software System Attributes
+
+- **Reliability:** [Requirements and targets]
+- **Availability:** [Uptime targets and maintenance windows]
+- **Security:** [Authentication, authorization, data protection requirements]
+- **Maintainability:** [Code standards, modularity, documentation requirements]
+- **Portability:** [Platform independence, migration requirements]
+
+### Compliance Requirements
+
+[Industry standards, regulatory compliance, certifications required]
+
+## Assumptions and Dependencies
+
+### Assumptions
+
+| ID | Assumption | Impact if False | Probability |
+|----|-----------|----------------|-------------|
+| A-001 | [Assumption] | [Impact] | [High/Medium/Low] |
+
+### Dependencies
+
+| ID | Dependency | Owner | Status | Risk if Unavailable |
+|----|-----------|-------|--------|-------------------|
+| D-001 | [Dependency] | [Who controls it] | [Available/Pending/Unknown] | [Impact] |
+```
+
+### 7. Present MENU OPTIONS
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Verification Plan (Step 10d)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow: {advancedElicitationTask}, process, ask acceptance, update or keep, redisplay
+- IF P: Read fully and follow: {partyModeWorkflow}, process, ask acceptance, update or keep, redisplay
+- IF C: Append to {outputFile}, update frontmatter, then read fully and follow: {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', append the content directly to the document using the structure from step 6.
+
+## SUCCESS METRICS:
+
+✅ Technology constraints explicitly documented
+✅ Software system attributes (reliability, availability, security, maintainability, portability) addressed
+✅ Compliance requirements identified
+✅ Assumptions documented with impact analysis
+✅ Dependencies documented with ownership and risk
+✅ ISO 29148 Clause 9 Sections 3.6, 3.7, 3.8 and Appendix A addressed
+
+## FAILURE MODES:
+
+❌ Missing technology constraints for system with mandated technology
+❌ Not documenting assumptions (leads to undiscovered risks)
+❌ Confusing constraints with requirements
+❌ Not identifying critical dependencies
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load {nextStepFile} to define the verification plan.

src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-10d-verification.md

@@ -0,0 +1,165 @@
+---
+name: 'step-10d-verification'
+description: 'Define verification approach for each requirement category - ISO 29148 Clause 9.4'
+
+# File References
+nextStepFile: './step-11-polish.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 10d: Verification Plan
+
+**Progress: Step 10d** - Next: Document Polish
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: ALWAYS 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
+- 💬 FOCUS on HOW each requirement will be verified
+- 🎯 This step is REQUIRED for Enterprise track, OPTIONAL for BMad Method track
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## TRACK-AWARE EXECUTION:
+
+**Check the document frontmatter for `track` value:**
+- If `track: 'enterprise'` → This step is MANDATORY
+- If `track: 'bmad'` or not set → This step is OPTIONAL, ask user if they want a verification plan
+- If user on non-Enterprise track declines → Skip to {nextStepFile} immediately
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating verification 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:
+
+- All FRs, NFRs, interface requirements, and constraints from previous steps
+- Focus on defining HOW requirements will be proven satisfied
+- ISO 29148 Clause 9 Section 4: Verification
+- This feeds directly into test strategy (TEA module for Enterprise track)
+
+## VERIFICATION PLAN SEQUENCE:
+
+### 1. Explain Verification Purpose
+
+**Purpose:**
+ISO 29148 requires that every requirement has a defined verification method. This ensures requirements are not only stated but can be proven satisfied. The four standard verification methods are:
+
+- **Inspection:** Visual examination of documents, code, or artifacts
+- **Analysis:** Mathematical or logical reasoning, modeling, or simulation
+- **Demonstration:** Operation of the system under specific conditions to show capability
+- **Test:** Execution of the system with test inputs and comparison against expected outputs
+
+### 2. Review All Requirements
+
+Load and review all requirements from the current PRD:
+- Functional Requirements (FRs)
+- Non-Functional Requirements (NFRs)
+- Interface Requirements (if defined)
+- Design Constraints (if defined)
+
+### 3. Assign Verification Methods
+
+For each requirement category, determine the appropriate verification method:
+
+**Guidelines:**
+- **FRs** → Typically verified by **Test** (automated or manual) or **Demonstration**
+- **NFR Performance** → Typically verified by **Test** (load testing, benchmarks) or **Analysis**
+- **NFR Security** → Typically verified by **Test** (penetration testing) and **Inspection** (code review)
+- **NFR Accessibility** → Typically verified by **Test** (automated) and **Inspection** (manual audit)
+- **Interface Requirements** → Typically verified by **Test** (integration testing) or **Demonstration**
+- **Constraints** → Typically verified by **Inspection** (architecture review) or **Analysis**
+- **Compliance** → Typically verified by **Inspection** (audit) or **Analysis** (gap analysis)
+
+### 4. Create Verification Summary
+
+**Key Questions:**
+- "For each capability area, what is the primary way you'd verify it works?"
+- "Are there requirements that can only be verified through analysis rather than testing?"
+- "What verification activities require specialized tools or expertise?"
+- "Are there requirements that need third-party verification?"
+
+### 5. Generate Verification Content
+
+#### Content Structure:
+
+```markdown
+## Verification Approaches
+
+### Verification Method Summary
+
+| Requirement Category | Primary Method | Secondary Method | Notes |
+|---------------------|---------------|-----------------|-------|
+| Functional Requirements | Test | Demonstration | Automated test suite |
+| Performance NFRs | Test | Analysis | Load testing required |
+| Security NFRs | Test + Inspection | Analysis | Penetration testing + code review |
+| Accessibility NFRs | Test + Inspection | Demonstration | WCAG automated + manual audit |
+| Interface Requirements | Test | Demonstration | Integration testing |
+| Design Constraints | Inspection | Analysis | Architecture review |
+| Compliance | Inspection | Analysis | Audit and gap analysis |
+
+### Verification Details
+
+#### Functional Requirements Verification
+
+[How FRs will be verified - test approach, acceptance criteria validation, demonstration scenarios]
+
+#### Non-Functional Requirements Verification
+
+[How NFRs will be verified - performance benchmarks, security scans, accessibility audits]
+
+#### Interface Requirements Verification
+
+[How interfaces will be verified - integration tests, API contract testing, protocol compliance]
+
+### Verification Dependencies
+
+[Tools, environments, expertise, or third-party services needed for verification]
+
+### TEA Module Integration (Enterprise Track)
+
+[Note: For Enterprise track projects, the TEA (Test Architecture Enterprise) module provides comprehensive test strategy, risk-based prioritization (P0-P3), and test-requirement traceability. This verification plan feeds into TEA's TD (Test Design) workflow.]
+```
+
+### 6. Present MENU OPTIONS
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Document Polish (Step 11)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow: {advancedElicitationTask}, process, ask acceptance, update or keep, redisplay
+- IF P: Read fully and follow: {partyModeWorkflow}, process, ask acceptance, update or keep, redisplay
+- IF C: Append to {outputFile}, update frontmatter, then read fully and follow: {nextStepFile}
+- IF Any other: help user respond, then redisplay menu
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', append the content directly to the document using the structure from step 5.
+
+## SUCCESS METRICS:
+
+✅ Every requirement category has an assigned verification method
+✅ Verification methods are appropriate (Test, Analysis, Demonstration, Inspection)
+✅ Verification dependencies identified (tools, environments, expertise)
+✅ TEA module integration noted for Enterprise track
+✅ ISO 29148 Clause 9 Section 4 requirements addressed
+
+## FAILURE MODES:
+
+❌ Requirements without any verification method
+❌ Using only "Test" when some requirements need Analysis or Inspection
+❌ Not identifying verification dependencies
+❌ Generating verification plan without reviewing actual requirements
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load {nextStepFile} to polish the document.

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

@@ -127,6 +127,11 @@ Make targeted improvements:
 - Check that headers follow consistent patterns
 - Verify headers support document navigation
 
+**Glossary Check (Enterprise track or if technical terms present):**
+- Ensure a "Definitions and Acronyms" section exists if the document uses domain-specific terminology
+- Consolidate all technical terms, acronyms, and abbreviations
+- This is MANDATORY for Enterprise track, recommended for all tracks
+
 ### 4. Preserve Critical Information
 
 **While optimizing, ensure NOTHING essential is lost:**
@@ -140,6 +145,10 @@ Make targeted improvements:
 - Product differentiator and vision
 - Domain-specific requirements
 - Innovation analysis (if present)
+- External interface requirements (if present)
+- Design constraints and assumptions (if present)
+- Verification approaches (if present)
+- All requirement IDs and attributes (Enterprise track)
 
 **Can Consolidate:**
 - Repeated explanations of the same concept

src/bmm/workflows/2-plan-workflows/create-prd/templates/prd-template.md

@@ -2,9 +2,13 @@
 stepsCompleted: []
 inputDocuments: []
 workflowType: 'prd'
+track: '{{track}}'
+version: '1.0'
+status: 'draft'
 ---
 
 # Product Requirements Document - {{project_name}}
 
 **Author:** {{user_name}}
 **Date:** {{date}}
+**ISO 29148 Reference:** Clause 9 - Software Requirements Specification (Enterprise Track)