@zeyue0329/xiaoma-cli 1.6.5 → 1.8.0

package/src/xmc/workflows/2-plan-workflows/xiaoma-validate-prd/steps-v/step-v-07-implementation-leakage-validation.md

@@ -0,0 +1,202 @@
+---
+# File references (ONLY variables used in this step)
+nextStepFile: './step-v-08-domain-compliance-validation.md'
+prdFile: '{prd_file_path}'
+validationReportPath: '{validation_report_path}'
+---
+
+# Step 7: Implementation Leakage Validation
+
+## STEP GOAL:
+
+Ensure Functional Requirements and Non-Functional Requirements don't include implementation details - they should specify WHAT, not HOW.
+
+## 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 analytical rigor and separation of concerns expertise
+- ✅ This step runs autonomously - no user input needed
+
+### Step-Specific Rules:
+
+- 🎯 Focus ONLY on implementation leakage detection
+- 🚫 FORBIDDEN to validate other aspects in this step
+- 💬 Approach: Systematic scanning for technology and implementation terms
+- 🚪 This is a validation sequence step - auto-proceeds when complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Scan FRs and NFRs for implementation terms
+- 💾 Distinguish capability-relevant vs leakage
+- 📖 Append 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, validation report
+- Focus: Implementation leakage detection only
+- Limits: Don't validate other aspects, don't pause for user input
+- Dependencies: Steps 2-6 completed - initial validations done
+
+## MANDATORY SEQUENCE
+
+**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
+
+### 1. Attempt Sub-Process Validation
+
+**Try to use Task tool to spawn a subprocess:**
+
+"Perform implementation leakage validation on this PRD:
+
+**Scan for:**
+1. Technology names (React, Vue, Angular, PostgreSQL, MongoDB, AWS, GCP, Azure, Docker, Kubernetes, etc.)
+2. Library names (Redux, axios, lodash, Express, Django, Rails, Spring, etc.)
+3. Data structures (JSON, XML, CSV) unless relevant to capability
+4. Architecture patterns (MVC, microservices, serverless) unless business requirement
+5. Protocol names (HTTP, REST, GraphQL, WebSockets) - check if capability-relevant
+
+**For each term found:**
+- Is this capability-relevant? (e.g., 'API consumers can access...' - API is capability)
+- Or is this implementation detail? (e.g., 'React component for...' - implementation)
+
+Document violations with line numbers and explanation.
+
+Return structured findings with leakage counts and examples."
+
+### 2. Graceful Degradation (if Task tool unavailable)
+
+If Task tool unavailable, perform analysis directly:
+
+**Implementation leakage terms to scan for:**
+
+**Frontend Frameworks:**
+React, Vue, Angular, Svelte, Solid, Next.js, Nuxt, etc.
+
+**Backend Frameworks:**
+Express, Django, Rails, Spring, Laravel, FastAPI, etc.
+
+**Databases:**
+PostgreSQL, MySQL, MongoDB, Redis, DynamoDB, Cassandra, etc.
+
+**Cloud Platforms:**
+AWS, GCP, Azure, Cloudflare, Vercel, Netlify, etc.
+
+**Infrastructure:**
+Docker, Kubernetes, Terraform, Ansible, etc.
+
+**Libraries:**
+Redux, Zustand, axios, fetch, lodash, jQuery, etc.
+
+**Data Formats:**
+JSON, XML, YAML, CSV (unless capability-relevant)
+
+**For each term found in FRs/NFRs:**
+- Determine if it's capability-relevant or implementation leakage
+- Example: "API consumers can access data via REST endpoints" - API/REST is capability
+- Example: "React components fetch data using Redux" - implementation leakage
+
+**Count violations and note line numbers**
+
+### 3. Tally Implementation Leakage
+
+**By category:**
+- Frontend framework leakage: count
+- Backend framework leakage: count
+- Database leakage: count
+- Cloud platform leakage: count
+- Infrastructure leakage: count
+- Library leakage: count
+- Other implementation details: count
+
+**Total implementation leakage violations:** sum
+
+### 4. Report Implementation Leakage Findings to Validation Report
+
+Append to validation report:
+
+```markdown
+## Implementation Leakage Validation
+
+### Leakage by Category
+
+**Frontend Frameworks:** {count} violations
+{If violations, list examples with line numbers}
+
+**Backend Frameworks:** {count} violations
+{If violations, list examples with line numbers}
+
+**Databases:** {count} violations
+{If violations, list examples with line numbers}
+
+**Cloud Platforms:** {count} violations
+{If violations, list examples with line numbers}
+
+**Infrastructure:** {count} violations
+{If violations, list examples with line numbers}
+
+**Libraries:** {count} violations
+{If violations, list examples with line numbers}
+
+**Other Implementation Details:** {count} violations
+{If violations, list examples with line numbers}
+
+### Summary
+
+**Total Implementation Leakage Violations:** {total}
+
+**Severity:** [Critical if >5 violations, Warning if 2-5, Pass if <2]
+
+**Recommendation:**
+[If Critical] "Extensive implementation leakage found. Requirements specify HOW instead of WHAT. Remove all implementation details - these belong in architecture, not PRD."
+[If Warning] "Some implementation leakage detected. Review violations and remove implementation details from requirements."
+[If Pass] "No significant implementation leakage found. Requirements properly specify WHAT without HOW."
+
+**Note:** API consumers, GraphQL (when required), and other capability-relevant terms are acceptable when they describe WHAT the system must do, not HOW to build it.
+```
+
+### 5. Display Progress and Auto-Proceed
+
+Display: "**Implementation Leakage Validation Complete**
+
+Total Violations: {count} ({severity})
+
+**Proceeding to next validation check...**"
+
+Without delay, read fully and follow: {nextStepFile} (step-v-08-domain-compliance-validation.md)
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- Scanned FRs and NFRs for all implementation term categories
+- Distinguished capability-relevant from implementation leakage
+- Violations documented with line numbers and explanations
+- Severity assessed correctly
+- Findings reported to validation report
+- Auto-proceeds to next validation step
+- Subprocess attempted with graceful degradation
+
+### ❌ SYSTEM FAILURE:
+
+- Not scanning all implementation term categories
+- Not distinguishing capability-relevant from leakage
+- Missing line numbers for violations
+- Not reporting findings to validation report
+- Not auto-proceeding
+
+**Master Rule:** Requirements specify WHAT, not HOW. Implementation details belong in architecture documents, not PRDs.

package/src/xmc/workflows/2-plan-workflows/xiaoma-validate-prd/steps-v/step-v-08-domain-compliance-validation.md

@@ -0,0 +1,240 @@
+---
+# 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/src/xmc/workflows/2-plan-workflows/xiaoma-validate-prd/steps-v/step-v-09-project-type-validation.md

@@ -0,0 +1,260 @@
+---
+# 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.