This is page 10 of 10. Use http://codebase.md/push-based/angular-toolkit-mcp?lines=true&page={x} to view the full context.
# Directory Structure
```
├── .aiignore
├── .cursor
│ ├── flows
│ │ ├── component-refactoring
│ │ │ ├── 01-review-component.mdc
│ │ │ ├── 02-refactor-component.mdc
│ │ │ ├── 03-validate-component.mdc
│ │ │ └── angular-20.md
│ │ ├── ds-refactoring-flow
│ │ │ ├── 01-find-violations.mdc
│ │ │ ├── 01b-find-all-violations.mdc
│ │ │ ├── 02-plan-refactoring.mdc
│ │ │ ├── 02b-plan-refactoring-for-all-violations.mdc
│ │ │ ├── 03-fix-violations.mdc
│ │ │ ├── 03-non-viable-cases.mdc
│ │ │ ├── 04-validate-changes.mdc
│ │ │ ├── 05-prepare-report.mdc
│ │ │ └── clean-global-styles.mdc
│ │ └── README.md
│ └── mcp.json.example
├── .github
│ └── workflows
│ └── ci.yml
├── .gitignore
├── .nvmrc
├── .prettierignore
├── .prettierrc
├── assets
│ ├── entain-logo.png
│ └── entain.png
├── CONTRIBUTING.MD
├── docs
│ ├── architecture-internal-design.md
│ ├── component-refactoring-flow.md
│ ├── contracts.md
│ ├── ds-refactoring-flow.md
│ ├── getting-started.md
│ ├── README.md
│ ├── tools.md
│ └── writing-custom-tools.md
├── eslint.config.mjs
├── jest.config.ts
├── jest.preset.mjs
├── LICENSE
├── nx.json
├── package-lock.json
├── package.json
├── packages
│ ├── .gitkeep
│ ├── angular-mcp
│ │ ├── eslint.config.mjs
│ │ ├── package.json
│ │ ├── README.md
│ │ ├── src
│ │ │ ├── assets
│ │ │ │ └── .gitkeep
│ │ │ └── main.ts
│ │ ├── tsconfig.app.json
│ │ ├── tsconfig.json
│ │ ├── vitest.config.mts
│ │ └── webpack.config.cjs
│ ├── angular-mcp-server
│ │ ├── eslint.config.mjs
│ │ ├── package.json
│ │ ├── README.md
│ │ ├── src
│ │ │ ├── index.ts
│ │ │ └── lib
│ │ │ ├── angular-mcp-server.ts
│ │ │ ├── prompts
│ │ │ │ └── prompt-registry.ts
│ │ │ ├── tools
│ │ │ │ ├── ds
│ │ │ │ │ ├── component
│ │ │ │ │ │ ├── get-deprecated-css-classes.tool.ts
│ │ │ │ │ │ ├── get-ds-component-data.tool.ts
│ │ │ │ │ │ ├── list-ds-components.tool.ts
│ │ │ │ │ │ └── utils
│ │ │ │ │ │ ├── deprecated-css-helpers.ts
│ │ │ │ │ │ ├── doc-helpers.ts
│ │ │ │ │ │ ├── metadata-helpers.ts
│ │ │ │ │ │ └── paths-helpers.ts
│ │ │ │ │ ├── component-contract
│ │ │ │ │ │ ├── builder
│ │ │ │ │ │ │ ├── build-component-contract.tool.ts
│ │ │ │ │ │ │ ├── models
│ │ │ │ │ │ │ │ ├── schema.ts
│ │ │ │ │ │ │ │ └── types.ts
│ │ │ │ │ │ │ ├── spec
│ │ │ │ │ │ │ │ ├── css-match.spec.ts
│ │ │ │ │ │ │ │ ├── dom-slots.extractor.spec.ts
│ │ │ │ │ │ │ │ ├── element-helpers.spec.ts
│ │ │ │ │ │ │ │ ├── inline-styles.collector.spec.ts
│ │ │ │ │ │ │ │ ├── meta.generator.spec.ts
│ │ │ │ │ │ │ │ ├── public-api.extractor.spec.ts
│ │ │ │ │ │ │ │ ├── styles.collector.spec.ts
│ │ │ │ │ │ │ │ └── typescript-analyzer.spec.ts
│ │ │ │ │ │ │ └── utils
│ │ │ │ │ │ │ ├── build-contract.ts
│ │ │ │ │ │ │ ├── css-match.ts
│ │ │ │ │ │ │ ├── dom-slots.extractor.ts
│ │ │ │ │ │ │ ├── element-helpers.ts
│ │ │ │ │ │ │ ├── inline-styles.collector.ts
│ │ │ │ │ │ │ ├── meta.generator.ts
│ │ │ │ │ │ │ ├── public-api.extractor.ts
│ │ │ │ │ │ │ ├── styles.collector.ts
│ │ │ │ │ │ │ └── typescript-analyzer.ts
│ │ │ │ │ │ ├── diff
│ │ │ │ │ │ │ ├── diff-component-contract.tool.ts
│ │ │ │ │ │ │ ├── models
│ │ │ │ │ │ │ │ └── schema.ts
│ │ │ │ │ │ │ ├── spec
│ │ │ │ │ │ │ │ ├── diff-utils.spec.ts
│ │ │ │ │ │ │ │ └── dom-path-utils.spec.ts
│ │ │ │ │ │ │ └── utils
│ │ │ │ │ │ │ ├── diff-utils.ts
│ │ │ │ │ │ │ └── dom-path-utils.ts
│ │ │ │ │ │ ├── index.ts
│ │ │ │ │ │ ├── list
│ │ │ │ │ │ │ ├── list-component-contracts.tool.ts
│ │ │ │ │ │ │ ├── models
│ │ │ │ │ │ │ │ ├── schema.ts
│ │ │ │ │ │ │ │ └── types.ts
│ │ │ │ │ │ │ ├── spec
│ │ │ │ │ │ │ │ └── contract-list-utils.spec.ts
│ │ │ │ │ │ │ └── utils
│ │ │ │ │ │ │ └── contract-list-utils.ts
│ │ │ │ │ │ └── shared
│ │ │ │ │ │ ├── models
│ │ │ │ │ │ │ └── types.ts
│ │ │ │ │ │ ├── spec
│ │ │ │ │ │ │ └── contract-file-ops.spec.ts
│ │ │ │ │ │ └── utils
│ │ │ │ │ │ └── contract-file-ops.ts
│ │ │ │ │ ├── component-usage-graph
│ │ │ │ │ │ ├── build-component-usage-graph.tool.ts
│ │ │ │ │ │ ├── index.ts
│ │ │ │ │ │ ├── models
│ │ │ │ │ │ │ ├── config.ts
│ │ │ │ │ │ │ ├── schema.ts
│ │ │ │ │ │ │ └── types.ts
│ │ │ │ │ │ └── utils
│ │ │ │ │ │ ├── angular-parser.ts
│ │ │ │ │ │ ├── component-helpers.ts
│ │ │ │ │ │ ├── component-usage-graph-builder.ts
│ │ │ │ │ │ ├── path-resolver.ts
│ │ │ │ │ │ └── unified-ast-analyzer.ts
│ │ │ │ │ ├── ds.tools.ts
│ │ │ │ │ ├── project
│ │ │ │ │ │ ├── get-project-dependencies.tool.ts
│ │ │ │ │ │ ├── report-deprecated-css.tool.ts
│ │ │ │ │ │ └── utils
│ │ │ │ │ │ ├── dependencies-helpers.ts
│ │ │ │ │ │ └── styles-report-helpers.ts
│ │ │ │ │ ├── report-violations
│ │ │ │ │ │ ├── index.ts
│ │ │ │ │ │ ├── models
│ │ │ │ │ │ │ ├── schema.ts
│ │ │ │ │ │ │ └── types.ts
│ │ │ │ │ │ ├── report-all-violations.tool.ts
│ │ │ │ │ │ └── report-violations.tool.ts
│ │ │ │ │ ├── shared
│ │ │ │ │ │ ├── index.ts
│ │ │ │ │ │ ├── models
│ │ │ │ │ │ │ ├── input-schemas.model.ts
│ │ │ │ │ │ │ └── schema-helpers.ts
│ │ │ │ │ │ ├── utils
│ │ │ │ │ │ │ ├── component-validation.ts
│ │ │ │ │ │ │ ├── cross-platform-path.ts
│ │ │ │ │ │ │ ├── handler-helpers.ts
│ │ │ │ │ │ │ ├── output.utils.ts
│ │ │ │ │ │ │ └── regex-helpers.ts
│ │ │ │ │ │ └── violation-analysis
│ │ │ │ │ │ ├── base-analyzer.ts
│ │ │ │ │ │ ├── coverage-analyzer.ts
│ │ │ │ │ │ ├── formatters.ts
│ │ │ │ │ │ ├── index.ts
│ │ │ │ │ │ └── types.ts
│ │ │ │ │ └── tools.ts
│ │ │ │ ├── schema.ts
│ │ │ │ ├── tools.ts
│ │ │ │ ├── types.ts
│ │ │ │ └── utils.ts
│ │ │ └── validation
│ │ │ ├── angular-mcp-server-options.schema.ts
│ │ │ ├── ds-components-file-loader.validation.ts
│ │ │ ├── ds-components-file.validation.ts
│ │ │ ├── ds-components.schema.ts
│ │ │ └── file-existence.ts
│ │ ├── tsconfig.json
│ │ ├── tsconfig.lib.json
│ │ ├── tsconfig.tsbuildinfo
│ │ └── vitest.config.mts
│ ├── minimal-repo
│ │ └── packages
│ │ ├── application
│ │ │ ├── angular.json
│ │ │ ├── code-pushup.config.ts
│ │ │ ├── src
│ │ │ │ ├── app
│ │ │ │ │ ├── app.component.ts
│ │ │ │ │ ├── app.config.ts
│ │ │ │ │ ├── app.routes.ts
│ │ │ │ │ ├── components
│ │ │ │ │ │ ├── refactoring-tests
│ │ │ │ │ │ │ ├── bad-alert-tooltip-input.component.ts
│ │ │ │ │ │ │ ├── bad-alert.component.ts
│ │ │ │ │ │ │ ├── bad-button-dropdown.component.ts
│ │ │ │ │ │ │ ├── bad-document.component.ts
│ │ │ │ │ │ │ ├── bad-global-this.component.ts
│ │ │ │ │ │ │ ├── bad-mixed-external-assets.component.css
│ │ │ │ │ │ │ ├── bad-mixed-external-assets.component.html
│ │ │ │ │ │ │ ├── bad-mixed-external-assets.component.ts
│ │ │ │ │ │ │ ├── bad-mixed-not-standalone.component.ts
│ │ │ │ │ │ │ ├── bad-mixed.component.ts
│ │ │ │ │ │ │ ├── bad-mixed.module.ts
│ │ │ │ │ │ │ ├── bad-modal-progress.component.ts
│ │ │ │ │ │ │ ├── bad-this-window-document.component.ts
│ │ │ │ │ │ │ ├── bad-window.component.ts
│ │ │ │ │ │ │ ├── complex-components
│ │ │ │ │ │ │ │ ├── first-case
│ │ │ │ │ │ │ │ │ ├── dashboard-demo.component.html
│ │ │ │ │ │ │ │ │ ├── dashboard-demo.component.scss
│ │ │ │ │ │ │ │ │ ├── dashboard-demo.component.ts
│ │ │ │ │ │ │ │ │ ├── dashboard-header.component.html
│ │ │ │ │ │ │ │ │ ├── dashboard-header.component.scss
│ │ │ │ │ │ │ │ │ └── dashboard-header.component.ts
│ │ │ │ │ │ │ │ ├── second-case
│ │ │ │ │ │ │ │ │ ├── complex-badge-widget.component.scss
│ │ │ │ │ │ │ │ │ ├── complex-badge-widget.component.ts
│ │ │ │ │ │ │ │ │ └── complex-widget-demo.component.ts
│ │ │ │ │ │ │ │ └── third-case
│ │ │ │ │ │ │ │ ├── product-card.component.scss
│ │ │ │ │ │ │ │ ├── product-card.component.ts
│ │ │ │ │ │ │ │ └── product-showcase.component.ts
│ │ │ │ │ │ │ ├── group-1
│ │ │ │ │ │ │ │ ├── bad-mixed-1.component.ts
│ │ │ │ │ │ │ │ ├── bad-mixed-1.module.ts
│ │ │ │ │ │ │ │ ├── bad-mixed-external-assets-1.component.css
│ │ │ │ │ │ │ │ ├── bad-mixed-external-assets-1.component.html
│ │ │ │ │ │ │ │ ├── bad-mixed-external-assets-1.component.ts
│ │ │ │ │ │ │ │ └── bad-mixed-not-standalone-1.component.ts
│ │ │ │ │ │ │ ├── group-2
│ │ │ │ │ │ │ │ ├── bad-mixed-2.component.ts
│ │ │ │ │ │ │ │ ├── bad-mixed-2.module.ts
│ │ │ │ │ │ │ │ ├── bad-mixed-external-assets-2.component.css
│ │ │ │ │ │ │ │ ├── bad-mixed-external-assets-2.component.html
│ │ │ │ │ │ │ │ ├── bad-mixed-external-assets-2.component.ts
│ │ │ │ │ │ │ │ └── bad-mixed-not-standalone-2.component.ts
│ │ │ │ │ │ │ ├── group-3
│ │ │ │ │ │ │ │ ├── bad-mixed-3.component.spec.ts
│ │ │ │ │ │ │ │ ├── bad-mixed-3.component.ts
│ │ │ │ │ │ │ │ ├── bad-mixed-3.module.ts
│ │ │ │ │ │ │ │ ├── bad-mixed-external-assets-3.component.css
│ │ │ │ │ │ │ │ ├── bad-mixed-external-assets-3.component.html
│ │ │ │ │ │ │ │ ├── bad-mixed-external-assets-3.component.ts
│ │ │ │ │ │ │ │ ├── bad-mixed-not-standalone-3.component.ts
│ │ │ │ │ │ │ │ └── lazy-loader-3.component.ts
│ │ │ │ │ │ │ └── group-4
│ │ │ │ │ │ │ ├── multi-violation-test.component.html
│ │ │ │ │ │ │ ├── multi-violation-test.component.scss
│ │ │ │ │ │ │ └── multi-violation-test.component.ts
│ │ │ │ │ │ └── validation-tests
│ │ │ │ │ │ ├── circular-dependency.component.ts
│ │ │ │ │ │ ├── external-files-missing.component.ts
│ │ │ │ │ │ ├── invalid-lifecycle.component.ts
│ │ │ │ │ │ ├── invalid-pipe-usage.component.ts
│ │ │ │ │ │ ├── invalid-template-syntax.component.ts
│ │ │ │ │ │ ├── missing-imports.component.ts
│ │ │ │ │ │ ├── missing-method.component.ts
│ │ │ │ │ │ ├── README.md
│ │ │ │ │ │ ├── standalone-module-conflict.component.ts
│ │ │ │ │ │ ├── standalone-module-conflict.module.ts
│ │ │ │ │ │ ├── template-reference-error.component.ts
│ │ │ │ │ │ ├── type-mismatch.component.ts
│ │ │ │ │ │ ├── valid.component.ts
│ │ │ │ │ │ ├── wrong-decorator-usage.component.ts
│ │ │ │ │ │ └── wrong-property-binding.component.ts
│ │ │ │ │ └── styles
│ │ │ │ │ ├── bad-global-styles.scss
│ │ │ │ │ ├── base
│ │ │ │ │ │ ├── _reset.scss
│ │ │ │ │ │ └── base.scss
│ │ │ │ │ ├── components
│ │ │ │ │ │ └── components.scss
│ │ │ │ │ ├── extended-deprecated-styles.scss
│ │ │ │ │ ├── layout
│ │ │ │ │ │ └── layout.scss
│ │ │ │ │ ├── new-styles-1.scss
│ │ │ │ │ ├── new-styles-10.scss
│ │ │ │ │ ├── new-styles-2.scss
│ │ │ │ │ ├── new-styles-3.scss
│ │ │ │ │ ├── new-styles-4.scss
│ │ │ │ │ ├── new-styles-5.scss
│ │ │ │ │ ├── new-styles-6.scss
│ │ │ │ │ ├── new-styles-7.scss
│ │ │ │ │ ├── new-styles-8.scss
│ │ │ │ │ ├── new-styles-9.scss
│ │ │ │ │ ├── themes
│ │ │ │ │ │ └── themes.scss
│ │ │ │ │ └── utilities
│ │ │ │ │ └── utilities.scss
│ │ │ │ ├── index.html
│ │ │ │ ├── main.ts
│ │ │ │ └── styles.css
│ │ │ ├── tsconfig.app.json
│ │ │ ├── tsconfig.json
│ │ │ └── tsconfig.spec.json
│ │ └── design-system
│ │ ├── component-options.mjs
│ │ ├── storybook
│ │ │ └── card
│ │ │ └── card-tabs
│ │ │ └── overview.mdx
│ │ ├── storybook-host-app
│ │ │ └── src
│ │ │ └── components
│ │ │ ├── badge
│ │ │ │ ├── badge-tabs
│ │ │ │ │ ├── api.mdx
│ │ │ │ │ ├── examples.mdx
│ │ │ │ │ └── overview.mdx
│ │ │ │ ├── badge.component.mdx
│ │ │ │ └── badge.component.stories.ts
│ │ │ ├── modal
│ │ │ │ ├── demo-cdk-dialog-cmp.component.ts
│ │ │ │ ├── demo-modal-cmp.component.ts
│ │ │ │ ├── modal-tabs
│ │ │ │ │ ├── api.mdx
│ │ │ │ │ ├── examples.mdx
│ │ │ │ │ └── overview.mdx
│ │ │ │ ├── modal.component.mdx
│ │ │ │ └── modal.component.stories.ts
│ │ │ └── segmented-control
│ │ │ ├── segmented-control-tabs
│ │ │ │ ├── api.mdx
│ │ │ │ ├── examples.mdx
│ │ │ │ └── overview.mdx
│ │ │ ├── segmented-control.component.mdx
│ │ │ └── segmented-control.component.stories.ts
│ │ └── ui
│ │ ├── badge
│ │ │ ├── package.json
│ │ │ ├── project.json
│ │ │ └── src
│ │ │ └── badge.component.ts
│ │ ├── modal
│ │ │ ├── package.json
│ │ │ ├── project.json
│ │ │ └── src
│ │ │ ├── modal-content.component.ts
│ │ │ ├── modal-header
│ │ │ │ └── modal-header.component.ts
│ │ │ ├── modal-header-drag
│ │ │ │ └── modal-header-drag.component.ts
│ │ │ └── modal.component.ts
│ │ ├── rx-host-listener
│ │ │ ├── package.json
│ │ │ ├── project.json
│ │ │ └── src
│ │ │ └── rx-host-listener.ts
│ │ └── segmented-control
│ │ ├── package.json
│ │ ├── project.json
│ │ └── src
│ │ ├── segmented-control.component.html
│ │ ├── segmented-control.component.ts
│ │ ├── segmented-control.token.ts
│ │ └── segmented-option.component.ts
│ └── shared
│ ├── angular-ast-utils
│ │ ├── .spec.swcrc
│ │ ├── ai
│ │ │ ├── API.md
│ │ │ ├── EXAMPLES.md
│ │ │ └── FUNCTIONS.md
│ │ ├── docs
│ │ │ └── angular-component-tree.md
│ │ ├── eslint.config.mjs
│ │ ├── jest.config.ts
│ │ ├── package.json
│ │ ├── README.md
│ │ ├── src
│ │ │ ├── index.ts
│ │ │ └── lib
│ │ │ ├── constants.ts
│ │ │ ├── decorator-config.visitor.inline-styles.spec.ts
│ │ │ ├── decorator-config.visitor.spec.ts
│ │ │ ├── decorator-config.visitor.ts
│ │ │ ├── parse-component.ts
│ │ │ ├── schema.ts
│ │ │ ├── styles
│ │ │ │ └── utils.ts
│ │ │ ├── template
│ │ │ │ ├── noop-tmpl-visitor.ts
│ │ │ │ ├── template.walk.ts
│ │ │ │ ├── utils.spec.ts
│ │ │ │ ├── utils.ts
│ │ │ │ └── utils.unit.test.ts
│ │ │ ├── ts.walk.ts
│ │ │ ├── types.ts
│ │ │ └── utils.ts
│ │ ├── tsconfig.json
│ │ ├── tsconfig.lib.json
│ │ ├── tsconfig.spec.json
│ │ └── vitest.config.mts
│ ├── DEPENDENCIES.md
│ ├── ds-component-coverage
│ │ ├── .spec.swcrc
│ │ ├── ai
│ │ │ ├── API.md
│ │ │ ├── EXAMPLES.md
│ │ │ └── FUNCTIONS.md
│ │ ├── docs
│ │ │ ├── examples
│ │ │ │ ├── report.json
│ │ │ │ └── report.md
│ │ │ ├── images
│ │ │ │ └── report-overview.png
│ │ │ └── README.md
│ │ ├── jest.config.ts
│ │ ├── mocks
│ │ │ └── fixtures
│ │ │ └── e2e
│ │ │ ├── asset-location
│ │ │ │ ├── code-pushup.config.ts
│ │ │ │ ├── inl-styl-inl-tmpl
│ │ │ │ │ └── inl-styl-inl-tmpl.component.ts
│ │ │ │ ├── inl-styl-url-tmpl
│ │ │ │ │ ├── inl-styl-url-tmpl.component.html
│ │ │ │ │ └── inl-styl-url-tmpl.component.ts
│ │ │ │ ├── multi-url-styl-inl-tmpl
│ │ │ │ │ ├── multi-url-styl-inl-tmpl-1.component.css
│ │ │ │ │ ├── multi-url-styl-inl-tmpl-2.component.css
│ │ │ │ │ └── multi-url-styl-inl-tmpl.component.ts
│ │ │ │ ├── url-styl-inl-tmpl
│ │ │ │ │ ├── url-styl-inl-tmpl.component.css
│ │ │ │ │ └── url-styl-inl-tmpl.component.ts
│ │ │ │ ├── url-styl-single-inl-tmpl
│ │ │ │ │ ├── url-styl-inl-tmpl.component.ts
│ │ │ │ │ └── url-styl-single-inl-tmpl.component.css
│ │ │ │ └── url-styl-url-tmpl
│ │ │ │ ├── inl-styl-url-tmpl.component.css
│ │ │ │ ├── inl-styl-url-tmpl.component.html
│ │ │ │ └── inl-styl-url-tmpl.component.ts
│ │ │ ├── demo
│ │ │ │ ├── code-pushup.config.ts
│ │ │ │ ├── prompt.md
│ │ │ │ └── src
│ │ │ │ ├── bad-button-dropdown.component.ts
│ │ │ │ ├── bad-modal-progress.component.ts
│ │ │ │ ├── mixed-external-assets.component.css
│ │ │ │ ├── mixed-external-assets.component.html
│ │ │ │ ├── mixed-external-assets.component.ts
│ │ │ │ └── sub-folder-1
│ │ │ │ ├── bad-alert.component.ts
│ │ │ │ ├── button.component.ts
│ │ │ │ └── sub-folder-2
│ │ │ │ ├── bad-alert-tooltip-input.component.ts
│ │ │ │ └── bad-mixed.component.ts
│ │ │ ├── line-number
│ │ │ │ ├── code-pushup.config.ts
│ │ │ │ ├── inl-styl-single.component.ts
│ │ │ │ ├── inl-styl-span.component.ts
│ │ │ │ ├── inl-tmpl-single.component.ts
│ │ │ │ ├── inl-tmpl-span.component.ts
│ │ │ │ ├── url-style
│ │ │ │ │ ├── url-styl-single.component.css
│ │ │ │ │ ├── url-styl-single.component.ts
│ │ │ │ │ ├── url-styl-span.component.css
│ │ │ │ │ └── url-styl-span.component.ts
│ │ │ │ └── url-tmpl
│ │ │ │ ├── url-tmpl-single.component.html
│ │ │ │ ├── url-tmpl-single.component.ts
│ │ │ │ ├── url-tmpl-span.component.html
│ │ │ │ └── url-tmpl-span.component.ts
│ │ │ ├── style-format
│ │ │ │ ├── code-pushup.config.ts
│ │ │ │ ├── inl-css.component.ts
│ │ │ │ ├── inl-scss.component.ts
│ │ │ │ ├── styles.css
│ │ │ │ ├── styles.scss
│ │ │ │ ├── url-css.component.ts
│ │ │ │ └── url-scss.component.ts
│ │ │ └── template-syntax
│ │ │ ├── class-attribute.component.ts
│ │ │ ├── class-binding.component.ts
│ │ │ ├── code-pushup.config.ts
│ │ │ └── ng-class-binding.component.ts
│ │ ├── package.json
│ │ ├── src
│ │ │ ├── core.config.ts
│ │ │ ├── index.ts
│ │ │ └── lib
│ │ │ ├── constants.ts
│ │ │ ├── ds-component-coverage.plugin.ts
│ │ │ ├── runner
│ │ │ │ ├── audits
│ │ │ │ │ └── ds-coverage
│ │ │ │ │ ├── class-definition.utils.ts
│ │ │ │ │ ├── class-definition.visitor.ts
│ │ │ │ │ ├── class-definition.visitor.unit.test.ts
│ │ │ │ │ ├── class-usage.utils.ts
│ │ │ │ │ ├── class-usage.visitor.spec.ts
│ │ │ │ │ ├── class-usage.visitor.ts
│ │ │ │ │ ├── constants.ts
│ │ │ │ │ ├── ds-coverage.audit.ts
│ │ │ │ │ ├── schema.ts
│ │ │ │ │ └── utils.ts
│ │ │ │ ├── create-runner.ts
│ │ │ │ └── schema.ts
│ │ │ └── utils.ts
│ │ ├── tsconfig.json
│ │ ├── tsconfig.lib.json
│ │ ├── tsconfig.spec.json
│ │ └── vitest.config.mts
│ ├── LLMS.md
│ ├── models
│ │ ├── ai
│ │ │ ├── API.md
│ │ │ ├── EXAMPLES.md
│ │ │ └── FUNCTIONS.md
│ │ ├── package.json
│ │ ├── README.md
│ │ ├── src
│ │ │ ├── index.ts
│ │ │ └── lib
│ │ │ ├── cli.ts
│ │ │ ├── diagnostics.ts
│ │ │ └── mcp.ts
│ │ ├── tsconfig.json
│ │ └── tsconfig.lib.json
│ ├── styles-ast-utils
│ │ ├── .spec.swcrc
│ │ ├── ai
│ │ │ ├── API.md
│ │ │ ├── EXAMPLES.md
│ │ │ └── FUNCTIONS.md
│ │ ├── jest.config.ts
│ │ ├── package.json
│ │ ├── README.md
│ │ ├── src
│ │ │ ├── index.ts
│ │ │ └── lib
│ │ │ ├── postcss-safe-parser.d.ts
│ │ │ ├── styles-ast-utils.spec.ts
│ │ │ ├── styles-ast-utils.ts
│ │ │ ├── stylesheet.parse.ts
│ │ │ ├── stylesheet.parse.unit.test.ts
│ │ │ ├── stylesheet.visitor.ts
│ │ │ ├── stylesheet.walk.ts
│ │ │ ├── types.ts
│ │ │ ├── utils.ts
│ │ │ └── utils.unit.test.ts
│ │ ├── tsconfig.json
│ │ ├── tsconfig.lib.json
│ │ ├── tsconfig.spec.json
│ │ └── vitest.config.mts
│ ├── typescript-ast-utils
│ │ ├── .spec.swcrc
│ │ ├── ai
│ │ │ ├── API.md
│ │ │ ├── EXAMPLES.md
│ │ │ └── FUNCTIONS.md
│ │ ├── jest.config.ts
│ │ ├── package.json
│ │ ├── README.md
│ │ ├── src
│ │ │ ├── index.ts
│ │ │ └── lib
│ │ │ ├── constants.ts
│ │ │ └── utils.ts
│ │ ├── tsconfig.json
│ │ ├── tsconfig.lib.json
│ │ ├── tsconfig.spec.json
│ │ └── vitest.config.mts
│ └── utils
│ ├── .spec.swcrc
│ ├── ai
│ │ ├── API.md
│ │ ├── EXAMPLES.md
│ │ └── FUNCTIONS.md
│ ├── package.json
│ ├── README.md
│ ├── src
│ │ ├── index.ts
│ │ └── lib
│ │ ├── execute-process.ts
│ │ ├── execute-process.unit.test.ts
│ │ ├── file
│ │ │ ├── default-export-loader.spec.ts
│ │ │ ├── default-export-loader.ts
│ │ │ ├── file.resolver.ts
│ │ │ └── find-in-file.ts
│ │ ├── format-command-log.integration.test.ts
│ │ ├── format-command-log.ts
│ │ ├── logging.ts
│ │ └── utils.ts
│ ├── tsconfig.json
│ ├── tsconfig.lib.json
│ ├── tsconfig.spec.json
│ ├── vite.config.ts
│ └── vitest.config.mts
├── README.md
├── testing
│ ├── setup
│ │ ├── eslint.config.mjs
│ │ ├── eslint.next.config.mjs
│ │ ├── package.json
│ │ ├── README.md
│ │ ├── src
│ │ │ ├── index.d.ts
│ │ │ ├── index.mjs
│ │ │ └── memfs.constants.ts
│ │ ├── tsconfig.json
│ │ ├── tsconfig.lib.json
│ │ ├── tsconfig.spec.json
│ │ ├── vitest.config.mts
│ │ └── vitest.integration.config.mts
│ ├── utils
│ │ ├── eslint.config.mjs
│ │ ├── eslint.next.config.mjs
│ │ ├── package.json
│ │ ├── README.md
│ │ ├── src
│ │ │ ├── index.ts
│ │ │ └── lib
│ │ │ ├── constants.ts
│ │ │ ├── e2e-setup.ts
│ │ │ ├── execute-process-helper.mock.ts
│ │ │ ├── execute-process.mock.mjs
│ │ │ ├── os-agnostic-paths.ts
│ │ │ ├── os-agnostic-paths.unit.test.ts
│ │ │ ├── source-file-from.code.ts
│ │ │ └── string.ts
│ │ ├── tsconfig.json
│ │ ├── tsconfig.lib.json
│ │ ├── tsconfig.spec.json
│ │ ├── vite.config.ts
│ │ ├── vitest.config.mts
│ │ └── vitest.integration.config.mts
│ └── vitest-setup
│ ├── eslint.config.mjs
│ ├── eslint.next.config.mjs
│ ├── package.json
│ ├── README.md
│ ├── src
│ │ ├── index.ts
│ │ └── lib
│ │ ├── configuration.ts
│ │ └── fs-memfs.setup-file.ts
│ ├── tsconfig.json
│ ├── tsconfig.lib.json
│ ├── tsconfig.spec.json
│ ├── vite.config.ts
│ ├── vitest.config.mts
│ └── vitest.integration.config.mts
├── tools
│ ├── nx-advanced-profile.bin.js
│ ├── nx-advanced-profile.js
│ ├── nx-advanced-profile.postinstall.js
│ └── perf_hooks.patch.js
├── tsconfig.base.json
├── tsconfig.json
└── vitest.workspace.ts
```
# Files
--------------------------------------------------------------------------------
/docs/ds-refactoring-flow.md:
--------------------------------------------------------------------------------
```markdown
1 | # Design System Refactoring Flow
2 |
3 |
4 | ## Overview
5 |
6 | This document describes a 5-step AI-assisted refactoring process for migrating legacy components to the design system. Each step uses a specific rule file (.mdc) that guides the Cursor agent through automated analysis and code changes.
7 |
8 | **Flow Approaches:**
9 |
10 | The refactoring process offers two alternative approaches for the initial phases:
11 |
12 | **Option A: Targeted Approach** (recommended for focused, incremental migrations)
13 | 1. **Find Violations** (`01-find-violations.mdc`) → Identify specific deprecated component usage
14 | 2. **Plan Refactoring** (`02-plan-refactoring.mdc`) → Create detailed migration strategy for specific cases
15 |
16 | **Option B: Comprehensive Approach** (recommended for large-scale migrations)
17 | 1. **Find All Violations** (`01b-find-all-violations.mdc`) → Scan entire codebase, group by folders, select subfolder for detailed analysis
18 | 2. **Plan Refactoring for All Violations** (`02b-plan-refactoring-for-all-violations.mdc`) → Create comprehensive migration plan for all violations in scope
19 |
20 | **Continuation Steps** (used with both approaches):
21 | 3. **Fix Violations** → Execute code changes
22 | - **If viable:** Proceed with normal checklist (`03-fix-violations.mdc`)
23 | - **If non-viable:** Use alternative handling (`03-non-viable-cases.mdc`)
24 | 4. **Validate Changes** → Verify refactoring safety
25 | 5. **Prepare Report** → Generate testing checklists and documentation
26 |
27 | The process includes three quality gates where human review and approval are required. When components are identified as non-viable during planning, an alternative handling process is used instead of proceeding to the normal fix violations step.
28 |
29 | ## Prerequisites
30 |
31 | Before starting the refactoring flow, ensure you have:
32 | - Cursor IDE with this MCP (Model Context Protocol) server connected. This flow was tested with Cursor but should also work with Windsurf or Copilot.
33 | - The five rule files (.mdc) available in your workspace
34 | - A git branch for the refactoring work
35 |
36 | ## 01-find-violations.mdc
37 |
38 | ### Goal
39 |
40 | Identify and locate legacy component usage in a codebase to prepare for systematic refactoring. This rule helps developers find deprecated design system components and their usage patterns across the project in a structured, two-step process.
41 |
42 | ### Process
43 |
44 | To start this process, drag file `01-find-violations.mdc` to the cursor chat and provide `directory` and `component` parameters, your chat message will look like this
45 |
46 | ```
47 | @01-find-violations.mdc directory=path/to/directory component=DsComponent
48 | ```
49 |
50 | This rule follows a two-step process to find violations:
51 |
52 | **Step 1: Folder-level scan**
53 | - Scans the specified directory for component violations grouped by folder
54 | - Provides a ranked list of folders with violation counts
55 | - Allows user to select a specific subfolder for detailed analysis
56 |
57 | **Step 2: File-level scan**
58 | - Performs detailed scanning of the selected subfolder
59 | - Groups violations by individual files
60 | - Outputs a sorted list of files with violation counts
61 | - Prepares the transition to the planning phase
62 |
63 | > After the second scan, AI will explicitly ask you to attach the second rule for planning.
64 |
65 | ### Tools used
66 |
67 | - `report-violations` - Main MCP tool that analyzes deprecated design system CSS usage
68 | - Parameters: `componentName`, `directory`, `groupBy` (folder/file)
69 | - Returns violation data with counts and locations
70 | - Supports both folder-level and file-level grouping
71 |
72 | ### Flow
73 |
74 | > You don't need to manually perform any of the listed actions except providing the `component=DsComponent directory=path/to/folder` in the initial message.
75 |
76 | 1. **Initial Setup**: User provides `{{COMPONENT_NAME}}` and `{{DIRECTORY}}` parameters
77 | 2. **Folder Scan**: Execute `report-violations` with `groupBy: "folder"`
78 | 3. **Error Handling**: Check for tool errors or zero violations
79 | 4. **Folder Results**: Display ranked folder list with violation counts
80 | 5. **User Selection**: Prompt user to choose a subfolder for detailed analysis
81 | 6. **File Scan**: Execute `report-violations` with `groupBy: "file"` on selected subfolder
82 | 7. **File Results**: Display sorted file list with violation counts
83 | 8. **Transition**: Prompt user to attach "Plan Phase" rules for next step
84 |
85 | The rule enforces strict output formatting with `<folders>` and `<violations>` tags, and uses `<commentary>` blocks for error messages and clarifications.
86 |
87 | ### Preferred model
88 |
89 | Claude-4-Sonnet
90 |
91 | ## 01b-find-all-violations.mdc (Alternative Comprehensive Approach)
92 |
93 | ### Goal
94 |
95 | Perform comprehensive analysis of an entire codebase to identify all deprecated component usage patterns across multiple directories and components. This rule provides a broader scope alternative to the targeted approach, allowing teams to understand the full migration scope before focusing on specific areas for detailed planning.
96 |
97 | ### Process
98 |
99 | To start this process, drag file `01b-find-all-violations.mdc` to the cursor chat and provide the `directory` parameter, your chat message will look like this:
100 |
101 | ```
102 | @01b-find-all-violations.mdc directory=path/to/directory
103 | ```
104 |
105 | This rule follows a comprehensive two-step process to find all violations:
106 |
107 | **Step 1: Global folder-level scan**
108 | - Scans the entire specified directory tree for all deprecated component violations
109 | - Groups results by folder to provide overview of violation distribution
110 | - Provides a ranked list of folders with violation counts and file counts
111 | - Allows user to understand migration scope across the entire codebase
112 | - Enables selection of specific subfolder for focused analysis
113 |
114 | **Step 2: Targeted file-level scan**
115 | - Performs detailed scanning of the selected subfolder from step 1
116 | - Groups violations by individual files within the selected scope
117 | - Outputs a sorted list of files with violation counts for precise targeting
118 | - Prepares comprehensive data for the planning phase
119 |
120 | > After the second scan, AI will explicitly ask you to attach the comprehensive planning rule.
121 |
122 | ### Tools used
123 |
124 | - `report-all-violations` - Comprehensive MCP tool that analyzes all deprecated design system CSS usage across the codebase
125 | - Parameters: `directory`, `groupBy` (folder/file)
126 | - Returns: Complete violation data with counts and locations across all components
127 | - Supports both folder-level overview and file-level detailed analysis
128 |
129 | ### Flow
130 |
131 | > You don't need to manually perform any of the listed actions except providing the `directory=path/to/folder` in the initial message.
132 |
133 | 1. **Initial Setup**: User provides `{{DIRECTORY}}` parameter for comprehensive analysis
134 | 2. **Global Scan**: Execute `report-all-violations` with `groupBy: "folder"` for complete overview
135 | 3. **Error Handling**: Check for tool errors or zero violations across entire codebase
136 | 4. **Folder Results**: Display ranked folder list with comprehensive violation and file counts
137 | 5. **User Selection**: Prompt user to choose a subfolder from the comprehensive results for detailed focus
138 | 6. **Targeted Scan**: Execute `report-all-violations` with `groupBy: "file"` on selected subfolder
139 | 7. **File Results**: Display sorted file list with precise violation counts for planning
140 | 8. **Transition**: Prompt user to attach comprehensive planning rules for next step
141 |
142 | The rule enforces structured output with `<folders>` and `<violations>` tags, and uses `<commentary>` blocks for error messages and progress updates.
143 |
144 | ### Preferred model
145 |
146 | Claude-4-Sonnet
147 |
148 | ## 02b-plan-refactoring-for-all-violations.mdc (Alternative Comprehensive Approach)
149 |
150 | ### Goal
151 |
152 | Create a comprehensive migration strategy for large-scale refactoring of legacy components across multiple files and violation types. This rule provides a thorough analysis approach for complex migration scenarios involving extensive deprecated component usage, focusing on creating detailed implementation plans for comprehensive scope migrations.
153 |
154 | ### Process
155 |
156 | To start this process, drag file `02b-plan-refactoring-for-all-violations.mdc` to the cursor chat after completing the comprehensive violations analysis.
157 |
158 | The rule implements an enhanced three-phase comprehensive planning process:
159 |
160 | **Phase 1: Comprehensive Analysis**
161 | - Reviews extensive component documentation, implementation code, and usage patterns across all violation files
162 | - Analyzes complete scope of affected files (templates, TypeScript, styles, specs, NgModules)
163 | - Assesses migration complexity across the entire selected scope and identifies potential non-viable migrations
164 | - Evaluates library dependencies and their comprehensive impact on large-scale migration
165 | - Considers cross-component dependencies and interaction patterns
166 |
167 | **Phase 2: Detailed Plan Creation for Complete Scope**
168 | - Compares deprecated usage patterns against design system exemplars across all files
169 | - Classifies each migration comprehensively as: Simple swap, Requires restructure, or Non-viable
170 | - Assigns complexity scores (1-10) with comprehensive penalties for animations/breakpoints/variants across scope
171 | - Creates comprehensive actionable plans ordered by effort with concrete edits needed for all files
172 | - Provides extensive verification notes for static file-based checks across the migration scope
173 | - Considers migration dependencies and optimal sequencing for large-scale changes
174 |
175 | ---
176 | **🚦 Quality Gate 1 (Comprehensive Review)**
177 |
178 | Before proceeding to Phase 3, you must review the comprehensive migration plan.
179 |
180 | **Required Actions:**
181 | - Review the complete migration strategy for all identified violations
182 | - **If all components are viable for migration:** Approve or request modifications, then proceed with comprehensive checklist creation
183 | - **If some components are non-viable:** Developer must thoroughly review and confirm non-viability decisions, then use `@03-non-viable-cases.mdc` for non-viable cases
184 | - **If mixed viability:** Proceed with checklist for viable cases and handle non-viable cases separately
185 | - Clarify any uncertainties regarding the comprehensive approach
186 |
187 | **Next Step:**
188 | - **All viable migrations:** When satisfied with the plan, the agent will create a comprehensive checklist
189 | - **Mixed or non-viable migrations:** Use appropriate handling rules for different component categories
190 | ---
191 |
192 | **Phase 3: Comprehensive Checklist Creation**
193 | - Generates extensive checklist covering all viable migrations with detailed checkbox items
194 | - Creates comprehensive verification phase with static checks across all affected files
195 | - Includes dependency management and sequencing considerations for large-scale migrations
196 | - Saves comprehensive checklist to `.cursor/tmp/refactoring-checklist-{{FOLDER_PATH}}.md`
197 |
198 | > After the comprehensive checklist is generated and you see it in the chat, it is time to attach the fix violations rule.
199 |
200 | ### Tools used
201 |
202 | - `list-ds-components` - Lists all available Design System components in the project
203 | - Parameters: `sections` (optional) - Array of sections to include: "implementation", "documentation", "stories", "all"
204 | - Returns: Complete inventory of DS components with their file paths and metadata
205 | - Provides: Overview of available components for comprehensive migration planning
206 |
207 | - `get-ds-component-data` - Retrieves comprehensive component information for all involved components
208 | - Parameters: `componentName`, `sections` (optional) - Array of sections to include: "implementation", "documentation", "stories", "all"
209 | - Returns: Complete implementation files, documentation files, import paths for multiple components
210 | - Provides: Component source code, API documentation, usage examples across scope
211 |
212 | - `build-component-usage-graph` - Maps comprehensive component dependencies and usage patterns
213 | - Parameters: `directory`, `violationFiles` (from comprehensive scan, automatically picked up)
214 | - Returns: Complete graph showing where all components are imported and used across scope
215 | - Analyzes: modules, specs, templates, styles, reverse dependencies for large-scale impact
216 |
217 | - `get-project-dependencies` - Analyzes project structure and dependencies for comprehensive scope
218 | - Parameters: `directory`, optional `componentName`
219 | - Returns: library type (buildable/publishable), peer dependencies for scope assessment
220 | - Validates: import paths, workspace configuration for large-scale migration compatibility
221 |
222 | ### Flow
223 |
224 | > You don't need to manually perform any of the listed actions.
225 |
226 | 1. **Comprehensive Input Gathering**: Collect all component data, folder path, documentation, code, usage graphs, and library data for complete scope
227 | 2. **Extensive Analysis**: Review all inputs and analyze comprehensive codebase impact across all violation files
228 | 3. **Large-Scale Complexity Assessment**: Evaluate migration difficulty and identify non-viable cases across complete scope
229 | 4. **Comprehensive File Classification**: Categorize each file's migration requirements within the broader context
230 | 5. **Detailed Plan Creation**: Generate comprehensive migration steps with complexity scores for all files
231 | 6. **Extensive Verification Design**: Create static checks for comprehensive plan validation across scope
232 | 7. **Large-Scale Ambiguity Resolution**: Identify and request clarification for unclear aspects across scope
233 | 8. **Comprehensive Approval Process**: Present complete plan with "🛠️ Approve this comprehensive plan or specify adjustments?"
234 | 9. **Extensive Checklist Generation**: Create detailed actionable checklist after approval covering all scope
235 | 10. **Comprehensive File Persistence**: Save complete checklist to temporary file for large-scale reference
236 |
237 | The rule enforces structured output with `<comprehensive_analysis>`, `<migration_plan>`, and `<checklist>` tags, and includes enhanced ambiguity safeguards for complex large-scale scenarios.
238 |
239 | ### Preferred model
240 |
241 | - Non-complex cases: Claude-4-Sonnet
242 | - Complex large-scale cases: Claude-4-Sonnet (thinking)
243 |
244 | ## 02-plan-refactoring.mdc
245 |
246 | ### Goal
247 |
248 | Create a comprehensive migration plan for refactoring legacy components to new design system components. This rule analyzes the current codebase, evaluates migration complexity, and provides a detailed, actionable plan with specific steps, classifications, and verification notes for each affected file.
249 |
250 | ### Process
251 |
252 | To start this process, drag file `02-plan-refactoring.mdc` to the cursor chat.
253 |
254 | The rule implements a three-phase migration planning process:
255 |
256 | **Phase 1: Comprehensive Analysis**
257 | - Reviews component documentation, implementation code, and usage patterns
258 | - Analyzes all affected files (templates, TypeScript, styles, specs, NgModules)
259 | - Assesses migration complexity and identifies potential non-viable migrations
260 | - Evaluates library dependencies and their impact on migration
261 |
262 | **Phase 2: Detailed Plan Creation**
263 | - Compares old markup against design system exemplars
264 | - Classifies each migration as: Simple swap, Requires restructure, or Non-viable
265 | - Assigns complexity scores (1-10) with penalties for animations/breakpoints/variants
266 | - Creates actionable plans ordered by effort with concrete edits needed
267 | - Provides verification notes for static file-based checks
268 |
269 | ---
270 | **🚦 Quality Gate 1**
271 |
272 | Before proceeding to Phase 3, you must review the migration plan.
273 |
274 | **Required Actions:**
275 | - Review the suggested plan thoroughly
276 | - **If components are viable for migration:** Approve or request modifications, then proceed with checklist creation
277 | - **If components are non-viable:** Developer must thoroughly review and confirm non-viability, then use `@03-non-viable-cases.mdc` instead of normal checklist
278 | - Clarify any uncertainties
279 |
280 | **Next Step:**
281 | - **Viable migrations:** When satisfied with the plan, the agent will create a checklist
282 | - **Non-viable migrations:** Use the non-viable cases rule instead of proceeding to fix violations
283 | ---
284 |
285 | **Phase 3: Checklist Creation**
286 | - Generates comprehensive checklist of actual changes as checkboxes
287 | - Creates verification phase with static checks that can be performed by reading files
288 | - Saves checklist to `.cursor/tmp/refactoring-checklist-{{FOLDER_PATH}}.md`
289 |
290 | > After the checklist is generated and you see it in the chat, it is time to attach the next rule.
291 |
292 | ### Tools used
293 |
294 | - `list-ds-components` - Lists all available Design System components in the project
295 | - Parameters: `sections` (optional) - Array of sections to include: "implementation", "documentation", "stories", "all"
296 | - Returns: Complete inventory of DS components with their file paths and metadata
297 | - Provides: Overview of available components for migration planning
298 |
299 | - `get-ds-component-data` - Retrieves comprehensive component information
300 | - Parameters: `componentName`, `sections` (optional) - Array of sections to include: "implementation", "documentation", "stories", "all"
301 | - Returns: implementation files, documentation files, import paths
302 | - Provides: component source code, API documentation, usage examples
303 |
304 | - `build-component-usage-graph` - Maps component dependencies and usage
305 | - Parameters: `directory`, `violationFiles` (from previous step, automatically picked up)
306 | - Returns: graph showing where components are imported and used
307 | - Analyzes: modules, specs, templates, styles, reverse dependencies
308 |
309 | - `get-project-dependencies` - Analyzes project structure and dependencies
310 | - Parameters: `directory`, optional `componentName`
311 | - Returns: library type (buildable/publishable), peer dependencies
312 | - Validates: import paths, workspace configuration
313 |
314 | ### Flow
315 |
316 | > You don't need to manually perform any of the listed actions.
317 |
318 | 1. **Input Gathering**: Collect component name, folder path, documentation, code, usage graph, and library data
319 | 2. **Comprehensive Analysis**: Review all inputs and analyze codebase impact
320 | 3. **Complexity Assessment**: Evaluate migration difficulty and identify non-viable cases
321 | 4. **File Classification**: Categorize each file's migration requirements
322 | 5. **Plan Creation**: Generate detailed migration steps with complexity scores
323 | 6. **Verification Design**: Create static checks for plan validation
324 | 7. **Ambiguity Resolution**: Identify and request clarification for unclear aspects
325 | 8. **Approval Process**: Present plan with "🛠️ Approve this plan or specify adjustments?"
326 | 9. **Checklist Generation**: Create actionable checklist after approval
327 | 10. **File Persistence**: Save checklist to temporary file for reference
328 |
329 | The rule enforces structured output with `<comprehensive_analysis>`, `<migration_plan>`, and `<checklist>` tags, and includes built-in ambiguity safeguards.
330 |
331 | ### Preferred model
332 |
333 | - Non-complex cases: Claude-4-Sonnet
334 | - Complex cases: Claude-4-Sonnet (thinking)
335 |
336 | ## Non-Viable Cases Handling
337 |
338 | ### When to Use
339 |
340 | During the **02-plan-refactoring.mdc** step, if the AI identifies components as non-viable for migration, this must be **thoroughly reviewed by an actual developer**. Only after developer confirmation should you proceed with non-viable handling instead of the normal checklist confirmation.
341 |
342 | ### Process
343 |
344 | When non-viable cases are confirmed during planning, instead of proceeding with the normal checklist, use the non-viable cases rule:
345 | - Reference: `@03-non-viable-cases.mdc` (or `@03-non-viable-cases.mdc` depending on your rule setup)
346 | - **Critical:** This replaces the normal "Fix Violations" step entirely
347 |
348 | The rule implements a systematic three-phase process for handling non-migratable components:
349 |
350 | **Phase 1: Identification & Discovery**
351 | - Identifies the target component class name from conversation context
352 | - Runs CSS discovery using `report-deprecated-css` tool on both global styles and style overrides directories
353 | - Creates a comprehensive implementation checklist with validation checks
354 | - Saves checklist to `.cursor/tmp/css-cleanup/[class-name]-[scope]-non-viable-migration-checklist.md`
355 |
356 | **Phase 2: Implementation**
357 | - Works systematically from the saved checklist file
358 | - **Step 1: HTML Template Updates (FIRST PRIORITY)**
359 | - Replaces original component classes with `after-migration-[ORIGINAL_CLASS]` in HTML files/templates
360 | - Must be done BEFORE any CSS changes to ensure consistency
361 | - **Step 2: CSS Selector Duplication (NOT REPLACEMENT)**
362 | - Duplicates CSS selectors rather than replacing them
363 | - Transforms: `.custom-radio {}` → `.custom-radio, .after-migration-custom-radio {}`
364 | - Maintains visual parity between original and prefixed versions
365 |
366 | **Phase 3: Validation (Mandatory)**
367 | - **Validation 1 - CSS Count Consistency**: Re-runs `report-deprecated-css` tool to verify deprecated class count remains identical
368 | - **Validation 2 - Violation Reduction**: Runs `report-violations` tool to verify the expected reduction in violations
369 | - Updates checklist with validation results and marks all items complete
370 |
371 | ### Key Features
372 |
373 | **Exclusion Strategy**: The `after-migration-` prefix serves as a marker that excludes these components from future violation reports, effectively removing them from the migration pipeline while preserving functionality.
374 |
375 | **Visual Consistency**: By duplicating CSS selectors rather than replacing them, the workflow ensures that both the original classes and the new prefixed classes render identically.
376 |
377 | **Comprehensive Tracking**: The workflow maintains detailed checklists and validation steps to ensure all instances are properly handled and tracked.
378 |
379 | **Error Prevention**: Systematic validation ensures that the transformation doesn't break existing functionality or miss any instances.
380 |
381 | ### Tools used
382 |
383 | - `report-deprecated-css` - Identifies deprecated CSS classes in style directories
384 | - Parameters: `directory`, `componentName`
385 | - Returns: List of deprecated CSS usage with file locations and line numbers
386 | - Used for: Discovery phase and validation of CSS count consistency
387 |
388 | - `report-violations` - Analyzes deprecated component usage in templates and code
389 | - Parameters: `directory`, `componentName`
390 | - Returns: List of component violations with file locations
391 | - Used for: Validation of violation reduction after implementation
392 |
393 | ### Flow
394 |
395 | > You don't need to manually perform any of the listed actions except providing directory paths when requested.
396 |
397 | 1. **Component Identification**: Extract target component class name from conversation context
398 | 2. **Directory Input**: Request global styles and style overrides directories from user (with fallback handling)
399 | 3. **CSS Discovery**: Run parallel `report-deprecated-css` scans on both directories
400 | 4. **Checklist Creation**: Generate comprehensive implementation checklist with validation checks
401 | 5. **HTML Updates**: Replace component classes with `after-migration-` prefixed versions in templates
402 | 6. **CSS Duplication**: Add prefixed selectors alongside original selectors in CSS files
403 | 7. **Validation Execution**: Run mandatory validation checks using actual tools
404 | 8. **Progress Tracking**: Update checklist file throughout the process with completion status
405 | 9. **Final Verification**: Confirm all validation criteria are met before completion
406 |
407 | The rule enforces structured output with `<target_component>`, `<checklist_summary>`, `<validation_1>`, and `<validation_2>` tags, and maintains strict validation criteria to ensure process integrity.
408 |
409 | ### When to Use This Workflow
410 |
411 | This workflow should be used when:
412 | - A component is identified as non-viable for migration during the planning phase
413 | - Legacy components cannot be updated due to technical constraints
414 | - Components need to be excluded from future violation reports
415 | - Maintaining existing visual appearance is critical during transition periods
416 |
417 | ### Integration with Main Flow
418 |
419 | This handling is integrated within the design system refactoring process:
420 | - **Decision Point**: During `02-plan-refactoring.mdc` when components are classified as "Non-viable"
421 | - **Developer Review Required**: Must be thoroughly reviewed and approved by actual developer before proceeding
422 | - **Replaces Steps 3-5**: When used, this replaces the normal Fix Violations → Validate Changes → Prepare Report sequence
423 | - **Outcome**: Successfully processed components will be excluded from subsequent violation reports
424 |
425 | ### Preferred model
426 |
427 | Claude-4-Sonnet
428 |
429 | ## 03-fix-violations.mdc
430 |
431 | ### Goal
432 |
433 | Execute the refactoring checklist by analyzing components, implementing changes, and tracking progress.
434 |
435 | ### Process
436 |
437 | To start this process, drag file `03-fix-violations.mdc` to the cursor chat AFTER you get a `<checklist>`.
438 |
439 | The rule implements a systematic refactoring execution process:
440 |
441 | **Step 1: Checklist Loading**
442 | - Reads the refactoring checklist from `.cursor/tmp/refactoring-checklist-{{FOLDER_PATH}}.md`
443 | - Parses checklist items and identifies components to be refactored
444 |
445 | **Step 2: Contract Generation**
446 | - Creates component contracts for each component before refactoring
447 | - Generates JSON snapshots of component's public API, DOM structure, and styles
448 | - Saves contracts to `.cursor/tmp/contracts/<ds-component-kebab>/` directory
449 |
450 | **Step 3: Refactoring Execution**
451 | - Analyzes each component using the generated contracts
452 | - Determines necessary changes based on checklist items
453 | - Implements code modifications (templates, TypeScript, styles, specs)
454 | - Updates checklist with progress notes
455 |
456 | **Step 4: Progress Tracking**
457 | - Updates checklist file with completion status and change descriptions
458 | - Documents what was changed or why no changes were needed
459 | - Maintains audit trail of refactoring progress
460 |
461 | **Step 5: Reflection and Confirmation**
462 | - Identifies uncertainties or areas needing user confirmation
463 | - Provides clear explanations of any ambiguous situations
464 | - Requests user approval for complex or uncertain changes
465 |
466 | ---
467 | **🚦 Quality Gate 2**
468 |
469 | At this point, initial refactoring is complete.
470 |
471 | **Required Actions:**
472 | - Review refactoring results
473 | - Resolve any ambiguities
474 | - Approve the results
475 |
476 | **Next Step:** After changes are approved and questions resolved, it is time to add the next rule to the chat.
477 | ---
478 |
479 | ### Tools used
480 |
481 | - `build_component_contract` - Creates component contracts for safe refactoring
482 | - Parameters: `saveLocation`, `typescriptFile` (required), `templateFile` (optional), `styleFile` (optional), `dsComponentName` (optional)
483 | - Returns: contract with public API, DOM structure, styles, and metadata
484 | - Generates: JSON contract files with SHA-256 hashes for validation
485 | - Note: Template and style files are optional—extracts inline templates/styles from TypeScript when not provided
486 |
487 | ### Flow
488 |
489 | > You don't need to manually perform any of the listed actions.
490 |
491 | 1. **Checklist Parsing**: Load and parse the refactoring checklist from temporary file
492 | 2. **Contract Generation**: Create baseline contracts for all components in scope
493 | 3. **Component Analysis**: Analyze each component using contract data
494 | 4. **Change Determination**: Evaluate what modifications are needed per checklist item
495 | 5. **Code Implementation**: Execute the actual refactoring changes
496 | 6. **Progress Documentation**: Update checklist with completion status and notes
497 | 7. **Reflection Phase**: Identify uncertainties and areas needing confirmation
498 | 8. **User Interaction**: Request approval for complex changes or clarifications
499 | 9. **Final Report**: Generate structured report with updates, reflections, and confirmations needed
500 |
501 | The rule enforces structured output with `<refactoring_report>`, `<checklist_updates>`, `<reflections>`, and `<user_confirmations_needed>` tags, and maintains detailed progress tracking throughout the process.
502 |
503 | ### Preferred model
504 |
505 | Claude-4-Sonnet
506 |
507 | ## 04-validate-changes.mdc
508 |
509 | ### Goal
510 |
511 | Analyze refactored code and component contracts to identify potential issues, breaking changes, and risky points that require attention from the development team. This rule provides comprehensive validation through static analysis, contract comparison, and structured reporting to ensure refactoring safety and quality.
512 |
513 | ### Process
514 |
515 | To start this process, drag file `04-validate-changes.mdc` to the cursor chat after refactoring is completed.
516 |
517 | The rule implements a comprehensive validation analysis process:
518 |
519 | **Step 1: Static Code Analysis**
520 | - Runs ESLint validation on all refactored files
521 | - Checks for Angular-specific rule violations and TypeScript issues
522 | - Reports any linting errors that need immediate attention
523 |
524 | **Step 2: Contract Generation**
525 | - Creates new component contracts for the refactored state
526 | - Captures current public API, DOM structure, and styles
527 | - Generates SHA-256 hashes for contract validation
528 |
529 | **Step 3: Contract Comparison**
530 | - Lists all available component contracts (before/after states)
531 | - Performs detailed diffs between old and new contracts
532 | - Identifies changes in function signatures, data structures, and interfaces
533 |
534 | **Step 4: Change Analysis**
535 | - Analyzes contract diffs for potential breaking changes
536 | - Evaluates severity and impact of each modification
537 | - Considers backwards compatibility and performance implications
538 |
539 | **Step 5: Risk Assessment**
540 | - Identifies high-risk changes requiring elevated attention
541 | - Evaluates potential impacts on other system parts
542 | - Assesses overall refactoring safety and quality
543 |
544 | **Step 6: Validation Reporting**
545 | - Generates structured analysis with detailed findings
546 | - Provides specific recommendations for development, QA, and UAT teams
547 | - Highlights critical issues requiring immediate action
548 |
549 | ---
550 | **🚦 Quality Gate 3**
551 |
552 | This is your last chance to make changes before opening the pull request.
553 |
554 | **Required Actions:**
555 | - Review validation report and risk assessment
556 | - Resolve any critical issues
557 | - Approve the final results
558 |
559 | **Next Step:** After all issues are resolved and no changes are needed, you can attach the next rule file.
560 | ---
561 |
562 | ### Tools used
563 |
564 | - `lint-changes` - Performs static code analysis using ESLint
565 | - Parameters: `directory`, optional `files` and `configPath`
566 | - Returns: Angular-specific rule violations, TypeScript issues, template errors
567 | - Features: Automatic ESLint config resolution, comprehensive rule coverage
568 |
569 | - `build_component_contract` - Creates contracts for refactored components
570 | - Parameters: `saveLocation`, `typescriptFile` (required), `templateFile` (optional), `styleFile` (optional), `dsComponentName` (optional)
571 | - Returns: JSON contract with public API, DOM structure, and styles
572 | - Purpose: Capture post-refactoring component state
573 | - Note: Template and style files are optional for components with inline templates/styles
574 |
575 | - `list_component_contracts` - Lists available component contracts
576 | - Parameters: `directory`
577 | - Returns: Available contract files with timestamps and metadata
578 | - Purpose: Identify before/after contract pairs for comparison
579 |
580 | - `diff_component_contract` - Compares component contracts
581 | - Parameters: `saveLocation`, `contractBeforePath`, `contractAfterPath`, `dsComponentName`
582 | - Returns: Detailed diff highlighting changes in API, DOM, and styles
583 | - Saves: Diff files to the specified saveLocation path
584 |
585 | ### Flow
586 |
587 | > You don't need to manually perform any of the listed actions.
588 |
589 | 1. **Input Processing**: Parse refactored files list and available component contracts
590 | 2. **Static Analysis**: Run ESLint validation on all refactored files
591 | 3. **Error Handling**: Address any linting errors before proceeding
592 | 4. **Contract Generation**: Create new contracts for refactored components
593 | 5. **Contract Discovery**: List all available contracts for comparison
594 | 6. **Contract Comparison**: Generate diffs between before/after contract states
595 | 7. **Change Analysis**: Analyze diffs for breaking changes and risks
596 | 8. **Impact Assessment**: Evaluate severity and system-wide implications
597 | 9. **Report Generation**: Create structured validation report with recommendations
598 | 10. **Quality Assurance**: Provide actionable insights for development teams
599 |
600 | The rule enforces structured output with `<analysis>`, `<questions_for_user>`, and `<validation_report>` tags, ensuring comprehensive coverage of all potential issues and clear communication of findings.
601 |
602 | ### Preferred model
603 |
604 | Claude-4-Sonnet (thinking)
605 |
606 | ## 05-prepare-report.mdc
607 |
608 | ### Goal
609 |
610 | Analyze the complete refactoring session, create comprehensive testing checklists for different roles, and generate documentation for code changes. This rule provides the final deliverables including role-specific testing checklists, semantic commit messages, and PR descriptions to ensure proper handoff to development teams and quality assurance processes.
611 |
612 | ### Process
613 |
614 | To start this process, drag file `05-prepare-report.mdc` to the cursor chat after validation is completed.
615 |
616 | The rule implements a comprehensive reporting and documentation process:
617 |
618 | **Step 1: Chat History Analysis**
619 | - Reviews the entire refactoring session conversation
620 | - Identifies all refactoring changes discussed and implemented
621 | - Extracts analysis, insights, and code modifications
622 | - Documents potential risks and concerns mentioned
623 |
624 | **Step 2: Impact Assessment**
625 | - Evaluates the overall impact of changes on the system
626 | - Identifies potential edge cases and affected scenarios
627 | - Determines areas requiring special attention during testing
628 | - Assesses both functional and non-functional implications
629 |
630 | **Step 3: Testing Checklist Creation**
631 | - Generates role-specific testing checklists for three key roles:
632 | - **Developer**: Unit tests, integration tests, code review points
633 | - **Manual QA Engineer**: Functional testing, regression testing, edge cases
634 | - **UAT Professional**: User acceptance criteria, business logic validation
635 | - Highlights uncertainties requiring clarification
636 | - Specifies critical verification points
637 |
638 | **Step 4: Documentation Generation**
639 | - Creates semantic commit message following conventional commit format
640 | - Generates PR description summarizing changes and review points
641 | - Saves comprehensive verification checklist to `.cursor/tmp/verification-checklist-{{FOLDER}}.md`
642 |
643 | **Step 5: Deliverable Packaging**
644 | - Structures all outputs in standardized format
645 | - Ensures proper handoff documentation
646 | - Provides actionable items for each stakeholder role
647 |
648 | > This is the end of the flow.
649 |
650 | ### Tools used
651 |
652 | None
653 |
654 | ### Flow
655 |
656 | > You don't need to manually perform any of the listed actions.
657 |
658 | 1. **History Review**: Analyze complete chat history for refactoring changes and insights
659 | 2. **Change Analysis**: Identify specific code areas modified and potential risks
660 | 3. **Impact Evaluation**: Assess overall system impact and edge cases
661 | 4. **Checklist Generation**: Create detailed testing checklists for each role
662 | 5. **Documentation Creation**: Generate semantic commit messages and PR descriptions
663 | 6. **File Persistence**: Save verification checklist to temporary directory
664 | 7. **Output Structuring**: Format all deliverables in standardized sections
665 | 8. **Quality Assurance**: Ensure comprehensive coverage and actionable items
666 | 9. **Stakeholder Handoff**: Provide clear documentation for development teams
667 |
668 | The rule enforces structured output with `<analysis>`, `<testing_checklists>`, `<verification_document_path>`, `<commit_message>`, and `<pr_description>` tags, ensuring complete documentation of the refactoring process and clear next steps for all stakeholders.
669 |
670 | ### Preferred model
671 |
672 | Claude-4-Sonnet
673 |
674 |
675 | ## clean-global-styles.mdc (Independent Step)
676 |
677 | ### Goal
678 |
679 | Analyze a project for deprecated CSS classes and component violations to provide a comprehensive assessment of design system migration readiness. This rule serves as a preliminary analysis step that can be used independently of the main refactoring flow to understand the scope of deprecated usage across both global styles and component-specific code.
680 |
681 | ### Process
682 |
683 | To start this process, drag file `clean-global-styles.mdc` to the cursor chat and provide the required parameters:
684 |
685 | ```
686 | directory=path/to/source/directory
687 | stylesDirectory=path/to/global/styles/directory
688 | componentName=DsComponentName
689 |
690 | @clean-global-styles.mdc
691 | ```
692 |
693 | This rule follows a three-step analysis process:
694 |
695 | **Step 1: Global Styles Analysis**
696 | - Scans the global styles directory for deprecated CSS classes
697 | - Identifies occurrences of deprecated classes across all style files
698 | - Reports file locations and line numbers for each violation
699 |
700 | **Step 2: Source Directory Analysis**
701 | - Scans the source directory for deprecated CSS classes in component styles
702 | - Identifies deprecated CSS usage in component-specific style files
703 | - Reports violations with precise file and line information
704 |
705 | **Step 3: Component Violations Analysis**
706 | - Scans the source directory for deprecated component usage in templates and TypeScript files
707 | - Identifies HTML elements and TypeScript code using deprecated classes
708 | - Reports violations with context about where deprecated components are used
709 |
710 | ### Tools used
711 |
712 | - `report-deprecated-css` - Analyzes deprecated CSS classes in style files
713 | - Parameters: `directory`, `componentName`
714 | - Returns: List of deprecated CSS class usage with file locations and line numbers
715 | - Scans: .scss, .sass, .less, .css files for deprecated class selectors
716 |
717 | - `report-violations` - Analyzes deprecated component usage in templates and code
718 | - Parameters: `directory`, `componentName`
719 | - Returns: List of component violations with file locations and line numbers
720 | - Scans: .html, .ts files for deprecated component usage in templates and inline templates
721 |
722 | ### Flow
723 |
724 | > You don't need to manually perform any of the listed actions except providing the initial parameters.
725 |
726 | 1. **Parameter Setup**: User provides `{{SOURCE_PATH}}`, `{{GLOBAL_STYLES_PATH}}`, and `{{COMPONENT_NAME}}`
727 | 2. **Global Styles Scan**: Execute `report-deprecated-css` on global styles directory
728 | 3. **Source Directory Scan**: Execute `report-deprecated-css` on source directory
729 | 4. **Component Violations Scan**: Execute `report-violations` on source directory
730 | 5. **Results Analysis**: Analyze all findings and determine next steps
731 | 6. **Recommendation Generation**: Provide structured recommendations based on findings
732 | 7. **User Action Decision**: Present options for handling deprecated CSS if no violations found
733 |
734 | ### Output Structure
735 |
736 | The rule provides structured output with three key sections:
737 |
738 | **Analysis Section**
739 | - Summary of violations found in source folder
740 | - Count and distribution of deprecated CSS occurrences
741 | - Assessment of migration readiness
742 |
743 | **Recommendation Section**
744 | - Priority actions based on findings
745 | - Guidance on whether to fix violations first or clean up deprecated CSS
746 | - Strategic recommendations for migration approach
747 |
748 | **User Action Required Section**
749 | - Interactive options when no violations are found but deprecated CSS exists
750 | - Choices for handling deprecated CSS (remove, save, or ignore)
751 | - Clear next steps for the user
752 |
753 | ### Decision Tree
754 |
755 | The rule follows a decision tree approach:
756 |
757 | 1. **If component violations are found**: Recommend fixing violations first before cleaning up deprecated CSS
758 | 2. **If no violations but deprecated CSS exists**: Offer options to remove, save, or ignore deprecated CSS
759 | 3. **If no violations and no deprecated CSS**: Confirm the directory is clean and ready
760 |
761 | ### Integration with Main Flow
762 |
763 | While this rule operates independently, it can inform the main refactoring flow:
764 |
765 | - **Before Main Flow**: Use to assess overall migration scope and readiness
766 | - **During Planning**: Reference findings to understand global impact
767 | - **After Refactoring**: Use to verify cleanup completeness
768 |
769 | ### Preferred model
770 |
771 | Claude-4-Sonnet
772 |
773 |
774 | ## discover-affected-urls.mdc (Independent Step)
775 |
776 | ### Goal
777 |
778 | Analyze Angular routing hierarchy to discover URL(s) where specific component files can be accessed in a web application. This rule performs comprehensive routing analysis using a bottom-up approach to identify both directly routable components and non-routable components (modals, dialogs, child components) that are accessible through their parent routes, providing complete URL discovery with redirect resolution.
779 |
780 | ### Process
781 |
782 | To start this process, drag file `discover-affected-urls.mdc` to the cursor chat and provide the required parameters:
783 |
784 | ```
785 | app_directory=src/app
786 | files=["src/app/components/user.component.ts", "src/app/dialogs/confirmation.component.ts"]
787 |
788 | @discover-affected-urls.mdc
789 | ```
790 |
791 | This rule implements a comprehensive five-phase analysis process:
792 |
793 | **Phase 1: Routing Hierarchy Discovery & Bottom-Top Point Identification**
794 | - Scans the complete app directory to identify ALL routing files and build routing hierarchy tree
795 | - Discovers top point (complete app routing structure) and bottom point (file parent routes)
796 | - Classifies each file as either directly routable or non-routable
797 | - Validates that both routing points are properly identified before proceeding
798 |
799 | **Phase 2: Non-Routable Component Analysis**
800 | - Identifies components without direct route definitions (modals, dialogs, library components)
801 | - Traverses component hierarchy upward through multiple levels to find routable parent components
802 | - Analyzes modal/dialog trigger mechanisms (MatDialog.open, component selectors, service calls)
803 | - Maps complete relationship chains from non-routable components to their accessible routes
804 |
805 | **Phase 3: Bottom-Up Route Connection & Path Construction**
806 | - Creates comprehensive redirect mapping from all routing files in the hierarchy
807 | - Traces routable components upward through routing hierarchy with full redirect resolution
808 | - Resolves non-routable component paths using parent relationships from Phase 2
809 | - Constructs complete paths with redirect audit trails and concrete URL examples
810 |
811 | **Phase 4: Parameter & Visibility Analysis**
812 | - Extracts parameter constraints from TypeScript files using established connections
813 | - Scans for visibility conditions (@if, *ngIf directives, route guards, permissions)
814 | - Provides realistic examples with culture codes and parameter values
815 | - Validates parameter inheritance and visibility constraints along routing paths
816 |
817 | **Phase 5: Quick Access Summary Generation**
818 | - Collects and organizes all route examples from previous phases
819 | - Generates structured summary with mandatory bullet list format
820 | - Provides 1-3 concrete URL examples per file with realistic parameters
821 | - Ensures complete coverage of all analyzed files with proper formatting
822 |
823 | ### Tools used
824 |
825 | None - This rule uses pure Angular routing analysis without external MCP tools
826 |
827 | ### Flow
828 |
829 | > You don't need to manually perform any of the listed actions except providing the initial parameters.
830 |
831 | 1. **Parameter Setup**: User provides `{{APP_DIRECTORY}}` and `{{FILES}}` array for analysis
832 | 2. **Routing Discovery**: Scan app directory for complete routing hierarchy and classify files
833 | 3. **Non-Routable Analysis**: Identify parent relationships for components without direct routes
834 | 4. **Route Construction**: Build complete paths with redirect resolution and concrete examples
835 | 5. **Parameter Analysis**: Extract constraints and visibility conditions along routing paths
836 | 6. **Summary Generation**: Create quick access summary with formatted URL examples for all files
837 | 7. **Validation**: Ensure complete coverage and proper formatting of all analyzed components
838 |
839 | ### Output Structure
840 |
841 | The rule provides structured output across five tagged sections:
842 |
843 | **Routing Discovery Section** (`<routing_discovery>`)
844 | - Complete app routing hierarchy tree
845 | - File classification (routable vs non-routable)
846 | - Top and bottom point identification
847 |
848 | **Non-Routable Analysis Section** (`<non_routable_analysis>`)
849 | - Parent component relationships
850 | - Multi-level hierarchy traversal results
851 | - Modal/dialog trigger analysis
852 |
853 | **Bottom-Up Connection Section** (`<bottom_up_connection>`)
854 | - Comprehensive redirect mapping
855 | - Complete path construction with examples
856 | - Redirect audit trails
857 |
858 | **Parameter Analysis Section** (`<parameter_analysis>`)
859 | - Parameter constraints and visibility conditions
860 | - Realistic examples with culture codes
861 | - Guard and permission analysis
862 |
863 | **Quick Access Summary Section** (`<quick_access_summary>`)
864 | - Structured summary with bullet format
865 | - 1-3 URL examples per file
866 | - Complete coverage verification
867 |
868 | ### Use Cases
869 |
870 | This rule is particularly useful for:
871 |
872 | - **Component Migration Planning**: Understanding where components are accessible before refactoring
873 | - **Testing Strategy**: Identifying all URLs that need testing after component changes
874 | - **Documentation**: Creating comprehensive route documentation for components
875 | - **Debugging**: Troubleshooting routing issues and finding component access points
876 | - **Impact Analysis**: Understanding the scope of changes when modifying routable components
877 |
878 | ### Integration with Main Flow
879 |
880 | While this rule operates independently, it complements the design system refactoring flow:
881 |
882 | - **Before Refactoring**: Identify all URLs where legacy components are accessible
883 | - **During Planning**: Understand routing impact of component changes
884 | - **After Migration**: Verify that refactored components remain accessible at expected URLs
885 | - **Testing Phase**: Use discovered URLs for comprehensive component testing
886 |
887 | ### Preferred model
888 |
889 | Claude-4-Sonnet
890 |
```