Merge 3aebb87ab8 into 382ab8ed45

.claude/skills/bmad-os-diataxis-style-fix/SKILL.md

@@ -1,7 +0,0 @@
----
-name: bmad-os-diataxis-style-fix
-description: Fixes documentation to comply with Diataxis framework and BMad Method style guide rules
-disable-model-invocation: true
----
-
-Read `prompts/instructions.md` and execute.

.claude/skills/bmad-os-diataxis-style-fix/prompts/instructions.md

@@ -1,229 +0,0 @@
-# Diataxis Style Fixer
-
-Automatically fixes documentation to comply with the Diataxis framework and BMad Method style guide.
-
-## CRITICAL RULES
-
-- **NEVER commit or push changes** — let the user review first
-- **NEVER make destructive edits** — preserve all content, only fix formatting
-- **Use Edit tool** — make targeted fixes, not full file rewrites
-- **Show summary** — after fixing, list all changes made
-
-## Input
-
-Documentation file path or directory to fix. Defaults to `docs/` if not specified.
-
-## Step 1: Understand Diataxis Framework
-
-**Diataxis** is a documentation framework that categorizes content into four types based on two axes:
-
-|                | **Learning** (oriented toward future)                                         | **Doing** (oriented toward present)                                          |
-| -------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
-| **Practical**  | **Tutorials** — lessons that guide learners through achieving a specific goal | **How-to guides** — step-by-step instructions for solving a specific problem |
-| **Conceptual** | **Explanation** — content that clarifies and describes underlying concepts    | **Reference** — technical descriptions, organized for lookup                 |
-
-**Key principles:**
-- Each document type serves a distinct user need
-- Don't mix types — a tutorial shouldn't explain concepts deeply
-- Focus on the user's goal, not exhaustive coverage
-- Structure follows purpose (tutorials are linear, reference is scannable)
-
-## Step 2: Read the Style Guide
-
-Read the project's style guide at `docs/_STYLE_GUIDE.md` to understand all project-specific conventions.
-
-## Step 3: Detect Document Type
-
-Based on file location, determine the document type:
-
-| Location             | Diataxis Type        |
-| -------------------- | -------------------- |
-| `/docs/tutorials/`   | Tutorial             |
-| `/docs/how-to/`      | How-to guide         |
-| `/docs/explanation/` | Explanation          |
-| `/docs/reference/`   | Reference            |
-| `/docs/glossary/`    | Reference (glossary) |
-
-## Step 4: Find and Fix Issues
-
-For each markdown file, scan for issues and fix them:
-
-### Universal Fixes (All Doc Types)
-
-**Horizontal Rules (`---`)**
-- Remove any `---` outside of YAML frontmatter
-- Replace with `##` section headers or admonitions as appropriate
-
-**`####` Headers**
-- Replace with bold text: `#### Header` → `**Header**`
-- Or convert to admonition if it's a warning/notice
-
-**"Related" or "Next:" Sections**
-- Remove entire section including links
-- The sidebar handles navigation
-
-**Deeply Nested Lists**
-- Break into sections with `##` headers
-- Flatten to max 3 levels
-
-**Code Blocks for Dialogue/Examples**
-- Convert to admonitions:
-  ```
-  :::note[Example]
-  [content]
-  :::
-  ```
-
-**Bold Paragraph Callouts**
-- Convert to admonitions with appropriate type
-
-**Too Many Admonitions**
-- Limit to 1-2 per section (tutorials allow 3-4 per major section)
-- Consolidate related admonitions
-- Remove less critical ones if over limit
-
-**Table Cells / List Items > 2 Sentences**
-- Break into multiple rows/cells
-- Or shorten to 1-2 sentences
-
-**Header Budget Exceeded**
-- Merge related sections
-- Convert some `##` to `###` subsections
-- Goal: 8-12 `##` per doc; 2-3 `###` per section
-
-### Type-Specific Fixes
-
-**Tutorials** (`/docs/tutorials/`)
-- Ensure hook describes outcome in 1-2 sentences
-- Add "What You'll Learn" bullet section if missing
-- Add `:::note[Prerequisites]` if missing
-- Add `:::tip[Quick Path]` TL;DR at top if missing
-- Use tables for phases, commands, agents
-- Add "What You've Accomplished" section if missing
-- Add Quick Reference table if missing
-- Add Common Questions section if missing
-- Add Getting Help section if missing
-- Add `:::tip[Key Takeaways]` at end if missing
-
-**How-To** (`/docs/how-to/`)
-- Ensure hook starts with "Use the `X` workflow to..."
-- Add "When to Use This" with 3-5 bullets if missing
-- Add `:::note[Prerequisites]` if missing
-- Ensure steps are numbered `###` with action verbs
-- Add "What You Get" describing outputs if missing
-
-**Explanation** (`/docs/explanation/`)
-- Ensure hook states what document explains
-- Organize content into scannable `##` sections
-- Add comparison tables for 3+ options
-- Link to how-to guides for procedural questions
-- Limit to 2-3 admonitions per document
-
-**Reference** (`/docs/reference/`)
-- Ensure hook states what document references
-- Ensure structure matches reference type
-- Use consistent item structure throughout
-- Use tables for structured/comparative data
-- Link to explanation docs for conceptual depth
-- Limit to 1-2 admonitions per document
-
-**Glossary** (`/docs/glossary/` or glossary files)
-- Ensure categories as `##` headers
-- Ensure terms in tables (not individual headers)
-- Definitions 1-2 sentences max
-- Bold term names in cells
-
-## Step 5: Apply Fixes
-
-For each file with issues:
-1. Read the file
-2. Use Edit tool for each fix
-3. Track what was changed
-
-## Step 6: Summary
-
-After processing all files, output a summary:
-
-```markdown
-# Style Fixes Applied
-
-**Files processed:** N
-**Files modified:** N
-
-## Changes Made
-
-### `path/to/file.md`
-- Removed horizontal rule at line 45
-- Converted `####` headers to bold text
-- Added `:::tip[Quick Path]` admonition
-- Consolidated 3 admonitions into 2
-
-### `path/to/other.md`
-- Removed "Related:" section
-- Fixed table cell length (broke into 2 rows)
-
-## Review Required
-
-Please review the changes. When satisfied, commit and push as needed.
-```
-
-## Common Patterns
-
-**Converting `####` to bold:**
-```markdown
-#### Important Note
-Some text here.
-```
-→
-```markdown
-**Important Note**
-
-Some text here.
-```
-
-**Removing horizontal rule:**
-```markdown
-Some content above.
-
----
-
-Some content below.
-```
-→
-```markdown
-Some content above.
-
-## [Descriptive Section Header]
-
-Some content below.
-```
-
-**Converting code block to admonition:**
-```markdown
-```
-User: What should I do?
-
-Agent: Run the workflow.
-```
-```
-→
-```markdown
-:::note[Example]
-
-**User:** What should I do?
-
-**Agent:** Run the workflow.
-
-:::
-```
-
-**Converting bold paragraph to admonition:**
-```markdown
-**IMPORTANT:** This is critical that you read this before proceeding.
-```
-→
-```markdown
-:::caution[Important]
-This is critical that you read this before proceeding.
-:::
-```

docs/_STYLE_GUIDE.md

@@ -75,12 +75,9 @@ Show in "What You've Accomplished" sections:
 ````md
 ```
 your-project/
-├── _bmad/                                   # BMad configuration
+├── _bmad/                         # BMad configuration
 ├── _bmad-output/
-│   ├── planning-artifacts/
+│   ├── PRD.md                     # Your requirements document
-│   │   └── PRD.md                           # Your requirements document
-│   ├── implementation-artifacts/
-│   └── project-context.md                   # Implementation rules (optional)
 └── ...
 ```
 ````

docs/explanation/project-context.md

@@ -1,157 +0,0 @@
----
-title: "Project Context"
-description: How project-context.md guides AI agents with your project's rules and preferences
-sidebar:
-  order: 7
----
-
-The `project-context.md` file is your project's implementation guide for AI agents. Similar to a "constitution" in other development systems, it captures the rules, patterns, and preferences that ensure consistent code generation across all workflows.
-
-## What It Does
-
-AI agents make implementation decisions constantly — which patterns to follow, how to structure code, what conventions to use. Without clear guidance, they may:
-- Follow generic best practices that don't match your codebase
-- Make inconsistent decisions across different stories
-- Miss project-specific requirements or constraints
-
-The `project-context.md` file solves this by documenting what agents need to know in a concise, LLM-optimized format.
-
-## How It Works
-
-Every implementation workflow automatically loads `project-context.md` if it exists. The architect workflow also loads it to respect your technical preferences when designing the architecture.
-
-**Loaded by these workflows:**
-- `create-architecture` — respects technical preferences during solutioning
-- `create-story` — informs story creation with project patterns
-- `dev-story` — guides implementation decisions
-- `code-review` — validates against project standards
-- `quick-dev` — applies patterns when implementing tech-specs
-- `sprint-planning`, `retrospective`, `correct-course` — provides project-wide context
-
-## When to Create It
-
-The `project-context.md` file is useful at any stage of a project:
-
-| Scenario | When to Create | Purpose |
-|----------|----------------|---------|
-| **New project, before architecture** | Manually, before `create-architecture` | Document your technical preferences so the architect respects them |
-| **New project, after architecture** | Via `generate-project-context` or manually | Capture architecture decisions for implementation agents |
-| **Existing project** | Via `generate-project-context` | Discover existing patterns so agents follow established conventions |
-| **Quick Flow project** | Before or during `quick-dev` | Ensure quick implementation respects your patterns |
-
-:::tip[Recommended]
-For new projects, create it manually before architecture if you have strong technical preferences. Otherwise, generate it after architecture to capture those decisions.
-:::
-
-## What Goes In It
-
-The file has two main sections:
-
-### Technology Stack & Versions
-
-Documents the frameworks, languages, and tools your project uses with specific versions:
-
-```markdown
-## Technology Stack & Versions
-
-- Node.js 20.x, TypeScript 5.3, React 18.2
-- State: Zustand (not Redux)
-- Testing: Vitest, Playwright, MSW
-- Styling: Tailwind CSS with custom design tokens
-```
-
-### Critical Implementation Rules
-
-Documents patterns and conventions that agents might otherwise miss:
-
-```markdown
-## Critical Implementation Rules
-
-**TypeScript Configuration:**
-- Strict mode enabled — no `any` types without explicit approval
-- Use `interface` for public APIs, `type` for unions/intersections
-
-**Code Organization:**
-- Components in `/src/components/` with co-located `.test.tsx`
-- Utilities in `/src/lib/` for reusable pure functions
-- API calls use the `apiClient` singleton — never fetch directly
-
-**Testing Patterns:**
-- Unit tests focus on business logic, not implementation details
-- Integration tests use MSW to mock API responses
-- E2E tests cover critical user journeys only
-
-**Framework-Specific:**
-- All async operations use the `handleError` wrapper for consistent error handling
-- Feature flags accessed via `featureFlag()` from `@/lib/flags`
-- New routes follow the file-based routing pattern in `/src/app/`
-```
-
-Focus on what's **unobvious** — things agents might not infer from reading code snippets. Don't document standard practices that apply universally.
-
-## Creating the File
-
-You have three options:
-
-### Manual Creation
-
-Create the file at `_bmad-output/project-context.md` and add your rules:
-
-```bash
-# In your project root
-mkdir -p _bmad-output
-touch _bmad-output/project-context.md
-```
-
-Edit it with your technology stack and implementation rules. The architect and implementation workflows will automatically find and load it.
-
-### Generate After Architecture
-
-Run the `generate-project-context` workflow after completing your architecture:
-
-```bash
-/bmad-bmm-generate-project-context
-```
-
-This scans your architecture document and project files to generate a context file capturing the decisions made.
-
-### Generate for Existing Projects
-
-For existing projects, run `generate-project-context` to discover existing patterns:
-
-```bash
-/bmad-bmm-generate-project-context
-```
-
-The workflow analyzes your codebase to identify conventions, then generates a context file you can review and refine.
-
-## Why It Matters
-
-Without `project-context.md`, agents make assumptions that may not match your project:
-
-| Without Context | With Context |
-|----------------|--------------|
-| Uses generic patterns | Follows your established conventions |
-| Inconsistent style across stories | Consistent implementation |
-| May miss project-specific constraints | Respects all technical requirements |
-| Each agent decides independently | All agents align with same rules |
-
-This is especially important for:
-- **Quick Flow** — skips PRD and architecture, so context file fills the gap
-- **Team projects** — ensures all agents follow the same standards
-- **Existing projects** — prevents breaking established patterns
-
-## Editing and Updating
-
-The `project-context.md` file is a living document. Update it when:
-
-- Architecture decisions change
-- New conventions are established
-- Patterns evolve during implementation
-- You identify gaps from agent behavior
-
-You can edit it manually at any time, or re-run `generate-project-context` to update it after significant changes.
-
-:::note[File Location]
-The default location is `_bmad-output/project-context.md`. Workflows search for it there, and also check `**/project-context.md` anywhere in your project.
-:::

docs/how-to/established-projects.md

@@ -5,7 +5,7 @@ sidebar:
   order: 6
 ---
 
-Use BMad Method effectively when working on existing projects and legacy codebases.
+Use BMad Method effectively when working on existing projects and legacy codebases, sometimes also referred to as brownfield projects.
 
 This guide covers the essential workflow for onboarding to existing projects with BMad Method.
 
@@ -23,30 +23,7 @@ If you have completed all PRD epics and stories through the BMad process, clean
 - `_bmad-output/planning-artifacts/`
 - `_bmad-output/implementation-artifacts/`
 
-## Step 2: Create Project Context
+## Step 2: Maintain Quality Project Documentation
-
-:::tip[Recommended for Existing Projects]
-Generate `project-context.md` to capture your existing codebase patterns and conventions. This ensures AI agents follow your established practices when implementing changes.
-:::
-
-Run the generate project context workflow:
-
-```bash
-/bmad-bmm-generate-project-context
-```
-
-This scans your codebase to identify:
-- Technology stack and versions
-- Code organization patterns
-- Naming conventions
-- Testing approaches
-- Framework-specific patterns
-
-You can review and refine the generated file, or create it manually at `_bmad-output/project-context.md` if you prefer.
-
-[Learn more about project context](../explanation/project-context.md)
-
-## Step 3: Maintain Quality Project Documentation
 
 Your `docs/` folder should contain succinct, well-organized documentation that accurately represents your project:
 

docs/how-to/project-context.md

@@ -1,136 +0,0 @@
----
-title: "Manage Project Context"
-description: Create and maintain project-context.md to guide AI agents
-sidebar:
-  order: 7
----
-
-Use the `project-context.md` file to ensure AI agents follow your project's technical preferences and implementation rules throughout all workflows.
-
-:::note[Prerequisites]
-- BMad Method installed
-- Understanding of your project's technology stack and conventions
-:::
-
-## When to Use This
-
-- You have strong technical preferences before starting architecture
-- You've completed architecture and want to capture decisions for implementation
-- You're working on an existing codebase with established patterns
-- You notice agents making inconsistent decisions across stories
-
-## Step 1: Choose Your Approach
-
-**Manual creation** — Best when you know exactly what rules you want to document
-
-**Generate after architecture** — Best for capturing decisions made during solutioning
-
-**Generate for existing projects** — Best for discovering patterns in existing codebases
-
-## Step 2: Create the File
-
-### Option A: Manual Creation
-
-Create the file at `_bmad-output/project-context.md`:
-
-```bash
-mkdir -p _bmad-output
-touch _bmad-output/project-context.md
-```
-
-Add your technology stack and implementation rules:
-
-```markdown
----
-project_name: 'MyProject'
-user_name: 'YourName'
-date: '2026-02-15'
-sections_completed: ['technology_stack', 'critical_rules']
----
-
-# Project Context for AI Agents
-
-## Technology Stack & Versions
-
-- Node.js 20.x, TypeScript 5.3, React 18.2
-- State: Zustand
-- Testing: Vitest, Playwright
-- Styling: Tailwind CSS
-
-## Critical Implementation Rules
-
-**TypeScript:**
-- Strict mode enabled, no `any` types
-- Use `interface` for public APIs, `type` for unions
-
-**Code Organization:**
-- Components in `/src/components/` with co-located tests
-- API calls use `apiClient` singleton — never fetch directly
-
-**Testing:**
-- Unit tests focus on business logic
-- Integration tests use MSW for API mocking
-```
-
-### Option B: Generate After Architecture
-
-Run the workflow in a fresh chat:
-
-```bash
-/bmad-bmm-generate-project-context
-```
-
-The workflow scans your architecture document and project files to generate a context file capturing the decisions made.
-
-### Option C: Generate for Existing Projects
-
-For existing projects, run:
-
-```bash
-/bmad-bmm-generate-project-context
-```
-
-The workflow analyzes your codebase to identify conventions, then generates a context file you can review and refine.
-
-## Step 3: Verify Content
-
-Review the generated file and ensure it captures:
-
-- Correct technology versions
-- Your actual conventions (not generic best practices)
-- Rules that prevent common mistakes
-- Framework-specific patterns
-
-Edit manually to add anything missing or remove inaccuracies.
-
-## What You Get
-
-A `project-context.md` file that:
-
-- Ensures all agents follow the same conventions
-- Prevents inconsistent decisions across stories
-- Captures architecture decisions for implementation
-- Serves as a reference for your project's patterns and rules
-
-## Tips
-
-:::tip[Focus on the Unobvious]
-Document patterns agents might miss such as "Use JSDoc style comments on every public class, function and variable", not universal practices like "use meaningful variable names" which LLMs know at this point.
-:::
-
-:::tip[Keep It Lean]
-This file is loaded by every implementation workflow. Long files waste context. Do not include content that only applies to narrow scope or specific stories or features.
-:::
-
-:::tip[Update as Needed]
-Edit manually when patterns change, or re-generate after significant architecture changes.
-:::
-
-:::tip[Works for All Project Types]
-Just as useful for Quick Flow as for full BMad Method projects.
-:::
-
-## Next Steps
-
-- [**Project Context Explanation**](../explanation/project-context.md) — Learn more about how it works
-- [**Workflow Map**](../reference/workflow-map.md) — See which workflows load project context

docs/how-to/shard-large-documents.md

@@ -23,11 +23,11 @@ Document sharding splits large markdown files into smaller, organized files base
 
 ```text
 Before Sharding:
-_bmad-output/planning-artifacts/
+docs/
 └── PRD.md (large 50k token file)
 
 After Sharding:
-_bmad-output/planning-artifacts/
+docs/
 └── prd/
     ├── index.md                    # Table of contents with descriptions
     ├── overview.md                 # Section 1

docs/reference/workflow-map.md

@@ -77,46 +77,14 @@ Skip phases 1-3 for small, well-understood work.
 
 Each document becomes context for the next phase. The PRD tells the architect what constraints matter. The architecture tells the dev agent which patterns to follow. Story files give focused, complete context for implementation. Without this structure, agents make inconsistent decisions.
 
-### Project Context
+For established projects, `document-project` creates or updates `project-context.md` - what exists in the codebase and the rules all implementation workflows must observe. Run it just before Phase 4, and again when something significant changes - structure, architecture, or those rules. You can also edit `project-context.md` by hand.
 
-:::tip[Recommended]
+All implementation workflows load `project-context.md` if it exists. Additional context per workflow:
-Create `project-context.md` to ensure AI agents follow your project's rules and preferences. This file works like a constitution for your project — it guides implementation decisions across all workflows.
-:::
 
-**When to create it:**
+| Workflow       | Also Loads                   |
-
+| -------------- | ---------------------------- |
-| Scenario | Approach |
-|----------|----------|
-| Before architecture (manual) | Document technical preferences you want the architect to respect |
-| After architecture | Generate it to capture decisions made during solutioning |
-| Existing projects | Run `generate-project-context` to discover established patterns |
-| Quick Flow | Create before `quick-dev` to ensure consistent implementation |
-
-**How to create it:**
-
-- **Manually** — Create `_bmad-output/project-context.md` with your technology stack and implementation rules
-- **Generate it** — Run `/bmad-bmm-generate-project-context` to auto-generate from your architecture or codebase
-
-**What workflows load it:**
-
-| Workflow | Purpose |
-|----------|---------|
-| `create-architecture` | Respects technical preferences when designing |
-| `create-story` | Informs story creation with project patterns |
-| `dev-story` | Guides implementation decisions |
-| `code-review` | Validates against project standards |
-| `quick-dev` | Applies patterns when implementing |
-
-[**Learn more about project-context.md**](../explanation/project-context.md)
-
-### Additional Context by Workflow
-
-Beyond `project-context.md`, each workflow loads specific documents:
-
-| Workflow | Also Loads |
-|----------|------------|
 | `create-story` | epics, PRD, architecture, UX |
-| `dev-story` | story file |
+| `dev-story`    | story file                   |
-| `code-review` | architecture, story file |
+| `code-review`  | architecture, story file     |
-| `quick-spec` | planning docs (if exist) |
+| `quick-spec`   | planning docs (if exist)     |
-| `quick-dev` | tech-spec |
+| `quick-dev`    | tech-spec                    |

docs/tutorials/getting-started.md

@@ -79,12 +79,6 @@ Always start a fresh chat for each workflow. This prevents context limitations f
 
 Work through phases 1-3. **Use fresh chats for each workflow.**
 
-:::tip[Project Context (Optional)]
-Before starting, consider creating `project-context.md` to document your technical preferences and implementation rules. This ensures all AI agents follow your conventions throughout the project.
-
-Create it manually at `_bmad-output/project-context.md` or generate it after architecture using `/bmad-bmm-generate-project-context`. [Learn more](../explanation/project-context.md).
-:::
-
 ### Phase 1: Analysis (Optional)
 
 All workflows in this phase are optional:
@@ -161,15 +155,12 @@ Your project now has:
 
 ```text
 your-project/
-├── _bmad/                                   # BMad configuration
+├── _bmad/                         # BMad configuration
 ├── _bmad-output/
