@zeyue0329/xiaoma-cli 1.6.4 → 1.7.0

package/src/xmc/workflows/2-plan-workflows/xiaoma-validate-prd/data/prd-purpose.md

@@ -0,0 +1,197 @@
+# BMAD PRD Purpose
+
+**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
+
+---
+
+## What is a BMAD PRD?
+
+A dual-audience document serving:
+1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
+2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
+
+Each successive document becomes more AI-tailored and granular.
+
+---
+
+## Core Philosophy: Information Density
+
+**High Signal-to-Noise Ratio**
+
+Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
+
+**Anti-Patterns (Eliminate These):**
+- ❌ "The system will allow users to..." → ✅ "Users can..."
+- ❌ "It is important to note that..." → ✅ State the fact directly
+- ❌ "In order to..." → ✅ "To..."
+- ❌ Conversational filler and padding → ✅ Direct, concise statements
+
+**Goal:** Maximum information per word. Zero fluff.
+
+---
+
+## The Traceability Chain
+
+**PRD starts the chain:**
+```
+Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
+```
+
+**In the PRD, establish:**
+- Vision → Success Criteria alignment
+- Success Criteria → User Journey coverage
+- User Journey → Functional Requirement mapping
+- All requirements traceable to user needs
+
+**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
+
+---
+
+## What Makes Great Functional Requirements?
+
+### FRs are Capabilities, Not Implementation
+
+**Good FR:** "Users can reset their password via email link"
+**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
+
+**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
+**Bad FR:** "Fast loading time" (subjective, unmeasurable)
+
+### SMART Quality Criteria
+
+**Specific:** Clear, precisely defined capability
+**Measurable:** Quantifiable with test criteria
+**Attainable:** Realistic within constraints
+**Relevant:** Aligns with business objectives
+**Traceable:** Links to source (executive summary or user journey)
+
+### FR Anti-Patterns
+
+**Subjective Adjectives:**
+- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
+- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
+
+**Implementation Leakage:**
+- ❌ Technology names, specific libraries, implementation details
+- ✅ Focus on capability and measurable outcomes
+
+**Vague Quantifiers:**
+- ❌ "multiple users", "several options", "various formats"
+- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
+
+**Missing Test Criteria:**
+- ❌ "The system shall provide notifications"
+- ✅ "The system shall send email notifications within 30 seconds of trigger event"
+
+---
+
+## What Makes Great Non-Functional Requirements?
+
+### NFRs Must Be Measurable
+
+**Template:**
+```
+"The system shall [metric] [condition] [measurement method]"
+```
+
+**Examples:**
+- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
+- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
+- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
+
+### NFR Anti-Patterns
+
+**Unmeasurable Claims:**
+- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
+- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
+
+**Missing Context:**
+- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
+
+---
+
+## Domain-Specific Requirements
+
+**Auto-Detect and Enforce Based on Project Context**
+
+Certain industries have mandatory requirements that must be present:
+
+- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
+- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
+- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
+- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
+
+**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
+
+---
+
+## Document Structure (Markdown, Human-Readable)
+
+### Required Sections
+1. **Executive Summary** - Vision, differentiator, target users
+2. **Success Criteria** - Measurable outcomes (SMART)
+3. **Product Scope** - MVP, Growth, Vision phases
+4. **User Journeys** - Comprehensive coverage
+5. **Domain Requirements** - Industry-specific compliance (if applicable)
+6. **Innovation Analysis** - Competitive differentiation (if applicable)
+7. **Project-Type Requirements** - Platform-specific needs
+8. **Functional Requirements** - Capability contract (FRs)
+9. **Non-Functional Requirements** - Quality attributes (NFRs)
+
+### Formatting for Dual Consumption
+
+**For Humans:**
+- Clear, professional language
+- Logical flow from vision to requirements
+- Easy for stakeholders to review and approve
+
+**For LLMs:**
+- ## Level 2 headers for all main sections (enables extraction)
+- Consistent structure and patterns
+- Precise, testable language
+- High information density
+
+---
+
+## Downstream Impact
+
+**How the PRD Feeds Next Artifacts:**
+
+**UX Design:**
+- User journeys → interaction flows
+- FRs → design requirements
+- Success criteria → UX metrics
+
+**Architecture:**
+- FRs → system capabilities
+- NFRs → architecture decisions
+- Domain requirements → compliance architecture
+- Project-type requirements → platform choices
+
+**Epics & Stories (created after architecture):**
+- FRs → user stories (1 FR could map to 1-3 stories potentially)
+- Acceptance criteria → story acceptance tests
+- Priority → sprint sequencing
+- Traceability → stories map back to vision
+
+**Development AI Agents:**
+- Precise requirements → implementation clarity
+- Test criteria → automated test generation
+- Domain requirements → compliance enforcement
+- Measurable NFRs → performance targets
+
+---
+
+## Summary: What Makes a Great BMAD PRD?
+
+✅ **High Information Density** - Every sentence carries weight, zero fluff
+✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
+✅ **Clear Traceability** - Each requirement links to user need and business objective
+✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
+✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
+✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
+✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
+
+---
+
+**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.

