bmad-studio 0.1.0 → 0.2.0

package/_bmad/bmm/workflows/2-plan-workflows/bmad-validate-prd/steps-v/step-v-08-domain-compliance-validation.md

@@ -1,240 +0,0 @@
----
-# File references (ONLY variables used in this step)
-nextStepFile: './step-v-09-project-type-validation.md'
-prdFile: '{prd_file_path}'
-prdFrontmatter: '{prd_frontmatter}'
-validationReportPath: '{validation_report_path}'
-domainComplexityData: '../data/domain-complexity.csv'
----
-
-# Step 8: Domain Compliance Validation
-
-## STEP GOAL:
-
-Validate domain-specific requirements are present for high-complexity domains (Healthcare, Fintech, GovTech, etc.), ensuring regulatory and compliance requirements are properly documented.
-
-## 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
-- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
-- ✅ We engage in systematic validation, not collaborative dialogue
-- ✅ You bring domain expertise and compliance knowledge
-- ✅ This step runs autonomously - no user input needed
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on domain-specific compliance requirements
-- 🚫 FORBIDDEN to validate other aspects in this step
-- 💬 Approach: Conditional validation based on domain classification
-- 🚪 This is a validation sequence step - auto-proceeds when complete
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Check classification.domain from PRD frontmatter
-- 💬 If low complexity (general): Skip detailed checks
-- 🎯 If high complexity: Validate required special sections
-- 💾 Append compliance findings to validation report
-- 📖 Display "Proceeding to next check..." and load next step
-- 🚫 FORBIDDEN to pause or request user input
-
-## CONTEXT BOUNDARIES:
-
-- Available context: PRD file with frontmatter classification, validation report
-- Focus: Domain compliance only (conditional on domain complexity)
-- Limits: Don't validate other aspects, conditional execution
-- Dependencies: Steps 2-7 completed - format and requirements validation done
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
-
-### 1. Load Domain Complexity Data
-
-Load and read the complete file at:
-`{domainComplexityData}` (../data/domain-complexity.csv)
-
-This CSV contains:
-- Domain classifications and complexity levels (high/medium/low)
-- Required special sections for each domain
-- Key concerns and requirements for regulated industries
-
-Internalize this data - it drives which domains require special compliance sections.
-
-### 2. Extract Domain Classification
-
-From PRD frontmatter, extract:
-- `classification.domain` - what domain is this PRD for?
-
-**If no domain classification found:**
-Treat as "general" (low complexity) and proceed to step 4
-
-### 2. Determine Domain Complexity
-
-**Low complexity domains (skip detailed checks):**
-- General
-- Consumer apps (standard e-commerce, social, productivity)
-- Content websites
-- Business tools (standard)
-
-**High complexity domains (require special sections):**
-- Healthcare / Healthtech
-- Fintech / Financial services
-- GovTech / Public sector
-- EdTech (educational records, accredited courses)
-- Legal tech
-- Other regulated domains
-
-### 3. For High-Complexity Domains: Validate Required Special Sections
-
-**Attempt subprocess validation:**
-
-"Perform domain compliance validation for {domain}:
-
-Based on {domain} requirements, check PRD for:
-
-**Healthcare:**
-- Clinical Requirements section
-- Regulatory Pathway (FDA, HIPAA, etc.)
-- Safety Measures
-- HIPAA Compliance (data privacy, security)
-- Patient safety considerations
-
-**Fintech:**
-- Compliance Matrix (SOC2, PCI-DSS, GDPR, etc.)
-- Security Architecture
-- Audit Requirements
-- Fraud Prevention measures
-- Financial transaction handling
-
-**GovTech:**
-- Accessibility Standards (WCAG 2.1 AA, Section 508)
-- Procurement Compliance
-- Security Clearance requirements
-- Data residency requirements
-
-**Other regulated domains:**
-- Check for domain-specific regulatory sections
-- Compliance requirements
-- Special considerations
-
-For each required section:
-- Is it present in PRD?
-- Is it adequately documented?
-- Note any gaps
-
-Return compliance matrix with presence/adequacy assessment."
-
-**Graceful degradation (if no Task tool):**
-- Manually check for required sections based on domain
-- List present sections and missing sections
-- Assess adequacy of documentation
-
-### 5. For Low-Complexity Domains: Skip Detailed Checks
-
-Append to validation report:
-```markdown
-## Domain Compliance Validation
-
-**Domain:** {domain}
-**Complexity:** Low (general/standard)
-**Assessment:** N/A - No special domain compliance requirements
-
-**Note:** This PRD is for a standard domain without regulatory compliance requirements.
-```
-
-Display: "**Domain Compliance Validation Skipped**
-
-Domain: {domain} (low complexity)
-
-**Proceeding to next validation check...**"
-
-Without delay, read fully and follow: {nextStepFile}
-
-### 6. Report Compliance Findings (High-Complexity Domains)
-
-Append to validation report:
-
-```markdown
-## Domain Compliance Validation
-
-**Domain:** {domain}
-**Complexity:** High (regulated)
-
-### Required Special Sections
-
-**{Section 1 Name}:** [Present/Missing/Adequate]
-{If missing or inadequate: Note specific gaps}
-
-**{Section 2 Name}:** [Present/Missing/Adequate]
-{If missing or inadequate: Note specific gaps}
-
-[Continue for all required sections]
-
-### Compliance Matrix
-
-| Requirement | Status | Notes |
-|-------------|--------|-------|
-| {Requirement 1} | [Met/Partial/Missing] | {Notes} |
-| {Requirement 2} | [Met/Partial/Missing] | {Notes} |
-[... continue for all requirements]
-
-### Summary
-
-**Required Sections Present:** {count}/{total}
-**Compliance Gaps:** {count}
-
-**Severity:** [Critical if missing regulatory sections, Warning if incomplete, Pass if complete]
-
-**Recommendation:**
-[If Critical] "PRD is missing required domain-specific compliance sections. These are essential for {domain} products."
-[If Warning] "Some domain compliance sections are incomplete. Strengthen documentation for full compliance."
-[If Pass] "All required domain compliance sections are present and adequately documented."
-```
-
-### 7. Display Progress and Auto-Proceed
-
-Display: "**Domain Compliance Validation Complete**
-
-Domain: {domain} ({complexity})
-Compliance Status: {status}
-
-**Proceeding to next validation check...**"
-
-Without delay, read fully and follow: {nextStepFile} (step-v-09-project-type-validation.md)
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Domain classification extracted correctly
-- Complexity assessed appropriately
-- Low complexity domains: Skipped with clear "N/A" documentation
-- High complexity domains: All required sections checked
-- Compliance matrix built with status for each requirement
-- Severity assessed correctly
-- Findings reported to validation report
-- Auto-proceeds to next validation step
-- Subprocess attempted with graceful degradation
-
-### ❌ SYSTEM FAILURE:
-
-- Not checking domain classification before proceeding
-- Performing detailed checks on low complexity domains
-- For high complexity: missing required section checks
-- Not building compliance matrix
-- Not reporting findings to validation report
-- Not auto-proceeding
-
-**Master Rule:** Domain compliance is conditional. High-complexity domains require special sections - low complexity domains skip these checks.