-│   ├── planning-artifacts/
+│   ├── PRD.md                     # Your requirements document
-│   │   ├── PRD.md                           # Your requirements document
+│   ├── architecture.md            # Technical decisions
-│   │   ├── architecture.md                  # Technical decisions
+│   ├── epics/                     # Epic and story files
-│   │   └── epics/                           # Epic and story files
+│   └── sprint-status.yaml         # Sprint tracking
-│   ├── implementation-artifacts/
-│   │   └── sprint-status.yaml               # Sprint tracking
-│   └── project-context.md                   # Implementation rules (optional)
 └── ...
 ```
 
@@ -180,7 +171,6 @@ your-project/
 | `help`                           | `/bmad-help`                               | Any       | Get guidance on what to do next      |
 | `prd`                            | `/bmad-bmm-create-prd`                     | PM        | Create Product Requirements Document |
 | `create-architecture`            | `/bmad-bmm-create-architecture`            | Architect | Create architecture document         |
-| `generate-project-context`       | `/bmad-bmm-generate-project-context`       | Analyst   | Create project context file          |
 | `create-epics-and-stories`       | `/bmad-bmm-create-epics-and-stories`       | PM        | Break down PRD into epics            |
 | `check-implementation-readiness` | `/bmad-bmm-check-implementation-readiness` | Architect | Validate planning cohesion           |
 | `sprint-planning`                | `/bmad-bmm-sprint-planning`                | SM        | Initialize sprint tracking           |

src/bmm/agents/analyst.agent.yaml

@@ -38,6 +38,10 @@ agent:
       exec: "{project-root}/_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md"
       description: "[CB] Create Brief: A guided experience to nail down your product idea into an executive brief"
 
+    - trigger: CS or fuzzy match on create-strs
+      exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-strs/workflow.md"
+      description: "[CS] Create StRS: Create ISO 29148 compliant Stakeholder Requirements Specification (Enterprise track)"
+
     - trigger: DP or fuzzy match on document-project
       workflow: "{project-root}/_bmad/bmm/workflows/document-project/workflow.yaml"
       description: "[DP] Document Project: Analyze an existing project to produce useful documentation for both human and LLM"

src/bmm/agents/architect.agent.yaml

@@ -24,6 +24,10 @@ agent:
       exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md"
       description: "[CA] Create Architecture: Guided Workflow to document technical decisions to keep implementation on track"
 
+    - trigger: SY or fuzzy match on create-syrs
+      exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs/workflow.md"
+      description: "[SY] Create SyRS: Create ISO 29148 compliant System Requirements Specification (Enterprise track)"
+
     - trigger: IR or fuzzy match on implementation-readiness
       exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md"
       description: "[IR] Implementation Readiness: Ensure the PRD, UX, and Architecture and Epics and Stories List are all aligned"

src/bmm/agents/pm.agent.yaml

@@ -39,6 +39,18 @@ agent:
       exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md"
       description: "[IR] Implementation Readiness: Ensure the PRD, UX, and Architecture and Epics and Stories List are all aligned"
 
+    - trigger: RT or fuzzy match on traceability
+      exec: "{project-root}/_bmad/bmm/workflows/shared/rtm/workflow.md"
+      description: "[RT] Traceability Matrix: Generate or update the Requirements Traceability Matrix (Enterprise track)"
+
+    - trigger: RM or fuzzy match on manage-requirements
+      exec: "{project-root}/_bmad/bmm/workflows/shared/change-management/workflow.md"
+      description: "[RM] Requirements Management: Formal change control process for requirements (Enterprise track)"
+
+    - trigger: QG or fuzzy match on quality-gate
+      exec: "{project-root}/_bmad/bmm/workflows/shared/quality-gate/workflow.md"
+      description: "[QG] Quality Gate: Run phase-transition quality gate check (Enterprise track)"
+
     - trigger: CC or fuzzy match on correct-course
       workflow: "{project-root}/_bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml"
       description: "[CC] Course Correction: Use this so we can determine how to proceed if major need for change is discovered mid implementation"

src/bmm/workflows/1-analysis/create-product-brief/steps/step-06-complete.md

@@ -107,9 +107,22 @@ Provide guidance on logical next workflows:
 1. `create-ux-design` - UX research and design (can run parallel with PRD)
 2. `domain-research` - Deep market or domain research (if needed)
 
+**Enterprise Track: StRS Creation (ISO 29148)**
+
+If the project follows the **Enterprise** track, the Product Brief serves as the primary input for creating an ISO 29148 compliant Stakeholder Requirements Specification (StRS):
+
+1. `create-strs` - Create Stakeholder Requirements Specification
+   - Product Brief vision → StRS business purpose and objectives
+   - Product Brief target users → StRS stakeholder profiles and user requirements
+   - Product Brief features → StRS operational requirements and system concept
+   - Product Brief constraints → StRS project constraints
+
+The StRS extends the Product Brief with formal stakeholder analysis, operational scenarios, and project constraints required by ISO 29148 Clause 7. This is recommended before starting the PRD for Enterprise track projects.
+
 **Strategic Considerations:**
 
 - The PRD workflow builds directly on this brief for detailed planning
+- Enterprise track: Consider creating StRS before PRD for full traceability chain
 - Consider team capacity and immediate priorities
 - Use brief to validate concept before committing to detailed work
 - Brief can guide early technical feasibility discussions

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/steps-v/step-v-06-traceability-validation.md

@@ -3,7 +3,7 @@ name: 'step-v-06-traceability-validation'
 description: 'Traceability Validation - Validate the traceability chain from vision → success → journeys → FRs is intact'
 
 # File references (ONLY variables used in this step)
-nextStepFile: './step-v-07-implementation-leakage-validation.md'
+nextStepFile: './step-v-06b-per-requirement-quality.md'
 prdFile: '{prd_file_path}'
 validationReportPath: '{validation_report_path}'
 ---

src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-06b-per-requirement-quality.md

@@ -0,0 +1,143 @@
+---
+name: 'step-v-06b-per-requirement-quality'
+description: 'Per-Requirement Quality Validation - Validate each requirement against 9 ISO 29148 quality criteria'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-06c-requirement-attributes.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+requirementQualityChecklist: '{project-root}/_bmad/bmm/workflows/shared/templates/requirement-quality-checklist.md'
+---
+
+# Step 6b: Per-Requirement Quality Validation (Enterprise Track)
+
+## STEP GOAL:
+
+Validate each individual requirement against the 9 ISO 29148 quality criteria: necessary, implementation-free, unambiguous, consistent, complete, singular, feasible, traceable, verifiable.
+
+## 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 entire file is read
+- 📋 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 Validation Architect and Quality Assurance Specialist
+- ✅ This step runs autonomously - no user input needed
+- ✅ You bring ISO 29148 requirement quality expertise
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on per-requirement quality validation
+- 🎯 This step is MANDATORY for Enterprise track, OPTIONAL for BMad Method track
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+### Track-Aware Execution:
+
+**Check the PRD frontmatter for `track` value:**
+- If `track: 'enterprise'` → Run full per-requirement quality validation
+- If `track: 'bmad'` or not set → Run a lightweight sample check (spot-check 5 requirements)
+- Log which track mode was used in the report
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Load the requirement quality checklist
+- 🎯 Extract all FRs and NFRs from the PRD
+- 🎯 Validate a representative sample (or all for Enterprise) against 9 criteria
+- 💾 Append findings to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+- 🚫 FORBIDDEN to pause or request user input
+
+## CONTEXT BOUNDARIES:
+
+- PRD document from previous validation steps is available
+- Quality checklist provides the 9 criteria
+- Focus on individual requirement quality, not document-level quality
+
+## VALIDATION SEQUENCE:
+
+### 1. Load Quality Criteria
+
+Load the requirement quality checklist from: `{requirementQualityChecklist}`
+
+### 2. Extract Requirements
+
+Extract all FRs and NFRs from the PRD document:
+- Count total requirements
+- Group by category (FR capability areas, NFR categories)
+
+### 3. Validate Requirements
+
+**For Enterprise track:** Validate ALL requirements against 9 criteria
+**For BMad track:** Spot-check 5 representative requirements
+
+**For each requirement, check:**
+1. **Necessary:** Does it trace to a stakeholder need?
+2. **Implementation-Free:** Does it state WHAT, not HOW?
+3. **Unambiguous:** Is there only one interpretation?
+4. **Consistent:** Does it conflict with other requirements?
+5. **Complete:** Is there sufficient detail?
+6. **Singular:** Is it one requirement, not compound?
+7. **Feasible:** Is it achievable within constraints?
+8. **Traceable:** Does it have an ID and source?
+9. **Verifiable:** Can it be tested or inspected?
+
+### 4. Generate Findings
+
+Create a quality report:
+
+```markdown
+### Per-Requirement Quality Validation
+
+**Track Mode:** [Enterprise (full) / BMad (sample)]
+**Requirements Analyzed:** [count] of [total]
+
+**Quality Summary:**
+| Criterion | Pass | Fail | Pass Rate |
+|-----------|------|------|-----------|
+| Necessary | | | |
+| Implementation-Free | | | |
+| Unambiguous | | | |
+| Consistent | | | |
+| Complete | | | |
+| Singular | | | |
+| Feasible | | | |
+| Traceable | | | |
+| Verifiable | | | |
+
+**Issues Found:**
+[List specific requirements that fail criteria with details]
+
+**Severity:** [PASS / CONCERNS / FAIL]
+```
+
+### 5. Append to Report and Proceed
+
+Append findings to `{validationReportPath}`.
+
+Display: "**Per-Requirement Quality:** [PASS/CONCERNS/FAIL] - [X] requirements checked, [Y] issues found. Proceeding to requirement attributes check..."
+
+Read fully and follow: `{nextStepFile}`
+
+## SUCCESS METRICS:
+
+✅ Quality checklist loaded and applied
+✅ Requirements extracted and counted
+✅ Representative or full sample validated against 9 criteria
+✅ Quality summary table generated
+✅ Specific issues identified with requirement references
+✅ Findings appended to validation report
+✅ Auto-proceeded to next step
+
+## FAILURE MODES:
+
+❌ Not loading the quality checklist
+❌ Validating document-level quality instead of per-requirement
+❌ Not reporting specific failing requirements
+❌ Skipping criteria in the check

src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-06c-requirement-attributes.md

@@ -0,0 +1,106 @@
+---
+name: 'step-v-06c-requirement-attributes'
+description: 'Requirement Attributes Validation - Verify each requirement has required attributes (ID, priority, source, V&V method)'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-07-implementation-leakage-validation.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 6c: Requirement Attributes Completeness Validation (Enterprise Track)
+
+## STEP GOAL:
+
+Verify that each requirement has the required attributes: unique ID, priority (MoSCoW), source reference, rationale, verification method, and risk level. This is primarily an Enterprise track check.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 📖 CRITICAL: Read the complete step file before taking any action
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on requirement attribute completeness
+- 🎯 This step is MANDATORY for Enterprise track, SKIP for other tracks
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+### Track-Aware Execution:
+
+**Check the PRD frontmatter for `track` value:**
+- If `track: 'enterprise'` → Run full attribute validation
+- If `track: 'bmad'` or not set → Skip this step entirely, proceed to next step
+- Log decision in report
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Extract all requirements and check for required attributes
+- 💾 Append findings to validation report
+- 📖 Display "Proceeding to next check..." and load next step
+
+## VALIDATION SEQUENCE:
+
+### 1. Track Check
+
+If not Enterprise track:
+- Append to report: "**Requirement Attributes:** SKIPPED (not Enterprise track)"
+- Proceed to {nextStepFile}
+
+### 2. Extract and Check Attributes (Enterprise Only)
+
+For each FR and NFR, verify presence of:
+
+**Required Attributes:**
+- [ ] **Unique ID**: Follows consistent pattern (FR-[AREA]-###, NFR-[AREA]-###)
+- [ ] **Priority**: Must / Should / Could / Won't (MoSCoW)
+- [ ] **Source**: StRS reference or stakeholder name
+- [ ] **Rationale**: Why this requirement exists
+- [ ] **Verification Method**: Test / Analysis / Demonstration / Inspection
+- [ ] **Risk**: High / Medium / Low
+
+### 3. Generate Findings
+
+```markdown
+### Requirement Attributes Completeness
+
+**Requirements Checked:** [count]
+
+**Attribute Coverage:**
+| Attribute | Present | Missing | Coverage % |
+|-----------|---------|---------|------------|
+| Unique ID | | | |
+| Priority (MoSCoW) | | | |
+| Source Reference | | | |
+| Rationale | | | |
+| Verification Method | | | |
+| Risk Level | | | |
+
+**Missing Attributes:**
+[List specific requirements with missing attributes]
+
+**Severity:** [PASS / CONCERNS / FAIL]
+```
+
+### 4. Append to Report and Proceed
+
+Append findings to `{validationReportPath}`.
+
+Display: "**Requirement Attributes:** [PASS/CONCERNS/FAIL] - [X]% attribute coverage. Proceeding to implementation leakage check..."
+
+Read fully and follow: `{nextStepFile}`
+
+## SUCCESS METRICS:
+
+✅ Track correctly detected and appropriate action taken
+✅ All requirements checked for attribute completeness
+✅ Coverage percentages calculated per attribute type
+✅ Missing attributes identified with specific requirements
+✅ Findings appended to validation report
+
+## FAILURE MODES:
+
+❌ Running Enterprise validation on non-Enterprise track
+❌ Not identifying specific requirements with missing attributes
+❌ Not calculating coverage percentages

src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-12-completeness-validation.md

@@ -3,7 +3,7 @@ name: 'step-v-12-completeness-validation'
 description: 'Completeness Check - Final comprehensive completeness check before report generation'
 
 # File references (ONLY variables used in this step)
-nextStepFile: './step-v-13-report-complete.md'
+nextStepFile: './step-v-12b-verification-coverage.md'
 prdFile: '{prd_file_path}'
 prdFrontmatter: '{prd_frontmatter}'
 validationReportPath: '{validation_report_path}'

src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-12b-verification-coverage.md

@@ -0,0 +1,91 @@
+---
+name: 'step-v-12b-verification-coverage'
+description: 'Verification Coverage Validation - Check that all requirements have assigned verification methods'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-12c-interface-coverage.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 12b: Verification Coverage Validation (Enterprise Track)
+
+## STEP GOAL:
+
+Validate that all requirements have assigned verification methods and that the verification approach section is complete.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 📖 CRITICAL: 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 is a validation sequence step - auto-proceeds when complete
+
+### Track-Aware Execution:
+
+- If `track: 'enterprise'` → Run full verification coverage check
+- If `track: 'bmad'` or not set → Check if verification section exists, basic review only
+- Log decision in report
+
+## VALIDATION SEQUENCE:
+
+### 1. Check Verification Section Exists
+
+Look for "## Verification Approaches" or similar section in the PRD.
+
+**If Enterprise track:**
+- Section MUST exist → FAIL if missing
+- Every requirement category must have a verification method assigned
+- Verification dependencies must be documented
+
+**If BMad track:**
+- Section is OPTIONAL → Note if missing but don't fail
+- If present, do a basic quality check
+
+### 2. Verify Coverage (Enterprise)
+
+For each requirement category (FRs, NFRs, Interfaces, Constraints):
+- Is a primary verification method assigned?
+- Is the method appropriate for the requirement type?
+- Are verification dependencies identified?
+
+### 3. Generate Findings
+
+```markdown
+### Verification Coverage Validation
+
+**Verification Section:** [Present / Missing]
+
+**Coverage by Category:**
+| Requirement Category | V&V Method Assigned | Appropriate | Notes |
+|---------------------|-------------------|-------------|-------|
+| Functional | [Yes/No] | [Yes/No] | |
+| Performance NFRs | [Yes/No] | [Yes/No] | |
+| Security NFRs | [Yes/No] | [Yes/No] | |
+| Interface | [Yes/No] | [Yes/No] | |
+| Constraints | [Yes/No] | [Yes/No] | |
+
+**Verification Dependencies:** [Documented / Not documented]
+
+**Severity:** [PASS / CONCERNS / FAIL]
+```
+
+### 4. Append to Report and Proceed
+
+Append findings to `{validationReportPath}`.
+
+Display: "**Verification Coverage:** [PASS/CONCERNS/FAIL]. Proceeding to interface coverage check..."
+
+Read fully and follow: `{nextStepFile}`
+
+## SUCCESS METRICS:
+
+✅ Verification section existence checked
+✅ Track-appropriate depth of validation
+✅ All requirement categories checked for V&V assignment
+✅ Verification method appropriateness validated
+✅ Dependencies identified
+
+## FAILURE MODES:
+
+❌ Not checking verification section for Enterprise track
+❌ Not validating method appropriateness

src/bmm/workflows/2-plan-workflows/create-prd/steps-v/step-v-12c-interface-coverage.md

@@ -0,0 +1,85 @@
+---
+name: 'step-v-12c-interface-coverage'
+description: 'Interface Coverage Validation - Check that external interface requirements are complete'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-13-report-complete.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 12c: Interface Coverage Validation (Enterprise Track)
+
+## STEP GOAL:
+
+Validate that external interface requirements are complete and cover all integration points mentioned in the PRD.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 📖 CRITICAL: 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 is a validation sequence step - auto-proceeds when complete
+
+### Track-Aware Execution:
+
+- If `track: 'enterprise'` → Run full interface coverage check
+- If `track: 'bmad'` or not set → Check if interface section exists, note for awareness
+- Log decision in report
+
+## VALIDATION SEQUENCE:
+
+### 1. Check Interface Section Exists
+
+Look for "## External Interface Requirements" or similar section in the PRD.
+
+### 2. Cross-Reference Analysis (Enterprise)
+
+Scan the entire PRD for mentions of:
+- External systems, APIs, services
+- User interface platforms (web, mobile, CLI)
+- Hardware devices or sensors
+- Communication protocols
+- Third-party integrations
+
+Compare these mentions against what's documented in the Interface Requirements section.
+
+### 3. Generate Findings
+
+```markdown
+### Interface Coverage Validation
+
+**Interface Section:** [Present / Missing]
+
+**Interface Category Coverage:**
+| Category | Section Present | Completeness | Notes |
+|----------|---------------|-------------|-------|
+| User Interfaces | [Yes/No/N/A] | [Complete/Partial/Missing] | |
+| Hardware Interfaces | [Yes/No/N/A] | [Complete/Partial/Missing] | |
+| Software Interfaces | [Yes/No/N/A] | [Complete/Partial/Missing] | |
+| Communication Interfaces | [Yes/No/N/A] | [Complete/Partial/Missing] | |
+
+**Cross-Reference Issues:**
+[List any integrations mentioned in PRD but not documented in interface section]
+
+**Severity:** [PASS / CONCERNS / FAIL]
+```
+
+### 4. Append to Report and Proceed
+
+Append findings to `{validationReportPath}`.
+
+Display: "**Interface Coverage:** [PASS/CONCERNS/FAIL]. Proceeding to final report..."
+
+Read fully and follow: `{nextStepFile}`
+
+## SUCCESS METRICS:
+
+✅ Interface section existence checked
+✅ Cross-reference analysis performed
+✅ Missing interfaces identified
+✅ Track-appropriate validation depth
+
+## FAILURE MODES:
+
+❌ Not cross-referencing integrations mentioned elsewhere in PRD
+❌ Not checking all four interface categories

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)

src/bmm/workflows/2-plan-workflows/create-strs/checklist.md

@@ -0,0 +1,102 @@
+# StRS Quality Checklist (ISO 29148 Clause 7)
+
+Use this checklist to validate StRS completeness and quality.
+
+## Document Structure
+
+- [ ] All ISO 29148 Clause 7 sections are present
+- [ ] Frontmatter includes version, status, and workflow tracking
+- [ ] Document follows the approved template structure
+- [ ] All sections contain substantive content (no empty placeholders)
+
+## Section 1: Introduction & Stakeholders
+
+- [ ] Business purpose is clearly stated
+- [ ] Business scope is defined
+- [ ] Business overview provides sufficient context
+- [ ] Definitions and acronyms section is present
+- [ ] All stakeholders are identified with category, interest, and influence levels
+- [ ] Each stakeholder has a profile with needs vs. wants distinction
+- [ ] Stakeholder relationships and conflicts are analyzed
+- [ ] Priority ordering for conflicting needs is established
+
+## Section 2: References
+
+- [ ] All referenced documents are listed
+- [ ] Standards and regulations are referenced
+- [ ] References are traceable (version, date, source)
+
+## Section 3: Business Management Requirements
+
+- [ ] Business environment is documented (market, competition, technology)
+- [ ] Business objectives are SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
+- [ ] Business model is articulated (value creation, revenue, costs)
+- [ ] Information environment is mapped (existing systems, data flows)
+- [ ] Business policies and rules are identified
+
+## Section 4: Business Operational Requirements
+
+- [ ] Key business processes are mapped (trigger, actors, steps, outcome)
+- [ ] Operational policies and constraints are documented
+- [ ] All operational modes are defined (normal, degraded, maintenance, emergency)
+- [ ] Operational quality expectations are specified
+- [ ] Business structure context is captured
+
+## Section 5: User Requirements
+
+- [ ] All user types are identified and categorized
+- [ ] Each user type has a detailed profile (proficiency, goals, frustrations)
+- [ ] Personnel requirements are defined (training, support, staffing)
+- [ ] User interaction requirements are captured (devices, connectivity, languages)
+- [ ] Accessibility needs are documented per user type
+
+## Section 6: Proposed System Concept
+
+- [ ] Operational concept provides clear picture of system in action
+- [ ] At least 3 operational scenarios are documented
+- [ ] Scenarios cover happy path, exceptions, and cross-user interactions
+- [ ] Each scenario has actors, preconditions, steps, postconditions, and variations
+- [ ] Scenario coverage matrix validates completeness against user types and processes
+
+## Section 7: Project Constraints
+
+- [ ] Budget and cost constraints are documented
+- [ ] Schedule and timeline constraints are identified
+- [ ] Technology and platform constraints are listed
+- [ ] Environmental constraints are captured
+- [ ] Regulatory and compliance constraints are explicitly identified
+- [ ] Organizational constraints are documented
+
+## Section 8: Appendices
+
+- [ ] Assumptions are documented separately from verified facts
+- [ ] Dependencies are listed
+- [ ] Abbreviations and acronyms glossary is complete
+
+## Cross-Section Consistency
+
+- [ ] Stakeholder names are used consistently throughout
+- [ ] Business objectives align with operational requirements
+- [ ] User profiles match actors in operational scenarios
+- [ ] Constraints don't contradict requirements
+- [ ] All abbreviations appear in the glossary
+
+## Quality Criteria (Per Requirement)
+
+- [ ] Each requirement is necessary (traces to a stakeholder need)
+- [ ] Each requirement is implementation-free (states WHAT, not HOW)
+- [ ] Each requirement is unambiguous (single interpretation)
+- [ ] Each requirement is consistent with other requirements
+- [ ] Each requirement is complete (sufficient detail)
+- [ ] Each requirement is singular (one requirement per statement)
+- [ ] Each requirement is feasible within stated constraints
+- [ ] Each requirement is traceable (has source reference)
+- [ ] Each requirement is verifiable (can be tested or inspected)
+
+## Downstream Readiness
+
+- [ ] StRS provides sufficient input for PRD/SRS creation
+- [ ] Stakeholder requirements are traceable (have IDs for RTM)
+- [ ] Business objectives can be decomposed into functional requirements
+- [ ] Operational scenarios inform user journey creation in PRD
+- [ ] Constraints inform architecture decisions

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

@@ -0,0 +1,197 @@
+---
+name: 'step-01-init'
+description: 'Initialize the StRS workflow by detecting continuation state and loading input documents'
+
+# File References
+nextStepFile: './step-02-stakeholder-identification.md'
+outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
+
+# Template References
+strsTemplate: '../templates/strs-template.md'
+---
+
+# Step 1: StRS Initialization
+
+## STEP GOAL:
+
+Initialize the StRS workflow by detecting continuation state, loading the Product Brief and other input documents, and setting up the document structure.
+
+## 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 entire file is read
+- 📋 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 Requirements Engineering specialist facilitating ISO 29148 compliance
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring structured requirements thinking, while the user brings domain expertise and stakeholder knowledge
+- ✅ Maintain collaborative discovery tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on initialization and setup - no content generation yet
+- 🚫 FORBIDDEN to look ahead to future steps or assume knowledge from them
+- 💬 Approach: Systematic setup with clear reporting to user
+- 📋 Detect existing workflow state and handle continuation properly
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis of current state before taking any action
+- 💾 Initialize document structure and update frontmatter appropriately
+- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
+- 🚫 FORBIDDEN to load next step until user selects 'C' (Continue)
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Variables from workflow.md are available in memory
+- Focus: Workflow initialization and document setup only
+- Limits: Don't assume knowledge from other steps or create content yet
+- Dependencies: Configuration loaded from workflow.md initialization
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Check for Existing Workflow State
+
+First, check if the output document already exists:
+
+**Workflow State Detection:**
+
+- Look for file `{outputFile}`
+- If exists, read the complete file including frontmatter
+- If not exists, this is a fresh workflow
+
+### 2. Handle Continuation (If Document Exists)
+
+If the document exists and has frontmatter with `stepsCompleted`:
+
+**Continuation Protocol:**
+
+- Determine which step to resume from based on `stepsCompleted` array
+- Report to user what has been completed and what remains
+- Offer to continue from the next incomplete step
+- Load the appropriate step file based on last completed step
+
+### 3. Fresh Workflow Setup (If No Document)
+
+If no document exists or no `stepsCompleted` in frontmatter:
+
+#### A. Input Document Discovery
+
+Load context documents using smart discovery. Documents can be in the following locations:
+- {planning_artifacts}/**
+- {output_folder}/**
+- {product_knowledge}/**
+- docs/**
+
+Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files.
+
+**REQUIRED Input (Product Brief):**
+Try to discover the Product Brief:
+- `*product-brief*.md` or `*brief*.md`
+- The Product Brief is the PRIMARY input for StRS creation - it provides business vision, target audience, and market context
+
+**Optional Inputs:**
+- Brainstorming Reports (`*brainstorming*.md`)
+- Research Documents (`*research*.md`)
+- Project Documentation (in `{product_knowledge}` or `docs` folder)
+- Project Context (`**/project-context.md`)
+
+<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. The Product Brief is strongly recommended - if not found, warn the user that StRS quality will be impacted. Only after this confirmation will you proceed to follow the loading rules.</critical>
+
+**Loading Rules:**
+
+- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
+- The Product Brief content should be biased throughout the entire workflow process
+- For sharded folders, load ALL files to get complete picture, using the index first
+- Track all successfully loaded files in frontmatter `inputDocuments` array
+
+#### B. Create Initial Document
+
+**Document Setup:**
+
+- Copy the template from `{strsTemplate}` to `{outputFile}`, and update the frontmatter fields
+
+#### C. Present Initialization Results
+
+**Setup Report to User:**
+"Welcome {{user_name}}! I've set up your Stakeholder Requirements Specification workspace for {{project_name}}.
+
+**What is an StRS?**
+The Stakeholder Requirements Specification (ISO 29148 Clause 7) captures WHAT stakeholders need from the system - their business requirements, operational needs, user profiles, and project constraints. It bridges your Product Brief (business vision) and the PRD/SRS (detailed software requirements).
+
+**Document Setup:**
+
+- Created: `{outputFile}` from ISO 29148 template
+- Initialized frontmatter with workflow state
+
+**Input Documents Discovered:**
+
+- Product Brief: {found or "NOT FOUND - strongly recommended"}
+- Research: {number of research files loaded or "None found"}
+- Brainstorming: {number of brainstorming files loaded or "None found"}
+- Project docs: {number of project files loaded or "None found"}
+
+**Files loaded:** {list of specific file names or "No additional documents found"}
+
+**We'll work through 7 sections together:**
+1. Stakeholder Identification & Analysis
+2. Business Context (objectives, model, environment)
+3. Operational Requirements (processes, constraints, modes)
+4. User Requirements (profiles, personas, needs)
+5. Operational Concept & Scenarios
+6. Project Constraints (budget, timeline, environment)
+7. Final Review & Quality Check
+
+Do you have any other documents you'd like me to include, or shall we continue?"
+
+### 4. Present MENU OPTIONS
+
+Display: "**Select:** [C] Continue to Stakeholder Identification (Step 2 of 8)"
+
+#### Menu Handling Logic:
+
+- IF C: Update frontmatter with `stepsCompleted: [1]`, 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'
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN [setup completion is achieved and frontmatter properly updated], will you then read fully and follow: `{nextStepFile}` to begin stakeholder identification.
+
+---
+
+## SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Existing workflow detected and properly handled for continuation
+- Fresh workflow initialized with ISO 29148 template and proper frontmatter
+- Product Brief discovered and loaded (primary input)
+- Input documents discovered and loaded using smart discovery
+- All discovered files tracked in frontmatter `inputDocuments`
+- User informed about StRS purpose and workflow structure
+- Menu presented and user input handled correctly
+- Frontmatter updated with `stepsCompleted: [1]` before proceeding
+
+### ❌ SYSTEM FAILURE:
+
+- Proceeding with fresh initialization when existing workflow exists
+- Not loading Product Brief when available
+- Not warning user if Product Brief is missing
+- Not updating frontmatter with discovered input documents
+- Creating document without proper template structure
+- Not reporting discovered documents to user clearly
+- Proceeding without user selecting 'C' (Continue)
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

src/bmm/workflows/2-plan-workflows/create-strs/steps/step-02-stakeholder-identification.md

@@ -0,0 +1,208 @@
+---
+name: 'step-02-stakeholder-identification'
+description: 'Identify and analyze all stakeholders and their relationships to the system'
+
+# File References
+nextStepFile: './step-03-business-context.md'
+outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 2: Stakeholder Identification & Analysis
+
+**Progress: Step 2 of 8** - Next: Business Context
+
+## 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 expert peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on identifying ALL stakeholders who have interest in or are affected by the system
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating stakeholder 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:
+
+- Product Brief content is the primary source for stakeholder discovery
+- All loaded input documents should inform stakeholder identification
+- Focus on WHO has stakes in this system, not WHAT the system does
+- ISO 29148 requires clear stakeholder categorization
+
+## STAKEHOLDER IDENTIFICATION SEQUENCE:
+
+### 1. Explain Stakeholder Identification Purpose
+
+Start by explaining why stakeholder identification matters:
+
+**Purpose:**
+ISO 29148 requires formal identification of all parties who have interest in, are affected by, or can influence the system. This ensures no stakeholder group is overlooked and their needs are captured.
+
+**Stakeholder Categories to Explore:**
+- **Users** - People who will directly interact with the system
+- **Acquirers/Customers** - People who purchase or commission the system
+- **Operators** - People who maintain or administer the system
+- **Regulators** - Bodies that govern or regulate the domain
+- **Sponsors** - People funding or authorizing the project
+- **Developers/Maintainers** - People who build and maintain the system
+- **Support Staff** - People providing user support
+- **Affected Parties** - People indirectly affected (competitors, displaced workers, etc.)
+
+### 2. Extract Stakeholders from Product Brief
+
+Systematically review the Product Brief to identify stakeholders:
+
+**Extract From:**
+- Target audience / user definitions → Primary users
+- Business model → Customers, partners, revenue stakeholders
+- Market context → Competitors, regulators
+- Technical context → Development team, operations team
+- Success criteria → Who benefits from success?
+
+### 3. Collaborative Stakeholder Discovery
+
+Engage the user to validate and expand the stakeholder list:
+
+**Key Questions:**
+- "Who will use this system daily? Are there different user types?"
+- "Who is paying for this? Who decides if the project continues?"
+- "Are there regulatory bodies or compliance requirements?"
+- "Who will maintain the system after launch?"
+- "Who might be negatively impacted by this system?"
+- "Are there external partners or integrations involving other organizations?"
+
+### 4. Create Stakeholder Profiles
+
+For each identified stakeholder, capture:
+
+**Stakeholder Profile Format:**
+- **Name/Role**: Clear identifier
+- **Category**: User / Acquirer / Operator / Regulator / Sponsor / Other
+- **Interest Level**: High / Medium / Low
+- **Influence Level**: High / Medium / Low
+- **Key Concerns**: What matters most to this stakeholder
+- **Success Criteria**: How this stakeholder measures success
+- **Needs vs. Wants**: Distinguish essential needs from desirable features
+
+### 5. Analyze Stakeholder Relationships
+
+Map relationships and potential conflicts:
+
+**Analysis Points:**
+- Which stakeholders have conflicting needs?
+- Which stakeholders have the most influence on requirements?
+- Which stakeholders are most affected by system success/failure?
+- What is the priority order when stakeholder needs conflict?
+
+### 6. Generate Stakeholder Content
+
+Prepare the content to append to the document:
+
+#### Content Structure:
+
+```markdown
+## 1. Introduction
+
+### 1.1 Business Purpose
+
+[Business purpose derived from Product Brief - why this system is being built]
+
+### 1.2 Business Scope
+
+[Scope of the business domain this system addresses]
+
+### 1.3 Business Overview
+
+[High-level overview of the business context]
+
+### 1.4 Definitions and Acronyms
+
+[Key terms and acronyms used in this document - start list, will grow through workflow]
+
+### 1.5 Stakeholder Identification
+
+| Stakeholder | Category | Interest | Influence | Key Concerns |
+|-------------|----------|----------|-----------|-------------- |
+| [Name/Role] | [Category] | [H/M/L] | [H/M/L] | [Primary concerns] |
+
+### 1.6 Stakeholder Profiles
+
+#### [Stakeholder Name/Role]
+
+- **Category:** [User / Acquirer / Operator / Regulator / Sponsor / Other]
+- **Interest Level:** [High / Medium / Low]
+- **Influence Level:** [High / Medium / Low]
+- **Key Concerns:** [What matters most]
+- **Success Criteria:** [How they measure success]
+- **Needs:** [Essential requirements]
+- **Wants:** [Desirable but not essential]
+
+[Repeat for each stakeholder]
+
+### 1.7 Stakeholder Relationship Analysis
+
+[Relationship mapping, conflict areas, priority ordering]
+```
+
+### 7. Present MENU OPTIONS
+
+Present the stakeholder identification and analysis for review, then display menu:
+- Show identified stakeholders with profiles
+- Highlight any potential conflicts between stakeholder needs
+- Ask if any stakeholders are missing or profiles need adjustment
+- Present menu options naturally as part of conversation
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Business Context (Step 3 of 8)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow: {advancedElicitationTask} with the current stakeholder analysis, process enhanced insights, ask user acceptance, if yes update then redisplay, if no keep original then redisplay
+- IF P: Read fully and follow: {partyModeWorkflow} with stakeholder analysis, process collaborative validation, ask user acceptance, if yes update then redisplay, if no keep original then 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
+
+#### 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 content directly to the document using the structure from step 6.
+
+## SUCCESS METRICS:
+
+✅ All stakeholder categories explored systematically
+✅ Product Brief content used as primary source
+✅ Each stakeholder has clear profile with needs vs. wants
+✅ Stakeholder relationships and conflicts identified
+✅ Priority ordering established for conflicting needs
+✅ ISO 29148 Clause 7 Section 1 requirements addressed
+✅ A/P/C menu presented and handled correctly
+✅ Content properly appended to document when C selected
+
+## FAILURE MODES:
+
+❌ Missing key stakeholder categories (especially regulators, operators)
+❌ Not distinguishing needs from wants
+❌ Not identifying stakeholder conflicts
+❌ Generating stakeholder list without user input
+❌ Not presenting A/P/C menu after content generation
+❌ Appending content without user selecting 'C'
+
+❌ **CRITICAL**: Reading only partial step file
+❌ **CRITICAL**: Proceeding with 'C' without fully reading next step file
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load {nextStepFile} to define business context.

src/bmm/workflows/2-plan-workflows/create-strs/steps/step-03-business-context.md

@@ -0,0 +1,192 @@
+---
+name: 'step-03-business-context'
+description: 'Define business management requirements including objectives, business model, and information environment'
+
+# File References
+nextStepFile: './step-04-operational-requirements.md'
+outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 3: Business Context & Management Requirements
+
+**Progress: Step 3 of 8** - Next: Operational Requirements
+
+## 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 expert peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on business context that shapes what the system must do
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating business context 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:
+
+- Stakeholder identification from Step 2 is now available in document
+- Product Brief content continues to inform this step
+- Focus on business-level requirements, NOT system design
+- ISO 29148 Clause 7 Section 3: Business Management Requirements
+
+## BUSINESS CONTEXT SEQUENCE:
+
+### 1. Explain Business Context Purpose
+
+**Purpose:**
+ISO 29148 requires understanding the business environment, objectives, and model before defining what the system must do. This ensures system requirements are grounded in real business needs, not assumptions.
+
+**Sections to Cover:**
+- Business Environment (market, competitive landscape, technology context)
+- Business Objectives and Success Measures
+- Business Model (how value is created and captured)
+- Information Environment (data flows, existing systems, integration landscape)
+
+### 2. Business Environment Discovery
+
+Extract and validate business environment from Product Brief and research:
+
+**Key Questions:**
+- "What market forces or trends are driving this system?"
+- "Who are the main competitors and how does this system differentiate?"
+- "What technology changes or opportunities enable this system?"
+- "What regulatory or compliance environment affects this system?"
+- "What are the current pain points this system addresses?"
+
+### 3. Business Objectives and Success
+
+Define measurable business objectives:
+
+**Key Questions:**
+- "What are the top 3 business objectives this system must achieve?"
+- "How will you measure whether these objectives are met?"
+- "What is the timeline for achieving these objectives?"
+- "What happens if these objectives are NOT met?"
+- "Are there intermediate milestones?"
+
+**Objective Format:**
+Each objective should be SMART: Specific, Measurable, Achievable, Relevant, Time-bound.
+
+### 4. Business Model
+
+Capture how the system fits the business model:
+
+**Key Questions:**
+- "How does this system generate or protect revenue?"
+- "What is the cost model (development, operations, maintenance)?"
+- "Who pays for the system and how?"
+- "What are the key business processes the system supports?"
+- "How does the system fit within the larger organizational strategy?"
+
+### 5. Information Environment
+
+Map the data and system landscape:
+
+**Key Questions:**
+- "What existing systems must this system interact with?"
+- "What data does the system consume and produce?"
+- "Are there data governance or privacy requirements?"
+- "What is the current state of data (paper, legacy systems, manual processes)?"
+- "What are the key information flows this system must support?"
+
+### 6. Business Policies and Rules
+
+Identify policies that constrain the system:
+
+**Key Questions:**
+- "What business policies must the system enforce?"
+- "Are there industry standards or best practices to follow?"
+- "What authorization or approval workflows exist?"
+- "Are there data retention or archiving requirements?"
+
+### 7. Generate Business Context Content
+
+Prepare the content to append to the document:
+
+#### Content Structure:
+
+```markdown
+## 2. References
+
+[List of reference documents, standards, and regulations relevant to this project]
+
+## 3. Business Management Requirements
+
+### 3.1 Business Environment
+
+[Market context, competitive landscape, technology drivers, regulatory context]
+
+### 3.2 Business Objectives
+
+| Objective ID | Objective | Success Measure | Timeline |
+|-------------|-----------|----------------|----------|
+| BO-001 | [Objective description] | [Measurable criteria] | [Target date] |
+
+### 3.3 Business Model
+
+[How the system creates, delivers, and captures value. Revenue model, cost structure, key processes supported.]
+
+### 3.4 Information Environment
+
+[Existing systems, data flows, integration landscape, data governance requirements]
+
+### 3.5 Business Policies and Rules
+
+[Business policies the system must enforce, industry standards, authorization workflows]
+```
+
+### 8. Present MENU OPTIONS
+
+Present the business context for review, then display menu:
+- Show synthesized business context and objectives
+- Highlight any gaps or assumptions that need validation
+- Ask if any business aspects are missing
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Operational Requirements (Step 4 of 8)"
+
+#### Menu Handling Logic:
+- IF A: Read fully and follow: {advancedElicitationTask} with current business context, process enhanced insights, ask user acceptance, if yes update then redisplay, if no keep original then redisplay
+- IF P: Read fully and follow: {partyModeWorkflow} with business context, process collaborative validation, ask user acceptance, if yes update then redisplay, if no keep original then 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
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', append the content directly to the document using the structure from step 7.
+
+## SUCCESS METRICS:
+
+✅ Business environment thoroughly documented
+✅ Business objectives are SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
+✅ Business model clearly articulated
+✅ Information environment mapped (existing systems, data flows)
+✅ Business policies and rules identified
+✅ All content grounded in Product Brief and user input
+✅ ISO 29148 Clause 7 Section 3 requirements addressed
+
+## FAILURE MODES:
+
+❌ Vague or unmeasurable business objectives
+❌ Missing information environment analysis
+❌ Not connecting business context to Product Brief
+❌ Generating content without user validation
+❌ Skipping business policy identification
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load {nextStepFile} to define operational requirements.

src/bmm/workflows/2-plan-workflows/create-strs/steps/step-04-operational-requirements.md

@@ -0,0 +1,206 @@
+---
+name: 'step-04-operational-requirements'
+description: 'Define business operational requirements including processes, constraints, operational modes, and quality expectations'
+
+# File References
+nextStepFile: './step-05-user-requirements.md'
+outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 4: Business Operational Requirements
+
+**Progress: Step 4 of 8** - Next: User Requirements
+
+## 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 expert peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on HOW the business operates and what the system must support operationally
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating operational requirements
+- 💾 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:
+
+- Previous steps (stakeholders, business context) are available in document
+- Focus on operational aspects - how the business runs and what the system must support
+- ISO 29148 Clause 7 Section 4: Business Operational Requirements
+
+## OPERATIONAL REQUIREMENTS SEQUENCE:
+
+### 1. Explain Operational Requirements Purpose
+
+**Purpose:**
+Operational requirements define HOW the business currently operates (or intends to operate) and what the system must support at a business process level. These are NOT system design requirements - they describe business operations.
+
+**Sections to Cover:**
+- Business Processes (what workflows the system supports)
+- Operational Policies and Constraints
+- Operational Modes (normal, degraded, maintenance, emergency)
+- Operational Quality Requirements (at business level)
+- Business Structure (organizational context)
+
+### 2. Business Process Discovery
+
+Map the key business processes this system supports:
+
+**Key Questions:**
+- "Walk me through the main business processes this system will support"
+- "What happens before and after someone uses this system?"
+- "Are there manual processes that this system will automate?"
+- "What handoffs exist between people/departments?"
+- "What are the critical path processes that cannot fail?"
+
+**For each process, capture:**
+- Process name and description
+- Trigger (what starts the process)
+- Actors involved
+- Key steps
+- Expected outcome
+- Current pain points
+
+### 3. Operational Policies and Constraints
+
+Identify operational boundaries:
+
+**Key Questions:**
+- "What are the operating hours? Is 24/7 availability required?"
+- "Are there geographic or regional constraints?"
+- "What are the data handling policies (retention, deletion, privacy)?"
+- "Are there capacity limits or constraints?"
+- "What compliance policies affect operations?"
+
+### 4. Operational Modes
+
+Define how the system behaves in different states:
+
+**Modes to Explore:**
+- **Normal Operation**: Standard operating conditions
+- **Degraded Mode**: What happens when parts of the system are unavailable?
+- **Maintenance Mode**: How are updates and maintenance handled?
+- **Emergency Mode**: What happens during incidents or emergencies?
+- **Peak Load**: How does the system behave under maximum load?
+
+**For each mode:**
+- "What triggers this mode?"
+- "What capabilities are available/unavailable?"
+- "What stakeholders are affected?"
+- "How is normal operation restored?"
+
+### 5. Operational Quality Expectations
+
+Define quality expectations from a business perspective:
+
+**Key Questions:**
+- "What level of availability does the business require?"
+- "What is the acceptable data loss window?"
+- "What response time expectations exist from a business perspective?"
+- "What are the business continuity requirements?"
+- "What reporting or audit capabilities are needed?"
+
+### 6. Business Structure Context
+
+Understand organizational context:
+
+**Key Questions:**
+- "How is the organization structured around this system?"
+- "What teams or departments interact with the system?"
+- "Are there geographical distributions to consider?"
+- "What is the decision-making hierarchy for this system?"
+
+### 7. Generate Operational Requirements Content
+
+Prepare the content to append to the document:
+
+#### Content Structure:
+
+```markdown
+## 4. Business Operational Requirements
+
+### 4.1 Business Processes
+
+#### BP-001: [Process Name]
+
+- **Trigger:** [What starts this process]
+- **Actors:** [Who is involved]
+- **Steps:** [Key process steps]
+- **Outcome:** [Expected result]
+- **Current Pain Points:** [What needs improvement]
+
+[Repeat for each key process]
+
+### 4.2 Operational Policies and Constraints
+
+| Policy ID | Policy | Rationale | Impact |
+|-----------|--------|-----------|--------|
+| OP-001 | [Policy description] | [Why this exists] | [How it affects the system] |
+
+### 4.3 Operational Modes
+
+| Mode | Trigger | Available Capabilities | Unavailable | Recovery |
+|------|---------|----------------------|-------------|----------|
+| Normal | Default state | All | None | N/A |
+| Degraded | [Trigger] | [Limited set] | [Unavailable] | [Recovery process] |
+| Maintenance | [Trigger] | [Available during maintenance] | [Suspended] | [Restoration] |
+| Emergency | [Trigger] | [Critical only] | [Non-critical] | [Emergency procedures] |
+
+### 4.4 Operational Quality
+
+[Business-level quality expectations: availability, data loss tolerance, response expectations, business continuity]
+
+### 4.5 Business Structure
+
+[Organizational context, team interactions, geographical distribution]
+```
+
+### 8. Present MENU OPTIONS
+
+Present the operational requirements for review, then display menu:
+- Show documented business processes and operational requirements
+- Highlight any gaps in operational mode coverage
+- Ask if any processes or constraints are missing
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to User Requirements (Step 5 of 8)"
+
+#### 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 7.
+
+## SUCCESS METRICS:
+
+✅ Key business processes mapped with triggers, actors, steps, outcomes
+✅ Operational policies and constraints identified
+✅ All operational modes defined (normal, degraded, maintenance, emergency)
+✅ Business-level quality expectations documented
+✅ Organizational structure context captured
+✅ ISO 29148 Clause 7 Section 4 requirements addressed
+
+## FAILURE MODES:
+
+❌ Confusing operational requirements with system design requirements
+❌ Missing operational modes (especially degraded and emergency)
+❌ Not identifying operational constraints
+❌ Generating process maps without user validation
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load {nextStepFile} to define user requirements.

src/bmm/workflows/2-plan-workflows/create-strs/steps/step-05-user-requirements.md

@@ -0,0 +1,203 @@
+---
+name: 'step-05-user-requirements'
+description: 'Define user requirements including user identification, profiles, and personnel requirements'
+
+# File References
+nextStepFile: './step-06-operational-concept.md'
+outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 5: User Requirements
+
+**Progress: Step 5 of 8** - Next: Operational Concept & Scenarios
+
+## 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 expert peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on who the users are and what they specifically need from the system
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating user requirements
+- 💾 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:
+
+- Stakeholder profiles from Step 2 are the foundation (especially User-category stakeholders)
+- Product Brief user definitions should inform user profiles
+- Focus on USER needs at a stakeholder level, not system features
+- ISO 29148 Clause 7 Section 5: User Requirements
+
+## USER REQUIREMENTS SEQUENCE:
+
+### 1. Explain User Requirements Purpose
+
+**Purpose:**
+User requirements capture WHO will use the system and WHAT they need at a human level. These are distinct from functional requirements (which define system capabilities) - user requirements focus on the human side: skills, training, environment, and interaction expectations.
+
+**Sections to Cover:**
+- User Identification (types and categories of users)
+- User Profiles (characteristics, skills, environment)
+- Personnel Requirements (staffing, training, support)
+
+### 2. User Identification
+
+Identify all user types from stakeholder analysis and Product Brief:
+
+**Key Questions:**
+- "What distinct types of users will interact with the system?"
+- "How do these user types differ in their goals and capabilities?"
+- "Are there user types who interact only occasionally vs. daily?"
+- "Are there administrative or support user types?"
+- "Are there automated system users (APIs, integrations)?"
+
+### 3. User Profile Development
+
+For each user type, build a detailed profile:
+
+**Profile Elements:**
+- **User Type Name**: Clear, descriptive identifier
+- **Description**: Who this user is and their role
+- **Technical Proficiency**: Low / Medium / High
+- **Domain Expertise**: Novice / Intermediate / Expert
+- **Usage Frequency**: Daily / Weekly / Monthly / Occasional
+- **Usage Environment**: Office / Mobile / Remote / Field / Varied
+- **Accessibility Needs**: Any specific accessibility requirements
+- **Key Goals**: Top 3-5 things this user wants to accomplish
+- **Frustrations**: Current pain points with existing solutions
+- **Constraints**: Limitations on how this user can interact
+
+**Key Questions per User Type:**
+- "What is a day in the life of this user?"
+- "What tools do they currently use?"
+- "What are their biggest frustrations with current approaches?"
+- "How tech-savvy is this user type?"
+- "What would make them consider the system a success?"
+
+### 4. Personnel Requirements
+
+Define staffing and training needs:
+
+**Key Questions:**
+- "Will users need training to use the system?"
+- "What level of training is acceptable (self-service, tutorial, formal)?"
+- "Are there specialized roles needed to operate the system?"
+- "What support model is expected (self-service, help desk, on-call)?"
+- "Are there regulatory requirements for user certification?"
+
+### 5. User Interaction Requirements
+
+Capture high-level interaction expectations:
+
+**Key Questions:**
+- "What devices will users primarily use?"
+- "What are the connectivity expectations (always online, offline capable)?"
+- "What languages must the system support?"
+- "Are there cultural or regional considerations?"
+- "What is the expected learning curve?"
+
+### 6. Generate User Requirements Content
+
+Prepare the content to append to the document:
+
+#### Content Structure:
+
+```markdown
+## 5. User Requirements
+
+### 5.1 User Identification
+
+| User Type | Description | Usage Frequency | Technical Proficiency |
+|-----------|-------------|----------------|----------------------|
+| [Type name] | [Brief description] | [Daily/Weekly/etc.] | [Low/Medium/High] |
+
+### 5.2 User Profiles
+
+#### UP-001: [User Type Name]
+
+- **Description:** [Who this user is]
+- **Technical Proficiency:** [Low / Medium / High]
+- **Domain Expertise:** [Novice / Intermediate / Expert]
+- **Usage Frequency:** [Daily / Weekly / Monthly / Occasional]
+- **Usage Environment:** [Office / Mobile / Remote / Field]
+- **Accessibility Needs:** [Specific requirements or "Standard"]
+- **Key Goals:**
+  1. [Primary goal]
+  2. [Secondary goal]
+  3. [Tertiary goal]
+- **Current Frustrations:** [Pain points with existing solutions]
+- **Constraints:** [Limitations on interaction]
+
+[Repeat for each user type]
+
+### 5.3 Personnel Requirements
+
+#### Training Requirements
+
+[Training model, certification needs, learning curve expectations]
+
+#### Support Model
+
+[Support structure, escalation paths, response time expectations]
+
+#### Staffing
+
+[Specialized roles needed, team structure implications]
+
+### 5.4 User Interaction Requirements
+
+[Device expectations, connectivity, languages, cultural considerations]
+```
+
+### 7. Present MENU OPTIONS
+
+Present the user requirements for review, then display menu:
+- Show user profiles and requirements
+- Highlight connections to stakeholder analysis from Step 2
+- Ask if any user types are missing or profiles need adjustment
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Operational Concept (Step 6 of 8)"
+
+#### 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 user types identified and categorized
+✅ Each user type has a detailed profile
+✅ Profiles include goals, frustrations, constraints, and proficiency levels
+✅ Personnel requirements (training, support, staffing) documented
+✅ User interaction requirements captured
+✅ Profiles connected to stakeholder analysis from Step 2
+✅ ISO 29148 Clause 7 Section 5 requirements addressed
+
+## FAILURE MODES:
+
+❌ Missing user types (especially admin, support, API users)
+❌ Generic profiles without specific goals and frustrations
+❌ Not connecting to stakeholder profiles from Step 2
+❌ Skipping personnel requirements
+❌ Not capturing accessibility needs
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load {nextStepFile} to define operational concept and scenarios.

src/bmm/workflows/2-plan-workflows/create-strs/steps/step-06-operational-concept.md

@@ -0,0 +1,187 @@
+---
+name: 'step-06-operational-concept'
+description: 'Define the proposed system operational concept and operational scenarios'
+
+# File References
+nextStepFile: './step-07-project-constraints.md'
+outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 6: Operational Concept & Scenarios
+
+**Progress: Step 6 of 8** - Next: Project 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 expert peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on HOW the system will be used in real operational scenarios
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating operational concept 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 steps (stakeholders, business context, operational requirements, user profiles) inform scenarios
+- Focus on HOW the system operates in context, not system internals
+- ISO 29148 Clause 7 Section 6: Proposed System Concept
+
+## OPERATIONAL CONCEPT SEQUENCE:
+
+### 1. Explain Operational Concept Purpose
+
+**Purpose:**
+The operational concept describes HOW the proposed system will work from the users' and operators' perspective. It paints a picture of the system in action - who does what, when, and how. Operational scenarios are concrete stories that illustrate the concept.
+
+**Sections to Cover:**
+- Operational Concept (high-level vision of system operation)
+- Operational Scenarios (concrete day-in-the-life stories)
+
+### 2. Build Operational Concept
+
+Synthesize previous steps into a cohesive operational picture:
+
+**Key Questions:**
+- "Describe a typical day with this system fully operational - what happens?"
+- "How does the system fit into users' existing workflows?"
+- "What changes from the current way of doing things?"
+- "How do different user types interact with each other through the system?"
+- "What is the system's role in the bigger picture (supporting tool vs. central platform)?"
+
+**Operational Concept Elements:**
+- System's place in the overall business workflow
+- Key interactions between user types and the system
+- Information flows between system and external entities
+- Major system capabilities from an operational perspective
+- How the system handles transitions between operational modes
+
+### 3. Create Operational Scenarios
+
+Develop concrete scenarios that illustrate the operational concept:
+
+**Scenario Development Guidelines:**
+
+Create 3-5 key scenarios covering:
+1. **Happy Path**: Normal, successful use of core functionality
+2. **First-Time Use**: New user onboarding experience
+3. **Exception Handling**: What happens when things go wrong
+4. **Peak Load**: System under maximum expected usage
+5. **Cross-User Interaction**: Different user types working together
+
+**For each scenario, capture:**
+- **Scenario Name**: Descriptive title
+- **Actors**: Who is involved
+- **Preconditions**: What must be true before the scenario starts
+- **Trigger**: What initiates the scenario
+- **Steps**: Sequential actions and system responses
+- **Postconditions**: What is true after the scenario completes
+- **Variations**: Alternative paths or edge cases
+
+**Key Questions per Scenario:**
+- "Walk me through exactly what happens step by step"
+- "What could go wrong at each step?"
+- "How does the user know the step was successful?"
+- "What data is created, modified, or consumed?"
+
+### 4. Validate Scenario Coverage
+
+Ensure scenarios cover all key stakeholder needs:
+
+**Coverage Check:**
+- Do scenarios cover all user types from Step 5?
+- Do scenarios exercise all business processes from Step 4?
+- Do scenarios address all operational modes (normal, degraded, maintenance)?
+- Are edge cases and error conditions represented?
+- Do scenarios illustrate the business objectives from Step 3?
+
+### 5. Generate Operational Concept Content
+
+Prepare the content to append to the document:
+
+#### Content Structure:
+
+```markdown
+## 6. Proposed System Concept
+
+### 6.1 Operational Concept
+
+[High-level narrative describing how the system operates in context. Paint a picture of the system in action - who does what, when, how. Include system's place in workflows, key interactions, information flows.]
+
+### 6.2 Operational Scenarios
+
+#### OS-001: [Scenario Name]
+
+- **Actors:** [Who is involved]
+- **Preconditions:** [What must be true]
+- **Trigger:** [What starts this scenario]
+- **Scenario Steps:**
+  1. [Actor] [action] → [System response/result]
+  2. [Actor] [action] → [System response/result]
+  3. [Continue for all steps]
+- **Postconditions:** [What is true after completion]
+- **Variations:**
+  - [Alternative path or edge case]
+  - [Error condition and handling]
+
+[Repeat for each scenario]
+
+### 6.3 Scenario Coverage Matrix
+
+| Scenario | User Types | Business Processes | Operational Modes | Business Objectives |
+|----------|-----------|-------------------|-------------------|-------------------|
+| OS-001 | [Types covered] | [Processes covered] | [Modes covered] | [Objectives addressed] |
+```
+
+### 6. Present MENU OPTIONS
+
+Present the operational concept and scenarios for review, then display menu:
+- Show operational concept narrative and scenarios
+- Highlight scenario coverage matrix
+- Ask if any scenarios are missing or need more detail
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Project Constraints (Step 7 of 8)"
+
+#### 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 5.
+
+## SUCCESS METRICS:
+
+✅ Operational concept provides clear picture of system in action
+✅ 3-5 operational scenarios covering happy path, exceptions, and cross-user interactions
+✅ Each scenario has actors, preconditions, steps, postconditions, and variations
+✅ Scenario coverage matrix validates completeness
+✅ All user types from Step 5 appear in at least one scenario
+✅ Business processes from Step 4 are exercised by scenarios
+✅ ISO 29148 Clause 7 Section 6 requirements addressed
+
+## FAILURE MODES:
+
+❌ Operational concept is too abstract (no concrete operational picture)
+❌ Scenarios are too vague (missing steps, actors, or postconditions)
+❌ Not covering all user types in scenarios
+❌ Only happy-path scenarios (missing error and edge cases)
+❌ Not validating scenario coverage against previous steps
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load {nextStepFile} to define project constraints.

src/bmm/workflows/2-plan-workflows/create-strs/steps/step-07-project-constraints.md

@@ -0,0 +1,206 @@
+---
+name: 'step-07-project-constraints'
+description: 'Define project constraints including budget, timeline, and environmental constraints'
+
+# File References
+nextStepFile: './step-08-review-complete.md'
+outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 7: Project Constraints
+
+**Progress: Step 7 of 8** - Next: Final Review & Completion
+
+## 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 expert peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on constraints that limit what and how the system can be built
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## 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 steps inform constraint identification
+- Focus on project-level constraints that affect feasibility and scope
+- ISO 29148 Clause 7 Section 7: Project Constraints
+
+## PROJECT CONSTRAINTS SEQUENCE:
+
+### 1. Explain Constraints Purpose
+
+**Purpose:**
+Project constraints define the boundaries within which the system must be built and operated. They are non-negotiable limitations from budget, time, technology, environment, regulations, or organizational factors. Understanding constraints early prevents unrealistic requirements.
+
+**Constraint Categories:**
+- Budget and Cost Constraints
+- Schedule and Timeline Constraints
+- Technology and Platform Constraints
+- Environmental and Infrastructure Constraints
+- Regulatory and Compliance Constraints
+- Organizational and Resource Constraints
+
+### 2. Budget and Cost Constraints
+
+**Key Questions:**
+- "What is the budget range for this project?"
+- "Are there ongoing operational cost limits?"
+- "What are the licensing or subscription constraints?"
+- "Is there a target cost per user or transaction?"
+- "What happens if the budget is exceeded?"
+
+### 3. Schedule and Timeline Constraints
+
+**Key Questions:**
+- "What is the target launch date? Is it fixed or flexible?"
+- "Are there regulatory deadlines or market windows?"
+- "What are the key milestones?"
+- "Are there dependencies on external timelines (partner launches, API availability)?"
+- "What is the minimum viable timeline?"
+
+### 4. Technology and Platform Constraints
+
+**Key Questions:**
+- "Are there mandated technology choices (programming languages, frameworks, cloud providers)?"
+- "Are there existing systems that must be maintained or integrated with?"
+- "Are there platform requirements (iOS, Android, web, desktop)?"
+- "Are there third-party service dependencies?"
+- "Are there open source vs. commercial software policies?"
+
+### 5. Environmental and Infrastructure Constraints
+
+**Key Questions:**
+- "What hosting or deployment environments are available?"
+- "Are there geographic restrictions (data residency, CDN locations)?"
+- "What are the network constraints (bandwidth, latency, offline requirements)?"
+- "Are there hardware constraints for end users?"
+- "What are the development and testing environment constraints?"
+
+### 6. Regulatory and Compliance Constraints
+
+**Key Questions:**
+- "What regulations apply (GDPR, HIPAA, PCI-DSS, SOC2, etc.)?"
+- "Are there industry-specific standards to comply with?"
+- "What certifications are required?"
+- "Are there accessibility requirements (WCAG, Section 508)?"
+- "What audit or reporting requirements exist?"
+
+### 7. Organizational and Resource Constraints
+
+**Key Questions:**
+- "What team size and skill sets are available?"
+- "Are there organizational process requirements (Agile, waterfall, approvals)?"
+- "What are the decision-making constraints?"
+- "Are there vendor or contractor limitations?"
+- "What knowledge transfer or documentation requirements exist?"
+
+### 8. Generate Constraints Content
+
+Prepare the content to append to the document:
+
+#### Content Structure:
+
+```markdown
+## 7. Project Constraints
+
+### 7.1 Budget and Cost Constraints
+
+| Constraint ID | Constraint | Impact | Flexibility |
+|--------------|-----------|--------|-------------|
+| BC-001 | [Budget constraint] | [How it affects the project] | [Fixed / Negotiable] |
+
+### 7.2 Schedule and Timeline Constraints
+
+| Constraint ID | Constraint | Deadline | Flexibility |
+|--------------|-----------|----------|-------------|
+| TC-001 | [Timeline constraint] | [Date or timeframe] | [Fixed / Negotiable] |
+
+### 7.3 Technology and Platform Constraints
+
+| Constraint ID | Constraint | Rationale | Impact |
+|--------------|-----------|-----------|--------|
+| PC-001 | [Platform/technology constraint] | [Why this constraint exists] | [How it affects design] |
+
+### 7.4 Environmental Constraints
+
+[Hosting, geographic, network, hardware, and development environment constraints]
+
+### 7.5 Regulatory and Compliance Constraints
+
+| Constraint ID | Regulation/Standard | Requirement | Impact |
+|--------------|-------------------|-------------|--------|
+| RC-001 | [Regulation name] | [What it requires] | [How it affects the system] |
+
+### 7.6 Organizational Constraints
+
+[Team, process, vendor, and knowledge constraints]
+
+## 8. Appendices
+
+### 8.1 Assumptions
+
+[List all assumptions made during StRS creation - these are statements believed to be true but not yet verified]
+
+### 8.2 Dependencies
+
+[List all external dependencies that could affect the project]
+
+### 8.3 Abbreviations and Acronyms
+
+[Complete list of all abbreviations and acronyms used in this document]
+```
+
+### 9. Present MENU OPTIONS
+
+Present the project constraints for review, then display menu:
+- Show all constraint categories
+- Highlight any constraints that may conflict with requirements from previous steps
+- Ask if any constraints are missing
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Final Review (Step 8 of 8)"
+
+#### 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 8.
+
+## SUCCESS METRICS:
+
+✅ All constraint categories explored
+✅ Each constraint has ID, description, impact, and flexibility level
+✅ Regulatory and compliance constraints explicitly identified
+✅ Assumptions clearly separated from verified facts
+✅ Dependencies documented
+✅ Abbreviations and acronyms collected
+✅ ISO 29148 Clause 7 Section 7 requirements addressed
+
+## FAILURE MODES:
+
+❌ Missing regulatory or compliance constraints
+❌ Not documenting assumptions separately from facts
+❌ Leaving constraint impact analysis blank
+❌ Not identifying constraint conflicts with requirements
+❌ Missing technology platform constraints
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved, load {nextStepFile} for final review and completion.

src/bmm/workflows/2-plan-workflows/create-strs/steps/step-08-review-complete.md

@@ -0,0 +1,149 @@
+---
+name: 'step-08-review-complete'
+description: 'Final quality review of the complete StRS document against ISO 29148 Clause 7 requirements'
+
+# File References
+outputFile: '{planning_artifacts}/strs-{{project_name}}.md'
+checklistFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-strs/checklist.md'
+---
+
+# Step 8: Final Review & Completion
+
+**Progress: Step 8 of 8** - Final Step
+
+## 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 is a REVIEW step - focus on validation, not content generation
+- 📋 Use the quality checklist to systematically verify document completeness
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Perform systematic review against ISO 29148 Clause 7
+- 📖 Load and use the quality checklist
+- 💾 Update document frontmatter to mark completion
+- ✅ Present review findings to user for final approval
+
+## REVIEW SEQUENCE:
+
+### 1. Load Quality Checklist
+
+Read the quality checklist from: `{checklistFile}`
+
+### 2. Systematic Document Review
+
+Review the complete StRS document against the checklist. For each item:
+
+**Check:**
+- Is the section present?
+- Is the content substantive (not placeholder text)?
+- Does it address the ISO 29148 requirement?
+- Is the content consistent with other sections?
+
+### 3. Cross-Section Consistency Check
+
+Verify consistency across the entire document:
+
+**Consistency Checks:**
+- Stakeholder names used consistently throughout
+- Business objectives align with operational requirements
+- User profiles match the actors in operational scenarios
+- Constraints don't contradict other requirements
+- All abbreviations in glossary
+- All referenced documents in references section
+
+### 4. Completeness Assessment
+
+Evaluate overall document completeness:
+
+**Scoring:**
+- **Complete**: All ISO 29148 Clause 7 sections present with substantive content
+- **Mostly Complete**: 1-2 minor sections missing or thin
+- **Incomplete**: Major sections missing or substantial gaps
+
+### 5. Present Review Results
+
+Present findings to the user:
+
+**Review Report:**
+"I've completed the ISO 29148 Clause 7 quality review of your StRS.
+
+**Overall Assessment:** [Complete / Mostly Complete / Incomplete]
+
+**Section Coverage:**
+| Section | Status | Notes |
+|---------|--------|-------|
+| 1. Introduction & Stakeholders | [✅/⚠️/❌] | [Notes] |
+| 2. References | [✅/⚠️/❌] | [Notes] |
+| 3. Business Management Requirements | [✅/⚠️/❌] | [Notes] |
+| 4. Business Operational Requirements | [✅/⚠️/❌] | [Notes] |
+| 5. User Requirements | [✅/⚠️/❌] | [Notes] |
+| 6. Proposed System Concept | [✅/⚠️/❌] | [Notes] |
+| 7. Project Constraints | [✅/⚠️/❌] | [Notes] |
+| 8. Appendices | [✅/⚠️/❌] | [Notes] |
+
+**Consistency Issues Found:** [List any issues or "None"]
+
+**Recommendations:** [Any suggestions for improvement]
+
+**Next Steps:**
+This StRS is now ready to serve as input for:
+1. **PRD/SRS Creation** (John - PM) - Translates stakeholder needs into software requirements
+2. **RTM Creation** - Links StRS requirements to downstream documents"
+
+### 6. Finalize Document
+
+**Frontmatter Updates:**
+- Add this step name to `stepsCompleted` array
+- Set `status: 'review'` (user should approve to set 'approved')
+- Set `version: '1.0'`
+
+**Present Completion Menu:**
+
+Display: "**StRS creation is complete!** Would you like to:
+- [R] Review and address any issues found
+- [F] Finalize the StRS as-is (status → review)
+- [A] Approve the StRS (status → approved)"
+
+#### Menu Handling Logic:
+- IF R: Go back to the relevant section and iterate, then return to this review
+- IF F: Update frontmatter with `status: 'review'`, report completion
+- IF A: Update frontmatter with `status: 'approved'`, report completion
+
+### 7. Completion Report
+
+After finalization:
+
+"**StRS Complete!** 🎯
+
+**Document:** `{outputFile}`
+**Status:** [review / approved]
+**ISO 29148 Clause 7 Coverage:** [Complete / Mostly Complete]
+
+**This StRS feeds into:**
+- PRD/SRS creation (use [CP] Create PRD with John)
+- Requirements Traceability Matrix (use [RT] with John)
+- Architecture decisions (use [CA] with Winston)
+
+**Enterprise Track Next Step:**
+Consider running the Quality Gate check before proceeding to PRD creation."
+
+## SUCCESS METRICS:
+
+✅ All ISO 29148 Clause 7 sections reviewed against checklist
+✅ Cross-section consistency verified
+✅ Completeness assessment provided with clear scoring
+✅ Review findings presented clearly to user
+✅ Document frontmatter updated with final status
+✅ Next steps and downstream workflow guidance provided
+
+## FAILURE MODES:
+
+❌ Not using the quality checklist for systematic review
+❌ Marking document complete without addressing critical gaps
+❌ Not checking cross-section consistency
+❌ Not providing clear next-step guidance
+❌ Not updating document status in frontmatter
+
+**Master Rule:** This review must be thorough and honest. Do NOT gloss over issues to appear complete.

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

@@ -0,0 +1,15 @@
+---
+stepsCompleted: []
+inputDocuments: []
+workflowType: 'strs'
+track: 'enterprise'
+version: '1.0'
+status: 'draft'
+baseline_version: null
+---
+
+# Stakeholder Requirements Specification - {{project_name}}
+
+**Author:** {{user_name}}
+**Date:** {{date}}
+**ISO 29148 Reference:** Clause 7 - Stakeholder Requirements Specification

src/bmm/workflows/2-plan-workflows/create-strs/workflow.md

@@ -0,0 +1,64 @@
+---
+name: create-strs
+description: Create an ISO 29148 compliant Stakeholder Requirements Specification (StRS) through collaborative step-by-step discovery. Enterprise track workflow that transforms Product Brief into formal stakeholder requirements.
+track: enterprise
+---
+
+# Create StRS Workflow (ISO 29148 Clause 7)
+
+**Goal:** Create a comprehensive Stakeholder Requirements Specification (StRS) compliant with ISO/IEC/IEEE 29148:2018 Clause 7 through collaborative step-by-step discovery.
+
+**Your Role:** In addition to your name, communication_style, and persona, you are a Requirements Engineering specialist facilitating formal stakeholder requirements capture. This is a partnership - you bring ISO 29148 expertise and structured elicitation skills, while the user brings domain knowledge and stakeholder insights. Work together as equals.
+
+**Track:** This workflow is part of the **Enterprise** track. It produces the StRS document that bridges the Product Brief (business vision) and the PRD/SRS (software requirements).
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
+- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **LOAD NEXT**: When directed, read fully and follow the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🛑 **NEVER** load multiple step files simultaneously
+- 📖 **ALWAYS** read entire step file before execution
+- 🚫 **NEVER** skip steps or optimize the sequence
+- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+---
+
+## INITIALIZATION SEQUENCE
+
+### 1. Configuration Loading
+
+Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
+
+- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
+- `communication_language`, `document_output_language`, `user_skill_level`
+- `date` as system-generated current datetime
+
+✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
+
+### 2. First Step EXECUTION
+
+Read fully and follow: `{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-strs/steps/step-01-init.md` to begin the workflow.

src/bmm/workflows/3-solutioning/check-implementation-readiness/steps/step-01-document-discovery.md

@@ -81,6 +81,21 @@ Search for each document type using these patterns:
 - Whole: `{planning_artifacts}/*ux*.md`
 - Sharded: `{planning_artifacts}/*ux*/index.md` and related files
 
+#### E. Enterprise Track Documents (if applicable)
+
+Check the PRD frontmatter for `track: enterprise`. If Enterprise track:
+
+- **StRS:** `{planning_artifacts}/*strs*.md`
+- **SyRS:** `{planning_artifacts}/*syrs*.md`
+- **RTM:** `{planning_artifacts}/*rtm*.md`
+
+Flag missing Enterprise documents:
+```
+⚠️ ENTERPRISE TRACK: Required document not found
+- StRS/SyRS/RTM document not found
+- Enterprise track requires these for full readiness assessment
+```
+
 ### 3. Organize Findings
 
 For each document type found:

src/bmm/workflows/3-solutioning/check-implementation-readiness/steps/step-06-final-assessment.md

@@ -63,6 +63,48 @@ Check the {outputFile} for sections added by previous steps:
 - UX Alignment issues
 - Epic Quality violations
 
+### 2b. Enterprise Track Additional Checks (if applicable)
+
+If the project is Enterprise track (check PRD frontmatter for `track: enterprise`), perform these additional validations:
+
+**StRS Completeness:**
+- [ ] StRS document exists and follows ISO 29148 Clause 7 structure
+- [ ] All 7 major sections present (Introduction, References, Business Mgmt, Operational, User, System Concept, Constraints)
+- [ ] StRS status is at least 'review' (check frontmatter)
+
+**SyRS Completeness:**
+- [ ] SyRS document exists and follows ISO 29148 Clause 8 structure
+- [ ] System functional requirements mapped from PRD
+- [ ] System interfaces defined
+- [ ] Verification plan for each system requirement
+- [ ] SyRS status is at least 'review' (check frontmatter)
+
+**RTM Integrity:**
+- [ ] RTM document exists with bidirectional traceability
+- [ ] StRS → SyRS traceability present (forward coverage > 90%)
+- [ ] SyRS → PRD traceability present (forward coverage > 90%)
+- [ ] PRD → Stories traceability present (forward coverage > 95%)
+- [ ] No orphan requirements at any level
+- [ ] All requirement statuses documented
+
+**Verification Method Assignment:**
+- [ ] Every FR in PRD has a verification method assigned (Inspection / Analysis / Demonstration / Test)
+- [ ] Every SyRS requirement has a verification method assigned
+- [ ] Verification plan section exists in PRD
+
+**Cross-Document Consistency:**
+- [ ] StRS scope aligns with PRD scope
+- [ ] SyRS interfaces match Architecture interfaces
+- [ ] No terminology contradictions across documents
+- [ ] Requirement priorities consistent across levels
+
+**Baseline Status:**
+- [ ] All requirement documents have version numbers in frontmatter
+- [ ] Baseline version established (or ready to establish)
+- [ ] Change history documented in each requirement document
+
+Add Enterprise assessment findings to the report under a dedicated "Enterprise Track Assessment" section.
+
 ### 3. Add Final Assessment Section
 
 Append to {outputFile}:

src/bmm/workflows/3-solutioning/create-architecture/steps/step-08-complete.md

@@ -39,7 +39,20 @@ status: 'complete'
 completedAt: '{{current_date}}'
 ```
 
-### 3. Next Steps Guidance
+### 3. Enterprise Track: SyRS Creation Guidance
+
+If the project follows the **Enterprise** track (check PRD frontmatter for `track: enterprise`), inform the user:
+
+"**Enterprise Track Note:** Your Architecture Document serves as a key input for the System Requirements Specification (SyRS). The SyRS extends your architectural decisions with ISO 29148 compliant system-level requirements including:
+
+- System functional requirements derived from PRD FRs
+- System interface specifications from your architecture interfaces
+- Quality requirements (performance, security) with measurable targets
+- Verification plan for each system requirement
+
+**Recommended next step:** `create-syrs` (Create SyRS) to establish the system requirements baseline before proceeding to Epics & Stories."
+
+### 4. Next Steps Guidance
 
 Architecture complete. Read fully and follow: `_bmad/core/tasks/help.md` with argument `Create Architecture`.
 

src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-01-validate-prerequisites.md

@@ -91,6 +91,14 @@ Search for required documents using these patterns (sharded means a large docume
 1. `{planning_artifacts}/*ux*.md` (whole document)
 2. `{planning_artifacts}/*ux*/index.md` (sharded version)
 
+**Enterprise Track Documents (if PRD frontmatter has `track: enterprise`):**
+
+1. **StRS:** `{planning_artifacts}/*strs*.md` - For requirement source traceability
+2. **SyRS:** `{planning_artifacts}/*syrs*.md` - For system requirement references
+3. **RTM:** `{planning_artifacts}/*rtm*.md` - For existing traceability matrix
+
+If Enterprise track: these documents provide source requirement IDs that stories MUST reference.
+
 Before proceeding, Ask the user if there are any other documents to include for analysis, and if anything found should be excluded. Wait for user confirmation. Once confirmed, create the {outputFile} from the {epicsTemplate} and in the front matter list the files in the array of `inputDocuments: []`.
 
 ### 3. Extract Functional Requirements (FRs)

src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-03-create-stories.md

@@ -112,6 +112,20 @@ So that {value_benefit}.
 **And** {additional_criteria}
 ```
 
+**ENTERPRISE TRACK: REQUIREMENT TRACEABILITY**
+
+If the project is Enterprise track (check PRD frontmatter for `track: enterprise`), each story MUST include a **Requirements Traceability** section after Acceptance Criteria:
+
+```
+**Requirements Traceability:**
+- **PRD:** FR-AUTH-001, FR-AUTH-002
+- **SyRS:** SYS-FUNC-001
+- **StRS:** STK-BIZ-001
+- **Verification:** Test
+```
+
+This links each story back to its source requirements at all levels. The verification method indicates how this story's requirements will be validated (Inspection / Analysis / Demonstration / Test).
+
 **✅ GOOD STORY EXAMPLES:**
 
 _Epic 1: User Authentication_

src/bmm/workflows/3-solutioning/create-epics-and-stories/steps/step-04-final-validation.md

@@ -111,7 +111,27 @@ Review the complete epic and story breakdown to ensure EVERY FR is covered:
 - Foundation stories only setup what's needed
 - No big upfront technical work
 
-### 5. Dependency Validation (CRITICAL)
+### 5. Enterprise Track: Requirements Traceability Validation
+
+If the project is Enterprise track (check PRD frontmatter for `track: enterprise`):
+
+**Requirement ID Reference Check:**
+
+- [ ] Every story has a **Requirements Traceability** section
+- [ ] Every story references at least one PRD FR by ID
+- [ ] Every story references corresponding SyRS requirement ID (if SyRS exists)
+- [ ] Every story references originating StRS requirement ID (if StRS exists)
+- [ ] Every story specifies a verification method
+
+**RTM Forward Coverage Check:**
+
+- [ ] Every PRD FR is referenced by at least one story
+- [ ] No stories reference non-existent requirement IDs
+- [ ] FR Coverage Map is consistent with story requirement references
+
+If traceability gaps found, list them as Critical findings and require resolution before completion.
+
+### 6. Dependency Validation (CRITICAL)
 
 **Epic Independence Check:**
 
@@ -131,7 +151,7 @@ For each epic, review stories in order:
 - ❌ WRONG: Story references features not yet implemented
 - ✅ RIGHT: Each story builds only on previous stories
 
-### 6. Complete and Save
+### 7. Complete and Save
 
 If all validations pass:
 

src/bmm/workflows/3-solutioning/create-epics-and-stories/templates/epics-template.md

@@ -1,6 +1,7 @@
 ---
 stepsCompleted: []
 inputDocuments: []
+track: "{{bmad|enterprise}}"
 ---
 
 # {{project_name}} - Epic Breakdown
@@ -27,6 +28,10 @@ This document provides the complete epic and story breakdown for {{project_name}
 
 {{requirements_coverage_map}}
 
+<!-- Enterprise Track Only: Requirements Traceability Summary -->
+<!-- ### Requirements Traceability Summary -->
+<!-- {{requirements_traceability_summary}} -->
+
 ## Epic List
 
 {{epics_list}}
@@ -54,4 +59,11 @@ So that {{value_benefit}}.
 **Then** {{expected_outcome}}
 **And** {{additional_criteria}}
 
+<!-- Enterprise Track Only: Requirements Traceability per story -->
+<!-- **Requirements Traceability:** -->
+<!-- - **PRD:** {{prd_requirement_ids}} -->
+<!-- - **SyRS:** {{syrs_requirement_ids}} -->
+<!-- - **StRS:** {{strs_requirement_ids}} -->
+<!-- - **Verification:** {{verification_method}} -->
+
 <!-- End story repeat -->

src/bmm/workflows/3-solutioning/create-syrs/checklist.md

@@ -0,0 +1,173 @@
+# SyRS Workflow - ISO 29148 Clause 8 Validation Checklist
+
+## Document Structure Completeness
+
+- [ ] Section 1 (Introduction) includes system purpose, scope, and overview
+- [ ] Section 1 includes system context diagram or description
+- [ ] Section 1 includes system functions summary
+- [ ] Section 1 includes user characteristics
+- [ ] Section 1 includes definitions, acronyms, and abbreviations
+- [ ] Section 2 (References) lists all referenced documents including StRS, PRD, and standards
+- [ ] Section 3 (System Requirements) contains all requirement subsections
+- [ ] Section 4 (Verification) includes verification methods and summary table
+- [ ] Section 5 (Assumptions and Dependencies) is documented
+- [ ] Section 6 (Traceability) includes both StRS and PRD traceability matrices
+- [ ] Appendices include glossary and requirements index
+
+## Functional Requirements (Section 3.1)
+
+- [ ] All PRD functional requirements mapped to system-level functional requirements
+- [ ] Each requirement uses SYS-FUNC-### identifier format
+- [ ] Each requirement has priority attribute (Critical / High / Medium / Low)
+- [ ] Each requirement has source attribute referencing PRD FR
+- [ ] Each requirement has V&V method attribute (Inspection / Analysis / Demonstration / Test)
+- [ ] Requirements are atomic (one requirement per statement)
+- [ ] Requirements are verifiable (measurable or observable)
+- [ ] Requirements are unambiguous (single interpretation)
+- [ ] Requirements are consistent (no conflicts between requirements)
+- [ ] Requirements are traceable (clear source and rationale)
+
+## System Interfaces (Section 3.2)
+
+- [ ] User interfaces defined with technical specificity
+- [ ] Hardware interfaces defined (if applicable)
+- [ ] Software interfaces defined with protocols and data formats
+- [ ] Communication interfaces defined with protocols and standards
+- [ ] Each interface requirement uses SYS-IF-### identifier format
+- [ ] Interface requirements reference relevant standards
+
+## Performance Requirements (Section 3.3)
+
+- [ ] Response time targets specified with measurable values
+- [ ] Throughput requirements specified with measurable values
+- [ ] Capacity requirements specified with measurable values
+- [ ] Scalability targets defined
+- [ ] Each requirement uses SYS-PERF-### identifier format
+- [ ] All performance targets are measurable (specific numbers, not vague terms)
+
+## Usability Requirements (Section 3.4)
+
+- [ ] Ease of use requirements specified
+- [ ] Accessibility requirements specified (WCAG level if applicable)
+- [ ] Learnability requirements specified
+- [ ] Error handling and recovery from user perspective defined
+- [ ] Each requirement uses SYS-USAB-### identifier format
+
+## Security Requirements (Section 3.5)
+
+- [ ] Authentication requirements defined
+- [ ] Authorization requirements defined
+- [ ] Data protection requirements defined
+- [ ] Audit and logging requirements defined
+- [ ] Compliance requirements referenced (GDPR, HIPAA, etc. if applicable)
+- [ ] Each requirement uses SYS-SEC-### identifier format
+
+## Operational Requirements (Sections 3.6 - 3.9)
+
+- [ ] System operations documented (startup, shutdown, backup, recovery)
+- [ ] System modes defined (operational, degraded, maintenance, emergency)
+- [ ] State transitions documented with conditions
+- [ ] Physical characteristics specified (if applicable)
+- [ ] Environment conditions specified (operating environment, deployment targets)
+- [ ] Each requirement uses appropriate identifier format (SYS-OPS-###, SYS-MODE-###, etc.)
+
+## Constraints and Lifecycle (Sections 3.10 - 3.13)
+
+- [ ] Information management requirements defined (data retention, archival, disposal)
+- [ ] Policy and regulation requirements documented
+- [ ] System lifecycle sustainability addressed (maintenance, evolution, decommission)
+- [ ] Design constraints documented (technology, standards, organizational)
+- [ ] Each requirement uses appropriate identifier format
+
+## Verification Plan (Section 4)
+
+- [ ] Every system requirement has an assigned verification method
+- [ ] Verification methods are appropriate (Inspection / Analysis / Demonstration / Test)
+- [ ] Verification summary table is complete with all requirements listed
+- [ ] TEA module integration noted for Enterprise track
+- [ ] Verification responsibilities identified where applicable
+
+## Traceability (Section 6)
+
+- [ ] Every system requirement traces to at least one StRS requirement
+- [ ] Every system requirement traces to at least one PRD requirement
+- [ ] Traceability to StRS is documented in matrix format
+- [ ] Traceability to PRD is documented in matrix format
+- [ ] No orphan requirements (requirements without source)
+- [ ] No gaps in coverage (all StRS/PRD requirements addressed)
+
+## Requirement Quality Criteria (per requirement)
+
+For each requirement, verify these 9 quality criteria:
+
+1. [ ] **Necessary** - The requirement is essential for system success
+2. [ ] **Appropriate** - The requirement is at the correct level of abstraction (system level)
+3. [ ] **Unambiguous** - The requirement has only one interpretation
+4. [ ] **Complete** - The requirement is fully stated with all necessary information
+5. [ ] **Singular** - The requirement addresses one thing only (atomic)
+6. [ ] **Feasible** - The requirement is technically achievable
+7. [ ] **Verifiable** - The requirement can be verified by Inspection, Analysis, Demonstration, or Test
+8. [ ] **Correct** - The requirement accurately represents the stakeholder need
+9. [ ] **Conforming** - The requirement conforms to the SyRS template and ISO 29148 standard
+
+## Cross-Section Consistency
+
+- [ ] No conflicting requirements between sections
+- [ ] Terminology is consistent throughout the document
+- [ ] Identifier numbering is sequential and gap-free
+- [ ] All cross-references between sections are valid
+- [ ] Performance requirements align with functional requirements
+- [ ] Security requirements align with interface requirements
+- [ ] Operational requirements align with system modes and states
+
+## Assumptions and Dependencies
+
+- [ ] All assumptions are explicitly stated
+- [ ] Dependencies on external systems documented
+- [ ] Dependencies on other project artifacts documented
+- [ ] Risk implications of assumptions noted
+
+## Glossary
+
+- [ ] All technical terms defined
+- [ ] All acronyms expanded
+- [ ] All domain-specific terms explained
+- [ ] Definitions are consistent with ISO 29148 terminology
+
+## Issues Found
+
+### Critical Issues (must fix before approval)
+
+-
+
+### Minor Issues (can be addressed in next baseline)
+
+-
+
+### Missing Information (to note for user)
+
+-
+
+## Completion Criteria
+
+All items in the following sections must be checked:
+
+- Document Structure Completeness
+- Functional Requirements
+- System Interfaces
+- Performance Requirements
+- Security Requirements
+- Operational Requirements
+- Constraints and Lifecycle
+- Verification Plan
+- Traceability
+- Cross-Section Consistency
+
+The SyRS is complete when:
+
+1. All critical checklist items are satisfied
+2. No critical issues remain
+3. Every requirement passes the 9 quality criteria
+4. Full traceability to StRS and PRD is established
+5. Every requirement has an assigned verification method
+6. User has reviewed and approved the specification

src/bmm/workflows/3-solutioning/create-syrs/steps/step-01-init.md

@@ -0,0 +1,207 @@
+---
+name: 'step-01-init'
+description: 'Initialize SyRS workflow, discover and load required input documents (StRS, PRD, Architecture), create output file from template'
+
+# Path Definitions
+workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs'
+
+# File References
+thisStepFile: './step-01-init.md'
+nextStepFile: './step-02-system-context.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{planning_artifacts}/syrs-{{project_name}}.md'
+syrsTemplate: '{workflow_path}/templates/syrs-template.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 1: SyRS Workflow Initialization
+
+## STEP GOAL:
+
+Initialize the System Requirements Specification workflow by discovering and loading all required input documents, validating prerequisites, and creating the output document from the SyRS template.
+
+## 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 entire file is read
+- 📋 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 System Architecture and Requirements Engineering specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring ISO 29148 compliance expertise and system-level requirements engineering
+- ✅ User brings domain expertise, stakeholder context, and system knowledge
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on initialization and document discovery
+- 🚫 FORBIDDEN to start writing requirements content in this step
+- 💬 Discover and validate input documents
+- 🚪 DETECT existing workflow state and handle continuation properly
+- ⚠️ StRS and PRD are REQUIRED inputs - warn prominently if missing
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- 💾 Initialize document and update frontmatter
+- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
+- 🚫 FORBIDDEN to load next step until setup is complete
+
+## CONTEXT BOUNDARIES:
+
+- Variables from workflow.md are available in memory
+- Previous context = what's in output document + frontmatter
+- Don't assume knowledge from other steps
+- Input document discovery happens in this step
+
+## INITIALIZATION SEQUENCE:
+
+### 1. Check for Existing Workflow
+
+First, check if the output document already exists:
+
+- Look for existing `{planning_artifacts}/*syrs*.md`
+- If exists, read the complete file(s) including frontmatter
+- If the document exists and has frontmatter with `stepsCompleted`:
+  - Determine the last completed step
+  - Report current state to user
+  - Ask if they want to resume from where they left off or restart
+  - If resume: Load the appropriate step file based on last completed step
+  - If restart: Continue with fresh workflow setup below
+- If not exists, this is a fresh workflow
+
+### 2. Fresh Workflow Setup (If No Document)
+
+If no document exists or user chose to restart:
+
+#### A. Input Document Discovery
+
+Discover and load context documents using smart discovery. Documents can be in the following locations:
+- {planning_artifacts}/**
+- {output_folder}/**
+- {product_knowledge}/**
+- docs/**
+
+Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files. For example, if searching for `*foo*.md` and not found, also search for a folder called *foo*/index.md (which indicates sharded content).
+
+Try to discover the following:
+
+**REQUIRED Documents:**
+- Stakeholder Requirements Specification (`*strs*.md` or `*stakeholder-req*.md` or `*stakeholder*.md`)
+- Product Requirements Document (`*prd*.md`)
+
+**RECOMMENDED Documents:**
+- Architecture Document (`*architecture*.md`)
+- Product Brief (`*brief*.md`)
+- UX Design (`*ux-design*.md`)
+- Research Documents (`*research*.md`)
+- Project Context (`**/project-context.md`)
+
+<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. Only after this confirmation will you proceed to follow the loading rules.</critical>
+
+**Loading Rules:**
+
+- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
+- For sharded folders, load ALL files to get complete picture, using the index first to potentially know the potential of each document
+- index.md is a guide to what's relevant whenever available
+- Track all successfully loaded files in frontmatter `inputDocuments` array
+
+#### B. Validate Required Inputs
+
+Before proceeding, verify we have the essential inputs:
+
+**StRS Validation (REQUIRED):**
+
+- If no StRS found: "⚠️ WARNING: The StRS (Stakeholder Requirements Specification) was not found. The SyRS derives system requirements from stakeholder requirements. Without StRS, traceability to stakeholder needs will be incomplete. You can still proceed, but traceability gaps will be noted throughout."
+- Strongly recommend running StRS workflow first or providing the StRS file path
+
+**PRD Validation (REQUIRED):**
+
+- If no PRD found: "⚠️ WARNING: The PRD (Product Requirements Document) was not found. The SyRS transforms PRD functional requirements into system-level requirements. Without PRD, the functional requirements section will lack source material."
+- Strongly recommend running PRD workflow first or providing the PRD file path
+
+**Architecture Document (RECOMMENDED):**
+
+- If found: "Architecture document informs system constraints and interface decisions but does not replace the SyRS. I will reference it for technical context."
+- If not found: "Architecture document not found. System interface and constraint sections will rely on collaborative discovery with you."
+
+**CRITICAL:** If BOTH StRS and PRD are missing, strongly advise the user to create them first. Allow proceeding only with explicit user acknowledgment of traceability gaps.
+
+#### C. Create Initial Document
+
+Copy the template from `{syrsTemplate}` to `{outputFile}`:
+
+1. Load the SyRS template
+2. Create the output file at `{planning_artifacts}/syrs-{{project_name}}.md`
+3. Replace `{{project_name}}` with the actual project name
+4. Replace `{{user_name}}` with the config user_name
+5. Replace `{{date}}` with the current date
+6. Initialize frontmatter with workflow state and inputDocuments array
+
+#### D. Complete Initialization and Report
+
+Complete setup and report to user:
+
+**Document Setup:**
+
+- Created: `{planning_artifacts}/syrs-{{project_name}}.md` from SyRS template
+- Initialized frontmatter with workflow state
+
+**Report:**
+"Welcome {{user_name}}! I've set up your System Requirements Specification workspace for {{project_name}}.
+
+**ISO 29148 Clause 8 Compliance:** This workflow will guide you through creating a fully compliant SyRS with sections covering system context, functional requirements, interfaces, performance, security, operations, lifecycle, and verification.
+
+**Documents Found:**
+
+- StRS: {status - loaded or "Not found - RECOMMENDED"}
+- PRD: {status - loaded or "Not found - RECOMMENDED"}
+- Architecture: {status - loaded or "Not found - optional"}
+- Other documents: {list of additional files loaded or "None found"}
+
+**Files loaded:** {list of specific file names}
+
+**Track:** Enterprise - includes full verification planning and TEA module integration
+
+Ready to begin system requirements engineering. Do you have any other documents you'd like me to include?
+
+[C] Continue to system context definition"
+
+## SUCCESS METRICS:
+
+✅ Existing workflow detected and resume/restart offered correctly
+✅ Fresh workflow initialized with SyRS template and frontmatter
+✅ Input documents discovered and loaded using sharded-first logic
+✅ All discovered files tracked in frontmatter `inputDocuments`
+✅ StRS and PRD requirement validated and clearly communicated
+✅ Architecture document relationship to SyRS explained
+✅ User confirmed document setup and can proceed
+
+## FAILURE MODES:
+
+❌ Proceeding with fresh initialization when existing workflow exists
+❌ Not warning about missing StRS or PRD
+❌ Not updating frontmatter with discovered input documents
+❌ Creating document without proper template
+❌ Not checking sharded folders first before whole files
+❌ Not reporting what documents were found to user
+❌ Proceeding without validating required document status
+
+❌ **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
+
+## NEXT STEP:
+
+After user selects [C] to continue, only after ensuring all the template output has been created and frontmatter updated with `stepsCompleted: [1]`, then load `./step-02-system-context.md` to define the system context and introduction.
+
+Remember: Do NOT proceed to step-02 until user explicitly selects [C] and setup is confirmed!

src/bmm/workflows/3-solutioning/create-syrs/steps/step-02-system-context.md

@@ -0,0 +1,276 @@
+---
+name: 'step-02-system-context'
+description: 'Define system purpose, scope, overview, boundaries, stakeholders, and references for SyRS Sections 1 and 2'
+
+# Path Definitions
+workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs'
+
+# File References
+thisStepFile: './step-02-system-context.md'
+nextStepFile: './step-03-functional-requirements.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{planning_artifacts}/syrs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 2: System Context
+
+## STEP GOAL:
+
+Define the system purpose, scope, overview, boundaries, stakeholders, and references. This step populates ISO 29148 Clause 8 Sections 1 (Introduction) and 2 (References) of the SyRS.
+
+## 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 entire file is read
+- 📋 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 System Architecture and Requirements Engineering specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring ISO 29148 system context framing expertise
+- ✅ User brings domain expertise and system knowledge
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on system context, scope, and introduction content
+- 🚫 FORBIDDEN to start writing system requirements in this step
+- 💬 Frame the system from a system engineering perspective, not product perspective
+- 🚪 Differentiate between product-level context (PRD) and system-level context (SyRS)
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating system context content
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to develop deeper insights about system boundaries and context
+- **P (Party Mode)**: Bring multiple perspectives to analyze system context from different engineering angles
+- **C (Continue)**: Save the content to the document and proceed to next step
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Read fully and follow: {advancedElicitationTask}
+- When 'P' selected: Read fully and follow: {partyModeWorkflow}
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Current document and frontmatter from step 1 are available
+- Input documents already loaded are in memory (StRS, PRD, Architecture, etc.)
+- Focus on system-level context framing
+- No requirements writing yet - pure system context definition
+
+## SYSTEM CONTEXT ANALYSIS SEQUENCE:
+
+### 1. Analyze Input Documents for System Context
+
+**From StRS (if available):**
+
+- Extract the overall system purpose from stakeholder perspective
+- Identify system boundaries as defined by stakeholders
+- Note stakeholder-identified constraints and operational environment
+- Extract stakeholder groups and their relationship to the system
+
+**From PRD (if available):**
+
+- Extract product scope and map to system scope
+- Identify system functions from product features
+- Extract user types and characteristics
+- Note any product-level assumptions that become system constraints
+
+**From Architecture (if available):**
+
+- Extract system boundary definitions
+- Note external system interfaces
+- Identify deployment environment characteristics
+- Reference architectural decisions that constrain the system
+
+### 2. Define System Purpose (Section 1.1)
+
+Collaborate with user to define:
+
+- Why the system exists (its reason for being)
+- What problem it solves at the system level
+- How it relates to the broader organizational or business context
+- The system's role within any larger system-of-systems
+
+### 3. Define System Scope (Section 1.2)
+
+Collaborate with user to define:
+
+- What is IN scope for this system
+- What is explicitly OUT of scope
+- System boundaries (what the system includes vs. external entities)
+- The system's relationship to adjacent systems
+
+### 4. Define System Overview (Section 1.3)
+
+#### System Context (1.3.1):
+
+- Describe the system's operating environment
+- Identify external entities the system interacts with
+- Define the system boundary clearly
+- Present a textual system context description (or suggest diagram contents)
+
+#### System Functions (1.3.2):
+
+- List the high-level system functions derived from PRD features
+- Group functions logically
+- Note which functions are primary vs. supporting
+- Map functions to stakeholder needs from StRS
+
+#### User Characteristics (1.3.3):
+
+- Define user types from a system perspective
+- Characterize user expertise levels
+- Note user access patterns and frequency
+- Define any user role hierarchies
+
+### 5. Define Glossary (Section 1.4)
+
+- Extract domain-specific terms from input documents
+- Define ISO 29148 terminology used in the document
+- Add system-specific acronyms and abbreviations
+- Ensure alignment with StRS and PRD glossaries
+
+### 6. Compile References (Section 2)
+
+Create the references section listing:
+
+- ISO/IEC/IEEE 29148:2018 - Systems and software engineering - Life cycle processes - Requirements engineering
+- StRS document (if available, with version/date)
+- PRD document (if available, with version/date)
+- Architecture document (if available, with version/date)
+- Any other standards, regulations, or documents referenced
+- Organizational standards or policies that apply
+
+### 7. Generate System Context Content
+
+Prepare the content to replace placeholders in Sections 1 and 2:
+
+#### Content Structure:
+
+```markdown
+## 1. Introduction
+
+### 1.1 System Purpose
+
+{{system_purpose_content}}
+
+### 1.2 System Scope
+
+{{system_scope_content}}
+
+### 1.3 System Overview
+
+#### 1.3.1 System Context
+
+{{system_context_content}}
+
+#### 1.3.2 System Functions
+
+{{system_functions_content}}
+
+#### 1.3.3 User Characteristics
+
+{{user_characteristics_content}}
+
+### 1.4 Definitions, Acronyms, and Abbreviations
+
+{{glossary_content}}
+
+## 2. References
+
+{{references_content}}
+```
+
+### 8. Present Content and Menu
+
+Show the generated content and present choices:
+
+"I've drafted the System Context and Introduction sections based on your input documents and our discussion.
+
+**Here's what I'll add to the SyRS document (Sections 1 and 2):**
+
+[Show the complete markdown content from step 7]
+
+**What would you like to do?**
+[A] Advanced Elicitation - Dive deeper into system boundary definition and context
+[P] Party Mode - Analyze system context from different engineering perspectives
+[C] Continue - Save this content and proceed to functional requirements"
+
+### 9. Handle Menu Selection
+
+#### If 'A' (Advanced Elicitation):
+
+- Read fully and follow: {advancedElicitationTask} with the current system context analysis
+- Process enhanced insights about system boundaries and context
+- Ask user: "Accept these enhancements to the system context? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'P' (Party Mode):
+
+- Read fully and follow: {partyModeWorkflow} with the current system context
+- Process collaborative improvements to system understanding
+- Ask user: "Accept these changes to the system context? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'C' (Continue):
+
+- Write the final content to Sections 1 and 2 in `{outputFile}`
+- Update frontmatter: `stepsCompleted: [1, 2]`
+- Load `{nextStepFile}`
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', replace the placeholder content in Sections 1 and 2 of the output document with the finalized content.
+
+## SUCCESS METRICS:
+
+✅ System purpose clearly defined from system engineering perspective
+✅ System scope and boundaries explicitly stated
+✅ System context described with external entities identified
+✅ System functions mapped from PRD features
+✅ User characteristics defined at system level
+✅ Glossary initiated with domain and standard terms
+✅ References section complete with all applicable documents and standards
+✅ A/P/C menu presented and handled correctly
+✅ Content properly written to document when C selected
+
+## FAILURE MODES:
+
+❌ Confusing product-level context with system-level context
+❌ Not defining system boundaries explicitly
+❌ Missing external entities in system context
+❌ Not referencing ISO 29148 in the references section
+❌ Skipping glossary initialization
+❌ Not presenting A/P/C menu after content generation
+
+❌ **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
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved to document, load `./step-03-functional-requirements.md` to begin defining system functional requirements.
+
+Remember: Do NOT proceed to step-03 until user explicitly selects 'C' from the A/P/C menu and content is saved!

src/bmm/workflows/3-solutioning/create-syrs/steps/step-03-functional-requirements.md

@@ -0,0 +1,282 @@
+---
+name: 'step-03-functional-requirements'
+description: 'Transform PRD functional requirements into system-level functional requirements with Enterprise attributes for SyRS Section 3.1'
+
+# Path Definitions
+workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs'
+
+# File References
+thisStepFile: './step-03-functional-requirements.md'
+nextStepFile: './step-04-interface-requirements.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{planning_artifacts}/syrs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 3: System Functional Requirements
+
+## STEP GOAL:
+
+Transform PRD functional requirements into system-level functional requirements. Map each PRD FR to system functions using the SYS-FUNC-### identifier format with Enterprise attributes (priority, source, V&V method). This step populates ISO 29148 Clause 8 Section 3.1 (Functional Requirements).
+
+## 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 entire file is read
+- 📋 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 System Architecture and Requirements Engineering specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring requirements transformation and decomposition expertise
+- ✅ User brings domain knowledge and priority decisions
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on functional requirements (Section 3.1)
+- 🚫 FORBIDDEN to write interface, performance, or other requirement types in this step
+- 💬 Transform PRD FRs to system-level - do NOT copy them verbatim
+- 🚪 Every system requirement MUST trace back to at least one PRD FR
+- 📐 Each requirement must be atomic, verifiable, and unambiguous
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating functional requirements content
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to uncover hidden functional requirements or refine transformations
+- **P (Party Mode)**: Bring multiple perspectives to evaluate requirement completeness and quality
+- **C (Continue)**: Save the content to the document and proceed to next step
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Read fully and follow: {advancedElicitationTask}
+- When 'P' selected: Read fully and follow: {partyModeWorkflow}
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Current document with Sections 1 and 2 completed from step 2
+- Input documents already loaded are in memory (StRS, PRD, Architecture)
+- Focus on system-level functional requirement engineering
+- Use system functions identified in Section 1.3.2 as a framework
+
+## FUNCTIONAL REQUIREMENTS ENGINEERING SEQUENCE:
+
+### 1. Extract PRD Functional Requirements
+
+From the loaded PRD document, systematically extract ALL functional requirements:
+
+**Extraction Method:**
+
+- Look for numbered items like "FR1:", "Functional Requirement 1:", or similar
+- Identify requirement statements that describe what the system must DO
+- Include user actions, system behaviors, and business rules
+- Count total PRD FRs extracted
+
+Present to user:
+"I've identified {{fr_count}} functional requirements from the PRD. Let me show you how I plan to transform these into system-level requirements."
+
+### 2. Explain Transformation Approach
+
+Explain the PRD-to-System requirement transformation:
+
+"**PRD-to-SyRS Transformation:**
+
+PRD requirements describe what the PRODUCT should do from a user/business perspective.
+System requirements describe what the SYSTEM must do from an engineering perspective.
+
+**Example Transformation:**
+- PRD FR: 'Users shall be able to search for products by name, category, or price range'
+- System Requirements:
+  - SYS-FUNC-001: The system shall accept search queries containing text strings up to 256 characters
+  - SYS-FUNC-002: The system shall support search filtering by product category from the defined category taxonomy
+  - SYS-FUNC-003: The system shall support search filtering by price range with minimum and maximum values
+  - SYS-FUNC-004: The system shall return search results within the response time defined in SYS-PERF-001
+
+Note: One PRD FR may produce multiple system requirements, and multiple PRD FRs may contribute to a single system function."
+
+### 3. Transform Requirements by System Function Group
+
+Organize system functional requirements by the system functions identified in Section 1.3.2:
+
+For each system function group:
+
+**Format each requirement as:**
+
+```markdown
+**SYS-FUNC-###:** [Requirement statement - atomic, verifiable, unambiguous]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD FR reference(s), e.g., "PRD-FR-001, PRD-FR-003"] |
+| V&V Method | [Inspection / Analysis / Demonstration / Test] |
+| Rationale | [Brief justification for this system requirement] |
+```
+
+**Requirement Quality Rules:**
+
+- **Atomic**: Each requirement addresses exactly one capability
+- **Verifiable**: Must be testable or inspectable with clear pass/fail criteria
+- **Unambiguous**: Only one possible interpretation
+- **System-Level**: Expressed in terms of what the SYSTEM does, not the user experience
+- **Shall Statements**: Use "The system shall..." phrasing consistently
+
+### 4. Map StRS Traceability
+
+If StRS is available, also note which StRS requirements each system requirement supports:
+
+- Add StRS reference to the Source attribute where applicable
+- Note any StRS requirements that don't yet have system-level coverage
+- Flag gaps for discussion with user
+
+### 5. Completeness Check
+
+After transforming all requirements, verify:
+
+- Every PRD FR has at least one corresponding SYS-FUNC requirement
+- No PRD FR was overlooked or dropped
+- System functions from Section 1.3.2 all have corresponding requirements
+- Present a coverage summary:
+
+```
+**PRD FR Coverage Summary:**
+- PRD FRs extracted: {{count}}
+- System functional requirements created: {{count}}
+- PRD FRs fully covered: {{count}}
+- PRD FRs partially covered: {{count}} (list them)
+- PRD FRs not covered: {{count}} (list them - REQUIRES ATTENTION)
+```
+
+### 6. Generate Functional Requirements Content
+
+Prepare the content to replace the Section 3.1 placeholder:
+
+#### Content Structure:
+
+```markdown
+### 3.1 Functional Requirements
+
+#### 3.1.1 [System Function Group 1 Name]
+
+**SYS-FUNC-001:** [Requirement statement]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [value] |
+| Source | [PRD FR ref] |
+| V&V Method | [method] |
+| Rationale | [justification] |
+
+**SYS-FUNC-002:** [Requirement statement]
+...
+
+#### 3.1.2 [System Function Group 2 Name]
+...
+
+#### PRD FR Coverage Map
+
+| PRD FR | System Requirements | Coverage Status |
+|--------|-------------------|-----------------|
+| PRD-FR-001 | SYS-FUNC-001, SYS-FUNC-002 | Full |
+| PRD-FR-002 | SYS-FUNC-003 | Full |
+...
+```
+
+### 7. Present Content and Menu
+
+Show the generated content and present choices:
+
+"I've transformed the PRD functional requirements into {{sys_func_count}} system-level functional requirements organized by system function groups.
+
+**Coverage Summary:**
+- {{prd_fr_count}} PRD FRs mapped to {{sys_func_count}} system requirements
+- Coverage: {{coverage_percentage}}%
+
+**Here's what I'll add to the SyRS document (Section 3.1):**
+
+[Show the complete markdown content from step 6]
+
+**What would you like to do?**
+[A] Advanced Elicitation - Uncover hidden requirements or refine transformations
+[P] Party Mode - Evaluate requirement quality from different perspectives
+[C] Continue - Save these requirements and proceed to interface requirements"
+
+### 8. Handle Menu Selection
+
+#### If 'A' (Advanced Elicitation):
+
+- Read fully and follow: {advancedElicitationTask} with the current functional requirements
+- Process enhanced insights about missing or refined requirements
+- Ask user: "Accept these enhancements to the functional requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'P' (Party Mode):
+
+- Read fully and follow: {partyModeWorkflow} with the current functional requirements
+- Process collaborative improvements to requirement quality
+- Ask user: "Accept these changes to the functional requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'C' (Continue):
+
+- Write the final content to Section 3.1 in `{outputFile}`
+- Update frontmatter: `stepsCompleted: [1, 2, 3]`
+- Load `{nextStepFile}`
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', replace the `{{functional_requirements}}` placeholder in Section 3.1 of the output document with the finalized content.
+
+## SUCCESS METRICS:
+
+✅ All PRD functional requirements extracted and counted
+✅ PRD FRs transformed to system-level requirements (not copied verbatim)
+✅ Each requirement uses SYS-FUNC-### identifier format
+✅ Each requirement has Enterprise attributes (priority, source, V&V method, rationale)
+✅ Each requirement is atomic, verifiable, and unambiguous
+✅ PRD FR coverage map complete with no unexplained gaps
+✅ Requirements organized by system function groups
+✅ StRS traceability noted where applicable
+✅ A/P/C menu presented and handled correctly
+✅ Content properly written to document when C selected
+
+## FAILURE MODES:
+
+❌ Copying PRD FRs verbatim instead of transforming to system level
+❌ Missing PRD FRs in the coverage map
+❌ Creating non-atomic requirements (multiple capabilities in one statement)
+❌ Using vague or non-verifiable language
+❌ Missing Enterprise attributes on any requirement
+❌ Not organizing by system function groups
+❌ Not presenting A/P/C menu after content generation
+
+❌ **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
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved to document, load `./step-04-interface-requirements.md` to define system interface requirements.
+
+Remember: Do NOT proceed to step-04 until user explicitly selects 'C' from the A/P/C menu and content is saved!

src/bmm/workflows/3-solutioning/create-syrs/steps/step-04-interface-requirements.md

@@ -0,0 +1,334 @@
+---
+name: 'step-04-interface-requirements'
+description: 'Define system interface requirements (user, hardware, software, communication) for SyRS Section 3.2'
+
+# Path Definitions
+workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs'
+
+# File References
+thisStepFile: './step-04-interface-requirements.md'
+nextStepFile: './step-05-quality-requirements.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{planning_artifacts}/syrs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 4: System Interface Requirements
+
+## STEP GOAL:
+
+Define all system interface requirements covering user interfaces, hardware interfaces, software interfaces, and communication interfaces. These are more technically focused than PRD interfaces - centered on system integration and interoperability. This step populates ISO 29148 Clause 8 Section 3.2 (System Interfaces).
+
+## 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 entire file is read
+- 📋 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 System Architecture and Requirements Engineering specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring system integration and interface engineering expertise
+- ✅ User brings knowledge of external systems and integration needs
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on interface requirements (Section 3.2)
+- 🚫 FORBIDDEN to write performance, security, or operational requirements in this step
+- 💬 Define interfaces at the SYSTEM integration level, not product feature level
+- 🚪 Reference the system context and external entities from Section 1.3.1
+- 📐 Each interface requirement must specify protocols, data formats, and standards where applicable
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating interface requirements content
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to uncover hidden interface requirements or integration complexities
+- **P (Party Mode)**: Bring multiple perspectives to evaluate interface completeness (security, ops, dev)
+- **C (Continue)**: Save the content to the document and proceed to next step
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Read fully and follow: {advancedElicitationTask}
+- When 'P' selected: Read fully and follow: {partyModeWorkflow}
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Current document with Sections 1, 2, and 3.1 completed
+- System context and external entities defined in Section 1.3.1
+- Functional requirements from Section 3.1 inform interface needs
+- Architecture document (if loaded) provides technical interface details
+- Focus on system-to-system and system-to-user integration points
+
+## INTERFACE REQUIREMENTS ENGINEERING SEQUENCE:
+
+### 1. Identify Interface Points
+
+Using the system context from Section 1.3.1 and the functional requirements from Section 3.1, identify all interface points:
+
+**Interface Discovery Sources:**
+
+- External entities identified in system context diagram/description
+- System functions that require external communication
+- Architecture document interface decisions (if available)
+- PRD interface requirements (if any)
+- StRS interface expectations (if available)
+
+Present to user:
+"Based on the system context and functional requirements, I've identified the following interface categories. Let me walk through each one."
+
+### 2. User Interfaces (Section 3.2.1)
+
+Define system-level user interface requirements:
+
+**NOTE:** These are NOT UI design requirements (that's UX). These are system requirements about HOW the system presents information to and accepts input from users.
+
+For each user interface requirement:
+
+```markdown
+**SYS-IF-###:** [Requirement statement about user interface capability]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD FR ref or StRS ref] |
+| V&V Method | [Inspection / Analysis / Demonstration / Test] |
+| Interface Type | User Interface |
+| Standards | [Applicable standards, e.g., WCAG 2.1 AA] |
+```
+
+**Consider:**
+- Input methods and modalities the system must support
+- Output formats and presentation methods the system must provide
+- Accessibility requirements at system level
+- Localization/internationalization requirements
+- Error communication mechanisms
+
+### 3. Hardware Interfaces (Section 3.2.2)
+
+Define system-level hardware interface requirements:
+
+For each hardware interface requirement:
+
+```markdown
+**SYS-IF-###:** [Requirement statement about hardware interface]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD FR ref or StRS ref] |
+| V&V Method | [Inspection / Analysis / Demonstration / Test] |
+| Interface Type | Hardware Interface |
+| Protocol | [Applicable protocol or standard] |
+```
+
+**Consider:**
+- Physical device connections
+- Sensor interfaces
+- Display or output device requirements
+- Storage device interfaces
+- Network hardware requirements
+- If not applicable, explicitly state: "No hardware interface requirements identified for this system."
+
+### 4. Software Interfaces (Section 3.2.3)
+
+Define system-level software interface requirements:
+
+For each software interface requirement:
+
+```markdown
+**SYS-IF-###:** [Requirement statement about software interface]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD FR ref or StRS ref] |
+| V&V Method | [Inspection / Analysis / Demonstration / Test] |
+| Interface Type | Software Interface |
+| Protocol | [API protocol, e.g., REST, GraphQL, gRPC] |
+| Data Format | [e.g., JSON, XML, Protocol Buffers] |
+| External System | [Name of external system or service] |
+```
+
+**Consider:**
+- Third-party API integrations
+- Database interfaces
+- Operating system interfaces
+- Authentication/authorization service interfaces (OAuth, SAML, etc.)
+- Cloud service interfaces (storage, compute, messaging)
+- Monitoring and logging system interfaces
+- CI/CD pipeline interfaces
+
+### 5. Communication Interfaces (Section 3.2.4)
+
+Define system-level communication interface requirements:
+
+For each communication interface requirement:
+
+```markdown
+**SYS-IF-###:** [Requirement statement about communication interface]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD FR ref or StRS ref] |
+| V&V Method | [Inspection / Analysis / Demonstration / Test] |
+| Interface Type | Communication Interface |
+| Protocol | [e.g., HTTPS, WebSocket, MQTT, AMQP] |
+| Standard | [Applicable communication standard] |
+```
+
+**Consider:**
+- Network protocols required
+- Real-time communication requirements
+- Message queue/event bus interfaces
+- Email/notification interfaces
+- File transfer protocols
+- Encryption and secure communication requirements
+
+### 6. Interface Consistency Check
+
+Verify interface requirements are consistent with:
+
+- Functional requirements in Section 3.1 (every function that communicates externally has an interface requirement)
+- System context entities from Section 1.3.1 (every external entity has interface requirements)
+- Architecture document interface decisions (if available)
+
+Present summary:
+```
+**Interface Requirements Summary:**
+- User Interfaces: {{count}} requirements
+- Hardware Interfaces: {{count}} requirements (or N/A)
+- Software Interfaces: {{count}} requirements
+- Communication Interfaces: {{count}} requirements
+- Total: {{total_count}} interface requirements
+
+**Coverage Check:**
+- External entities with interface requirements: {{covered}}/{{total_entities}}
+- Uncovered entities: {{list or "None"}}
+```
+
+### 7. Generate Interface Requirements Content
+
+Prepare the content to replace the Section 3.2 placeholders:
+
+#### Content Structure:
+
+```markdown
+### 3.2 System Interfaces
+
+#### 3.2.1 User Interfaces
+
+[User interface requirements with SYS-IF-### format and attribute tables]
+
+#### 3.2.2 Hardware Interfaces
+
+[Hardware interface requirements or "No hardware interface requirements identified for this system."]
+
+#### 3.2.3 Software Interfaces
+
+[Software interface requirements with protocols and data formats]
+
+#### 3.2.4 Communication Interfaces
+
+[Communication interface requirements with protocols and standards]
+```
+
+### 8. Present Content and Menu
+
+Show the generated content and present choices:
+
+"I've defined {{total_if_count}} system interface requirements covering all identified integration points.
+
+**Interface Summary:**
+- User Interfaces: {{ui_count}} requirements
+- Hardware Interfaces: {{hw_count}} requirements
+- Software Interfaces: {{sw_count}} requirements
+- Communication Interfaces: {{comm_count}} requirements
+
+**Here's what I'll add to the SyRS document (Section 3.2):**
+
+[Show the complete markdown content from step 7]
+
+**What would you like to do?**
+[A] Advanced Elicitation - Explore hidden interface complexities or integration challenges
+[P] Party Mode - Evaluate interfaces from security, operations, and development perspectives
+[C] Continue - Save these interface requirements and proceed to quality requirements"
+
+### 9. Handle Menu Selection
+
+#### If 'A' (Advanced Elicitation):
+
+- Read fully and follow: {advancedElicitationTask} with the current interface requirements
+- Process enhanced insights about interface complexities
+- Ask user: "Accept these enhancements to the interface requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'P' (Party Mode):
+
+- Read fully and follow: {partyModeWorkflow} with the current interface requirements
+- Process collaborative improvements to interface coverage
+- Ask user: "Accept these changes to the interface requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'C' (Continue):
+
+- Write the final content to Section 3.2 in `{outputFile}`
+- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
+- Load `{nextStepFile}`
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', replace the interface placeholder sections (3.2.1 through 3.2.4) in the output document with the finalized content.
+
+## SUCCESS METRICS:
+
+✅ All external entities from system context have interface requirements
+✅ Interface requirements organized by type (user, hardware, software, communication)
+✅ Each requirement uses SYS-IF-### identifier format
+✅ Each requirement has Enterprise attributes (priority, source, V&V method)
+✅ Protocols and data formats specified for software/communication interfaces
+✅ Standards referenced where applicable
+✅ Consistency with functional requirements verified
+✅ A/P/C menu presented and handled correctly
+✅ Content properly written to document when C selected
+
+## FAILURE MODES:
+
+❌ Confusing UI design requirements with system-level user interface requirements
+❌ Missing interfaces for external entities identified in system context
+❌ Not specifying protocols and data formats
+❌ Missing Enterprise attributes on any requirement
+❌ Not checking consistency with functional requirements
+❌ Not presenting A/P/C menu after content generation
+
+❌ **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
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved to document, load `./step-05-quality-requirements.md` to define quality and performance requirements.
+
+Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!

src/bmm/workflows/3-solutioning/create-syrs/steps/step-05-quality-requirements.md

@@ -0,0 +1,307 @@
+---
+name: 'step-05-quality-requirements'
+description: 'Define performance, usability, and security requirements with measurable targets for SyRS Sections 3.3-3.5'
+
+# Path Definitions
+workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs'
+
+# File References
+thisStepFile: './step-05-quality-requirements.md'
+nextStepFile: './step-06-operational-requirements.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{planning_artifacts}/syrs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 5: Quality & Performance Requirements
+
+## STEP GOAL:
+
+Define performance requirements with measurable targets, usability requirements, and security requirements at the system level. All quality requirements must have quantifiable acceptance criteria. This step populates ISO 29148 Clause 8 Sections 3.3 (Performance), 3.4 (Usability), and 3.5 (Security).
+
+## 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 entire file is read
+- 📋 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 System Architecture and Requirements Engineering specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring performance engineering and security requirements expertise
+- ✅ User brings business context for quality targets and risk tolerance
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on performance, usability, and security requirements (Sections 3.3-3.5)
+- 🚫 FORBIDDEN to write operational or lifecycle requirements in this step
+- 💬 Every performance requirement MUST have a measurable target (specific number, not "fast" or "responsive")
+- 🚪 Security requirements must be at system level, not implementation level
+- 📐 Quality requirements must be verifiable with clear pass/fail criteria
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating quality requirements content
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading next step
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to refine performance targets or uncover security concerns
+- **P (Party Mode)**: Bring multiple perspectives to evaluate quality requirements from ops, security, and UX angles
+- **C (Continue)**: Save the content to the document and proceed to next step
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Read fully and follow: {advancedElicitationTask}
+- When 'P' selected: Read fully and follow: {partyModeWorkflow}
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Current document with Sections 1, 2, 3.1, and 3.2 completed
+- Functional and interface requirements inform quality targets
+- PRD NFRs are primary source for quality requirements
+- Architecture document may specify performance constraints
+- Focus on measurable, verifiable quality attributes
+
+## QUALITY REQUIREMENTS ENGINEERING SEQUENCE:
+
+### 1. Extract Quality-Related Requirements from Sources
+
+**From PRD NFRs:**
+
+- Extract all performance-related NFRs
+- Extract all usability-related NFRs
+- Extract all security-related NFRs
+- Note the business context and rationale for each
+
+**From StRS (if available):**
+
+- Extract stakeholder quality expectations
+- Note any compliance or regulatory quality requirements
+- Identify stakeholder-driven performance thresholds
+
+**From Architecture (if available):**
+
+- Note any performance constraints from architectural decisions
+- Identify security architecture patterns that imply requirements
+- Extract any capacity planning assumptions
+
+### 2. Performance Requirements (Section 3.3)
+
+Define measurable performance requirements:
+
+**Performance Categories to Address:**
+
+1. **Response Time** - How quickly the system must respond to specific operations
+2. **Throughput** - How many operations the system must handle per time unit
+3. **Capacity** - Maximum load the system must support (users, data, transactions)
+4. **Scalability** - How the system must scale under increasing load
+5. **Resource Utilization** - Constraints on CPU, memory, storage, bandwidth
+6. **Availability** - Uptime requirements (e.g., 99.9% availability)
+7. **Recovery Time** - How quickly the system must recover from failures
+
+For each performance requirement:
+
+```markdown
+**SYS-PERF-###:** [Requirement statement with specific measurable target]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD NFR ref or StRS ref] |
+| V&V Method | [Test / Analysis] |
+| Measurement | [How this will be measured, e.g., "p95 latency under load test"] |
+| Target | [Specific numeric target, e.g., "< 200ms"] |
+| Conditions | [Under what conditions, e.g., "with 1000 concurrent users"] |
+```
+
+**CRITICAL RULE:** Every performance requirement MUST have a specific numeric target. Reject vague terms:
+- "The system shall respond quickly" - REJECTED
+- "The system shall respond to API requests within 200ms at the 95th percentile under a load of 500 concurrent users" - ACCEPTED
+
+### 3. Usability Requirements (Section 3.4)
+
+Define measurable usability requirements:
+
+**Usability Categories to Address:**
+
+1. **Ease of Use** - Task completion metrics
+2. **Learnability** - Time to proficiency for new users
+3. **Accessibility** - WCAG compliance level and specific accommodations
+4. **Error Tolerance** - System behavior when users make mistakes
+5. **User Satisfaction** - Measurable satisfaction targets (if applicable)
+
+For each usability requirement:
+
+```markdown
+**SYS-USAB-###:** [Requirement statement with measurable criteria]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD NFR ref or StRS ref] |
+| V&V Method | [Demonstration / Test / Inspection] |
+| Measurement | [How this will be verified] |
+```
+
+**Consider:**
+- Task completion rate targets
+- Error rate thresholds
+- Accessibility compliance levels (WCAG 2.1 Level A, AA, or AAA)
+- Localization and internationalization requirements
+- Help and documentation accessibility
+
+### 4. Security Requirements (Section 3.5)
+
+Define system-level security requirements:
+
+**Security Categories to Address:**
+
+1. **Authentication** - How the system verifies user identity
+2. **Authorization** - How the system controls access to functions and data
+3. **Data Protection** - How the system protects data at rest and in transit
+4. **Audit & Logging** - What the system must record for security monitoring
+5. **Compliance** - Regulatory security requirements (GDPR, HIPAA, SOC2, etc.)
+6. **Vulnerability Management** - How the system must handle security updates
+7. **Session Management** - How the system manages user sessions securely
+
+For each security requirement:
+
+```markdown
+**SYS-SEC-###:** [Requirement statement at system level]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD NFR ref, StRS ref, or Regulatory requirement] |
+| V&V Method | [Test / Inspection / Analysis] |
+| Standard | [Applicable security standard, e.g., "OWASP Top 10"] |
+```
+
+**CRITICAL RULE:** Security requirements must be at the system level, not implementation level:
+- "The system shall use bcrypt for password hashing" - IMPLEMENTATION LEVEL (too specific)
+- "The system shall store user credentials using a one-way cryptographic hash function that meets NIST SP 800-63B requirements" - SYSTEM LEVEL (correct)
+
+### 5. Cross-Reference Quality with Functional Requirements
+
+Verify that quality requirements align with functional requirements:
+
+- Performance requirements should reference the functions they apply to
+- Security requirements should cover all sensitive functions identified in 3.1
+- Usability requirements should address user-facing functions
+
+### 6. Generate Quality Requirements Content
+
+Prepare the content to replace the Sections 3.3-3.5 placeholders:
+
+#### Content Structure:
+
+```markdown
+### 3.3 Performance Requirements
+
+[Performance requirements with SYS-PERF-### format, each with measurable targets]
+
+### 3.4 Usability Requirements
+
+[Usability requirements with SYS-USAB-### format]
+
+### 3.5 Security Requirements
+
+[Security requirements with SYS-SEC-### format]
+```
+
+### 7. Present Content and Menu
+
+Show the generated content and present choices:
+
+"I've defined quality and performance requirements across three areas:
+
+**Quality Requirements Summary:**
+- Performance: {{perf_count}} requirements (all with measurable targets)
+- Usability: {{usab_count}} requirements
+- Security: {{sec_count}} requirements
+
+**Here's what I'll add to the SyRS document (Sections 3.3-3.5):**
+
+[Show the complete markdown content from step 6]
+
+**What would you like to do?**
+[A] Advanced Elicitation - Refine performance targets or explore security concerns
+[P] Party Mode - Evaluate quality requirements from operations, security, and UX perspectives
+[C] Continue - Save these quality requirements and proceed to operational requirements"
+
+### 8. Handle Menu Selection
+
+#### If 'A' (Advanced Elicitation):
+
+- Read fully and follow: {advancedElicitationTask} with the current quality requirements
+- Process enhanced insights about performance targets or security concerns
+- Ask user: "Accept these enhancements to the quality requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'P' (Party Mode):
+
+- Read fully and follow: {partyModeWorkflow} with the current quality requirements
+- Process collaborative improvements to quality requirements
+- Ask user: "Accept these changes to the quality requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'C' (Continue):
+
+- Write the final content to Sections 3.3-3.5 in `{outputFile}`
+- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5]`
+- Load `{nextStepFile}`
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', replace the placeholder content in Sections 3.3, 3.4, and 3.5 of the output document with the finalized content.
+
+## SUCCESS METRICS:
+
+✅ All performance requirements have specific measurable targets (no vague language)
+✅ Performance requirements include conditions and measurement methods
+✅ Usability requirements address accessibility with compliance levels
+✅ Security requirements are at system level, not implementation level
+✅ Each requirement uses appropriate identifier format (SYS-PERF, SYS-USAB, SYS-SEC)
+✅ Each requirement has Enterprise attributes
+✅ Quality requirements cross-referenced with functional requirements
+✅ A/P/C menu presented and handled correctly
+✅ Content properly written to document when C selected
+
+## FAILURE MODES:
+
+❌ Using vague performance targets ("fast", "responsive", "scalable")
+❌ Missing measurement methods for performance requirements
+❌ Specifying implementation-level security instead of system-level
+❌ Not addressing accessibility in usability requirements
+❌ Missing Enterprise attributes on any requirement
+❌ Not cross-referencing with functional requirements
+❌ Not presenting A/P/C menu after content generation
+
+❌ **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
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved to document, load `./step-06-operational-requirements.md` to define operational requirements.
+
+Remember: Do NOT proceed to step-06 until user explicitly selects 'C' from the A/P/C menu and content is saved!

src/bmm/workflows/3-solutioning/create-syrs/steps/step-06-operational-requirements.md

@@ -0,0 +1,334 @@
+---
+name: 'step-06-operational-requirements'
+description: 'Define system operations, modes and states, physical characteristics, and environment conditions for SyRS Sections 3.6-3.9'
+
+# Path Definitions
+workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs'
+
+# File References
+thisStepFile: './step-06-operational-requirements.md'
+nextStepFile: './step-07-constraints-lifecycle.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{planning_artifacts}/syrs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 6: Operational Requirements
+
+## STEP GOAL:
+
+Define system operations and maintenance, system modes and states (operational, degraded, maintenance, emergency), physical characteristics (if applicable), and environment conditions. This step populates ISO 29148 Clause 8 Sections 3.6 (System Operations), 3.7 (System Modes and States), 3.8 (Physical Characteristics), and 3.9 (Environment Conditions).
+
+## 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 entire file is read
+- 📋 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 System Architecture and Requirements Engineering specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring operational systems engineering and resilience expertise
+- ✅ User brings operational context, deployment environment knowledge, and operational procedures
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on operational requirements (Sections 3.6-3.9)
+- 🚫 FORBIDDEN to write constraint or lifecycle requirements in this step
+- 💬 System modes and states must include transition conditions
+- 🚪 Physical characteristics should be marked N/A if truly not applicable (e.g., pure software systems)
+- 📐 Operational requirements must be consistent with performance and security from previous step
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating operational requirements content
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before loading next step
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to explore edge cases in system operations and failure scenarios
+- **P (Party Mode)**: Bring multiple perspectives to evaluate operational completeness (ops, SRE, infrastructure)
+- **C (Continue)**: Save the content to the document and proceed to next step
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Read fully and follow: {advancedElicitationTask}
+- When 'P' selected: Read fully and follow: {partyModeWorkflow}
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Current document with Sections 1, 2, 3.1-3.5 completed
+- Performance and security requirements inform operational needs
+- Architecture document may define deployment and operational patterns
+- Focus on how the system operates, not what it does functionally
+
+## OPERATIONAL REQUIREMENTS ENGINEERING SEQUENCE:
+
+### 1. System Operations (Section 3.6)
+
+Define how the system is operated and maintained:
+
+**Operations Categories to Address:**
+
+1. **System Startup** - How the system is brought online
+2. **System Shutdown** - How the system is gracefully stopped
+3. **Backup and Recovery** - Data backup requirements and recovery procedures
+4. **Monitoring** - What the system must expose for monitoring
+5. **Alerting** - What conditions trigger alerts and to whom
+6. **Maintenance Windows** - Requirements for planned maintenance
+7. **Data Management** - Routine data operations (archival, cleanup, migration)
+
+For each operational requirement:
+
+```markdown
+**SYS-OPS-###:** [Requirement statement about system operation]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD NFR ref, StRS ref, or Operational need] |
+| V&V Method | [Demonstration / Test / Inspection] |
+```
+
+**Consider:**
+- Who operates the system (operations team, automated systems, end users)?
+- What operational procedures are required?
+- What level of operational expertise is assumed?
+- What operational documentation must the system support?
+
+### 2. System Modes and States (Section 3.7)
+
+Define the system's operational modes and state transitions:
+
+**Standard Modes to Consider:**
+
+1. **Operational Mode** - Normal full-functionality operation
+2. **Degraded Mode** - Reduced functionality when components fail
+3. **Maintenance Mode** - System available for maintenance activities only
+4. **Emergency Mode** - Critical situation handling
+5. **Initialization Mode** - System startup/bootstrapping
+6. **Shutdown Mode** - Graceful termination
+7. **Standby Mode** - System ready but not actively processing (if applicable)
+
+For each mode:
+
+```markdown
+**SYS-MODE-###:** [Requirement statement about system mode]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [PRD NFR ref, StRS ref, or Operational need] |
+| V&V Method | [Demonstration / Test] |
+| Mode | [Mode name] |
+| Available Functions | [What functions are available in this mode] |
+| Restricted Functions | [What functions are restricted in this mode] |
+```
+
+**State Transition Requirements:**
+
+Define the conditions under which the system transitions between modes:
+
+```markdown
+**State Transition Table:**
+
+| From State | To State | Trigger Condition | Actions Required |
+|------------|----------|-------------------|------------------|
+| Operational | Degraded | [condition] | [actions] |
+| Degraded | Operational | [condition] | [actions] |
+| Operational | Maintenance | [condition] | [actions] |
+| Maintenance | Operational | [condition] | [actions] |
+| Any | Emergency | [condition] | [actions] |
+| Emergency | Operational | [condition] | [actions] |
+```
+
+### 3. Physical Characteristics (Section 3.8)
+
+Define physical requirements of the system:
+
+**For software-only systems:**
+"This system is a software system with no dedicated physical hardware requirements. Physical characteristics are governed by the deployment environment specified in Section 3.9."
+
+**For systems with physical components:**
+
+```markdown
+**SYS-PHYS-###:** [Requirement statement about physical characteristic]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [StRS ref or Operational need] |
+| V&V Method | [Inspection / Test] |
+```
+
+**Consider:**
+- Size and weight constraints
+- Power requirements
+- Heat dissipation requirements
+- Physical security requirements (locks, enclosures)
+- Portability requirements
+- Hardware component specifications
+
+### 4. Environment Conditions (Section 3.9)
+
+Define the environment in which the system must operate:
+
+**Environment Categories:**
+
+1. **Deployment Environment** - Where the system runs (cloud, on-premise, hybrid, edge)
+2. **Operating System Requirements** - Supported OS versions
+3. **Runtime Environment** - Required runtime dependencies
+4. **Network Environment** - Network conditions the system must handle
+5. **Geographic Distribution** - Multi-region or single-region deployment
+6. **Regulatory Environment** - Data residency or jurisdictional requirements
+
+For each environment requirement:
+
+```markdown
+**SYS-ENV-###:** [Requirement statement about environment condition]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [StRS ref, Architecture ref, or Operational need] |
+| V&V Method | [Inspection / Analysis / Demonstration] |
+```
+
+**Consider:**
+- Cloud provider requirements or constraints
+- Container/orchestration requirements (Kubernetes, Docker)
+- Network latency and bandwidth constraints
+- Browser/client environment requirements
+- Temperature, humidity, vibration (for physical deployments)
+
+### 5. Consistency Check
+
+Verify operational requirements are consistent with:
+
+- Performance requirements from Section 3.3 (e.g., availability targets match mode definitions)
+- Security requirements from Section 3.5 (e.g., maintenance mode security)
+- Functional requirements from Section 3.1 (e.g., functions available per mode)
+
+### 6. Generate Operational Requirements Content
+
+Prepare the content to replace the Sections 3.6-3.9 placeholders:
+
+#### Content Structure:
+
+```markdown
+### 3.6 System Operations
+
+[Operational requirements with SYS-OPS-### format]
+
+### 3.7 System Modes and States
+
+[Mode requirements with SYS-MODE-### format]
+
+[State Transition Table]
+
+### 3.8 Physical Characteristics
+
+[Physical requirements with SYS-PHYS-### format, or N/A statement for software systems]
+
+### 3.9 Environment Conditions
+
+[Environment requirements with SYS-ENV-### format]
+```
+
+### 7. Present Content and Menu
+
+Show the generated content and present choices:
+
+"I've defined operational requirements covering system operations, modes, physical characteristics, and environment.
+
+**Operational Requirements Summary:**
+- System Operations: {{ops_count}} requirements
+- System Modes: {{mode_count}} modes defined with state transition table
+- Physical Characteristics: {{phys_count}} requirements (or N/A)
+- Environment Conditions: {{env_count}} requirements
+
+**Here's what I'll add to the SyRS document (Sections 3.6-3.9):**
+
+[Show the complete markdown content from step 6]
+
+**What would you like to do?**
+[A] Advanced Elicitation - Explore edge cases in operations and failure scenarios
+[P] Party Mode - Evaluate from operations, SRE, and infrastructure perspectives
+[C] Continue - Save these operational requirements and proceed to constraints and lifecycle"
+
+### 8. Handle Menu Selection
+
+#### If 'A' (Advanced Elicitation):
+
+- Read fully and follow: {advancedElicitationTask} with the current operational requirements
+- Process enhanced insights about operational edge cases
+- Ask user: "Accept these enhancements to the operational requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'P' (Party Mode):
+
+- Read fully and follow: {partyModeWorkflow} with the current operational requirements
+- Process collaborative improvements to operational coverage
+- Ask user: "Accept these changes to the operational requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'C' (Continue):
+
+- Write the final content to Sections 3.6-3.9 in `{outputFile}`
+- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6]`
+- Load `{nextStepFile}`
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', replace the placeholder content in Sections 3.6, 3.7, 3.8, and 3.9 of the output document with the finalized content.
+
+## SUCCESS METRICS:
+
+✅ System operations cover startup, shutdown, backup, monitoring, and maintenance
+✅ System modes defined with clear available/restricted functions per mode
+✅ State transition table complete with trigger conditions and actions
+✅ Physical characteristics addressed (requirements or explicit N/A)
+✅ Environment conditions cover deployment, runtime, and network requirements
+✅ Each requirement uses appropriate identifier format (SYS-OPS, SYS-MODE, SYS-PHYS, SYS-ENV)
+✅ Each requirement has Enterprise attributes
+✅ Consistency with performance and security requirements verified
+✅ A/P/C menu presented and handled correctly
+✅ Content properly written to document when C selected
+
+## FAILURE MODES:
+
+❌ Not defining system modes and state transitions
+❌ Missing degraded mode definition (critical for resilience)
+❌ Not addressing physical characteristics (even to say N/A)
+❌ Vague environment conditions without specific targets
+❌ Operational requirements inconsistent with performance targets
+❌ Missing Enterprise attributes on any requirement
+❌ Not presenting A/P/C menu after content generation
+
+❌ **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
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved to document, load `./step-07-constraints-lifecycle.md` to define constraints and lifecycle requirements.
+
+Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu and content is saved!

src/bmm/workflows/3-solutioning/create-syrs/steps/step-07-constraints-lifecycle.md

@@ -0,0 +1,322 @@
+---
+name: 'step-07-constraints-lifecycle'
+description: 'Define design constraints, information management, policy and regulation, and lifecycle sustainability for SyRS Sections 3.10-3.13'
+
+# Path Definitions
+workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs'
+
+# File References
+thisStepFile: './step-07-constraints-lifecycle.md'
+nextStepFile: './step-08-verification-plan.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{planning_artifacts}/syrs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 7: Constraints & Lifecycle
+
+## STEP GOAL:
+
+Define design constraints at the system level, information management requirements, policy and regulation requirements, and lifecycle sustainability (maintenance, evolution, decommission). This step populates ISO 29148 Clause 8 Sections 3.10 (Information Management), 3.11 (Policies and Regulations), 3.12 (System Lifecycle Sustainability), and 3.13 (Design Constraints).
+
+## 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 entire file is read
+- 📋 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 System Architecture and Requirements Engineering specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring systems lifecycle engineering and governance expertise
+- ✅ User brings organizational context, regulatory knowledge, and long-term vision
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on constraints and lifecycle requirements (Sections 3.10-3.13)
+- 🚫 FORBIDDEN to write verification or traceability content in this step
+- 💬 Lifecycle sustainability must address the entire system lifespan - not just initial development
+- 🚪 Design constraints must not duplicate architectural decisions but complement them
+- 📐 Policy requirements must reference specific regulations or standards
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating constraints and lifecycle content
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading next step
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to explore regulatory landscape or lifecycle implications
+- **P (Party Mode)**: Bring multiple perspectives to evaluate constraints from governance, legal, and engineering angles
+- **C (Continue)**: Save the content to the document and proceed to next step
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Read fully and follow: {advancedElicitationTask}
+- When 'P' selected: Read fully and follow: {partyModeWorkflow}
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Current document with Sections 1, 2, 3.1-3.9 completed
+- All previous requirements inform constraint and lifecycle decisions
+- Architecture document may define technology constraints
+- StRS may specify organizational and regulatory constraints
+- Focus on long-term system viability and governance
+
+## CONSTRAINTS AND LIFECYCLE ENGINEERING SEQUENCE:
+
+### 1. Information Management (Section 3.10)
+
+Define how the system manages information throughout its lifecycle:
+
+**Information Management Categories:**
+
+1. **Data Retention** - How long different data types must be retained
+2. **Data Archival** - Requirements for moving data to long-term storage
+3. **Data Disposal** - Requirements for secure data deletion/destruction
+4. **Data Classification** - Categories of data sensitivity and handling rules
+5. **Data Integrity** - Requirements for ensuring data accuracy and consistency
+6. **Data Migration** - Requirements for moving data between system versions
+7. **Backup and Restoration** - Data backup frequency and restoration requirements
+
+For each information management requirement:
+
+```markdown
+**SYS-INFO-###:** [Requirement statement about information management]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [StRS ref, Regulatory ref, or Business need] |
+| V&V Method | [Inspection / Analysis / Demonstration / Test] |
+```
+
+### 2. Policies and Regulations (Section 3.11)
+
+Define policy and regulatory requirements the system must comply with:
+
+**Policy Categories to Address:**
+
+1. **Data Privacy Regulations** - GDPR, CCPA, LGPD, PIPEDA, etc.
+2. **Industry Regulations** - HIPAA, PCI-DSS, SOX, etc. as applicable
+3. **Accessibility Standards** - ADA, Section 508, EN 301 549, etc.
+4. **Organizational Policies** - Internal security, data handling, development policies
+5. **Export Control** - If applicable, ITAR, EAR, etc.
+6. **Licensing** - Open source licensing compliance requirements
+
+For each policy/regulation requirement:
+
+```markdown
+**SYS-POL-###:** [Requirement statement about policy or regulation compliance]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [Specific regulation, e.g., "GDPR Article 17"] |
+| V&V Method | [Inspection / Analysis / Audit] |
+| Regulation | [Full regulation name and version] |
+```
+
+**NOTE:** If no specific regulations apply, explicitly state: "No specific regulatory requirements have been identified for this system. The following organizational policies apply: [list or 'None identified']."
+
+### 3. System Lifecycle Sustainability (Section 3.12)
+
+Define requirements for the system's long-term viability:
+
+**Lifecycle Categories:**
+
+1. **Maintenance** - How the system must support ongoing maintenance
+   - Corrective maintenance (bug fixing)
+   - Adaptive maintenance (environment changes)
+   - Perfective maintenance (enhancements)
+   - Preventive maintenance (technical debt reduction)
+
+2. **Evolution** - How the system must support planned growth
+   - Extensibility requirements
+   - Modularity requirements
+   - API versioning requirements
+   - Feature toggling capabilities
+
+3. **Decommission** - How the system must support end-of-life
+   - Data export requirements
+   - Migration path requirements
+   - Graceful degradation during sunset period
+   - Data preservation obligations
+
+For each lifecycle requirement:
+
+```markdown
+**SYS-LIFE-###:** [Requirement statement about lifecycle sustainability]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [StRS ref, Organizational policy, or Engineering best practice] |
+| V&V Method | [Inspection / Analysis / Demonstration] |
+| Lifecycle Phase | [Maintenance / Evolution / Decommission] |
+```
+
+### 4. Design Constraints (Section 3.13)
+
+Define constraints that limit the design solution space:
+
+**Constraint Categories:**
+
+1. **Technology Constraints** - Required or prohibited technologies
+2. **Standards Compliance** - Required technical standards (coding standards, API standards)
+3. **Organizational Constraints** - Imposed by the organization (approved vendors, platforms)
+4. **Interoperability Constraints** - Must work with specific existing systems
+5. **Resource Constraints** - Budget, timeline, team size limitations on design
+6. **Legacy Constraints** - Requirements to maintain backward compatibility
+
+For each design constraint:
+
+```markdown
+**SYS-CON-###:** [Constraint statement]
+
+| Attribute | Value |
+|-----------|-------|
+| Priority | [Critical / High / Medium / Low] |
+| Source | [Architecture ref, StRS ref, or Organizational policy] |
+| V&V Method | [Inspection / Analysis] |
+| Constraint Type | [Technology / Standard / Organizational / Interoperability / Resource / Legacy] |
+```
+
+**NOTE:** Design constraints should complement, not duplicate, architectural decisions. If the Architecture document specifies technology choices, reference them here as constraints on the system design rather than restating them.
+
+### 5. Cross-Reference Check
+
+Verify constraints and lifecycle requirements are consistent with:
+
+- Security requirements from Section 3.5 (data handling, compliance)
+- Operational requirements from Sections 3.6-3.9 (maintenance, environment)
+- Interface requirements from Section 3.2 (interoperability constraints)
+- Architecture document decisions (if available)
+
+### 6. Generate Constraints and Lifecycle Content
+
+Prepare the content to replace the Sections 3.10-3.13 placeholders:
+
+#### Content Structure:
+
+```markdown
+### 3.10 Information Management
+
+[Information management requirements with SYS-INFO-### format]
+
+### 3.11 Policies and Regulations
+
+[Policy and regulation requirements with SYS-POL-### format]
+
+### 3.12 System Lifecycle Sustainability
+
+#### 3.12.1 Maintenance Requirements
+[Maintenance requirements with SYS-LIFE-### format]
+
+#### 3.12.2 Evolution Requirements
+[Evolution requirements with SYS-LIFE-### format]
+
+#### 3.12.3 Decommission Requirements
+[Decommission requirements with SYS-LIFE-### format]
+
+### 3.13 Design Constraints
+
+[Design constraint requirements with SYS-CON-### format]
+```
+
+### 7. Present Content and Menu
+
+Show the generated content and present choices:
+
+"I've defined constraints and lifecycle requirements covering information management, policies, sustainability, and design constraints.
+
+**Constraints & Lifecycle Summary:**
+- Information Management: {{info_count}} requirements
+- Policies and Regulations: {{pol_count}} requirements
+- Lifecycle Sustainability: {{life_count}} requirements (maintenance: {{m}}, evolution: {{e}}, decommission: {{d}})
+- Design Constraints: {{con_count}} constraints
+
+**Here's what I'll add to the SyRS document (Sections 3.10-3.13):**
+
+[Show the complete markdown content from step 6]
+
+**What would you like to do?**
+[A] Advanced Elicitation - Explore regulatory landscape or lifecycle implications in depth
+[P] Party Mode - Evaluate constraints from governance, legal, and engineering perspectives
+[C] Continue - Save these requirements and proceed to verification planning"
+
+### 8. Handle Menu Selection
+
+#### If 'A' (Advanced Elicitation):
+
+- Read fully and follow: {advancedElicitationTask} with the current constraints and lifecycle requirements
+- Process enhanced insights about regulatory or lifecycle concerns
+- Ask user: "Accept these enhancements to the constraints and lifecycle requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'P' (Party Mode):
+
+- Read fully and follow: {partyModeWorkflow} with the current constraints and lifecycle requirements
+- Process collaborative improvements to constraint coverage
+- Ask user: "Accept these changes to the constraints and lifecycle requirements? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'C' (Continue):
+
+- Write the final content to Sections 3.10-3.13 in `{outputFile}`
+- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]`
+- Load `{nextStepFile}`
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', replace the placeholder content in Sections 3.10, 3.11, 3.12, and 3.13 of the output document with the finalized content.
+
+## SUCCESS METRICS:
+
+✅ Information management covers retention, archival, disposal, and integrity
+✅ Policy requirements reference specific regulations and standards
+✅ Lifecycle sustainability addresses maintenance, evolution, AND decommission
+✅ Design constraints complement (not duplicate) architectural decisions
+✅ Each requirement uses appropriate identifier format (SYS-INFO, SYS-POL, SYS-LIFE, SYS-CON)
+✅ Each requirement has Enterprise attributes
+✅ Constraints cross-referenced with architecture document
+✅ A/P/C menu presented and handled correctly
+✅ Content properly written to document when C selected
+
+## FAILURE MODES:
+
+❌ Ignoring lifecycle sustainability (common oversight)
+❌ Not addressing decommission requirements
+❌ Vague policy requirements without specific regulation references
+❌ Duplicating architectural decisions as constraints
+❌ Missing information management for data-intensive systems
+❌ Missing Enterprise attributes on any requirement
+❌ Not presenting A/P/C menu after content generation
+
+❌ **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
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved to document, load `./step-08-verification-plan.md` to create the verification plan for all system requirements.
+
+Remember: Do NOT proceed to step-08 until user explicitly selects 'C' from the A/P/C menu and content is saved!

src/bmm/workflows/3-solutioning/create-syrs/steps/step-08-verification-plan.md

@@ -0,0 +1,359 @@
+---
+name: 'step-08-verification-plan'
+description: 'Create verification plan assigning verification methods to every system requirement, with TEA module integration for Enterprise track. SyRS Section 4'
+
+# Path Definitions
+workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs'
+
+# File References
+thisStepFile: './step-08-verification-plan.md'
+nextStepFile: './step-09-review-complete.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{planning_artifacts}/syrs-{{project_name}}.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 8: Verification Plan
+
+## STEP GOAL:
+
+Create a comprehensive verification plan that assigns a verification method to EVERY system requirement defined in Sections 3.1 through 3.13. Build the verification summary table and note TEA (Test, Evaluate, Approve) module integration for the Enterprise track. This step populates ISO 29148 Clause 8 Section 4 (Verification) and also populates Section 5 (Assumptions and Dependencies).
+
+## 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 entire file is read
+- 📋 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 System Architecture and Requirements Engineering specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring verification and validation engineering expertise
+- ✅ User brings context on testing capabilities and organizational V&V practices
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on verification planning (Section 4) and assumptions (Section 5)
+- 🚫 FORBIDDEN to modify existing requirements in Sections 3.x
+- 💬 EVERY requirement must have a verification method - no exceptions
+- 🚪 Verification methods must be appropriate to the requirement type
+- 📐 The verification summary table must be complete and gap-free
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ⚠️ Present A/P/C menu after generating verification plan content
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]` before loading next step
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to refine verification approaches or explore testing strategies
+- **P (Party Mode)**: Bring multiple perspectives to evaluate verification completeness (QA, test, ops)
+- **C (Continue)**: Save the content to the document and proceed to next step
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Read fully and follow: {advancedElicitationTask}
+- When 'P' selected: Read fully and follow: {partyModeWorkflow}
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Current document with all Sections 1 through 3.13 completed
+- All system requirements are defined and available for verification planning
+- V&V Method attributes already assigned on each requirement serve as initial input
+- Focus on consolidating and validating verification approach
+
+## VERIFICATION PLANNING SEQUENCE:
+
+### 1. Explain Verification Methods
+
+Present the four standard verification methods per ISO 29148:
+
+"**Verification Methods (ISO 29148):**
+
+1. **Inspection** - Visual examination of the system, documentation, or code to verify compliance
+   - Best for: Design constraints, documentation requirements, coding standards, policy compliance
+   - Example: Verifying that the system uses the required encryption algorithm by code review
+
+2. **Analysis** - Processing of accumulated data using mathematical or statistical methods
+   - Best for: Performance under theoretical conditions, capacity planning, resource utilization
+   - Example: Analyzing system architecture to verify scalability requirements
+
+3. **Demonstration** - Operation of the system showing observable functional behavior
+   - Best for: User interface requirements, workflow requirements, operational procedures
+   - Example: Demonstrating that the system can transition from operational to maintenance mode
+
+4. **Test** - Exercising the system under controlled conditions and comparing results to criteria
+   - Best for: Functional requirements, performance targets, security requirements
+   - Example: Load testing to verify the system handles 1000 concurrent users with <200ms response time"
+
+### 2. Review All Requirements and V&V Assignments
+
+Systematically review every requirement across all sections:
+
+**For each requirement section, verify the V&V method is appropriate:**
+
+| Requirement Category | Typical V&V Methods |
+|---------------------|-------------------|
+| SYS-FUNC-### (Functional) | Test, Demonstration |
+| SYS-IF-### (Interface) | Test, Demonstration, Inspection |
+| SYS-PERF-### (Performance) | Test, Analysis |
+| SYS-USAB-### (Usability) | Demonstration, Test |
+| SYS-SEC-### (Security) | Test, Inspection, Analysis |
+| SYS-OPS-### (Operations) | Demonstration, Test |
+| SYS-MODE-### (Modes) | Demonstration, Test |
+| SYS-PHYS-### (Physical) | Inspection, Test |
+| SYS-ENV-### (Environment) | Inspection, Analysis, Demonstration |
+| SYS-INFO-### (Info Mgmt) | Inspection, Test, Analysis |
+| SYS-POL-### (Policy) | Inspection, Analysis |
+| SYS-LIFE-### (Lifecycle) | Inspection, Analysis, Demonstration |
+| SYS-CON-### (Constraints) | Inspection, Analysis |
+
+**Validation Rules:**
+
+- Every requirement MUST have at least one verification method
+- The method must be achievable with available resources
+- Prefer Test for requirements with measurable acceptance criteria
+- Use Inspection for requirements verified by examination
+- Use Analysis for requirements verified by calculation or modeling
+- Use Demonstration for requirements verified by showing behavior
+
+### 3. Define Verification Methods Detail (Section 4.1)
+
+For each verification method used, define the approach:
+
+```markdown
+### 4.1 Verification Methods
+
+#### 4.1.1 Inspection
+**Scope:** [Which requirement categories will be verified by inspection]
+**Approach:** [How inspections will be conducted - code review, document review, etc.]
+**Criteria:** [What constitutes pass/fail for inspections]
+
+#### 4.1.2 Analysis
+**Scope:** [Which requirement categories will be verified by analysis]
+**Approach:** [How analyses will be conducted - modeling, simulation, calculation]
+**Criteria:** [What constitutes pass/fail for analyses]
+
+#### 4.1.3 Demonstration
+**Scope:** [Which requirement categories will be verified by demonstration]
+**Approach:** [How demonstrations will be conducted - operational scenarios, walkthroughs]
+**Criteria:** [What constitutes pass/fail for demonstrations]
+
+#### 4.1.4 Test
+**Scope:** [Which requirement categories will be verified by test]
+**Approach:** [How tests will be conducted - unit, integration, system, acceptance]
+**Criteria:** [What constitutes pass/fail for tests]
+```
+
+### 4. Build Verification Summary Table (Section 4.2)
+
+Create the comprehensive verification summary table:
+
+```markdown
+### 4.2 Verification Summary Table
+
+| Req ID | Requirement Summary | V&V Method | V&V Level | V&V Criteria | Status |
+|--------|-------------------|------------|-----------|--------------|--------|
+| SYS-FUNC-001 | [Brief summary] | Test | System Test | [Pass criteria] | Planned |
+| SYS-FUNC-002 | [Brief summary] | Test | Integration Test | [Pass criteria] | Planned |
+| SYS-IF-001 | [Brief summary] | Demonstration | System Demo | [Pass criteria] | Planned |
+| SYS-PERF-001 | [Brief summary] | Test | Performance Test | [Pass criteria] | Planned |
+| SYS-SEC-001 | [Brief summary] | Test | Security Test | [Pass criteria] | Planned |
+...
+```
+
+**The table MUST include EVERY requirement from Sections 3.1 through 3.13. No gaps allowed.**
+
+**V&V Level Options:**
+- Unit Test
+- Integration Test
+- System Test
+- Acceptance Test
+- Performance Test
+- Security Test
+- Code Review
+- Design Review
+- Architecture Review
+- Operational Demonstration
+- System Demo
+
+### 5. TEA Module Integration (Enterprise Track)
+
+For Enterprise track, note TEA module integration:
+
+```markdown
+### 4.3 TEA Module Integration
+
+**Track:** Enterprise
+
+The verification plan integrates with the BMAD Enterprise TEA (Test, Evaluate, Approve) module:
+
+- **Test Phase:** Automated and manual test execution per the verification summary table
+- **Evaluate Phase:** Assessment of test results against pass/fail criteria for each requirement
+- **Approve Phase:** Formal approval workflow for verification results with sign-off authority
+
+**TEA Integration Points:**
+- Each requirement's verification status will be tracked in the RTM (Requirements Traceability Matrix)
+- Verification results feed into the project's quality gate decisions
+- Failed verifications trigger the defect management workflow
+- Verification completion is a prerequisite for baseline approval
+```
+
+### 6. Document Assumptions and Dependencies (Section 5)
+
+Compile all assumptions and dependencies identified throughout the workflow:
+
+```markdown
+## 5. Assumptions and Dependencies
+
+### 5.1 Assumptions
+
+[List all assumptions that underpin the requirements in this SyRS]
+- [Assumption about user behavior]
+- [Assumption about technology availability]
+- [Assumption about organizational readiness]
+...
+
+### 5.2 Dependencies
+
+[List all external dependencies]
+- [Dependency on external system availability]
+- [Dependency on third-party service]
+- [Dependency on organizational decision]
+...
+
+### 5.3 Risk Implications
+
+[Note risks that arise from key assumptions]
+| Assumption | Risk if Invalid | Mitigation |
+|-----------|----------------|------------|
+| [assumption] | [risk] | [mitigation approach] |
+...
+```
+
+### 7. Verification Completeness Check
+
+Verify the plan is complete:
+
+```
+**Verification Plan Completeness:**
+- Total requirements: {{total_req_count}}
+- Requirements with verification method: {{verified_count}}
+- Requirements WITHOUT verification method: {{unverified_count}} (MUST BE ZERO)
+
+**Verification Method Distribution:**
+- Inspection: {{inspection_count}} requirements
+- Analysis: {{analysis_count}} requirements
+- Demonstration: {{demo_count}} requirements
+- Test: {{test_count}} requirements
+
+**Coverage: {{coverage_percentage}}%** (must be 100%)
+```
+
+### 8. Generate Verification Plan Content
+
+Prepare the content to replace the Section 4 and Section 5 placeholders.
+
+### 9. Present Content and Menu
+
+Show the generated content and present choices:
+
+"I've created the verification plan covering all {{total_req_count}} system requirements.
+
+**Verification Plan Summary:**
+- Inspection: {{inspection_count}} requirements
+- Analysis: {{analysis_count}} requirements
+- Demonstration: {{demo_count}} requirements
+- Test: {{test_count}} requirements
+- Coverage: 100% (all requirements have verification methods)
+
+**TEA Module:** Enterprise track integration documented
+
+**Assumptions & Dependencies:** {{assumption_count}} assumptions and {{dependency_count}} dependencies documented
+
+**Here's what I'll add to the SyRS document (Sections 4 and 5):**
+
+[Show the complete markdown content]
+
+**What would you like to do?**
+[A] Advanced Elicitation - Refine verification approaches or explore testing strategies
+[P] Party Mode - Evaluate verification plan from QA, test, and operations perspectives
+[C] Continue - Save the verification plan and proceed to final review"
+
+### 10. Handle Menu Selection
+
+#### If 'A' (Advanced Elicitation):
+
+- Read fully and follow: {advancedElicitationTask} with the current verification plan
+- Process enhanced insights about verification strategies
+- Ask user: "Accept these enhancements to the verification plan? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'P' (Party Mode):
+
+- Read fully and follow: {partyModeWorkflow} with the current verification plan
+- Process collaborative improvements to verification coverage
+- Ask user: "Accept these changes to the verification plan? (y/n)"
+- If yes: Update content with improvements, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'C' (Continue):
+
+- Write the final content to Sections 4 and 5 in `{outputFile}`
+- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]`
+- Load `{nextStepFile}`
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', replace the placeholder content in Sections 4 and 5 of the output document with the finalized content.
+
+## SUCCESS METRICS:
+
+✅ Every system requirement (100%) has an assigned verification method
+✅ Verification methods are appropriate to requirement types
+✅ Verification summary table is complete with all requirements listed
+✅ V&V levels specified for each requirement
+✅ Pass/fail criteria defined for each verification
+✅ TEA module integration documented for Enterprise track
+✅ Assumptions and dependencies compiled from all steps
+✅ Risk implications of key assumptions noted
+✅ A/P/C menu presented and handled correctly
+✅ Content properly written to document when C selected
+
+## FAILURE MODES:
+
+❌ Missing verification methods for any requirement (CRITICAL - 100% coverage required)
+❌ Inappropriate verification method for requirement type
+❌ Incomplete verification summary table
+❌ Missing TEA module integration for Enterprise track
+❌ Not documenting assumptions and dependencies
+❌ Vague pass/fail criteria
+❌ Missing Enterprise attributes on any requirement
+❌ Not presenting A/P/C menu after content generation
+
+❌ **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
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved to document, load `./step-09-review-complete.md` to perform the final review and complete the workflow.
+
+Remember: Do NOT proceed to step-09 until user explicitly selects 'C' from the A/P/C menu and content is saved!

src/bmm/workflows/3-solutioning/create-syrs/steps/step-09-review-complete.md

@@ -0,0 +1,387 @@
+---
+name: 'step-09-review-complete'
+description: 'Final review against ISO 29148 Clause 8, cross-section consistency check, traceability verification, completeness assessment, and workflow completion'
+
+# Path Definitions
+workflow_path: '{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs'
+
+# File References
+thisStepFile: './step-09-review-complete.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{planning_artifacts}/syrs-{{project_name}}.md'
+checklistFile: '{workflow_path}/checklist.md'
+
+# Task References
+advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
+partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
+---
+
+# Step 9: Final Review & Completion
+
+## STEP GOAL:
+
+Perform a systematic final review of the complete SyRS against ISO 29148 Clause 8 requirements, check cross-section consistency, verify traceability to StRS and PRD, assess completeness, populate traceability matrices, and complete the workflow.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 📋 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 System Architecture and Requirements Engineering specialist
+- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring ISO 29148 compliance review and quality assurance expertise
+- ✅ User brings final approval authority and domain validation
+
+### Step-Specific Rules:
+
+- 🎯 Focus on comprehensive review, traceability completion, and workflow finalization
+- 🚫 FORBIDDEN to skip any review checks
+- 💬 Present review results transparently including any issues found
+- 🚪 This is the FINAL step - ensure the document is complete before approval
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Load and apply the checklist systematically
+- ✅ Present review findings with clear pass/fail status
+- 📖 Update frontmatter to final state upon completion
+- 🚫 THIS STEP CONTAINS THE FINAL REVIEW - handle with the R/F/A menu
+
+## CONTEXT BOUNDARIES:
+
+- Complete SyRS document with all sections populated
+- All input documents still available for traceability verification
+- Checklist available for systematic review
+- Focus on review, traceability completion, and final approval
+
+## FINAL REVIEW SEQUENCE:
+
+### 1. Load Checklist
+
+Read the checklist from `{checklistFile}` to guide the systematic review.
+
+### 2. Build Traceability Matrices (Section 6)
+
+Before the review, complete the traceability section:
+
+#### Traceability to StRS (Section 6.1)
+
+If StRS was available, create the traceability matrix:
+
+```markdown
+### 6.1 Traceability to StRS
+
+| StRS Requirement | System Requirements | Coverage |
+|-----------------|-------------------|----------|
+| [StRS-001] | SYS-FUNC-001, SYS-FUNC-002 | Full |
+| [StRS-002] | SYS-PERF-001, SYS-SEC-001 | Full |
+| [StRS-003] | SYS-IF-001 | Partial - [note what's missing] |
+...
+
+**StRS Coverage Summary:**
+- StRS requirements traced: {{count}}/{{total}}
+- Fully covered: {{count}}
+- Partially covered: {{count}}
+- Not covered: {{count}} [list with justification]
+```
+
+If StRS was not available:
+```markdown
+### 6.1 Traceability to StRS
+
+StRS was not available during SyRS creation. Traceability to stakeholder requirements should be established when the StRS is created or provided. System requirements in this document are derived from the PRD and collaborative engineering analysis.
+```
+
+#### Traceability to PRD (Section 6.2)
+
+Create the PRD traceability matrix:
+
+```markdown
+### 6.2 Traceability to PRD
+
+| PRD Requirement | System Requirements | Coverage |
+|----------------|-------------------|----------|
+| PRD-FR-001 | SYS-FUNC-001, SYS-FUNC-002, SYS-FUNC-003 | Full |
+| PRD-FR-002 | SYS-FUNC-004 | Full |
+| PRD-NFR-001 | SYS-PERF-001, SYS-PERF-002 | Full |
+...
+
+**PRD Coverage Summary:**
+- PRD FRs traced: {{count}}/{{total}}
+- PRD NFRs traced: {{count}}/{{total}}
+- Fully covered: {{count}}
+- Partially covered: {{count}}
+- Not covered: {{count}} [list with justification]
+```
+
+### 3. Build Requirements Index (Appendix B)
+
+Create a complete index of all requirements in the document:
+
+```markdown
+### Appendix B: Requirements Index
+
+| Req ID | Section | Category | Priority | V&V Method |
+|--------|---------|----------|----------|------------|
+| SYS-FUNC-001 | 3.1.1 | Functional | Critical | Test |
+| SYS-FUNC-002 | 3.1.1 | Functional | High | Test |
+| SYS-IF-001 | 3.2.1 | User Interface | High | Demonstration |
+...
+
+**Requirements Summary:**
+- Total requirements: {{total}}
+- By category: Functional ({{count}}), Interface ({{count}}), Performance ({{count}}), Usability ({{count}}), Security ({{count}}), Operations ({{count}}), Modes ({{count}}), Physical ({{count}}), Environment ({{count}}), Info Mgmt ({{count}}), Policy ({{count}}), Lifecycle ({{count}}), Constraints ({{count}})
+- By priority: Critical ({{count}}), High ({{count}}), Medium ({{count}}), Low ({{count}})
+```
+
+### 4. Systematic ISO 29148 Clause 8 Review
+
+Using the checklist, review each section:
+
+**Section 1 - Introduction:**
+- [ ] System purpose clearly stated
+- [ ] System scope and boundaries defined
+- [ ] System context with external entities
+- [ ] System functions listed
+- [ ] User characteristics defined
+- [ ] Glossary present and complete
+
+**Section 2 - References:**
+- [ ] ISO 29148 referenced
+- [ ] All input documents listed
+- [ ] All referenced standards included
+
+**Section 3 - System Requirements:**
+- [ ] 3.1 Functional requirements complete with SYS-FUNC-### format
+- [ ] 3.2 Interface requirements complete with SYS-IF-### format
+- [ ] 3.3 Performance requirements with measurable targets
+- [ ] 3.4 Usability requirements specified
+- [ ] 3.5 Security requirements at system level
+- [ ] 3.6 System operations defined
+- [ ] 3.7 System modes and states with transitions
+- [ ] 3.8 Physical characteristics (or N/A)
+- [ ] 3.9 Environment conditions specified
+- [ ] 3.10 Information management defined
+- [ ] 3.11 Policies and regulations documented
+- [ ] 3.12 Lifecycle sustainability addressed
+- [ ] 3.13 Design constraints documented
+
+**Section 4 - Verification:**
+- [ ] Every requirement has a verification method
+- [ ] Verification summary table is complete
+- [ ] TEA module integration documented
+
+**Section 5 - Assumptions and Dependencies:**
+- [ ] Assumptions documented
+- [ ] Dependencies listed
+- [ ] Risk implications noted
+
+**Section 6 - Traceability:**
+- [ ] StRS traceability matrix (or noted as unavailable)
+- [ ] PRD traceability matrix
+- [ ] No orphan requirements
+- [ ] No coverage gaps
+
+### 5. Cross-Section Consistency Check
+
+Verify consistency across all sections:
+
+- No conflicting requirements between sections
+- Terminology consistent throughout
+- Identifier numbering sequential and gap-free
+- All cross-references between sections valid
+- Performance requirements align with functional requirements
+- Security requirements align with interface requirements
+- Operational requirements align with system modes and states
+- Constraints consistent with architectural decisions
+
+### 6. Requirement Quality Spot Check
+
+Select a representative sample of requirements (at least 3 from each category) and verify the 9 quality criteria:
+
+1. **Necessary** - Essential for system success
+2. **Appropriate** - Correct level of abstraction
+3. **Unambiguous** - Single interpretation
+4. **Complete** - Fully stated
+5. **Singular** - Atomic (one thing per requirement)
+6. **Feasible** - Technically achievable
+7. **Verifiable** - Can be verified
+8. **Correct** - Accurately represents need
+9. **Conforming** - Follows SyRS format
+
+### 7. Compile Review Results
+
+Prepare the review findings:
+
+```markdown
+## SyRS Review Results
+
+### ISO 29148 Clause 8 Compliance
+**Status:** [COMPLIANT / PARTIALLY COMPLIANT / NON-COMPLIANT]
+
+**Section Compliance:**
+| Section | Status | Notes |
+|---------|--------|-------|
+| 1. Introduction | [Pass/Fail] | [notes] |
+| 2. References | [Pass/Fail] | [notes] |
+| 3.1 Functional | [Pass/Fail] | [notes] |
+| 3.2 Interfaces | [Pass/Fail] | [notes] |
+| 3.3 Performance | [Pass/Fail] | [notes] |
+| 3.4 Usability | [Pass/Fail] | [notes] |
+| 3.5 Security | [Pass/Fail] | [notes] |
+| 3.6 Operations | [Pass/Fail] | [notes] |
+| 3.7 Modes | [Pass/Fail] | [notes] |
+| 3.8 Physical | [Pass/Fail] | [notes] |
+| 3.9 Environment | [Pass/Fail] | [notes] |
+| 3.10 Info Mgmt | [Pass/Fail] | [notes] |
+| 3.11 Policy | [Pass/Fail] | [notes] |
+| 3.12 Lifecycle | [Pass/Fail] | [notes] |
+| 3.13 Constraints | [Pass/Fail] | [notes] |
+| 4. Verification | [Pass/Fail] | [notes] |
+| 5. Assumptions | [Pass/Fail] | [notes] |
+| 6. Traceability | [Pass/Fail] | [notes] |
+
+### Cross-Section Consistency
+**Status:** [CONSISTENT / ISSUES FOUND]
+[Details of any consistency issues]
+
+### Traceability Assessment
+- StRS coverage: {{percentage}}%
+- PRD coverage: {{percentage}}%
+- Orphan requirements: {{count}}
+
+### Requirement Quality Assessment
+- Sample size: {{count}} requirements reviewed
+- Quality criteria pass rate: {{percentage}}%
+- Issues found: [list any quality issues]
+
+### Overall Assessment
+**Total requirements:** {{count}}
+**Verified (V&V assigned):** {{count}} (must be 100%)
+**Traced (to StRS/PRD):** {{count}}
+
+### Issues Found
+**Critical (must fix):** [list or "None"]
+**Minor (can address later):** [list or "None"]
+**Recommendations:** [list or "None"]
+```
+
+### 8. Present Review Results and Menu
+
+Present the complete review findings to the user:
+
+"I've completed a comprehensive review of the System Requirements Specification.
+
+**Review Summary:**
+[Show key findings from step 7]
+
+**What would you like to do?**
+[R] Review - Address issues found and re-review specific sections
+[F] Finalize - Accept the SyRS and finalize the document (minor issues to be addressed in next baseline)
+[A] Approve - Formally approve the SyRS as the current baseline"
+
+### 9. Handle Menu Selection
+
+#### If 'R' (Review):
+
+- Ask user which issues they want to address
+- For each issue, collaborate to resolve it
+- Update the relevant section in the output document
+- After all issues addressed, re-run the review checks on affected sections
+- Return to R/F/A menu
+
+#### If 'F' (Finalize):
+
+- Write all remaining content to the document (traceability matrices, requirements index, review results)
+- Update frontmatter:
+  ```yaml
+  stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]
+  status: 'final'
+  completedAt: '{{current_date}}'
+  ```
+- Proceed to completion summary (step 10 below)
+
+#### If 'A' (Approve):
+
+- Write all remaining content to the document
+- Update frontmatter:
+  ```yaml
+  stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]
+  status: 'approved'
+  baseline_version: '1.0'
+  approvedAt: '{{current_date}}'
+  approvedBy: '{{user_name}}'
+  ```
+- Proceed to completion summary (step 10 below)
+
+### 10. Workflow Completion
+
+Congratulate the user on completing the SyRS:
+
+"Congratulations {{user_name}}! We've completed the System Requirements Specification for {{project_name}}.
+
+**Document:** `{outputFile}`
+**Status:** [Finalized / Approved as Baseline 1.0]
+**Total System Requirements:** {{count}}
+**ISO 29148 Clause 8 Compliance:** [COMPLIANT / status]
+
+**What we accomplished together:**
+- Defined the system context and boundaries
+- Transformed {{prd_fr_count}} PRD requirements into {{sys_func_count}} system functional requirements
+- Defined {{if_count}} interface requirements
+- Specified {{quality_count}} quality requirements with measurable targets
+- Documented {{ops_count}} operational requirements including system modes and states
+- Established {{constraint_count}} constraints and lifecycle requirements
+- Created a verification plan covering 100% of requirements
+- Built traceability matrices to StRS and PRD
+
+**Suggested Next Steps:**
+1. **RTM Update** - Update the Requirements Traceability Matrix with the SyRS baseline
+2. **Epics Creation** - Run the Create Epics and Stories workflow to break down system requirements into implementable stories
+3. **Architecture Review** - Review and update the Architecture document for alignment with the SyRS
+4. **Verification Execution** - Begin planning verification activities per the verification summary table"
+
+SyRS complete. Read fully and follow: `_bmad/core/tasks/help.md` with argument `Create SyRS`.
+
+Upon Completion of task output: offer to answer any questions about the System Requirements Specification.
+
+## SUCCESS METRICS:
+
+✅ Traceability matrices complete for both StRS and PRD
+✅ Requirements index complete with all requirements listed
+✅ Systematic ISO 29148 Clause 8 review performed using checklist
+✅ Cross-section consistency verified
+✅ Requirement quality spot check performed
+✅ Review results clearly presented with pass/fail status
+✅ R/F/A menu presented and handled correctly
+✅ All content written to document upon finalization/approval
+✅ Frontmatter updated to final/approved status
+✅ User provided with clear next steps
+
+## FAILURE MODES:
+
+❌ Skipping the systematic review (just rubber-stamping)
+❌ Not building traceability matrices
+❌ Not identifying cross-section inconsistencies
+❌ Not performing requirement quality spot check
+❌ Approving document with critical issues unresolved
+❌ Not updating frontmatter to final status
+❌ Not providing next step guidance
+
+❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
+❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
+
+## WORKFLOW COMPLETE:
+
+This is the final step of the SyRS workflow. The user now has a complete, reviewed System Requirements Specification that is:
+
+- ISO 29148 Clause 8 compliant
+- Traceable to StRS and PRD
+- Verified with methods assigned to every requirement
+- Ready for use in downstream engineering activities (epics, architecture review, verification execution)

src/bmm/workflows/3-solutioning/create-syrs/templates/syrs-template.md

@@ -0,0 +1,149 @@
+---
+stepsCompleted: []
+inputDocuments: []
+workflowType: 'syrs'
+track: 'enterprise'
+version: '1.0'
+status: 'draft'
+baseline_version: null
+---
+
+# System Requirements Specification - {{project_name}}
+
+**Author:** {{user_name}}
+**Date:** {{date}}
+**ISO 29148 Reference:** Clause 8 - System Requirements Specification
+
+## 1. Introduction
+
+### 1.1 System Purpose
+
+{{system_purpose}}
+
+### 1.2 System Scope
+
+{{system_scope}}
+
+### 1.3 System Overview
+
+#### 1.3.1 System Context
+
+{{system_context}}
+
+#### 1.3.2 System Functions
+
+{{system_functions}}
+
+#### 1.3.3 User Characteristics
+
+{{user_characteristics}}
+
+### 1.4 Definitions, Acronyms, and Abbreviations
+
+{{glossary}}
+
+## 2. References
+
+{{references}}
+
+## 3. System Requirements
+
+### 3.1 Functional Requirements
+
+{{functional_requirements}}
+
+### 3.2 System Interfaces
+
+#### 3.2.1 User Interfaces
+
+{{user_interfaces}}
+
+#### 3.2.2 Hardware Interfaces
+
+{{hardware_interfaces}}
+
+#### 3.2.3 Software Interfaces
+
+{{software_interfaces}}
+
+#### 3.2.4 Communication Interfaces
+
+{{communication_interfaces}}
+
+### 3.3 Performance Requirements
+
+{{performance_requirements}}
+
+### 3.4 Usability Requirements
+
+{{usability_requirements}}
+
+### 3.5 Security Requirements
+
+{{security_requirements}}
+
+### 3.6 System Operations
+
+{{system_operations}}
+
+### 3.7 System Modes and States
+
+{{system_modes_and_states}}
+
+### 3.8 Physical Characteristics
+
+{{physical_characteristics}}
+
+### 3.9 Environment Conditions
+
+{{environment_conditions}}
+
+### 3.10 Information Management
+
+{{information_management}}
+
+### 3.11 Policies and Regulations
+
+{{policies_and_regulations}}
+
+### 3.12 System Lifecycle Sustainability
+
+{{lifecycle_sustainability}}
+
+### 3.13 Design Constraints
+
+{{design_constraints}}
+
+## 4. Verification
+
+### 4.1 Verification Methods
+
+{{verification_methods}}
+
+### 4.2 Verification Summary Table
+
+{{verification_summary_table}}
+
+## 5. Assumptions and Dependencies
+
+{{assumptions_and_dependencies}}
+
+## 6. Traceability
+
+### 6.1 Traceability to StRS
+
+{{traceability_strs}}
+
+### 6.2 Traceability to PRD
+
+{{traceability_prd}}
+
+## Appendices
+
+### Appendix A: Glossary
+
+{{appendix_glossary}}
+
+### Appendix B: Requirements Index
+
+{{requirements_index}}

src/bmm/workflows/3-solutioning/create-syrs/workflow.md

@@ -0,0 +1,59 @@
+---
+name: create-syrs
+description: 'Create an ISO 29148 Clause 8 compliant System Requirements Specification (SyRS). Transforms stakeholder requirements (StRS) and product requirements (PRD) into system-level requirements with full traceability, verification planning, and lifecycle sustainability. Enterprise track workflow for structured requirements engineering.'
+---
+
+# System Requirements Specification Workflow
+
+**Goal:** Create a comprehensive ISO 29148 Clause 8 compliant System Requirements Specification through collaborative step-by-step requirements engineering, ensuring full traceability to StRS and PRD with verification methods assigned to every requirement.
+
+**Your Role:** In addition to your name, communication_style, and persona, you are also a System Architecture and Requirements Engineering specialist collaborating with a systems engineer. This is a partnership, not a client-vendor relationship. You bring expertise in ISO 29148 compliance, system-level requirements engineering, verification planning, and traceability analysis, while the user brings domain expertise, stakeholder context, and system knowledge. Work together as equals to produce a specification that enables consistent system implementation.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere to 1 file as directed at a time
+- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **LOAD NEXT**: When directed, read fully and follow the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🛑 **NEVER** load multiple step files simultaneously
+- 📖 **ALWAYS** read entire step file before execution
+- 🚫 **NEVER** skip steps or optimize the sequence
+- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+---
+
+## INITIALIZATION SEQUENCE
+
+### 1. Configuration Loading
+
+Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
+
+- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`
+- `date` as system-generated current datetime
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### 2. First Step EXECUTION
+
+Read fully and follow: `{project-root}/_bmad/bmm/workflows/3-solutioning/create-syrs/steps/step-01-init.md` to begin the workflow.

src/bmm/workflows/4-implementation/code-review/instructions.xml

@@ -94,6 +94,17 @@
       5. **Test Quality**: Are tests real assertions or placeholders?
     </action>
 
+    <!-- Enterprise Track: Requirements Verification Check -->
+    <action>If story has a "Requirements Traceability" section (Enterprise track):
+      1. **Verification Method Check**: For each referenced requirement, check if the specified verification method is satisfied:
+         - **Test**: Are there actual tests that verify this requirement? Tests must exist and be meaningful.
+         - **Demonstration**: Can the implemented feature be demonstrated to satisfy the requirement?
+         - **Inspection**: Does the code implementation clearly match the requirement intent?
+         - **Analysis**: Are there calculations, models, or analysis artifacts that verify the requirement?
+      2. **Requirement Coverage**: Are ALL referenced PRD FRs actually addressed by the implementation?
+      3. If verification gaps found → HIGH SEVERITY finding: "Requirement {{REQ-ID}} verification method '{{method}}' not satisfied"
+    </action>
+
     <check if="total_issues_found lt 3">
       <critical>NOT LOOKING HARD ENOUGH - Find more problems!</critical>
       <action>Re-examine code for:

src/bmm/workflows/4-implementation/sprint-planning/instructions.md

@@ -144,7 +144,28 @@ development_status:
 <action>Ensure all items are ordered: epic, its stories, its retrospective, next epic...</action>
 </step>
 
-<step n="5" goal="Validate and report">
+<step n="5" goal="Enterprise track: requirements traceability enrichment">
+<action>Check if the project is Enterprise track (look for StRS/SyRS/RTM documents or PRD frontmatter `track: enterprise`)</action>
+
+<action>If Enterprise track, enrich the sprint status with a requirements traceability comment block:</action>
+
+```yaml
+# REQUIREMENTS TRACEABILITY (Enterprise Track):
+# =============================================
+# This section maps stories to their source requirements for traceability.
+# Format: story-key: [PRD FR IDs] ← [SyRS IDs] ← [StRS IDs]
+#
+# requirements_trace:
+#   1-1-user-authentication: [FR-AUTH-001, FR-AUTH-002] ← [SYS-FUNC-001] ← [STK-BIZ-001]
+#   1-2-account-management: [FR-AUTH-003] ← [SYS-FUNC-002] ← [STK-BIZ-001]
+```
+
+<action>Extract requirement ID references from each story's "Requirements Traceability" section (if present in epics document)</action>
+<action>Add as YAML comments to sprint status for reference during development</action>
+<action>If no requirement traceability found in stories, add a note suggesting to run the RTM workflow</action>
+</step>
+
+<step n="6" goal="Validate and report">
 <action>Perform validation checks:</action>
 
 - [ ] Every epic in epic files appears in {status_file}

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

@@ -36,4 +36,31 @@ Run the tests using your project's test command.
 
 ---
 
+## Enterprise Track: TEA Module Integration
+
+**When the TEA (Test Architecture Enterprise) module is installed, verify these additional items:**
+
+### TEA Workflow Completion
+
+- [ ] TEA TD (Test Design) has been run and test strategy document exists
+- [ ] TEA TR (Traceability) has been run and test-requirement traceability matrix exists
+- [ ] TEA NR (NFR Assessment) has been run if NFRs are present in the PRD
+- [ ] TEA gate decision has been obtained (PASS / CONCERNS / FAIL)
+
+### TEA Quality Gate
+
+- [ ] TEA quality gate result is PASS or CONCERNS (FAIL blocks progression)
+- [ ] If CONCERNS: issues documented and accepted by stakeholders
+- [ ] RTM test columns populated from TEA TR output
+- [ ] No orphan tests exist (every test traces to a requirement)
+
+### Enterprise Test Metrics (from TEA outputs)
+
+- [ ] Test coverage by requirement documented (from TEA TR)
+- [ ] Test coverage by risk level P0-P3 documented (from TEA TD)
+- [ ] NFR compliance status documented (from TEA NR)
+- [ ] Full traceability chain verified: Test → Story → FR → SyRS → StRS
+
+---
+
 **Need more comprehensive testing?** Install [Test Architect (TEA)](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/) for advanced workflows.

src/bmm/workflows/shared/change-management/checklist.md

@@ -0,0 +1,53 @@
+# Requirements Change Management - Validation Checklist
+
+## Change Request Completeness
+
+- [ ] Change request has unique ID (CR-###)
+- [ ] Change title clearly describes the modification
+- [ ] Change category identified (New / Modification / Deletion / Clarification)
+- [ ] Priority assigned (Must / Should / Could / Won't)
+- [ ] Rationale provided explaining why the change is needed
+- [ ] Source identified (stakeholder, technical finding, defect, etc.)
+- [ ] Affected requirements listed with current and proposed text
+
+## Impact Analysis
+
+- [ ] All affected requirement documents identified
+- [ ] Impact level assessed for each document (None / Low / Medium / High)
+- [ ] RTM traceability chain traced for affected requirements
+- [ ] Scope impact assessed (Increase / Decrease / Neutral)
+- [ ] Effort estimate provided (Minimal / Moderate / Significant)
+- [ ] Timeline impact assessed (None / Minor delay / Major delay)
+- [ ] Risk assessment completed (Low / Medium / High)
+
+## Baseline Comparison
+
+- [ ] Current baseline version documented
+- [ ] Baseline state vs. proposed state compared
+- [ ] All deviations from baseline clearly documented
+
+## Approval Process
+
+- [ ] Change request presented to appropriate decision maker
+- [ ] Decision recorded (Approved / Rejected / Deferred)
+- [ ] Decision rationale documented
+- [ ] If deferred: conditions for revisiting specified
+
+## Implementation (After Approval)
+
+- [ ] All affected requirement documents updated
+- [ ] Requirement attributes updated (status, change reference)
+- [ ] RTM updated with new/modified traceability links
+- [ ] No orphan requirements created by the change
+- [ ] No broken traceability links after the change
+- [ ] Downstream artifacts update plan created (stories, tests, architecture)
+- [ ] Baseline version incremented in all affected documents
+- [ ] Change log entries added to all affected documents
+- [ ] Change request status updated to "IMPLEMENTED"
+
+## Post-Implementation Verification
+
+- [ ] Cross-document consistency verified (no terminology conflicts)
+- [ ] RTM integrity verified (forward and backward traceability intact)
+- [ ] No scope creep introduced beyond approved change
+- [ ] Change history file updated and searchable

src/bmm/workflows/shared/change-management/workflow.md

@@ -0,0 +1,190 @@
+---
+name: requirements-change-management
+description: Formal requirements change control process for managing modifications to baselined requirements. Enterprise track workflow.
+track: enterprise
+---
+
+# Requirements Change Management Workflow
+
+**Goal:** Provide a formal, traceable process for requesting, analyzing, approving, and implementing changes to baselined requirements.
+
+**Your Role:** You are a Change Control Analyst. Your job is to ensure every requirements change is properly documented, impact-analyzed, approved, and traced through the full requirements chain.
+
+**Track:** This workflow is primarily for the **Enterprise** track (mandatory). It is available but optional for **BMad Method** track.
+
+---
+
+## CHANGE MANAGEMENT ARCHITECTURE
+
+This is a **single-pass analytical workflow** (not step-file based). It guides the user through the complete change control cycle.
+
+### Critical Rules
+
+- 🔐 **NEVER** modify baselined requirements without a formal change request
+- 📋 **ALWAYS** perform impact analysis before approving any change
+- 🔗 **ALWAYS** update RTM after implementing any requirement change
+- ⚠️ **ALWAYS** assess downstream impact (stories, tests, architecture)
+- 💾 **ALWAYS** increment baseline version after approved changes are implemented
+- 🚫 **NEVER** implement changes without explicit user approval
+
+---
+
+## INITIALIZATION
+
+### 1. Configuration Loading
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve project variables.
+
+### 2. Context Discovery
+
+Discover and load all available requirement documents:
+
+- **StRS:** `{planning_artifacts}/*strs*.md`
+- **SyRS:** `{planning_artifacts}/*syrs*.md`
+- **PRD/SRS:** `{planning_artifacts}/*prd*.md`
+- **Architecture:** `{planning_artifacts}/*architecture*.md`
+- **Epics:** `{planning_artifacts}/*epic*.md`
+- **RTM:** `{planning_artifacts}/*rtm*.md`
+- **UX Design:** `{planning_artifacts}/*ux*.md`
+
+Report which documents were found and their current baseline versions (from frontmatter).
+
+### 3. Change Mode Detection
+
+Ask the user which mode to operate in:
+
+- **[NC] New Change Request:** Create a new change request from scratch
+- **[RC] Review Change:** Review and decide on an existing change request
+- **[IC] Implement Change:** Implement an approved change request
+- **[SH] Change History:** View change history and statistics
+
+---
+
+## MODE: NEW CHANGE REQUEST (NC)
+
+### Step 1: Capture Change Details
+
+Ask the user:
+1. **What is changing?** (specific requirement ID or general area)
+2. **Why is it changing?** (stakeholder feedback, technical discovery, defect, scope refinement)
+3. **What is the proposed new state?** (new requirement text, modification, or deletion)
+
+### Step 2: Locate Affected Requirements
+
+Using the discovered documents:
+1. Find the specific requirement(s) being changed
+2. Follow traceability links in RTM to identify all connected requirements
+3. Build the complete impact chain: StRS → SyRS → PRD → Stories → Tests
+
+### Step 3: Impact Analysis
+
+For each affected document, assess:
+
+**Document Impact Assessment:**
+
+| Document | Impact Level | Specific Changes Needed |
+|----------|-------------|------------------------|
+| StRS | None / Low / Medium / High | Details |
+| SyRS | None / Low / Medium / High | Details |
+| PRD/SRS | None / Low / Medium / High | Details |
+| Architecture | None / Low / Medium / High | Details |
+| UX Design | None / Low / Medium / High | Details |
+| Epics & Stories | None / Low / Medium / High | Details |
+| Test Cases | None / Low / Medium / High | Details |
+
+**Scope Impact:**
+- Does this increase, decrease, or maintain current scope?
+- Estimated effort impact (Minimal / Moderate / Significant)
+- Timeline risk (None / Minor / Major)
+
+### Step 4: Generate Change Request
+
+Create the formal change request document using the template at `{project-root}/_bmad/bmm/workflows/shared/templates/change-request-template.md`.
+
+Populate all sections with the analysis results.
+
+Save to: `{planning_artifacts}/change-requests/{{change_id}}.md`
+
+### Step 5: Present for Decision
+
+Present the change request summary to the user with:
+- Clear statement of what's changing and why
+- Impact analysis summary (highlight HIGH impact areas)
+- Recommendation: Approve / Reject / Defer
+- If approving, outline the implementation plan
+
+**Menu:**
+- **[A] Approve** - Mark as approved, proceed to implementation guidance
+- **[R] Reject** - Mark as rejected with rationale
+- **[D] Defer** - Mark as deferred with conditions for revisiting
+- **[M] Modify** - Revise the change request before deciding
+
+---
+
+## MODE: IMPLEMENT CHANGE (IC)
+
+### Step 1: Load Approved Change Request
+
+Load the specified change request file. Verify status is "APPROVED".
+
+### Step 2: Document Update Checklist
+
+For each affected document, guide the user through updates:
+
+1. **Update requirement text** in the source document
+2. **Update requirement attributes** (status → "Modified", change reference)
+3. **Update RTM** with new traceability links
+4. **Update downstream artifacts** (stories, tests)
+
+### Step 3: Baseline Version Increment
+
+After all changes are implemented:
+1. Increment the baseline version in all affected document frontmatters
+2. Add change log entry to each affected document
+3. Update the change request status to "IMPLEMENTED"
+
+### Step 4: Verification
+
+Run the cross-document validation workflow to ensure consistency after changes:
+- Terminology still consistent across documents?
+- No broken traceability links?
+- No orphan requirements created?
+
+---
+
+## MODE: CHANGE HISTORY (SH)
+
+Scan `{planning_artifacts}/change-requests/` directory for all change request files.
+
+Present a summary table:
+
+| CR ID | Title | Status | Priority | Date | Impact |
+|-------|-------|--------|----------|------|--------|
+| CR-001 | ... | Approved | Must | ... | High |
+
+Provide statistics:
+- Total change requests
+- By status (Proposed / Approved / Rejected / Deferred / Implemented)
+- By priority (Must / Should / Could)
+- By impact level
+
+---
+
+## SUCCESS METRICS:
+
+✅ Change request properly documented with all required fields
+✅ Impact analysis covers all requirement documents and downstream artifacts
+✅ RTM traceability links identified for affected requirements
+✅ Clear approval decision with rationale
+✅ Implementation plan includes all affected documents
+✅ Baseline version management maintained
+✅ Change history searchable and complete
+
+## FAILURE MODES:
+
+❌ Modifying baselined requirements without formal change request
+❌ Incomplete impact analysis (missing downstream effects)
+❌ Not updating RTM after implementing changes
+❌ Not incrementing baseline version after changes
+❌ Approving changes without assessing scope/timeline impact
+❌ Not notifying downstream agents/workflows of changes

src/bmm/workflows/shared/cross-document-validation/workflow.md

@@ -0,0 +1,294 @@
+---
+name: cross-document-validation
+description: Systematic validation of consistency and alignment across all requirement documents in the project. Enterprise track workflow with BMad Method optional use.
+track: enterprise
+---
+
+# Cross-Document Validation Workflow
+
+**Goal:** Systematically verify that all requirement documents (StRS, SyRS, PRD/SRS, Architecture, UX, Epics) are internally consistent, properly aligned, and maintain full traceability.
+
+**Your Role:** You are a Consistency Auditor. Your job is to find every contradiction, gap, terminology mismatch, and broken traceability link across all project documents. You are THOROUGH and UNFORGIVING - inconsistencies cause implementation failures.
+
+**Track:** This workflow is primarily for the **Enterprise** track (mandatory before implementation). Available but optional for **BMad Method** track.
+
+---
+
+## CROSS-DOCUMENT VALIDATION ARCHITECTURE
+
+This is a **single-pass analytical workflow** (not step-file based). It loads all documents and performs systematic cross-referencing.
+
+### Critical Rules
+
+- 🔐 **NEVER** declare consistency without checking every document pair
+- 📖 **ALWAYS** load and read ALL available requirement documents fully
+- 🔗 **ALWAYS** verify both forward AND backward traceability
+- ⚠️ **ALWAYS** report findings with specific document locations and quotes
+- 💾 **ALWAYS** produce a consistency report with actionable findings
+- 🚫 **NEVER** assume consistency - verify everything explicitly
+
+---
+
+## INITIALIZATION
+
+### 1. Configuration Loading
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve project variables.
+
+### 2. Document Discovery
+
+Search for and load ALL available requirement documents:
+
+| Document | Search Pattern | Required? |
+|----------|---------------|-----------|
+| StRS | `{planning_artifacts}/*strs*.md` | Enterprise: Yes |
+| SyRS | `{planning_artifacts}/*syrs*.md` | Enterprise: Yes |
+| PRD/SRS | `{planning_artifacts}/*prd*.md` | All tracks: Yes |
+| Architecture | `{planning_artifacts}/*architecture*.md` | BMad+Enterprise: Yes |
+| UX Design | `{planning_artifacts}/*ux*.md` | Optional |
+| Epics & Stories | `{planning_artifacts}/*epic*.md` | All tracks: Yes |
+| RTM | `{planning_artifacts}/*rtm*.md` | Enterprise: Yes |
+| Product Brief | `{planning_artifacts}/*brief*.md` | Optional (reference) |
+
+Report which documents were found and which are missing.
+
+---
+
+## VALIDATION PHASE 1: Terminology Consistency
+
+### 1.1 Term Extraction
+
+From each document, extract:
+- Key domain terms and their definitions
+- Actor/user role names
+- System component names
+- Feature/capability names
+
+### 1.2 Terminology Cross-Check
+
+| Check | Description |
+|-------|-------------|
+| **Same concept, different names** | Is "user" called "customer" in one doc and "end-user" in another? |
+| **Same name, different meanings** | Does "admin" mean different things in different documents? |
+| **Undefined terms** | Terms used but never defined in any glossary |
+| **Conflicting definitions** | Same term defined differently in different glossaries |
+
+**Output:** Terminology Consistency Matrix with all findings.
+
+---
+
+## VALIDATION PHASE 2: Requirements Alignment
+
+### 2.1 StRS ↔ PRD/SRS Alignment (Enterprise)
+
+For each StRS stakeholder requirement:
+- [ ] Is it traced forward to at least one PRD requirement?
+- [ ] Does the PRD requirement accurately reflect the stakeholder need?
+- [ ] Is the scope of the PRD requirement within the StRS scope?
+
+For each PRD requirement:
+- [ ] Does it trace back to a StRS stakeholder need?
+- [ ] If not traceable to StRS, is it justified (derived requirement)?
+
+**Check for:**
+- StRS requirements with no PRD coverage (orphans)
+- PRD requirements not traceable to StRS (scope creep or derived)
+- Scope contradictions (PRD exceeds StRS boundaries)
+- Priority mismatches (StRS Must → PRD Could = inconsistency)
+
+### 2.2 SyRS ↔ PRD Alignment (Enterprise)
+
+For each SyRS system requirement:
+- [ ] Is it traceable to a PRD requirement?
+- [ ] Does the system-level requirement correctly decompose the software requirement?
+
+For each PRD functional requirement:
+- [ ] Is there a corresponding SyRS system requirement?
+- [ ] Are the system-level constraints compatible with the PRD requirement?
+
+**Check for:**
+- SyRS requirements without PRD traceability
+- PRD requirements without SyRS system-level mapping
+- Interface specification contradictions
+- Performance/quality attribute mismatches
+
+### 2.3 StRS ↔ SyRS Alignment (Enterprise)
+
+- [ ] SyRS system scope aligns with StRS operational concept
+- [ ] SyRS interfaces cover all StRS operational scenarios
+- [ ] SyRS constraints are compatible with StRS project constraints
+- [ ] SyRS quality attributes meet StRS operational quality expectations
+
+---
+
+## VALIDATION PHASE 3: Architecture Alignment
+
+### 3.1 Architecture ↔ PRD Alignment
+
+- [ ] Every PRD functional requirement is addressable by the architecture
+- [ ] Architecture tech stack supports all PRD non-functional requirements
+- [ ] Architecture data model supports all PRD data-related requirements
+- [ ] No architecture decisions contradict PRD requirements
+- [ ] API design covers all PRD functional capabilities
+
+### 3.2 Architecture ↔ SyRS Alignment (Enterprise)
+
+- [ ] Architecture interfaces match SyRS interface specifications
+- [ ] Architecture performance characteristics meet SyRS quality requirements
+- [ ] Architecture security model satisfies SyRS security requirements
+- [ ] Architecture deployment model aligns with SyRS operational requirements
+
+### 3.3 Architecture ↔ UX Alignment (if UX exists)
+
+- [ ] Architecture API endpoints support all UX interaction patterns
+- [ ] Architecture data model supports all UX data display needs
+- [ ] Architecture performance targets enable responsive UX
+- [ ] No architecture constraints make UX designs infeasible
+
+---
+
+## VALIDATION PHASE 4: Epics & Stories Alignment
+
+### 4.1 Epics ↔ PRD Coverage
+
+- [ ] Every PRD functional requirement is covered by at least one story
+- [ ] Story acceptance criteria accurately reflect PRD requirement intent
+- [ ] No stories introduce features beyond PRD scope (scope creep)
+- [ ] Epic grouping aligns with PRD capability areas
+
+### 4.2 Stories ↔ Architecture Alignment
+
+- [ ] Stories reference correct architectural components
+- [ ] Story implementation approach is compatible with architecture decisions
+- [ ] Database stories align with architecture data model
+- [ ] API stories align with architecture API design
+
+### 4.3 Stories ↔ UX Alignment (if UX exists)
+
+- [ ] UI stories implement the correct UX designs
+- [ ] UX interaction patterns are captured in story acceptance criteria
+- [ ] All UX screens/flows have corresponding stories
+
+### 4.4 Stories ↔ SyRS Alignment (Enterprise)
+
+- [ ] Stories reference source requirement IDs (StRS/SyRS/PRD)
+- [ ] Story acceptance criteria support verification of system requirements
+- [ ] No stories implement features not traceable to system requirements
+
+---
+
+## VALIDATION PHASE 5: RTM Integrity (Enterprise)
+
+### 5.1 Forward Traceability
+
+- [ ] StRS → SyRS: Every StRS requirement traces to at least one SyRS requirement
+- [ ] SyRS → PRD: Every SyRS requirement traces to at least one PRD requirement
+- [ ] PRD → Stories: Every PRD requirement traces to at least one story
+- [ ] Stories → Tests: Every story has associated test references (if TEA module active)
+
+### 5.2 Backward Traceability
+
+- [ ] Tests → Stories: Every test traces back to a story
+- [ ] Stories → PRD: Every story traces back to a PRD requirement
+- [ ] PRD → SyRS: Every PRD requirement traces back to a SyRS requirement
+- [ ] SyRS → StRS: Every SyRS requirement traces back to a StRS requirement
+
+### 5.3 Orphan Detection
+
+- [ ] No StRS requirements without forward links
+- [ ] No SyRS requirements without forward OR backward links
+- [ ] No PRD requirements without forward links
+- [ ] No stories without backward links to requirements
+- [ ] No derived requirements without documented justification
+
+### 5.4 Coverage Statistics
+
+Calculate and report:
+- Forward traceability coverage % at each level
+- Backward traceability coverage % at each level
+- Number of orphan requirements per level
+- Number of derived (unlinked) requirements per level
+
+---
+
+## CONSISTENCY REPORT
+
+After completing all validation phases, produce a report:
+
+```markdown
+# Cross-Document Consistency Report - {{project_name}}
+
+**Date:** {{date}}
+**Assessed By:** {{agent_name}}
+**Documents Assessed:** {{list of documents found}}
+
+## Overall Consistency Score: [HIGH / MEDIUM / LOW / CRITICAL ISSUES]
+
+## Phase 1: Terminology Consistency
+
+| Finding | Severity | Documents | Details |
+|---------|----------|-----------|---------|
+| [Finding] | [Critical/High/Medium/Low] | [Doc A ↔ Doc B] | [Specific text] |
+
+## Phase 2: Requirements Alignment
+
+### StRS ↔ PRD
+| Check | Result | Details |
+|-------|--------|---------|
+
+### SyRS ↔ PRD
+| Check | Result | Details |
+|-------|--------|---------|
+
+## Phase 3: Architecture Alignment
+
+| Check | Result | Details |
+|-------|--------|---------|
+
+## Phase 4: Epics & Stories Alignment
+
+| Check | Result | Details |
+|-------|--------|---------|
+
+## Phase 5: RTM Integrity
+
+| Metric | Value | Target | Status |
+|--------|-------|--------|--------|
+| Forward Traceability (StRS→SyRS) | X% | >90% | PASS/FAIL |
+| Forward Traceability (SyRS→PRD) | X% | >90% | PASS/FAIL |
+| Forward Traceability (PRD→Stories) | X% | >95% | PASS/FAIL |
+| Orphan Requirements | N | 0 | PASS/FAIL |
+
+## Critical Issues Requiring Resolution
+
+| Issue | Severity | Documents | Resolution Required |
+|-------|----------|-----------|-------------------|
+
+## Recommendations
+
+[Prioritized list of actions to resolve consistency issues]
+```
+
+Save report to: `{planning_artifacts}/cross-document-validation-report-{{date}}.md`
+
+---
+
+## SUCCESS METRICS:
+
+✅ All available documents discovered and loaded
+✅ Terminology consistency checked across all document pairs
+✅ Requirements alignment verified at every level (StRS↔SyRS↔PRD)
+✅ Architecture alignment checked against requirements and UX
+✅ Epics & Stories coverage validated against PRD
+✅ RTM integrity verified with coverage statistics
+✅ Consistency report generated with specific, actionable findings
+
+## FAILURE MODES:
+
+❌ Missing documents not flagged
+❌ Terminology inconsistencies not caught
+❌ Orphan requirements not detected
+❌ Scope creep in stories not flagged
+❌ Broken traceability links not identified
+❌ Vague findings without specific document references
+❌ Not checking all document pair combinations

src/bmm/workflows/shared/quality-gate/workflow.md

@@ -0,0 +1,253 @@
+---
+name: quality-gate-check
+description: Phase-transition quality gate that validates all required artifacts are complete and consistent before allowing progression to the next development phase. Enterprise track workflow.
+track: enterprise
+---
+
+# Quality Gate Check Workflow
+
+**Goal:** Validate that all required artifacts for the current phase are complete, consistent, and of sufficient quality before allowing progression to the next phase.
+
+**Your Role:** You are a Quality Gate Inspector. Your job is to systematically verify completeness and consistency of all artifacts produced in the current phase. You are STRICT - incomplete or inconsistent artifacts BLOCK progression.
+
+**Track:** This workflow is primarily for the **Enterprise** track (mandatory). It is available but optional for **BMad Method** track.
+
+---
+
+## QUALITY GATE ARCHITECTURE
+
+This is a **single-pass validation workflow** (not step-file based). It identifies the current phase and runs the appropriate gate checks.
+
+### Critical Rules
+
+- 🔐 **NEVER** pass a gate with critical issues unresolved
+- 📖 **ALWAYS** load and verify ALL required artifacts
+- 🔗 **ALWAYS** check cross-document consistency
+- ⚠️ **ALWAYS** report findings honestly - no sugar-coating
+- 💾 **ALWAYS** produce a gate decision report
+
+---
+
+## INITIALIZATION
+
+### 1. Configuration Loading
+
+Load config from {project-root}/_bmad/bmm/config.yaml and resolve project variables.
+
+### 2. Phase Detection
+
+Determine which quality gate to run based on user request or artifact state:
+
+- **QG-1: Analysis → Planning** (Product Brief + StRS complete?)
+- **QG-2: Planning → Solutioning** (PRD + StRS + RTM complete and consistent?)
+- **QG-3: Solutioning → Implementation** (Architecture + SyRS + Epics + RTM + TEA Gate complete?)
+
+If unclear, ask user which gate to run.
+
+---
+
+## QUALITY GATE 1: Analysis → Planning
+
+**Required Artifacts:**
+- Product Brief (any track)
+- StRS (Enterprise track only)
+
+**Validation Checks:**
+
+### Product Brief Completeness
+- [ ] Product Brief exists and is substantive
+- [ ] Vision/mission clearly defined
+- [ ] Target audience identified
+- [ ] Key features or capabilities listed
+- [ ] Success metrics defined
+
+### StRS Completeness (Enterprise Only)
+- [ ] StRS exists and follows ISO 29148 Clause 7 structure
+- [ ] All 7 major sections present (Introduction, References, Business Mgmt, Operational, User, System Concept, Constraints)
+- [ ] Stakeholders identified with profiles
+- [ ] Business objectives are SMART
+- [ ] Operational scenarios documented
+- [ ] Project constraints specified
+- [ ] StRS status is at least 'review'
+
+### Cross-Document Consistency
+- [ ] StRS business purpose aligns with Product Brief vision
+- [ ] StRS stakeholders consistent with Product Brief target audience
+- [ ] No contradictions between documents
+
+### Gate Decision
+- **PASS:** All required artifacts complete and consistent → Proceed to Planning
+- **PASS WITH CONDITIONS:** Minor gaps noted but non-blocking → Proceed with documented risks
+- **FAIL:** Critical gaps or inconsistencies → Must resolve before proceeding
+
+---
+
+## QUALITY GATE 2: Planning → Solutioning
+
+**Required Artifacts:**
+- PRD/SRS (all tracks)
+- StRS (Enterprise track)
+- RTM initial version (Enterprise track)
+- UX Design (if UI project)
+
+**Validation Checks:**
+
+### PRD Completeness
+- [ ] PRD exists with all required sections
+- [ ] Functional requirements defined with proper format
+- [ ] Non-functional requirements defined
+- [ ] Success criteria measurable
+- [ ] User journeys documented
+- [ ] Enterprise: Interface requirements, constraints, verification plan present
+- [ ] Enterprise: All requirements have attributes (ID, priority, source, V&V)
+
+### StRS-PRD Consistency (Enterprise)
+- [ ] Every PRD FR traces to a stakeholder need in StRS
+- [ ] PRD scope doesn't exceed StRS scope
+- [ ] Terminology consistent between StRS and PRD
+- [ ] No contradictions between StRS and PRD
+
+### RTM Status (Enterprise)
+- [ ] RTM exists with StRS → PRD traceability
+- [ ] No orphan StRS requirements (all traced forward)
+- [ ] Forward traceability coverage > 80%
+
+### UX-PRD Alignment (if UX exists)
+- [ ] UX design covers all UI-relevant FRs
+- [ ] No UX features that aren't in PRD (scope creep)
+- [ ] UX handoff checklist completed
+
+### Gate Decision
+- **PASS:** All artifacts complete, consistent, and traced → Proceed to Solutioning
+- **PASS WITH CONDITIONS:** Minor gaps → Proceed with documented risks
+- **FAIL:** Critical gaps, broken traceability, or inconsistencies → Must resolve
+
+---
+
+## QUALITY GATE 3: Solutioning → Implementation
+
+**Required Artifacts:**
+- Architecture Document (BMad + Enterprise)
+- SyRS (Enterprise only)
+- Epics & Stories (all tracks)
+- RTM updated (Enterprise)
+- Implementation Readiness Report (recommended)
+- TEA Gate Decision (Enterprise with TEA installed)
+
+**Validation Checks:**
+
+### Architecture Completeness
+- [ ] Architecture document exists with technical decisions
+- [ ] Key ADRs (Architecture Decision Records) documented
+- [ ] Tech stack defined
+- [ ] Data model defined
+- [ ] API contracts defined (if applicable)
+
+### SyRS Completeness (Enterprise)
+- [ ] SyRS exists with ISO 29148 Clause 8 structure
+- [ ] System functional requirements mapped from PRD
+- [ ] System interfaces defined
+- [ ] Verification plan for system requirements
+- [ ] Traceability to StRS and PRD maintained
+
+### Epics & Stories Completeness
+- [ ] Epics cover all PRD functional requirements
+- [ ] Each story has acceptance criteria
+- [ ] Enterprise: Stories reference source requirement IDs
+- [ ] FR Coverage Map shows complete coverage
+- [ ] Stories are implementation-ready (clear, actionable)
+
+### RTM Completeness (Enterprise)
+- [ ] RTM updated with StRS → SyRS → PRD → Stories chain
+- [ ] No orphan requirements at any level
+- [ ] Forward traceability coverage > 90%
+- [ ] All requirement statuses updated
+
+### TEA Gate Integration (Enterprise with TEA)
+- [ ] TEA TD (Test Design) completed - test strategy exists
+- [ ] TEA TR (Traceability) completed - test traceability exists
+- [ ] TEA gate decision obtained: PASS / CONCERNS / FAIL
+- [ ] If TEA FAIL → This gate also FAILS (blocking)
+- [ ] If TEA CONCERNS → Document accepted risks
+
+### Cross-Document Consistency
+- [ ] Architecture aligns with PRD requirements
+- [ ] SyRS consistent with Architecture decisions
+- [ ] Epics/Stories don't introduce scope beyond PRD
+- [ ] No terminology conflicts across documents
+
+### Baseline Check (Enterprise)
+- [ ] All requirement documents ready for baseline
+- [ ] Version numbers assigned
+- [ ] Change history documented
+
+### Gate Decision
+- **PASS:** All artifacts complete, consistent, traced, TEA passed → Proceed to Implementation
+- **PASS WITH CONDITIONS:** Minor gaps, TEA CONCERNS accepted → Proceed with documented risks
+- **FAIL:** Critical gaps, broken traceability, TEA FAIL, or major inconsistencies → Must resolve
+
+---
+
+## GATE DECISION REPORT
+
+After running the appropriate gate, produce a report:
+
+```markdown
+# Quality Gate Report - {{project_name}}
+
+**Gate:** QG-[1|2|3] - [Phase A] → [Phase B]
+**Date:** {{date}}
+**Assessed By:** {{agent_name}}
+
+## Decision: [PASS | PASS WITH CONDITIONS | FAIL]
+
+## Artifacts Assessed
+
+| Artifact | Status | Issues |
+|----------|--------|--------|
+| [Name] | [✅ Complete / ⚠️ Partial / ❌ Missing] | [Details] |
+
+## Validation Results
+
+| Check | Result | Notes |
+|-------|--------|-------|
+| [Check name] | [PASS/FAIL] | [Details] |
+
+## Issues Requiring Resolution (if FAIL)
+
+| Issue | Severity | Resolution Required |
+|-------|----------|-------------------|
+| [Issue] | [Critical/High/Medium] | [What needs to happen] |
+
+## Accepted Risks (if PASS WITH CONDITIONS)
+
+| Risk | Impact | Mitigation |
+|------|--------|-----------|
+| [Risk] | [Impact] | [How to mitigate] |
+
+## Recommendation
+
+[Clear statement of whether to proceed, with any conditions]
+```
+
+Save report to: `{planning_artifacts}/quality-gate-report-qg[N]-{{date}}.md`
+
+---
+
+## SUCCESS METRICS:
+
+✅ Correct gate identified and run
+✅ All required artifacts discovered and assessed
+✅ Cross-document consistency checked
+✅ TEA gate decision integrated (if applicable)
+✅ Clear PASS/FAIL/CONDITIONS decision with justification
+✅ Report generated with actionable findings
+✅ Blocking issues clearly identified (if FAIL)
+
+## FAILURE MODES:
+
+❌ Passing a gate when critical artifacts are missing
+❌ Not checking cross-document consistency
+❌ Not integrating TEA gate decision for Enterprise track
+❌ Producing vague findings without specific artifacts/issues
+❌ Not saving the gate report

src/bmm/workflows/shared/rtm/checklist.md

@@ -0,0 +1,86 @@
+# Requirements Traceability Matrix (RTM) - Integrity Checklist
+
+## Document Structure
+
+- [ ] RTM document exists at the expected location
+- [ ] Forward Traceability table present and populated
+- [ ] Backward Traceability table present and populated
+- [ ] Coverage Analysis section present
+- [ ] Orphan Analysis section present
+- [ ] Requirement Status Summary present
+- [ ] Change History section present with at least one entry
+
+## Forward Traceability (StRS → SyRS → PRD → Stories → Tests)
+
+### StRS → SyRS Coverage
+
+- [ ] Every StRS requirement is referenced by at least one SyRS requirement
+- [ ] No StRS requirements listed as "orphan" (no forward link)
+- [ ] Forward traceability coverage > 90%
+- [ ] Derived SyRS requirements (no StRS source) are documented with justification
+
+### SyRS → PRD Coverage
+
+- [ ] Every SyRS requirement is referenced by at least one PRD requirement
+- [ ] No SyRS requirements listed as "orphan" (no forward link)
+- [ ] Forward traceability coverage > 90%
+- [ ] Derived PRD requirements (no SyRS source) are documented with justification
+
+### PRD → Stories Coverage
+
+- [ ] Every PRD functional requirement is covered by at least one story
+- [ ] No PRD requirements listed as "orphan" (no forward link)
+- [ ] Forward traceability coverage > 95%
+- [ ] FR Coverage Map in epics document is consistent with RTM
+
+### Stories → Tests Coverage (TEA module, if installed)
+
+- [ ] Every story acceptance criterion has at least one test reference
+- [ ] Test references are valid (test files/cases exist)
+- [ ] Test coverage by requirement is documented
+
+## Backward Traceability (Tests → Stories → PRD → SyRS → StRS)
+
+- [ ] Every story traces back to at least one PRD requirement
+- [ ] Every PRD requirement traces back to a SyRS requirement (or is marked as derived)
+- [ ] Every SyRS requirement traces back to a StRS requirement (or is marked as derived)
+- [ ] No orphan stories (stories without requirement traceability)
+
+## Orphan Detection
+
+- [ ] No orphan StRS requirements (requirements with no downstream links)
+- [ ] No orphan SyRS requirements (requirements with no upstream OR downstream links)
+- [ ] No orphan PRD requirements (requirements with no downstream links to stories)
+- [ ] No orphan stories (stories with no upstream links to requirements)
+- [ ] All identified orphans have been resolved or documented with justification
+
+## Requirement Status Consistency
+
+- [ ] Requirement statuses in RTM match statuses in source documents
+- [ ] No "Approved" requirements in RTM that are "Draft" in source document
+- [ ] Verification methods in RTM match those in source documents
+- [ ] Priority levels in RTM match those in source documents
+
+## Coverage Statistics
+
+- [ ] Overall forward traceability coverage calculated
+- [ ] Per-level coverage percentages documented
+- [ ] Coverage meets minimum thresholds:
+  - StRS → SyRS: > 90%
+  - SyRS → PRD: > 90%
+  - PRD → Stories: > 95%
+- [ ] Coverage trends noted (if RTM has been updated multiple times)
+
+## Cross-Document ID Consistency
+
+- [ ] Requirement IDs in RTM match exactly with source documents
+- [ ] No typos or mismatched IDs in traceability links
+- [ ] ID format is consistent across all levels (e.g., STK-BIZ-001, SYS-FUNC-001, FR-AUTH-001)
+- [ ] No duplicate requirement IDs within any single level
+
+## Change Tracking
+
+- [ ] RTM version matches latest document versions
+- [ ] Change history records when RTM was last updated
+- [ ] Any recent document changes are reflected in RTM
+- [ ] Baseline alignment noted (RTM baseline matches document baselines)

src/bmm/workflows/shared/rtm/workflow.md

@@ -0,0 +1,182 @@
+---
+name: create-update-rtm
+description: Generate or update the Requirements Traceability Matrix (RTM) by scanning all requirement documents and mapping bidirectional traceability. Enterprise track workflow.
+track: enterprise
+---
+
+# Requirements Traceability Matrix (RTM) Workflow
+
+**Goal:** Generate or update the RTM by scanning all requirement documents (StRS, SyRS, PRD/SRS, Epics/Stories) and creating bidirectional traceability links with gap analysis.
+
+**Your Role:** You are a Requirements Traceability specialist. Your job is to systematically scan all requirement documents, extract requirement IDs, and map the traceability chain. This is a systematic, analytical task.
+
+**Track:** This workflow is part of the **Enterprise** track.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This is a **single-pass analytical workflow** (not step-file based). It runs as a complete analysis task.
+
+### Critical Rules
+
+- 📖 **ALWAYS** load ALL requirement documents before analysis
+- 🔗 **ALWAYS** trace in both directions (forward and backward)
+- 🔍 **ALWAYS** identify orphan items (unlinked requirements, stories, tests)
+- ⚠️ **NEVER** fabricate traceability links that don't exist in documents
+- 💾 **ALWAYS** save the RTM to the output file
+
+---
+
+## INITIALIZATION SEQUENCE
+
+### 1. Configuration Loading
+
+Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
+
+- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
+- `communication_language`, `document_output_language`
+- `date` as system-generated current datetime
+
+✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
+
+### 2. Document Discovery
+
+Search for all requirement documents:
+
+**Required Documents (load if found):**
+- StRS: `{planning_artifacts}/*strs*.md`
+- SyRS: `{planning_artifacts}/*syrs*.md`
+- PRD/SRS: `{planning_artifacts}/*prd*.md`
+- Epics & Stories: `{planning_artifacts}/*epic*.md`
+
+**Optional Documents:**
+- Test documents: `{implementation_artifacts}/tests/**`
+- Story files: `{implementation_artifacts}/*story*.md`
+
+**Report to user what was found and what's missing.**
+
+### 3. Check for Existing RTM
+
+Look for existing RTM: `{planning_artifacts}/rtm-{{project_name}}.md`
+- If exists: Load and update (preserve change history)
+- If not exists: Create new from template
+
+---
+
+## RTM GENERATION SEQUENCE
+
+### Step 1: Extract All Requirement IDs
+
+Scan each document and extract all requirement identifiers:
+
+**From StRS:**
+- Look for patterns: `BO-###`, `OP-###`, `UP-###`, `OS-###`, `BC-###`, `TC-###`, `RC-###`
+- Or any consistent ID pattern in the document
+
+**From SyRS:**
+- Look for patterns: `SYS-###`, `SYS-FUNC-###`, `SYS-IF-###`, `SYS-PERF-###`
+- Or any consistent ID pattern in the document
+
+**From PRD/SRS:**
+- Look for patterns: `FR-###`, `FR#`, `NFR-###`
+- Look for Enterprise format: `FR-[AREA]-###`, `NFR-[AREA]-###`
+- Or any consistent ID pattern in the document
+
+**From Epics/Stories:**
+- Look for Epic numbers: `Epic N`, `Story N.M`
+- Look for acceptance criteria patterns
+
+### Step 2: Map Forward Traceability
+
+For each requirement at each level, find its downstream references:
+
+**StRS → SyRS:** Match by content similarity, explicit references, or source fields
+**SyRS → PRD:** Match by content similarity, explicit references, or source fields
+**PRD → Stories:** Match by FR references in stories, acceptance criteria alignment
+**Stories → Tests:** Match by test descriptions, acceptance criteria references
+
+### Step 3: Map Backward Traceability
+
+Verify backward links exist:
+- Each test traces to a story
+- Each story traces to a PRD requirement
+- Each PRD requirement traces to SyRS (if SyRS exists)
+- Each SyRS requirement traces to StRS (if StRS exists)
+
+### Step 4: Identify Orphans and Gaps
+
+**Orphan Requirements:** Requirements with no downstream trace
+- These represent features that will NOT be implemented unless addressed
+
+**Orphan Stories:** Stories with no upstream requirement trace
+- These represent scope creep or undocumented requirements
+
+**Orphan Tests:** Tests with no story or requirement trace
+- These represent untraceable testing effort
+
+**Coverage Gaps:** Downstream levels with missing upstream links
+- These represent broken traceability chains
+
+### Step 5: Generate Coverage Statistics
+
+Calculate:
+- Forward traceability coverage percentage per level
+- Total requirements per status (proposed, approved, implemented, verified)
+- Orphan count per category
+
+### Step 6: Generate RTM Document
+
+Create or update the RTM document at: `{planning_artifacts}/rtm-{{project_name}}.md`
+
+Use the template from: `{project-root}/_bmad/bmm/workflows/shared/templates/rtm-template.md`
+
+Fill in all tables with extracted data.
+
+### Step 7: Present Results
+
+**Report to user:**
+
+"**RTM Analysis Complete for {{project_name}}**
+
+**Documents Scanned:**
+- StRS: [found/not found] - [X requirements extracted]
+- SyRS: [found/not found] - [X requirements extracted]
+- PRD/SRS: [found/not found] - [X requirements extracted]
+- Epics/Stories: [found/not found] - [X stories extracted]
+
+**Traceability Coverage:**
+- StRS → SyRS: [X%]
+- SyRS → PRD: [X%]
+- PRD → Stories: [X%]
+- Stories → Tests: [X%]
+
+**Issues Found:**
+- Orphan requirements: [count]
+- Orphan stories: [count]
+- Orphan tests: [count]
+
+**RTM saved to:** `{planning_artifacts}/rtm-{{project_name}}.md`
+
+**Recommendations:** [List any actions needed to improve traceability]"
+
+---
+
+## SUCCESS METRICS:
+
+✅ All available requirement documents discovered and scanned
+✅ Requirement IDs extracted from all documents
+✅ Forward traceability mapped (StRS→SyRS→PRD→Stories→Tests)
+✅ Backward traceability mapped (Tests→Stories→PRD→SyRS→StRS)
+✅ Orphan items identified with clear actions needed
+✅ Coverage statistics calculated accurately
+✅ RTM document generated/updated with all data
+✅ Clear summary presented to user
+
+## FAILURE MODES:
+
+❌ Not scanning all available documents
+❌ Fabricating traceability links that don't exist
+❌ Missing orphan identification
+❌ Not providing actionable recommendations
+❌ Not preserving change history when updating existing RTM

src/bmm/workflows/shared/templates/change-request-template.md

@@ -0,0 +1,118 @@
+---
+change_id: "CR-{{sequence_number}}"
+title: "{{change_title}}"
+date_submitted: "{{date}}"
+submitted_by: "{{agent_name}}"
+status: "proposed"
+priority: "{{Must|Should|Could|Won't}}"
+baseline_version: "{{current_baseline_version}}"
+---
+
+# Requirements Change Request: {{change_id}}
+
+## 1. Change Identification
+
+| Field | Value |
+|-------|-------|
+| **Change ID** | {{change_id}} |
+| **Title** | {{change_title}} |
+| **Date Submitted** | {{date}} |
+| **Submitted By** | {{agent_name}} |
+| **Priority** | {{Must / Should / Could / Won't}} |
+| **Category** | {{New Requirement / Modification / Deletion / Clarification}} |
+
+## 2. Change Description
+
+### What is being changed?
+
+{{Detailed description of the proposed change}}
+
+### Rationale
+
+{{Why this change is necessary - link to stakeholder need, user feedback, technical discovery, or defect}}
+
+### Source
+
+{{Where did this change request originate - stakeholder name, user interview, technical finding, etc.}}
+
+## 3. Affected Requirements
+
+| Requirement ID | Document | Current Text | Proposed Change |
+|---------------|----------|-------------|-----------------|
+| {{REQ-ID}} | {{StRS/SyRS/PRD}} | {{Current requirement text}} | {{New/modified text or "DELETE"}} |
+
+## 4. Impact Analysis
+
+### 4.1 Document Impact
+
+| Document | Impact Level | Description |
+|----------|-------------|-------------|
+| StRS | {{None / Low / Medium / High}} | {{What changes needed}} |
+| SyRS | {{None / Low / Medium / High}} | {{What changes needed}} |
+| PRD/SRS | {{None / Low / Medium / High}} | {{What changes needed}} |
+| Architecture | {{None / Low / Medium / High}} | {{What changes needed}} |
+| UX Design | {{None / Low / Medium / High}} | {{What changes needed}} |
+| Epics & Stories | {{None / Low / Medium / High}} | {{What changes needed}} |
+| Test Cases | {{None / Low / Medium / High}} | {{What changes needed}} |
+
+### 4.2 RTM Impact
+
+| Traceability Chain | Affected? | Details |
+|-------------------|----------|---------|
+| StRS → SyRS | {{Yes/No}} | {{Which links affected}} |
+| SyRS → PRD | {{Yes/No}} | {{Which links affected}} |
+| PRD → Stories | {{Yes/No}} | {{Which links affected}} |
+| Stories → Tests | {{Yes/No}} | {{Which links affected}} |
+
+### 4.3 Scope Impact
+
+- **Scope Change:** {{Increase / Decrease / Neutral}}
+- **Effort Estimate:** {{Minimal / Moderate / Significant}}
+- **Timeline Impact:** {{None / Minor delay / Major delay}}
+- **Risk Assessment:** {{Low / Medium / High}}
+
+## 5. Baseline Comparison
+
+**Current Baseline Version:** {{baseline_version}}
+
+| Aspect | Baseline State | Proposed State |
+|--------|---------------|---------------|
+| {{Requirement count}} | {{N}} | {{N+/-M}} |
+| {{Scope boundary}} | {{Current}} | {{Proposed}} |
+| {{Architecture impact}} | {{Current}} | {{Proposed}} |
+
+## 6. Approval
+
+| Role | Decision | Date | Notes |
+|------|---------|------|-------|
+| Product Manager | {{Approved / Rejected / Deferred}} | {{date}} | {{notes}} |
+| Architect | {{Approved / Rejected / Deferred}} | {{date}} | {{notes}} |
+| Stakeholder | {{Approved / Rejected / Deferred}} | {{date}} | {{notes}} |
+
+**Final Decision:** {{APPROVED / REJECTED / DEFERRED}}
+
+## 7. Implementation Plan
+
+### 7.1 Document Updates Required
+
+- [ ] StRS updated (if affected)
+- [ ] SyRS updated (if affected)
+- [ ] PRD/SRS updated (if affected)
+- [ ] Architecture updated (if affected)
+- [ ] UX Design updated (if affected)
+- [ ] Epics & Stories updated (if affected)
+- [ ] RTM updated with new traceability links
+- [ ] Test cases updated (if affected)
+- [ ] Baseline version incremented
+
+### 7.2 Downstream Notifications
+
+| Workflow/Agent | Action Required |
+|---------------|----------------|
+| {{Agent/Workflow}} | {{What needs to happen}} |
+
+## 8. Change History
+
+| Date | Action | By | Details |
+|------|--------|-----|---------|
+| {{date}} | Created | {{agent}} | Initial change request |

src/bmm/workflows/shared/templates/context-guard-rules.md

@@ -0,0 +1,39 @@
+# Context Guard Rules - Enterprise Track
+
+These rules MUST be followed by all agents when working with requirement documents in Enterprise track projects. They prevent common AI agent errors that can corrupt the requirements chain.
+
+## Requirement Modification Rules
+
+- **BASELINE CHECK:** Before modifying any requirement, verify the document's current `baseline_version` in frontmatter. If a baseline exists, changes MUST go through the change management workflow (`RM` command).
+- **RTM UPDATE:** After any requirement change (add, modify, delete), the Requirements Traceability Matrix MUST be updated. Never leave the RTM out of sync.
+- **TRACEABILITY:** Every new requirement MUST have a `Source` attribute referencing its origin (stakeholder need, StRS requirement, or technical derivation).
+- **QUALITY:** Every new or modified requirement MUST satisfy the 9 ISO quality criteria: necessary, implementation-free, unambiguous, consistent, complete, singular, feasible, traceable, verifiable.
+- **SCOPE GUARD:** NEVER add requirements that are not traceable to a stakeholder need or documented derivation. If a new need is discovered, it must be documented as a change request.
+
+## Document Integrity Rules
+
+- **VERSION TRACKING:** Always update `version` in frontmatter when modifying a requirement document. Use semantic versioning (1.0.0 → 1.1.0 for additions, 1.0.0 → 1.0.1 for corrections).
+- **CHANGE LOG:** Always add an entry to the document's change history when making modifications.
+- **STATUS MANAGEMENT:** Document status progresses: `draft` → `review` → `approved` → `baseline`. Never skip states. Never revert from `baseline` without a formal change request.
+- **UNIQUE IDs:** Never reuse a deleted requirement's ID. Maintain ID sequence continuity without gaps.
+
+## Cross-Document Consistency Rules
+
+- **TERMINOLOGY:** Use terms consistently across all documents. If a concept is named "user" in the StRS, it must be "user" in the SyRS, PRD, and stories - not "customer", "end-user", or "client" interchangeably.
+- **SCOPE ALIGNMENT:** PRD scope must not exceed StRS scope. SyRS scope must not exceed PRD scope. Stories must not introduce features beyond PRD scope.
+- **PRIORITY CONSISTENCY:** A requirement's priority should not increase downstream without justification (e.g., StRS "Should" should not become PRD "Must" without documented rationale).
+- **CONTRADICTION DETECTION:** If you detect a contradiction between documents, STOP and flag it to the user. Do not silently resolve contradictions.
+
+## Assumption Management Rules
+
+- **NO SILENT ASSUMPTIONS:** Never fill in missing requirement details with assumptions. If information is missing, ask the user.
+- **DOCUMENT ASSUMPTIONS:** If an assumption must be made to proceed, document it explicitly in the document's Assumptions section.
+- **VALIDATE ASSUMPTIONS:** When loading input documents, verify that assumptions from upstream documents have been validated or still hold.
+
+## Usage
+
+These rules should be referenced by Enterprise track workflow steps. Include this at the beginning of content-generation steps:
+
+```markdown
+**Enterprise Track Context Guards Active.** All requirement modifications follow formal change control.
+```

src/bmm/workflows/shared/templates/document-versioning-guide.md

@@ -0,0 +1,99 @@
+# Document Versioning and Approval Guide - Enterprise Track
+
+## Frontmatter Standard
+
+All Enterprise track requirement documents MUST include these frontmatter fields:
+
+```yaml
+---
+version: "1.0.0"
+status: "draft"
+baseline_version: null
+track: "enterprise"
+last_updated: "{{date}}"
+last_updated_by: "{{agent_name}}"
+change_log:
+  - version: "1.0.0"
+    date: "{{date}}"
+    change: "Initial creation"
+    by: "{{agent_name}}"
+---
+```
+
+## Version Numbering
+
+Follow semantic versioning for requirement documents:
+
+| Change Type | Version Bump | Example |
+|------------|-------------|---------|
+| Initial creation | 1.0.0 | First draft |
+| New requirements added | +0.1.0 | 1.0.0 → 1.1.0 |
+| Requirement modifications | +0.1.0 | 1.1.0 → 1.2.0 |
+| Corrections/typos | +0.0.1 | 1.2.0 → 1.2.1 |
+| Major restructuring | +1.0.0 | 1.2.1 → 2.0.0 |
+| Post-baseline changes | +0.1.0 minimum | Via change request only |
+
+## Document Status Lifecycle
+
+```
+draft → review → approved → baseline
+  ↑                           |
+  └──── (change request) ─────┘
+```
+
+### Status Definitions
+
+| Status | Meaning | Who Can Transition |
+|--------|---------|-------------------|
+| **draft** | Document is being created or actively modified | Any agent during workflow |
+| **review** | Document is complete and ready for quality validation | Workflow completion step |
+| **approved** | Document has passed quality validation | User confirmation |
+| **baseline** | Document is locked for reference; changes require formal CR | User explicit approval |
+
+### Transition Rules
+
+1. `draft` → `review`: Workflow completion step sets this automatically
+2. `review` → `approved`: User confirms after validation workflow passes
+3. `approved` → `baseline`: User explicitly baselines (typically at phase transition quality gate)
+4. `baseline` → `draft` (new version): Only via approved Change Request (CR)
+
+## Baseline Management
+
+### When to Baseline
+
+- At each quality gate (QG-1, QG-2, QG-3) for documents assessed
+- Before starting the next development phase
+- When all stakeholders agree the document is stable
+
+### Baseline Rules
+
+1. Record `baseline_version` in frontmatter (matches current `version`)
+2. All requirement IDs are frozen at baseline
+3. Changes after baseline require formal Change Request
+4. Previous baseline versions should be noted in change log
+
+## Change Log Format
+
+Each change log entry should include:
+
+```yaml
+change_log:
+  - version: "1.2.0"
+    date: "2024-01-15"
+    change: "Added FR-AUTH-005 per CR-003"
+    by: "John (PM)"
+    cr_ref: "CR-003"  # Optional: link to change request
+```
+
+## Approval History (Optional)
+
+For formal approval tracking:
+
+```yaml
+approval_history:
+  - version: "1.0.0"
+    date: "2024-01-10"
+    approved_by: "Mary (Analyst)"
+    status: "approved"
+    notes: "Initial StRS approved after QG-1"
+```

src/bmm/workflows/shared/templates/rtm-template.md

@@ -0,0 +1,83 @@
+---
+workflowType: 'rtm'
+track: 'enterprise'
+version: '1.0'
+status: 'draft'
+last_updated: '{{date}}'
+generated_by: '{{agent_name}}'
+---
+
+# Requirements Traceability Matrix - {{project_name}}
+
+**Author:** {{user_name}}
+**Date:** {{date}}
+**ISO 29148 Reference:** Requirements Traceability
+
+## Purpose
+
+This Requirements Traceability Matrix (RTM) provides bidirectional traceability across the entire requirements chain:
+
+**Forward Traceability:** StRS → SyRS → PRD/SRS → Stories → Tests
+**Backward Traceability:** Tests → Stories → PRD/SRS → SyRS → StRS
+
+## Traceability Matrix
+
+### Stakeholder Requirements → System/Software Requirements
+
+| StRS Req ID | StRS Description | SyRS Ref(s) | PRD/SRS Ref(s) | Status |
+|-------------|-----------------|-------------|----------------|--------|
+| | | | | |
+
+### Software Requirements → Stories → Tests
+
+| PRD/SRS Req ID | Description | Priority | Story Ref(s) | Test Ref(s) | V&V Method | Status |
+|---------------|-------------|----------|-------------|-------------|------------|--------|
+| | | | | | | |
+
+## Coverage Analysis
+
+### Forward Traceability Coverage
+
+| Source Level | Total Reqs | Traced Forward | Not Traced | Coverage % |
+|-------------|-----------|---------------|------------|------------|
+| StRS | | | | |
+| SyRS | | | | |
+| PRD/SRS | | | | |
+| Stories | | | | |
+
+### Orphan Analysis
+
+#### Orphan Requirements (not traced to any downstream artifact)
+
+| Req ID | Source | Description | Action Needed |
+|--------|--------|-------------|--------------|
+| | | | |
+
+#### Orphan Stories (not traced to any requirement)
+
+| Story ID | Epic | Description | Action Needed |
+|----------|------|-------------|--------------|
+| | | | |
+
+#### Orphan Tests (not traced to any story or requirement)
+
+| Test ID | Description | Action Needed |
+|---------|-------------|--------------|
+| | | |
+
+## Requirement Status Summary
+
+| Status | Count | Percentage |
+|--------|-------|------------|
+| Proposed | | |
+| Approved | | |
+| Implemented | | |
+| Verified | | |
+| Deferred | | |
+| Rejected | | |
+
+## Change History
+
+| Date | Change | By | Affected Reqs |
+|------|--------|-----|--------------|
+| {{date}} | Initial RTM creation | {{agent_name}} | All |

tools/cli/external-official-modules.yaml

@@ -32,16 +32,6 @@ 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