@pennyfarthing/core 9.2.0 → 9.3.0

package/pennyfarthing-dist/workflows/prd/steps-v/step-v-06-traceability-validation.md

@@ -1,223 +0,0 @@
----
-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'
-prdFile: '{prd_file_path}'
-validationReportPath: '{validation_report_path}'
----
-
-# Step 6: Traceability Validation
-
-<purpose>Validate the traceability chain from Executive Summary → Success Criteria → User Journeys → Functional Requirements is intact, ensuring every requirement traces back to a user need or business objective.</purpose>
-
-<instructions>Extract vision, success criteria, user journeys, and requirements from PRD; map traceability links from requirements back to journeys, success criteria, and vision; identify orphaned requirements without traceability; verify bidirectional traceability; calculate traceability completeness; update validation report.</instructions>
-
-<output>Traceability validation report with traceability chain visualization, identified gaps and orphaned requirements, bidirectional traceability verification, traceability coverage metrics.</output>
-
-## STEP GOAL:
-
-Validate the traceability chain from Executive Summary → Success Criteria → User Journeys → Functional Requirements is intact, ensuring every requirement traces back to a user need or business objective.
-
-## 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 traceability matrix expertise
-- ✅ This step runs autonomously - no user input needed
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on traceability chain validation
-- 🚫 FORBIDDEN to validate other aspects in this step
-- 💬 Approach: Systematic chain validation and orphan detection
-- 🚪 This is a validation sequence step - auto-proceeds when complete
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Build and validate traceability matrix
-- 💾 Identify broken chains and orphan requirements
-- 📖 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: Traceability chain validation only
-- Limits: Don't validate other aspects, don't pause for user input
-- Dependencies: Steps 2-5 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 traceability validation on this PRD:
-
-1. Extract content from Executive Summary (vision, goals)
-2. Extract Success Criteria
-3. Extract User Journeys (user types, flows, outcomes)
-4. Extract Functional Requirements (FRs)
-5. Extract Product Scope (in-scope items)
-
-**Validate chains:**
-- Executive Summary → Success Criteria: Does vision align with defined success?
-- Success Criteria → User Journeys: Are success criteria supported by user journeys?
-- User Journeys → Functional Requirements: Does each FR trace back to a user journey?
-- Scope → FRs: Do MVP scope FRs align with in-scope items?
-
-**Identify orphans:**
-- FRs not traceable to any user journey or business objective
-- Success criteria not supported by user journeys
-- User journeys without supporting FRs
-
-Build traceability matrix and identify broken chains and orphan FRs.
-
-Return structured findings with chain status and orphan list."
-
-### 2. Graceful Degradation (if Task tool unavailable)
-
-If Task tool unavailable, perform analysis directly:
-
-**Step 1: Extract key elements**
-- Executive Summary: Note vision, goals, objectives
-- Success Criteria: List all criteria
-- User Journeys: List user types and their flows
-- Functional Requirements: List all FRs
-- Product Scope: List in-scope items
-
-**Step 2: Validate Executive Summary → Success Criteria**
-- Does Executive Summary mention the success dimensions?
-- Are Success Criteria aligned with vision?
-- Note any misalignment
-
-**Step 3: Validate Success Criteria → User Journeys**
-- For each success criterion, is there a user journey that achieves it?
-- Note success criteria without supporting journeys
-
-**Step 4: Validate User Journeys → FRs**
-- For each user journey/flow, are there FRs that enable it?
-- List FRs with no clear user journey origin
-- Note orphan FRs (requirements without traceable source)
-
-**Step 5: Validate Scope → FR Alignment**
-- Does MVP scope align with essential FRs?
-- Are in-scope items supported by FRs?
-- Note misalignments
-
-**Step 6: Build traceability matrix**
-- Map each FR to its source (journey or business objective)
-- Note orphan FRs
-- Identify broken chains
-
-### 3. Tally Traceability Issues
-
-**Broken chains:**
-- Executive Summary → Success Criteria gaps: count
-- Success Criteria → User Journeys gaps: count
-- User Journeys → FRs gaps: count
-- Scope → FR misalignments: count
-
-**Orphan elements:**
-- Orphan FRs (no traceable source): count
-- Unsupported success criteria: count
-- User journeys without FRs: count
-
-**Total issues:** Sum of all broken chains and orphans
-
-### 4. Report Traceability Findings to Validation Report
-
-Append to validation report:
-
-```markdown
-## Traceability Validation
-
-### Chain Validation
-
-**Executive Summary → Success Criteria:** [Intact/Gaps Identified]
-{If gaps: List specific misalignments}
-
-**Success Criteria → User Journeys:** [Intact/Gaps Identified]
-{If gaps: List unsupported success criteria}
-
-**User Journeys → Functional Requirements:** [Intact/Gaps Identified]
-{If gaps: List journeys without supporting FRs}
-
-**Scope → FR Alignment:** [Intact/Misaligned]
-{If misaligned: List specific issues}
-
-### Orphan Elements
-
-**Orphan Functional Requirements:** {count}
-{List orphan FRs with numbers}
-
-**Unsupported Success Criteria:** {count}
-{List unsupported criteria}
-
-**User Journeys Without FRs:** {count}
-{List journeys without FRs}
-
-### Traceability Matrix
-
-{Summary table showing traceability coverage}
-
-**Total Traceability Issues:** {total}
-
-**Severity:** [Critical if orphan FRs exist, Warning if gaps, Pass if intact]
-
-**Recommendation:**
-[If Critical] "Orphan requirements exist - every FR must trace back to a user need or business objective."
-[If Warning] "Traceability gaps identified - strengthen chains to ensure all requirements are justified."
-[If Pass] "Traceability chain is intact - all requirements trace to user needs or business objectives."
-```
-
-### 5. Display Progress and Auto-Proceed
-
-Display: "**Traceability Validation Complete**
-
-Total Issues: {count} ({severity})
-
-**Proceeding to next validation check...**"
-
-Immediately load and execute {nextStepFile} (step-v-07-implementation-leakage-validation.md)
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- All traceability chains validated systematically
-- Orphan FRs identified with numbers
-- Broken chains documented
-- Traceability matrix built
-- Severity assessed correctly
-- Findings reported to validation report
-- Auto-proceeds to next validation step
-- Subprocess attempted with graceful degradation
-
-### ❌ SYSTEM FAILURE:
-
-- Not validating all traceability chains
-- Missing orphan FR detection
-- Not building traceability matrix
-- Not reporting findings to validation report
-- Not auto-proceeding
-
-**Master Rule:** Every requirement should trace to a user need or business objective. Orphan FRs indicate broken traceability that must be fixed.