package/_bmad/bmm/workflows/2-plan-workflows/bmad-validate-prd/steps-v/step-v-09-project-type-validation.md

@@ -1,260 +0,0 @@
----
-# File references (ONLY variables used in this step)
-nextStepFile: './step-v-10-smart-validation.md'
-prdFile: '{prd_file_path}'
-prdFrontmatter: '{prd_frontmatter}'
-validationReportPath: '{validation_report_path}'
-projectTypesData: '../data/project-types.csv'
----
-
-# Step 9: Project-Type Compliance Validation
-
-## STEP GOAL:
-
-Validate project-type specific requirements are properly documented - different project types (api_backend, web_app, mobile_app, etc.) have different required and excluded sections.
-
-## 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
-- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
-- ✅ We engage in systematic validation, not collaborative dialogue
-- ✅ You bring project type expertise and architectural knowledge
-- ✅ This step runs autonomously - no user input needed
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on project-type compliance
-- 🚫 FORBIDDEN to validate other aspects in this step
-- 💬 Approach: Validate required sections present, excluded sections absent
-- 🚪 This is a validation sequence step - auto-proceeds when complete
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Check classification.projectType from PRD frontmatter
-- 🎯 Validate required sections for that project type are present
-- 🎯 Validate excluded sections for that project type are absent
-- 💾 Append compliance findings to validation report
-- 📖 Display "Proceeding to next check..." and load next step
-- 🚫 FORBIDDEN to pause or request user input
-
-## CONTEXT BOUNDARIES:
-
-- Available context: PRD file with frontmatter classification, validation report
-- Focus: Project-type compliance only
-- Limits: Don't validate other aspects, don't pause for user input
-- Dependencies: Steps 2-8 completed - domain and requirements validation done
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
-
-### 1. Load Project Types Data
-
-Load and read the complete file at:
-`{projectTypesData}` (../data/project-types.csv)
-
-This CSV contains:
-- Detection signals for each project type
-- Required sections for each project type
-- Skip/excluded sections for each project type
-- Innovation signals
-
-Internalize this data - it drives what sections must be present or absent for each project type.
-
-### 2. Extract Project Type Classification
-
-From PRD frontmatter, extract:
-- `classification.projectType` - what type of project is this?
-
-**Common project types:**
-- api_backend
-- web_app
-- mobile_app
-- desktop_app
-- data_pipeline
-- ml_system
-- library_sdk
-- infrastructure
-- other
-
-**If no projectType classification found:**
-Assume "web_app" (most common) and note in findings
-
-### 3. Determine Required and Excluded Sections from CSV Data
-
-**From loaded project-types.csv data, for this project type:**
-
-**Required sections:** (from required_sections column)
-These MUST be present in the PRD
-
-**Skip sections:** (from skip_sections column)
-These MUST NOT be present in the PRD
-
-**Example mappings from CSV:**
-- api_backend: Required=[endpoint_specs, auth_model, data_schemas], Skip=[ux_ui, visual_design]
-- mobile_app: Required=[platform_reqs, device_permissions, offline_mode], Skip=[desktop_features, cli_commands]
-- cli_tool: Required=[command_structure, output_formats, config_schema], Skip=[visual_design, ux_principles, touch_interactions]
-- etc.
-
-### 4. Validate Against CSV-Based Requirements
-
-**Based on project type, determine:**
-
-**api_backend:**
-- Required: Endpoint Specs, Auth Model, Data Schemas, API Versioning
-- Excluded: UX/UI sections, mobile-specific sections
-
-**web_app:**
-- Required: User Journeys, UX/UI Requirements, Responsive Design
-- Excluded: None typically
-
-**mobile_app:**
-- Required: Mobile UX, Platform specifics (iOS/Android), Offline mode
-- Excluded: Desktop-specific sections
-
-**desktop_app:**
-- Required: Desktop UX, Platform specifics (Windows/Mac/Linux)
-- Excluded: Mobile-specific sections
-
-**data_pipeline:**
-- Required: Data Sources, Data Transformation, Data Sinks, Error Handling
-- Excluded: UX/UI sections
-
-**ml_system:**
-- Required: Model Requirements, Training Data, Inference Requirements, Model Performance
-- Excluded: UX/UI sections (unless ML UI)
-
-**library_sdk:**
-- Required: API Surface, Usage Examples, Integration Guide
-- Excluded: UX/UI sections, deployment sections
-
-**infrastructure:**
-- Required: Infrastructure Components, Deployment, Monitoring, Scaling
-- Excluded: Feature requirements (this is infrastructure, not product)
-
-### 4. Attempt Sub-Process Validation
-
-"Perform project-type compliance validation for {projectType}:
-
-**Check that required sections are present:**
-{List required sections for this project type}
-For each: Is it present in PRD? Is it adequately documented?
-
-**Check that excluded sections are absent:**
-{List excluded sections for this project type}
-For each: Is it absent from PRD? (Should not be present)
-
-Build compliance table showing:
-- Required sections: [Present/Missing/Incomplete]
-- Excluded sections: [Absent/Present] (Present = violation)
-
-Return compliance table with findings."
-
-**Graceful degradation (if no Task tool):**
-- Manually check PRD for required sections
-- Manually check PRD for excluded sections
-- Build compliance table
-
-### 5. Build Compliance Table
-
-**Required sections check:**
-- For each required section: Present / Missing / Incomplete
-- Count: Required sections present vs total required
-
-**Excluded sections check:**
-- For each excluded section: Absent / Present (violation)
-- Count: Excluded sections present (violations)
-
-**Total compliance score:**
-- Required: {present}/{total}
-- Excluded violations: {count}
-
-### 6. Report Project-Type Compliance Findings to Validation Report
-
-Append to validation report:
-
-```markdown
-## Project-Type Compliance Validation
-
-**Project Type:** {projectType}
-
-### Required Sections
-
-**{Section 1}:** [Present/Missing/Incomplete]
-{If missing or incomplete: Note specific gaps}
-
-**{Section 2}:** [Present/Missing/Incomplete]
-{If missing or incomplete: Note specific gaps}
-
-[Continue for all required sections]
-
-### Excluded Sections (Should Not Be Present)
-
-**{Section 1}:** [Absent/Present] ✓
-{If present: This section should not be present for {projectType}}
-
-**{Section 2}:** [Absent/Present] ✓
-{If present: This section should not be present for {projectType}}
-
-[Continue for all excluded sections]
-
-### Compliance Summary
-
-**Required Sections:** {present}/{total} present
-**Excluded Sections Present:** {violations} (should be 0)
-**Compliance Score:** {percentage}%
-
-**Severity:** [Critical if required sections missing, Warning if incomplete, Pass if complete]
-
-**Recommendation:**
-[If Critical] "PRD is missing required sections for {projectType}. Add missing sections to properly specify this type of project."
-[If Warning] "Some required sections for {projectType} are incomplete. Strengthen documentation."
-[If Pass] "All required sections for {projectType} are present. No excluded sections found."
-```
-
-### 7. Display Progress and Auto-Proceed
-
-Display: "**Project-Type Compliance Validation Complete**
-
-Project Type: {projectType}
-Compliance: {score}%
-
-**Proceeding to next validation check...**"
-
-Without delay, read fully and follow: {nextStepFile} (step-v-10-smart-validation.md)
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Project type extracted correctly (or default assumed)
-- Required sections validated for presence and completeness
-- Excluded sections validated for absence
-- Compliance table built with status for all sections
-- Severity assessed correctly
-- Findings reported to validation report
-- Auto-proceeds to next validation step
-- Subprocess attempted with graceful degradation
-
-### ❌ SYSTEM FAILURE:
-
-- Not checking project type before proceeding
-- Missing required section checks
-- Missing excluded section checks
-- Not building compliance table
-- Not reporting findings to validation report
-- Not auto-proceeding
-
-**Master Rule:** Different project types have different requirements. API PRDs don't need UX sections - validate accordingly.

