feat(): report all violations

.cursor/flows/README.md

@@ -27,21 +27,34 @@ Flows are collections of rule files (.mdc) that guide the AI through multi-step
 **Location:** `ds-refactoring-flow/`
 **Purpose:** Migrate components from deprecated design system patterns to modern alternatives
 
-**Files:**
-- `01-find-violations.mdc` - Identify deprecated component usage
-- `02-plan-refactoring.mdc` - Create detailed migration strategy
+**Flow Options:**
+
+**Option A: Targeted Approach** (recommended for focused, incremental migrations)
+- `01-find-violations.mdc` - Identify specific deprecated component usage
+- `02-plan-refactoring.mdc` - Create detailed migration strategy for specific cases
+
+**Option B: Comprehensive Approach** (recommended for large-scale migrations)
+- `01a-find-all-violations.mdc` - Scan entire codebase, group by folders, select subfolder for detailed analysis
+- `02a-plan-refactoring-for-all-violations.mdc` - Create comprehensive migration plan for all violations in scope
+
+**Continuation Steps** (used with both approaches):
 - `03-non-viable-cases.mdc` - Handle non-migratable components by marking them for exclusion
 - `03-fix-violations.mdc` - Execute code changes
 - `04-validate-changes.mdc` - Verify improvements through contract comparison
 - `05-prepare-report.mdc` - Generate testing checklists and documentation
 - `clean-global-styles.mdc` - Independent analysis of deprecated CSS usage
 
+**Choosing Your Approach:**
+- **Targeted (01 → 02)**: Use when working on specific components or small sets of violations. Provides focused analysis and incremental progress.
+- **Comprehensive (01a → 02a)**: Use when planning large-scale migrations across multiple folders. Provides broad overview first, then detailed planning for selected scope.
+
 **Special Handling:**
 - **Non-Viable Cases**: When components are identified as non-viable during the planning step, use `03-non-viable-cases.mdc` instead of proceeding with the normal fix violations step. This marks components with special prefixes (`after-migration-[ORIGINAL_CLASS]`) to exclude them from future violation reports.
 
 **Use Cases:** 
-- **Primary Flow**: Migrating components to modern design system patterns
-- **Non-Viable Handling**: Alternative handling within the main flow for legacy components that cannot be migrated
+- **Targeted Flow**: Incremental migration of specific components or small violation sets
+- **Comprehensive Flow**: Large-scale migration planning across multiple directories
+- **Non-Viable Handling**: Alternative handling within either flow for legacy components that cannot be migrated
 
 ## How to Use Flows
 

.cursor/rules/01-find-violations.mdc → .cursor/flows/ds-refactoring-flow/01a-find-all-violations.mdc

@@ -6,13 +6,11 @@ alwaysApply: false
 You are an AI assistant tasked with helping a developer identify and plan refactoring for legacy component usage. Follow these instructions carefully to complete the task in two main steps.
 
 First, I will provide you with the following information:
-<component_name>{{COMPONENT_NAME}}</component_name>
 <directory>{{DIRECTORY}}</directory>
 
 Step 1: Find violations
 
-1. Run a scan using the report-violations function with the following parameters:
-   - component: {{COMPONENT_NAME}}
+1. Run a scan using the report-all-violations function with the following parameters:
    - directory: {{DIRECTORY}}
    - groupBy: "folder"
 
@@ -22,8 +20,8 @@ Step 1: Find violations
    - If the function call returns an error, respond with:
      <commentary>🚨 *Tool execution failed* – [error message]</commentary>
      Then stop execution.
-   - If scanResult.totalViolations is 0, respond with:
-     "✅ No legacy usage of {{COMPONENT_NAME}} found."
+   - If no violations are found, respond with:
+     "✅ No legacy usage found."
      Then stop execution.
    - Otherwise, continue to the next step.
 
@@ -50,8 +48,7 @@ Once the user provides a subfolder choice, proceed as follows:
      Then stop execution.
 
 2. Run a file-level scan:
-   - Use the report-violations function with these parameters:
-     - component: {{COMPONENT_NAME}}
+   - Use the report-all-violations function with these parameters:
      - directory: {{SUBFOLDER}}
      - groupBy: "file"
    - Store the result in a variable called fileScan.
@@ -73,12 +70,4 @@ Once the user provides a subfolder choice, proceed as follows:
      ...
      </violations>
    - After the </violations> tag, prompt the user with:
-     ❓ **Please attach the "Plan Phase" rules now so I can start refactoring planning.**
-
-As in Step 1, any side remarks should go in an optional <commentary>...</commentary> tag.
-
-Final instructions:
-- Always use the exact format and wording provided for outputs and prompts.
-- Do not add any explanations or additional text unless explicitly instructed.
-- If you encounter any situations not covered by these instructions, respond with:
-  <commentary>⚠️ Unexpected situation encountered. Please provide further guidance.</commentary>
+     ❓ **Please attach the "Plan Phase" rules now so I can start refactoring planning.**

.cursor/flows/ds-refactoring-flow/02a-plan-refactoring-for-all-violations.mdc

@@ -0,0 +1,37 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+You are an AI assistant tasked with helping a development team migrate legacy components to a new design system. Your goal is to analyze the current codebase, identify areas that need updating, and provide a detailed plan for the migration process. This task will be completed in three phases: a comprehensive analysis, a detailed plan creation, and a checklist creation.
+
+You will be working with the following inputs:
+<folder_path>{{FOLDER_PATH}}</folder_path>: The path to the folder containing the legacy components
+<component_docs>{{COMPONENT_DOCS}}</component_docs>: The official documentation for the target design-system components
+<component_code>{{COMPONENT_CODE}}</component_code>: The source files of the target design-system components
+<usage_graph>{{USAGE_GRAPH}}</usage_graph>: A graph showing the usage of the legacy components in the specified folder
+<library_data>{{LIBRARY_DATA}}</library_data>: Information about library type
+
+# Phase 1: Comprehensive Analysis
+
+1. Review all provided inputs: COMPONENT_DOCS, COMPONENT_CODE, USAGE_GRAPH, and LIBRARY_DATA.
+
+2. Analyze the current codebase, focusing on:
+   a. The approved markup and API for the target components
+   b. The actual implementation of the design-system components
+   c. All files (templates, TS, styles, specs, NgModules) that reference the legacy components
+   d. Dependencies and library information
+
+3. Create a comprehensive summary of the analysis, including:
+   a. Total number of files affected
+   b. Assessment of migration complexity (Low, Medium, High)
+   c. Any potential non-viable migrations that may require manual rethinking
+   d. Key decisions or assumptions made during the analysis
+   e. Insights gained from examining the component files
+   f. Implications of the LIBRARY_DATA on the migration process
+
+Write your comprehensive analysis in <comprehensive_analysis> tags.
+
+# Phase 2: Detailed Plan Creation
+
+Please think about this problem thoroughly