feat(): update cursor rules and ds-refactoring-flow

Author: Szymon.Poltorak

.cursor/flows/ds-refactoring-flow/01-find-violations.mdc

@@ -6,28 +6,32 @@ 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"
 
    Store the result in a variable called scanResult.
 
-2. Perform first-level error handling:
+2. Deduplicate violations by file and line:
+   - Process scanResult to remove duplicate entries that have the same file path and line number
+   - When combining duplicates, merge the component/class information (e.g., "btn, btn-primary violations on line 10")
+   - Keep the deduplicated count for accurate violation totals
+   - Store the deduplicated result and use it for all subsequent processing
+
+3. Perform first-level error handling:
    - 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.
 
-3. Output the results for the user:
+4. Output the results for the user:
    - Print the ranked list of folders inside <folders> tags, like this:
      <folders>
      1. [path/to/folder-A] – [X] violations in [Y] files
@@ -50,13 +54,18 @@ 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.
 
-3. Perform error handling and validation:
+3. Deduplicate violations by file and line:
+   - Process fileScan to remove duplicate entries that have the same file path and line number
+   - When combining duplicates, merge the component/class information
+   - Keep the deduplicated count for accurate violation totals
+   - Store the deduplicated result and use it for all subsequent processing
+
+4. Perform error handling and validation:
    - If the function call returns an error, respond with:
      <commentary>🚨 *Tool execution failed* – [error message]</commentary>
      Then stop execution.
@@ -65,20 +74,12 @@ Once the user provides a subfolder choice, proceed as follows:
      Then stop execution.
    - Sort the files by number of violations (descending) and then alphabetically.
 
-4. Output the results for the plan phase:
+5. Output the results for the plan phase:
    - Print the sorted list of files inside <violations> tags, like this:
      <violations>
      1. [path/to/file-A.tsx] – [X] violations
      2. [path/to/file-B.tsx] – [X] violations
      ...
      </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/02-plan-refactoring.mdc

@@ -6,21 +6,20 @@ 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:
-<component_name>{{COMPONENT_NAME}}</component_name>: The name of the target design-system component
 <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 component
-<component_code>{{COMPONENT_CODE}}</component_code>: The source files of the target design-system component
-<usage_graph>{{USAGE_GRAPH}}</usage_graph>: A graph showing the usage of the legacy component in the specified folder
+<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 component
-   b. The actual implementation of the design-system component
-   c. All files (templates, TS, styles, specs, NgModules) that reference the legacy component
+   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:
@@ -35,47 +34,4 @@ Write your comprehensive analysis in <comprehensive_analysis> tags.
 
 # Phase 2: Detailed Plan Creation
 
-Please think about this problem thoroughly and in great detail. Consider multiple approaches and show your complete reasoning. Please perform a thourough and Based on your comprehensive analysis, create a detailed migration plan:
-
-1. For each affected file:
-   a. Compare the old markup against the design-system exemplar from the COMPONENT_DOCS.
-   b. Classify the migration effort as:
-      - Simple swap (straight replacement with no loss of behavior, styling, responsive rules, animation, click/test-ID, or accessibility attributes)
-      - Requires restructure (minor code or CSS tweaks needed to preserve behaviors or visuals that the design-system component lacks)
-      - Non-viable (needs manual rethink)
-   c. Assign a complexity score on a scale of 1-10, adding:
-      - +1 per removed animation or breakpoint
-      - +2 per business variant that needs to be rebuilt
-
-2. Create an actionable plan ordered by effort, including:
-   a. File path & type
-   b. Refactor classification
-   c. Concrete edits needed (template, TS, styles, NgModule, spec)
-   d. Verification notes (2-3 static checks that can be performed by reading files only)
-   e. Complexity score
-
-3. If any items are classified as non-viable, explicitly highlight these in a separate section of your plan.
-
-4. Review your detailed plan against the COMPONENT_DOCS to ensure all recommendations align with the official documentation.
-
-5. Identify any ambiguities in your plan that could be interpreted multiple ways and list these in a separate section.
-
-Write your detailed migration plan in <migration_plan> tags.
-
-# Phase 3: Checklist Creation
-
-After the user approves the plan and clarifies any ambiguities:
-
-1. Create a checklist that lists only actual changes as checkboxes.
-2. Create a "check" phase where all verifications (2-3 static checks that can be performed by reading files only) are listed as checkboxes.
-3. Ensure the checklist is comprehensive and follows directly from the approved migration plan.
-
-Write your checklist in <checklist> tags.
-
-Your final output should include only the following:
-1. The <comprehensive_analysis> block
-2. The <migration_plan> block
-3. The following approval request: "🛠️ Approve this plan or specify adjustments?"
-4. If applicable, an ambiguity safeguard: "❓ The plan contains ambiguities: [short description]. Please clarify."
-
-After the user approves the plan and clarifies any ambiguities, provide only the <checklist> block in your response. Also, remember to save the checklist in a file at .cursor/tmp/refactoring-checklis-{{FOLDER_PATH}}.md.
+Please think about this problem thoroughly