package/_bmad/bmm/workflows/2-plan-workflows/bmad-validate-prd/steps-v/step-v-10-smart-validation.md

@@ -1,206 +0,0 @@
----
-# File references (ONLY variables used in this step)
-nextStepFile: './step-v-11-holistic-quality-validation.md'
-prdFile: '{prd_file_path}'
-validationReportPath: '{validation_report_path}'
----
-
-# Step 10: SMART Requirements Validation
-
-## STEP GOAL:
-
-Validate Functional Requirements meet SMART quality criteria (Specific, Measurable, Attainable, Relevant, Traceable), ensuring high-quality 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}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a Validation Architect and Quality Assurance Specialist
-- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
-- ✅ We engage in systematic validation, not collaborative dialogue
-- ✅ You bring requirements engineering expertise and quality assessment
-- ✅ This step runs autonomously - no user input needed
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on FR quality assessment using SMART framework
-- 🚫 FORBIDDEN to validate other aspects in this step
-- 💬 Approach: Score each FR on SMART criteria (1-5 scale)
-- 🚪 This is a validation sequence step - auto-proceeds when complete
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Extract all FRs from PRD
-- 🎯 Score each FR on SMART criteria (Specific, Measurable, Attainable, Relevant, Traceable)
-- 💾 Flag FRs with score < 3 in any category
-- 📖 Append scoring table and suggestions to validation report
-- 📖 Display "Proceeding to next check..." and load next step
-- 🚫 FORBIDDEN to pause or request user input
-
-## CONTEXT BOUNDARIES:
-
-- Available context: PRD file, validation report
-- Focus: FR quality assessment only using SMART framework
-- Limits: Don't validate NFRs or other aspects, don't pause for user input
-- Dependencies: Steps 2-9 completed - comprehensive validation checks done
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
-
-### 1. Extract All Functional Requirements
-
-From the PRD's Functional Requirements section, extract:
-- All FRs with their FR numbers (FR-001, FR-002, etc.)
-- Count total FRs
-
-### 2. Attempt Sub-Process Validation
-
-**Try to use Task tool to spawn a subprocess:**
-
-"Perform SMART requirements validation on these Functional Requirements:
-
-{List all FRs}
-
-**For each FR, score on SMART criteria (1-5 scale):**
-
-**Specific (1-5):**
-- 5: Clear, unambiguous, well-defined
-- 3: Somewhat clear but could be more specific
-- 1: Vague, ambiguous, unclear
-
-**Measurable (1-5):**
-- 5: Quantifiable metrics, testable
-- 3: Partially measurable
-- 1: Not measurable, subjective
-
-**Attainable (1-5):**
-- 5: Realistic, achievable with constraints
-- 3: Probably achievable but uncertain
-- 1: Unrealistic, technically infeasible
-
-**Relevant (1-5):**
-- 5: Clearly aligned with user needs and business objectives
-- 3: Somewhat relevant but connection unclear
-- 1: Not relevant, doesn't align with goals
-
-**Traceable (1-5):**
-- 5: Clearly traces to user journey or business objective
-- 3: Partially traceable
-- 1: Orphan requirement, no clear source
-
-**For each FR with score < 3 in any category:**
-- Provide specific improvement suggestions
-
-Return scoring table with all FR scores and improvement suggestions for low-scoring FRs."
-
-**Graceful degradation (if no Task tool):**
-- Manually score each FR on SMART criteria
-- Note FRs with low scores
-- Provide improvement suggestions
-
-### 3. Build Scoring Table
-
-For each FR:
-- FR number
-- Specific score (1-5)
-- Measurable score (1-5)
-- Attainable score (1-5)
-- Relevant score (1-5)
-- Traceable score (1-5)
-- Average score
-- Flag if any category < 3
-
-**Calculate overall FR quality:**
-- Percentage of FRs with all scores ≥ 3
-- Percentage of FRs with all scores ≥ 4
-- Average score across all FRs and categories
-
-### 4. Report SMART Findings to Validation Report
-
-Append to validation report:
-
-```markdown
-## SMART Requirements Validation
-
-**Total Functional Requirements:** {count}
-
-### Scoring Summary
-
-**All scores ≥ 3:** {percentage}% ({count}/{total})
-**All scores ≥ 4:** {percentage}% ({count}/{total})
-**Overall Average Score:** {average}/5.0
-
-### Scoring Table
-
-| FR # | Specific | Measurable | Attainable | Relevant | Traceable | Average | Flag |
-|------|----------|------------|------------|----------|-----------|--------|------|
-| FR-001 | {s1} | {m1} | {a1} | {r1} | {t1} | {avg1} | {X if any <3} |
-| FR-002 | {s2} | {m2} | {a2} | {r2} | {t2} | {avg2} | {X if any <3} |
-[Continue for all FRs]
-
-**Legend:** 1=Poor, 3=Acceptable, 5=Excellent
-**Flag:** X = Score < 3 in one or more categories
-
-### Improvement Suggestions
-
-**Low-Scoring FRs:**
-
-**FR-{number}:** {specific suggestion for improvement}
-[For each FR with score < 3 in any category]
-
-### Overall Assessment
-
-**Severity:** [Critical if >30% flagged FRs, Warning if 10-30%, Pass if <10%]
-
-**Recommendation:**
-[If Critical] "Many FRs have quality issues. Revise flagged FRs using SMART framework to improve clarity and testability."
-[If Warning] "Some FRs would benefit from SMART refinement. Focus on flagged requirements above."
-[If Pass] "Functional Requirements demonstrate good SMART quality overall."
-```
-
-### 5. Display Progress and Auto-Proceed
-
-Display: "**SMART Requirements Validation Complete**
-
-FR Quality: {percentage}% with acceptable scores ({severity})
-
-**Proceeding to next validation check...**"
-
-Without delay, read fully and follow: {nextStepFile} (step-v-11-holistic-quality-validation.md)
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- All FRs extracted from PRD
-- Each FR scored on all 5 SMART criteria (1-5 scale)
-- FRs with scores < 3 flagged for improvement
-- Improvement suggestions provided for low-scoring FRs
-- Scoring table built with all FR scores
-- Overall quality assessment calculated
-- Findings reported to validation report
-- Auto-proceeds to next validation step
-- Subprocess attempted with graceful degradation
-
-### ❌ SYSTEM FAILURE:
-
-- Not scoring all FRs on all SMART criteria
-- Missing improvement suggestions for low-scoring FRs
-- Not building scoring table
-- Not calculating overall quality metrics
-- Not reporting findings to validation report
-- Not auto-proceeding
-
-**Master Rule:** FRs should be high-quality, not just present. SMART framework provides objective quality measure.