package/src/xmc/workflows/2-plan-workflows/xiaoma-validate-prd/data/project-types.csv

@@ -0,0 +1,11 @@
+project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
+api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
+mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
+saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
+developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
+cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
+web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
+game,"game,player,gameplay,level,character","REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
+desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
+iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
+blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"

package/src/xmc/workflows/2-plan-workflows/xiaoma-validate-prd/steps-v/step-v-01-discovery.md

@@ -0,0 +1,224 @@
+---
+name: 'step-v-01-discovery'
+description: 'Document Discovery & Confirmation - Handle fresh context validation, confirm PRD path, discover input documents'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-02-format-detection.md'
+prdPurpose: '../data/prd-purpose.md'
+---
+
+# Step 1: Document Discovery & Confirmation
+
+## STEP GOAL:
+
+Handle fresh context validation by confirming PRD path, discovering and loading input documents from frontmatter, and initializing the validation report.
+
+## 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 collaborative dialogue, not command-response
+- ✅ You bring systematic validation expertise and analytical rigor
+- ✅ User brings domain knowledge and specific PRD context
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on discovering PRD and input documents, not validating yet
+- 🚫 FORBIDDEN to perform any validation checks in this step
+- 💬 Approach: Systematic discovery with clear reporting to user
+- 🚪 This is the setup step - get everything ready for validation
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Discover and confirm PRD to validate
+- 💾 Load PRD and all input documents from frontmatter
+- 📖 Initialize validation report next to PRD
+- 🚫 FORBIDDEN to load next step until user confirms setup
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD path (user-specified or discovered), workflow configuration
+- Focus: Document discovery and setup only
+- Limits: Don't perform validation, don't skip discovery
+- Dependencies: Configuration loaded from PRD workflow.md initialization
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Load PRD Purpose and Standards
+
+Load and read the complete file at:
+`{prdPurpose}`
+
+This file contains the BMAD PRD philosophy, standards, and validation criteria that will guide all validation checks. Internalize this understanding - it defines what makes a great BMAD PRD.
+
+### 2. Discover PRD to Validate
+
+**If PRD path provided as invocation parameter:**
+- Use provided path
+
+**If no PRD path provided, auto-discover:**
+- Search `{planning_artifacts}` for files matching `*prd*.md`
+- Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md`
+
+**If exactly ONE PRD found:**
+- Use it automatically
+- Inform user: "Found PRD: {discovered_path} — using it for validation."
+
+**If MULTIPLE PRDs found:**
+- List all discovered PRDs with numbered options
+- "I found multiple PRDs. Which one would you like to validate?"
+- Wait for user selection
+
+**If NO PRDs found:**
+- "I couldn't find any PRD files in {planning_artifacts}. Please provide the path to the PRD file you want to validate."
+- Wait for user to provide PRD path.
+
+### 3. Validate PRD Exists and Load
+
+Once PRD path is provided:
+
+- Check if PRD file exists at specified path
+- If not found: "I cannot find a PRD at that path. Please check the path and try again."
+- If found: Load the complete PRD file including frontmatter
+
+### 4. Extract Frontmatter and Input Documents
+
+From the loaded PRD frontmatter, extract:
+
+- `inputDocuments: []` array (if present)
+- Any other relevant metadata (classification, date, etc.)
+
+**If no inputDocuments array exists:**
+Note this and proceed with PRD-only validation
+
+### 5. Load Input Documents
+
+For each document listed in `inputDocuments`:
+
+- Attempt to load the document
+- Track successfully loaded documents
+- Note any documents that fail to load
+
+**Build list of loaded input documents:**
+- Product Brief (if present)
+- Research documents (if present)
+- Other reference materials (if present)
+
+### 6. Ask About Additional Reference Documents
+
+"**I've loaded the following documents from your PRD frontmatter:**
+
+{list loaded documents with file names}
+
+**Are there any additional reference documents you'd like me to include in this validation?**
+
+These could include:
+- Additional research or context documents
+- Project documentation not tracked in frontmatter
+- Standards or compliance documents
+- Competitive analysis or benchmarks
+
+Please provide paths to any additional documents, or type 'none' to proceed."
+
+**Load any additional documents provided by user.**
+
+### 7. Initialize Validation Report
+
+Create validation report at: `{validationReportPath}`
+
+**Initialize with frontmatter:**
+```yaml
+---
+validationTarget: '{prd_path}'
+validationDate: '{current_date}'
+inputDocuments: [list of all loaded documents]
+validationStepsCompleted: []
+validationStatus: IN_PROGRESS
+---
+```
+
+**Initial content:**
+```markdown
+# PRD Validation Report
+
+**PRD Being Validated:** {prd_path}
+**Validation Date:** {current_date}
+
+## Input Documents
+
+{list all documents loaded for validation}
+
+## Validation Findings
+
+[Findings will be appended as validation progresses]
+```
+
+### 8. Present Discovery Summary
+
+"**Setup Complete!**
+
+**PRD to Validate:** {prd_path}
+
+**Input Documents Loaded:**
+- PRD: {prd_name} ✓
+- Product Brief: {count} {if count > 0}✓{else}(none found){/if}
+- Research: {count} {if count > 0}✓{else}(none found){/if}
+- Additional References: {count} {if count > 0}✓{else}(none){/if}
+
+**Validation Report:** {validationReportPath}
+
+**Ready to begin validation.**"
+
+### 9. Present MENU OPTIONS
+
+Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Format Detection
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can ask questions or add more documents - always respond and redisplay menu
+
+#### Menu Handling Logic:
+
+- IF A: Invoke the `xiaoma-advanced-elicitation` skill, and when finished redisplay the menu
+- IF P: Invoke the `xiaoma-party-mode` skill, and when finished redisplay the menu
+- IF C: Read fully and follow: {nextStepFile} to begin format detection
+- IF user provides additional document: Load it, update report, redisplay summary
+- IF Any other: help user, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- PRD path discovered and confirmed
+- PRD file exists and loads successfully
+- All input documents from frontmatter loaded
+- Additional reference documents (if any) loaded
+- Validation report initialized next to PRD
+- User clearly informed of setup status
+- Menu presented and user input handled correctly
+
+### ❌ SYSTEM FAILURE:
+
+- Proceeding with non-existent PRD file
+- Not loading input documents from frontmatter
+- Creating validation report in wrong location
+- Proceeding without user confirming setup
+- Not handling missing input documents gracefully
+
+**Master Rule:** Complete discovery and setup BEFORE validation. This step ensures everything is in place for systematic validation checks.

package/src/xmc/workflows/2-plan-workflows/xiaoma-validate-prd/steps-v/step-v-02-format-detection.md

@@ -0,0 +1,191 @@
+---
+name: 'step-v-02-format-detection'
+description: 'Format Detection & Structure Analysis - Classify PRD format and route appropriately'
+
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-03-density-validation.md'
+altStepFile: './step-v-02b-parity-check.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 2: Format Detection & Structure Analysis
+
+## STEP GOAL:
+
+Detect if PRD follows BMAD format and route appropriately - classify as BMAD Standard / BMAD Variant / Non-Standard, with optional parity check for non-standard formats.
+
+## 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 collaborative dialogue, not command-response
+- ✅ You bring systematic validation expertise and pattern recognition
+- ✅ User brings domain knowledge and PRD context
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on detecting format and classifying structure
+- 🚫 FORBIDDEN to perform other validation checks in this step
+- 💬 Approach: Analytical and systematic, clear reporting of findings
+- 🚪 This is a branch step - may route to parity check for non-standard PRDs
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Analyze PRD structure systematically
+- 💾 Append format findings to validation report
+- 📖 Route appropriately based on format classification
+- 🚫 FORBIDDEN to skip format detection or proceed without classification
+
+## CONTEXT BOUNDARIES:
+
+- Available context: PRD file loaded in step 1, validation report initialized
+- Focus: Format detection and classification only
+- Limits: Don't perform other validation, don't skip classification
+- Dependencies: Step 1 completed - PRD loaded and report initialized
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Extract PRD Structure
+
+Load the complete PRD file and extract:
+
+**All Level 2 (##) headers:**
+- Scan through entire PRD document
+- Extract all ## section headers
+- List them in order
+
+**PRD frontmatter:**
+- Extract classification.domain if present
+- Extract classification.projectType if present
+- Note any other relevant metadata
+
+### 2. Check for BMAD PRD Core Sections
+
+Check if the PRD contains the following BMAD PRD core sections:
+
+1. **Executive Summary** (or variations: ## Executive Summary, ## Overview, ## Introduction)
+2. **Success Criteria** (or: ## Success Criteria, ## Goals, ## Objectives)
+3. **Product Scope** (or: ## Product Scope, ## Scope, ## In Scope, ## Out of Scope)
+4. **User Journeys** (or: ## User Journeys, ## User Stories, ## User Flows)
+5. **Functional Requirements** (or: ## Functional Requirements, ## Features, ## Capabilities)
+6. **Non-Functional Requirements** (or: ## Non-Functional Requirements, ## NFRs, ## Quality Attributes)
+
+**Count matches:**
+- How many of these 6 core sections are present?
+- Which specific sections are present?
+- Which are missing?
+
+### 3. Classify PRD Format
+
+Based on core section count, classify:
+
+**BMAD Standard:**
+- 5-6 core sections present
+- Follows BMAD PRD structure closely
+
+**BMAD Variant:**
+- 3-4 core sections present
+- Generally follows BMAD patterns but may have structural differences
+- Missing some sections but recognizable as BMAD-style
+
+**Non-Standard:**
+- Fewer than 3 core sections present
+- Does not follow BMAD PRD structure
+- May be completely custom format, legacy format, or from another framework
+
+### 4. Report Format Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Format Detection
+
+**PRD Structure:**
+[List all ## Level 2 headers found]
+
+**BMAD Core Sections Present:**
+- Executive Summary: [Present/Missing]
+- Success Criteria: [Present/Missing]
+- Product Scope: [Present/Missing]
+- User Journeys: [Present/Missing]
+- Functional Requirements: [Present/Missing]
+- Non-Functional Requirements: [Present/Missing]
+
+**Format Classification:** [BMAD Standard / BMAD Variant / Non-Standard]
+**Core Sections Present:** [count]/6
+```
+
+### 5. Route Based on Format Classification
+
+**IF format is BMAD Standard or BMAD Variant:**
+
+Display: "**Format Detected:** {classification}
+
+Proceeding to systematic validation checks..."
+
+Without delay, read fully and follow: {nextStepFile} (step-v-03-density-validation.md)
+
+**IF format is Non-Standard (< 3 core sections):**
+
+Display: "**Format Detected:** Non-Standard PRD
+
+This PRD does not follow BMAD standard structure (only {count}/6 core sections present).
+
+You have options:"
+
+Present MENU OPTIONS below for user selection
+
+### 6. Present MENU OPTIONS (Non-Standard PRDs Only)
+
+**[A] Parity Check** - Analyze gaps and estimate effort to reach BMAD PRD parity
+**[B] Validate As-Is** - Proceed with validation using current structure
+**[C] Exit** - Exit validation and review format findings
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input
+- Only proceed based on user selection
+
+#### Menu Handling Logic:
+
+- IF A (Parity Check): Read fully and follow: {altStepFile} (step-v-02b-parity-check.md)
+- IF B (Validate As-Is): Display "Proceeding with validation..." then read fully and follow: {nextStepFile}
+- IF C (Exit): Display format findings summary and exit validation
+- IF Any other: help user respond, then redisplay menu
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All ## Level 2 headers extracted successfully
+- BMAD core sections checked systematically
+- Format classified correctly based on section count
+- Findings reported to validation report
+- BMAD Standard/Variant PRDs proceed directly to next validation step
+- Non-Standard PRDs pause and present options to user
+- User can choose parity check, validate as-is, or exit
+
+### ❌ SYSTEM FAILURE:
+
+- Not extracting all headers before classification
+- Incorrect format classification
+- Not reporting findings to validation report
+- Not pausing for non-standard PRDs
+- Proceeding without user decision for non-standard formats
+
+**Master Rule:** Format detection determines validation path. Non-standard PRDs require user choice before proceeding.