.cursor/rules/01-find-violations.mdc

@@ -6,28 +6,32 @@ 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"
 
    Store the result in a variable called scanResult.
 
-2. Perform first-level error handling:
+2. Deduplicate violations by file and line:
+   - Process scanResult to remove duplicate entries that have the same file path and line number
+   - When combining duplicates, merge the component/class information (e.g., "btn, btn-primary violations on line 10")
+   - Keep the deduplicated count for accurate violation totals
+   - Store the deduplicated result and use it for all subsequent processing
+
+3. Perform first-level error handling:
    - 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.
 
-3. Output the results for the user:
+4. Output the results for the user:
    - Print the ranked list of folders inside <folders> tags, like this:
      <folders>
      1. [path/to/folder-A] – [X] violations in [Y] files
@@ -50,13 +54,18 @@ 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.
 
-3. Perform error handling and validation:
+3. Deduplicate violations by file and line:
+   - Process fileScan to remove duplicate entries that have the same file path and line number
+   - When combining duplicates, merge the component/class information
+   - Keep the deduplicated count for accurate violation totals
+   - Store the deduplicated result and use it for all subsequent processing
+
+4. Perform error handling and validation:
    - If the function call returns an error, respond with:
      <commentary>🚨 *Tool execution failed* – [error message]</commentary>
      Then stop execution.
@@ -65,20 +74,12 @@ Once the user provides a subfolder choice, proceed as follows:
      Then stop execution.
    - Sort the files by number of violations (descending) and then alphabetically.
 
-4. Output the results for the plan phase:
+5. Output the results for the plan phase:
    - Print the sorted list of files inside <violations> tags, like this:
      <violations>
      1. [path/to/file-A.tsx] – [X] violations
      2. [path/to/file-B.tsx] – [X] violations
      ...
      </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/rules/02-plan-refactoring.mdc

@@ -6,21 +6,20 @@ 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:
-<component_name>{{COMPONENT_NAME}}</component_name>: The name of the target design-system component
 <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 component
-<component_code>{{COMPONENT_CODE}}</component_code>: The source files of the target design-system component
-<usage_graph>{{USAGE_GRAPH}}</usage_graph>: A graph showing the usage of the legacy component in the specified folder
+<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 component
-   b. The actual implementation of the design-system component
-   c. All files (templates, TS, styles, specs, NgModules) that reference the legacy component
+   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:
@@ -35,47 +34,4 @@ Write your comprehensive analysis in <comprehensive_analysis> tags.
 
 # Phase 2: Detailed Plan Creation
 
-Please think about this problem thoroughly and in great detail. Consider multiple approaches and show your complete reasoning. Please perform a thourough and Based on your comprehensive analysis, create a detailed migration plan:
-
-1. For each affected file:
-   a. Compare the old markup against the design-system exemplar from the COMPONENT_DOCS.
-   b. Classify the migration effort as:
-      - Simple swap (straight replacement with no loss of behavior, styling, responsive rules, animation, click/test-ID, or accessibility attributes)
-      - Requires restructure (minor code or CSS tweaks needed to preserve behaviors or visuals that the design-system component lacks)
-      - Non-viable (needs manual rethink)
-   c. Assign a complexity score on a scale of 1-10, adding:
-      - +1 per removed animation or breakpoint
-      - +2 per business variant that needs to be rebuilt
-
-2. Create an actionable plan ordered by effort, including:
-   a. File path & type
-   b. Refactor classification
-   c. Concrete edits needed (template, TS, styles, NgModule, spec)
-   d. Verification notes (2-3 static checks that can be performed by reading files only)
-   e. Complexity score
-
-3. If any items are classified as non-viable, explicitly highlight these in a separate section of your plan.
-
-4. Review your detailed plan against the COMPONENT_DOCS to ensure all recommendations align with the official documentation.
-
-5. Identify any ambiguities in your plan that could be interpreted multiple ways and list these in a separate section.
-
-Write your detailed migration plan in <migration_plan> tags.
-
-# Phase 3: Checklist Creation
-
-After the user approves the plan and clarifies any ambiguities:
-
-1. Create a checklist that lists only actual changes as checkboxes.
-2. Create a "check" phase where all verifications (2-3 static checks that can be performed by reading files only) are listed as checkboxes.
-3. Ensure the checklist is comprehensive and follows directly from the approved migration plan.
-
-Write your checklist in <checklist> tags.
-
-Your final output should include only the following:
-1. The <comprehensive_analysis> block
-2. The <migration_plan> block
-3. The following approval request: "🛠️ Approve this plan or specify adjustments?"
-4. If applicable, an ambiguity safeguard: "❓ The plan contains ambiguities: [short description]. Please clarify."
-
-After the user approves the plan and clarifies any ambiguities, provide only the <checklist> block in your response. Also, remember to save the checklist in a file at .cursor/tmp/refactoring-checklis-{{FOLDER_PATH}}.md.
+Please think about this problem thoroughly