create-byan-agent 2.1.0 → 2.1.1

package/_bmad/bmb/workflows/workflow/steps-v/step-02b-path-violations.md

@@ -1,265 +0,0 @@
----
-name: 'step-02b-path-violations'
-description: 'CRITICAL: Catch path violations step-02 misses - hardcoded paths, dead links, module awareness'
-
-nextStepFile: './step-03-menu-validation.md'
-targetWorkflowPath: '{workflow_folder_path}'
-validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
----
-
-# Validation Step 2b: Critical Path Violations
-
-## STEP GOAL:
-
-CRITICAL path checks that step-02's frontmatter validation MISSES. This catches violations in CONTENT (not frontmatter), dead links, and module path unawareness using grep/bash (ideally in a subprocess that can update the report or return all results to parent).
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 DO NOT BE LAZY - CHECK EVERY FILE
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
-- ⚙️ If any instruction in this file references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the instructed outcome in your main context thread and available toolset
-
-### Step-Specific Rules:
-
-- 🎯 Perform systematic bash/grep checks using subprocess optimization - single subprocess for grep/regex across many files
-- 🚫 DO NOT skip any file or violation type - DO NOT BE LAZY
-- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
-- 🚪 This catches what step-02 misses - CONTENT violations, dead links, module awareness, links in code and not in front matter
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Perform systematic checks using subprocess optimization when available - single subprocess for grep/regex across many files, separate subprocess per file for deep analysis, subprocess for data file operations
-- 💾 Subprocesses must either update validation report OR return findings for parent aggregation
-- 📖 Save report before continuing to {nextStepFile}
-
-## CONTEXT BOUNDARIES:
-
-- Step-02 validated frontmatter (variables, relative paths)
-- This step validates CONTENT and file existence with a Focus on: hardcoded paths in body, dead links, module awareness in every file found under {targetWorkflowPath}
-- **CRITICAL:** Output files the workflow itself being validated produces won't exist during validation - <example> a contract document creation workflow might have a reference to said output - but it of course will not yet exist during workflow validation</example>
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
-
-### 1. Perform Critical Path Violation Detection
-
-**Perform systematic path violation checks on EVERY workflow file using subprocess optimization when available - each file in its own subprocess:**
-
-**SUBPROCESS EXECUTION PATTERN:**
-
-For EACH file in the workflow being validated, launch a subprocess that:
-1. Loads any reference files it needs (to avoid bloating parent context)
-2. Performs all required checks on that file
-3. **EITHER** updates the validation report directly with its findings
-4. **OR** returns structured findings to parent for aggregation
-
-**DO NOT BE LAZY - Use appropriate subprocess pattern for each check:**
-- **Single subprocess for grep/regex**: Run one command across many files, return matches
-- **Separate subprocess per file**: When deep analysis of each file's content is required
-- **Subprocess for data operations**: Load reference data, find matches, summarize key findings
-
-**PHASE 1: Identify Config Variables (EXCEPTIONS to path checks):**
-
-Read {targetWorkflowPath}/workflow.md to extract known config variables from the Configuration Loading section:
-
-```bash
-# Extract config variables from workflow.md
-grep -A 20 "Configuration Loading" {targetWorkflowPath}/workflow.md | grep -E "^\s+-\s+`\{[^}]+\}`" | sed "s/.*//;s/[`']//g"
-```
-
-**Store these as KNOWN_CONFIG_VARIABLES for reference in later checks.**
-
-These are EXCEPTIONS - paths using these variables are VALID even if not relative:
-- Example: `{output_folder}/doc.md` - VALID (uses config variable)
-- Example: `{planning_artifacts}/prd.md` - VALID (uses config variable)
-- These paths won't exist during validation (workflow not running yet)
-
----
-
-**PHASE 2: Hardcoded paths in CONTENT (CRITICAL):**
-
-Step-02 checks frontmatter - this checks CONTENT (body text after frontmatter).
-
-**Launch a single subprocess that:**
-
-1. Runs grep across all step files to find hardcoded {project-root}/ paths in content
-2. Extracts content after frontmatter from each file
-3. Returns all findings to parent for aggregation
-
-```bash
-# Extract content after frontmatter from all files, search for {project-root}/
-for file in steps-c/*.md; do
-  awk '/^---$/,0 {if (p) print; p=1} /^---$/{p=1}' "$file" | grep -n "{project-root}/" && echo "Found in: $file"
-done
-```
-
-**What we're catching:**
-- Content like: `Load {project-root}/_bmad/foo/workflows/.../file.csv`
-- Should be: `Load {dataFile}` (frontmatter variable with a relative path like ../data/file.csv)
-
-**SKIP:** Paths using KNOWN_CONFIG_VARIABLES (these are valid exceptions)
-
----
-
-**PHASE 3: Dead or bad links - referenced files don't exist (CRITICAL):**
-
-**Launch a single subprocess that:**
-
-1. Extracts all frontmatter path references from all files
-2. Tests file existence for each reference (skipping output files that use config variables)
-3. Returns all dead link findings to parent for aggregation
-
-**CRITICAL DISTINCTION:**
-- **Output files using config variables:** Skip (won't exist yet - workflow not installed/running)
-  - Example: `{output_folder}/my-doc.md` - SKIP
-  - Example: `{planning_artifacts}/prd.md` - SKIP
-  - Example: `{bmb_creations_output_folder}/file.md` - SKIP
-
-- **Data files, step files, other workflows:** MUST EXIST - flag if missing
-  - Example: `{dataFile}` where value is `../data/config.csv` - MUST EXIST
-  - Example: `{nextStepFile}` where value is `./step-02.md` - MUST EXIST
-  - Example: `{advancedElicitationTask}` - MUST EXIST
-  - Example: `{partyModeWorkflow}` - MUST EXIST
-
-**Bash execution pattern:**
-```bash
-# Extract all frontmatter path references from all files
-for file in steps-c/*.md; do
-  # Extract file reference variables from frontmatter
-  grep "^\w*File:" "$file" | sed "s/.*: //"
-
-  # Resolve path (handle relative paths)
-  resolved_path=$(resolve_relative_path "$file" "$value")
-
-  # Check file existence - BUT SKIP output files using config variables
-  if ! path_uses_known_config_variable "$value"; then
-    if ! test -f "$resolved_path"; then
-      echo "DEAD LINK: $file references $resolved_path (not found)"
-    fi
-  fi
-done
-```
-
-**What we're catching:**
-- Dead links to any files that don't exist that the workflow needs during execution
-
----
-
-**PHASE 4: Module path awareness:**
-
-**Launch a single subprocess that:**
-
-1. Determines if current workflow is in a non-bmb module
-2. If yes, runs grep across all files to find bmb-specific path assumptions
-3. Returns all module awareness issues to parent for aggregation
-
-```bash
-# Check if in non-bmb module, then search for bmb-specific paths
-if pwd | grep -q "/modules/[^/]\+/" && ! pwd | grep -q "/bmb/"; then
-  grep -rn "{project-root}/_bmad/bmb/" steps-c/ steps-e/ steps-v/ 2>/dev/null || echo "No bmb-specific paths found"
-fi
-```
-
----
-
-**RETURN FORMAT:**
-
-```json
-{
-  "known_config_variables": ["output_folder", "planning_artifacts", "bmb_creations_output_folder", ...],
-  "content_violations": [
-    {"file": "step-v-01-discovery.md", "line": 63, "violation": "hardcoded path in content", "details": "{project-root}/src/modules/.../prd-purpose.md"}
-  ],
-  "dead_links": [
-    {"file": "step-06-innovation.md", "line": 215, "violation": "dead link", "details": "nextStepFile './step-07-project-type.md' should be './step-07-project-type.md'"}
-  ],
-  "module_awareness_issues": [
-    {"file": "step-XX.md", "issue": "using bmb-specific path in non-bmb module"}
-  ],
-  "summary": {"critical": N, "high": N, "medium": N}
-}
-```
-
-Check ALL files systematically. Return structured report for compilation and appendage to validation report.
-
-### 2. Process Findings and Update Report
-
-**Create/Update "Critical Path Violations" section in {validationReportFile}:**
-
-If ANY violations found:
-
-```markdown
-## Critical Path Violations
-
-### Config Variables (Exceptions)
-
-The following config variables were identified from workflow.md Configuration Loading section.
-Paths using these variables are valid even if not relative (they reference post-install output locations):
-
-{list of known_config_variables found}
-
-### Content Path Violations
-
-| File | Line | Issue | Details |
-| ---- | ---- | ----- | ------- |
-{table from content_violations}
-
-### Dead Links
-
-| File | Line | Issue | Details |
-| ---- | ---- | ----- | ------- |
-{table from dead_links}
-
-**Note:** Output files using config variables were correctly skipped during existence checks.
-
-### Module Awareness
-
-{module_awareness_issues}
-
-### Summary
-
-- **CRITICAL:** {critical_count} violations (must fix - workflow will break)
-- **HIGH:** {high_count} violations (should fix)
-- **MEDIUM:** {medium_count} violations (review)
-
-**Status:** {"❌ FAIL - Critical violations detected" or "⚠️ WARNINGS - Review recommended" or "✅ PASS - No violations"}
-```
-
-### 3. Handle Critical Violations
-
-**If CRITICAL violations found (content violations OR dead links):**
-
-Halt process once all files have been checked and aggregated - and share the severity of the issue with the user and ask them if they want to stop and you can try to fix these now, or else go to the next item in this list. If not proceeding - its still critical all findings thus far are documented in the report output.
-
-### 4. Save Report and Auto-Proceed
-
-**CRITICAL:** Save the validation report to {validationReportFile} BEFORE loading and executing {nextStepFile}.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Config variables identified from workflow.md FIRST
-- Known config variables used as exceptions in later checks
-- ALL step files checked for content path violations
-- Dead links detected via file existence tests (skipping output files)
-- Module awareness issues flagged
-- Findings appended to validation report
-- CRITICAL violations halt validation
-- Clean workflows proceed to step-03
-
-### ❌ SYSTEM FAILURE:
-
-- Not identifying config variables first
-- Not skipping output files during existence checks
-- Not checking content (only frontmatter)
-- Missing dead link detection
-- Not detecting module-specific assumptions
-- Proceeding despite critical violations

package/_bmad/bmb/workflows/workflow/steps-v/step-03-menu-validation.md

@@ -1,164 +0,0 @@
----
-name: 'step-03-menu-validation'
-description: 'Validate menu handling compliance across all step files'
-
-nextStepFile: './step-04-step-type-validation.md'
-targetWorkflowPath: '{workflow_folder_path}'
-validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
-menuHandlingStandards: '../data/menu-handling-standards.md'
----
-
-# Validation Step 3: Menu Handling Validation
-
-## STEP GOAL:
-
-To validate that EVERY step file's menus follow the menu handling standards - proper handlers, execution rules, appropriate menu types.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step, ensure entire file is read
-- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
-- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
-
-### Step-Specific Rules:
-
-- 🎯 Validate EVERY step file's menus using subprocess optimization - per-file deep analysis pattern (Pattern 2)
-- 🚫 DO NOT skip any files or checks - DO NOT BE LAZY
-- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
-- 🚪 This is validation - systematic and thorough, leveraging per-file subprocess for menu structure analysis
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load menu standards first
-- 💾 Check EVERY file's menu structure using subprocess optimization when available - per-file deep analysis for menu structure validation
-- 📖 Append findings to validation report (subprocesses either update report OR return findings for parent aggregation)
-- 🚫 DO NOT halt for user input - validation runs to completion
-
-## CONTEXT BOUNDARIES:
-
-- All step files in steps-c/ must be validated
-- Load {menuHandlingStandards} for validation criteria
-- Check for: handler section, execution rules, reserved letters, inappropriate A/P
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
-
-### 1. Load Menu Standards
-
-Load {menuHandlingStandards} to understand validation criteria:
-
-**Reserved Letters:** A (Advanced Elicitation), P (Party Mode), C (Continue/Accept), X (Exit/Cancel)
-
-**Required Structure:**
-1. Display section
-2. Handler section (MANDATORY)
-3. Execution Rules section
-
-**When To Include A/P:**
-- DON'T: Step 1 (init), validation sequences, simple data gathering
-- DO: Collaborative content creation, user might want alternatives, quality gates
-
-### 2. Check EVERY Step File
-
-**DO NOT BE LAZY - For EVERY file in steps-c/, launch a subprocess that:**
-
-1. Loads that step file
-2. Loads {menuHandlingStandards} to understand validation criteria
-3. Validates menu structure deeply (handler section, execution rules, A/P appropriateness, reserved letter compliance)
-4. **EITHER** updates validation report directly with findings
-5. **OR** returns structured validation findings to parent for aggregation
-
-**SUBPROCESS VALIDATION PATTERN - Each subprocess checks for:**
-
-**Check 1: Handler Section Exists**
-- ✅ Handler section immediately follows Display
-- ❌ If missing: mark as violation
-
-**Check 2: Execution Rules Section Exists**
-- ✅ "EXECUTION RULES" section present
-- ✅ Contains "halt and wait" instruction
-- ❌ If missing: mark as violation
-
-**Check 3: Non-C Options Redisplay Menu**
-- ✅ A/P options specify "redisplay menu"
-- ❌ If missing: mark as violation
-
-**Check 4: C Option Sequence**
-- ✅ C option: save → update frontmatter → load next step
-- ❌ If sequence wrong: mark as violation
-
-**Check 5: A/P Only Where Appropriate**
-- Step 01 should NOT have A/P (inappropriate for init)
-- Validation sequences should auto-proceed, not have menus
-- ❌ If A/P in wrong place: mark as violation
-
-**RETURN FORMAT:**
-Each subprocess should return validation findings for its assigned file including:
-- File name
-- Whether a menu is present
-- Results of all 5 checks (handler section, execution rules, redisplay menu, C sequence, A/P appropriateness)
-- List of any violations found
-- Overall status (PASS/FAIL/WARN)
-
-**Context savings estimate:** Each subprocess returns structured findings vs full file content. Parent aggregates all findings into final report table.
-
-### 3. Aggregate Findings and Document Results
-
-After ALL files have been validated (either via subprocess or main context), document the menu handling validation results in the validation report, including:
-
-- Overall assessment of menu handling compliance across all step files
-- Summary of files checked and their menu status
-- Files that passed all menu validation checks
-- Files with warnings or issues that need attention
-- Files that failed validation with specific violations
-
-### 4. List Violations
-
-Compile and document all violations found during validation, organizing them by file and providing clear descriptions of each issue, such as:
-
-- Missing handler sections
-- Incomplete execution rules
-- Improper A/P usage
-- Missing redisplay menu instructions
-- Any other menu handling standard violations
-
-### 5. Append to Report
-
-Update {validationReportFile} - replace "## Menu Handling Validation *Pending...*" with actual findings.
-
-### 6. Save Report and Auto-Proceed
-
-**CRITICAL:** Save the validation report BEFORE loading next step.
-
-Then immediately load, read entire file, then execute {nextStepFile}.
-
-**Display:**
-"**Menu Handling validation complete.** Proceeding to Step Type Validation..."
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Menu standards loaded and understood
-- EVERY step file's menus validated via subprocess (per-file deep analysis) OR main context
-- All violations documented across handler sections, execution rules, A/P appropriateness
-- Findings aggregated into validation report (subprocesses either updated report OR returned findings)
-- Report saved before proceeding
-- Next validation step loaded
-
-### ❌ SYSTEM FAILURE:
-
-- Not checking every file's menus
-- Skipping menu structure checks
-- Not documenting violations
-- Not saving report before proceeding
-- Loading full file contents into parent context instead of using subprocess analysis
-
-**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Use subprocess optimization (Pattern 2) - each file in its own subprocess for deep menu structure analysis. Subprocess returns only findings to parent. Auto-proceed through all validation steps.

package/_bmad/bmb/workflows/workflow/steps-v/step-04-step-type-validation.md

@@ -1,211 +0,0 @@
----
-name: 'step-04-step-type-validation'
-description: 'Validate that each step follows its correct step type pattern'
-
-nextStepFile: './step-05-output-format-validation.md'
-targetWorkflowPath: '{workflow_folder_path}'
-validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
-stepTypePatterns: '../data/step-type-patterns.md'
-workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
----
-
-# Validation Step 4: Step Type Validation
-
-## STEP GOAL:
-
-To validate that each step file follows the correct pattern for its step type - init, continuation, middle, branch, validation, final polish, or final.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step, ensure entire file is read
-- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
-- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
-
-### Step-Specific Rules:
-
-- 🎯 Load and validate EVERY step against its type pattern - use subprocess optimization (Pattern 2: per-file deep analysis) when available
-- 🚫 DO NOT skip any files or checks - DO NOT BE LAZY
-- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
-- 🚪 This is validation - systematic and thorough
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load step type patterns first (use subprocess for data operations when available)
-- 💾 Check EACH file follows its designated type pattern - use per-file subprocesses for deep analysis when available
-- 📖 Append findings to validation report (subprocess updates report OR returns findings to parent)
-- 🚫 DO NOT halt for user input - validation runs to completion
-
-## CONTEXT BOUNDARIES:
-
-- All step files in steps-c/ must be validated
-- Load {stepTypePatterns} for pattern definitions
-- The design in {workflowPlanFile} specifies what each step should be
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
-
-### 1. Load Step Type Patterns
-
-**Load {stepTypePatterns} to understand the pattern for each type:**
-
-**If subprocess capability available:**
-```markdown
-Launch a subprocess that:
-1. Loads {stepTypePatterns}
-2. Extracts all pattern definitions deeply
-3. Returns summary of patterns to parent (not full file - saves context)
-```
-
-**If subprocess unavailable:**
-```markdown
-Load {stepTypePatterns} in main context
-# Larger context but still functional - demonstrates graceful fallback
-```
-
-**Step Types:**
-1. **Init (Non-Continuable)** - Auto-proceed, no continuation logic
-2. **Init (Continuable)** - Has continueFile reference, continuation detection
-3. **Continuation (01b)** - Paired with continuable init, routes based on stepsCompleted
-4. **Middle (Standard)** - A/P/C menu, collaborative content
-5. **Middle (Simple)** - C only menu, no A/P
-6. **Branch** - Custom menu with routing to different steps
-7. **Validation Sequence** - Auto-proceed through checks, no menu
-8. **Init (With Input Discovery)** - Has inputDocuments array, discovery logic
-9. **Final Polish** - Loads entire doc, optimizes flow
-10. **Final** - No next step, completion message
-
-### 2. Check EACH Step Against Its Type
-
-**DO NOT BE LAZY - For EACH file in steps-c/, launch a subprocess that:**
-
-1. Determines what type this step SHOULD be from:
-   - Step number (01 = init, 01b = continuation, last = final)
-   - Design in {workflowPlanFile}
-   - Step name pattern
-
-2. Loads the step file
-
-3. Validates it follows the pattern for its type
-
-4. **EITHER** updates the validation report directly with its findings
-5. **OR** returns structured findings to parent for aggregation
-
-**SUBPROCESS ANALYSIS PATTERN - Validate each step file for:**
-
-**For Init Steps:**
-- ✅ Creates output from template (if document-producing)
-- ✅ No A/P menu (or C-only)
-- ✅ If continuable: has continueFile reference
-
-**For Continuation (01b):**
-- ✅ Has nextStepOptions in frontmatter
-- ✅ Reads stepsCompleted from output
-- ✅ Routes to appropriate step
-
-**For Middle (Standard):**
-- ✅ Has A/P/C menu
-- ✅ Outputs to document (if applicable)
-- ✅ Has mandatory execution rules
-
-**For Middle (Simple):**
-- ✅ Has C-only menu
-- ✅ No A/P options
-
-**For Branch:**
-- ✅ Has custom menu letters
-- ✅ Handler routes to different steps
-
-**For Validation Sequence:**
-- ✅ Auto-proceeds (no user choice)
-- ✅ Proceeds to next validation
-
-**For Final Polish:**
-- ✅ Loads entire document
-- ✅ Optimizes flow, removes duplication
-- ✅ Uses ## Level 2 headers
-
-**For Final:**
-- ✅ No nextStepFile in frontmatter
-- ✅ Completion message
-- ✅ No next step to load
-
-**RETURN FORMAT:**
-Return a concise summary containing:
-- File name analyzed
-- What type the step should be
-- What type it actually is
-- Whether it follows the correct pattern
-- List of any violations found
-- Overall pass/fail status
-
-**Context savings:** Each subprocess returns only validation findings, not full file contents. Parent receives structured analysis objects instead of 10+ full step files.
-
-### 3. Aggregate Findings and Document
-
-**After ALL files analyzed, aggregate findings from subprocesses and document results:**
-
-**Document the following in the validation report:**
-
-- Overall summary of step type validation (how many steps checked, pass/fail counts)
-- For each step file:
-  - File name
-  - What type the step should be (based on design, step number, naming)
-  - What type it actually is
-  - Whether it follows the correct pattern for its type
-  - Any violations or issues found
-  - Pass/fail/warning status
-
-**Format:** Create a clear, readable section in the validation report that shows the validation results for each step file.
-
-### 4. List Violations
-
-**Compile and document all violations found:**
-
-**Document the following for any violations:**
-
-- File name with violation
-- What the violation is (specifically what doesn't match the expected pattern)
-- What should be changed to fix it
-- Severity level (error/warning)
-
-**For files that pass validation:** Briefly note they follow their type patterns correctly.
-
-### 5. Append to Report
-
-Update {validationReportFile} - replace "## Step Type Validation *Pending...*" with actual findings.
-
-### 6. Save Report and Auto-Proceed
-
-**CRITICAL:** Save the validation report BEFORE loading next step.
-
-Then immediately load, read entire file, then execute {nextStepFile}.
-
-**Display:**
-"**Step Type validation complete.** Proceeding to Output Format Validation..."
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- EVERY step validated against its type pattern (ideally using per-file subprocess optimization)
-- All violations documented with structured findings
-- Findings aggregated from subprocesses into report
-- Report saved before proceeding
-- Next validation step loaded
-- Context saved: parent receives only findings, not full file contents
-
-### ❌ SYSTEM FAILURE:
-
-- Not checking every file's type pattern
-- Skipping type-specific checks
-- Not documenting violations
-- Not saving report before proceeding
-
-**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY file's type pattern. Auto-proceed through all validation steps.