package/pennyfarthing-dist/workflows/prd/steps-v/step-v-07-implementation-leakage-validation.md

@@ -1,211 +0,0 @@
----
-name: 'step-v-07-implementation-leakage-validation'
-description: 'Implementation Leakage Check - Ensure FRs and NFRs don\'t include implementation details'
-
-# 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
-
-<purpose>Ensure Functional Requirements and Non-Functional Requirements don't include implementation details - they should specify WHAT, not HOW.</purpose>
-
-<instructions>Extract all FRs and NFRs from PRD; scan each requirement for implementation keywords and patterns (specific technologies, frameworks, methodologies, HOW details); identify leakage violations; classify by severity; calculate leakage percentage; update validation report with findings and recommendations.</instructions>
-
-<output>Implementation leakage validation report with identified violations, severity classification, specific examples of leakage, leakage metrics, and recommendations for abstraction improvements.</output>
-
-## 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...**"
-
-Immediately load and execute {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/pennyfarthing-dist/workflows/prd/steps-v/step-v-08-domain-compliance-validation.md

@@ -1,249 +0,0 @@
----
-name: 'step-v-08-domain-compliance-validation'
-description: 'Domain Compliance Validation - Validate domain-specific requirements are present for high-complexity domains'
-
-# 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
-
-<purpose>Validate domain-specific requirements are present for high-complexity domains (Healthcare, Fintech, GovTech, etc.), ensuring regulatory and compliance requirements are properly documented.</purpose>
-
-<instructions>Determine project domain from PRD frontmatter; check domain complexity level from CSV data; for high-complexity domains, verify domain-specific requirements section exists and covers applicable regulations; analyze compliance coverage; identify compliance gaps; update validation report.</instructions>
-
-<output>Domain compliance validation report with complexity assessment, identified compliance requirements, coverage analysis, compliance gaps, and recommendations for domain-specific improvements.</output>
-
-## 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...**"
-
-Immediately load and execute {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...**"
-
-Immediately load and execute {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.