Skip to content

Commit 4a09b14

Browse files
poltorakSzymon.Poltorak
andauthored
feat(rules): add Angular routing URL-discovery analysis rule (#8)
* feat(rules): add Angular routing URL-discovery analysis rule * feat(rules): extend ds-refactoring-flow.md * feat(rules): improve discover-affected-urls.mdc prompt * feat(rules): discover-affected-urls.mdc now saves results to tmp folder --------- Co-authored-by: Szymon.Poltorak <szymon.poltorak@push-based.io>
1 parent 733a355 commit 4a09b14

File tree

2 files changed

+199
-0
lines changed

2 files changed

+199
-0
lines changed
Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
---
2+
description: Discovering URL(s) where given component(s) can be found
3+
globs:
4+
alwaysApply: false
5+
---
6+
{
7+
"schema_version": "1.0",
8+
"task": "Angular routing analysis and URL discovery",
9+
"description": "Analyze Angular routing hierarchy using bottom-up approach: identify complete routing structure from app_directory (top point) and parent routes for specific files (bottom point), then connect them bottom-up with comprehensive redirect resolution. Output plain text with markdown syntax throughout; at the end, persist discovered URLs to JSON files as specified.",
10+
"inputs": {
11+
"app_directory": "Directory path where route definition files should be scanned (e.g., 'src/app')",
12+
"files": "Array of specific file paths to analyze (e.g., ['src/app/components/user.component.ts'])"
13+
},
14+
"phases": [
15+
{
16+
"id": 1,
17+
"name": "Routing Hierarchy Discovery & Component Search",
18+
"requires_approval": false,
19+
"response_format": "plain text with markdown syntax wrapped with <routing_discovery> tags, maximum 200 tokens, NO file generation",
20+
"steps": [
21+
"TOP POINT DISCOVERY: Scan app_directory completely to identify ALL routing files and build complete routing hierarchy tree (app.routes.ts, app-routing.module.ts, main.ts, and all loadChildren declarations).",
22+
"BOTTOM-UP DUAL DISCOVERY: For each file in 'files' parameter, extract component class name AND template selector. From these specific components, search upward for BOTH: (1) Direct parent routes referencing the component class, (2) Parent components using the template selector. MANDATORY: Trace ALL upward paths from each specific component - do not stop after finding first parent.",
23+
"BOTTOM-UP ROUTE MAPPING: From each specific component file, map ALL discovered upward paths. A single component may have multiple parent relationships (direct route definitions + template selector usage). Document every upward path discovered from the bottom point.",
24+
"ENHANCED CLASSIFICATION: Classify each component as DIRECTLY-ROUTABLE (found in route definitions), INDIRECTLY-ROUTABLE (template selector usage only), or BOTH. Components can have multiple routing scenarios simultaneously.",
25+
"VALIDATION: Present 'Files to Analyze', 'TOP POINT: Complete App Routing Hierarchy', 'BOTTOM POINT: All Route Scenarios per File', and 'ROUTE COMPLETENESS CHECK' confirming exhaustive search was performed."
26+
]
27+
},
28+
{
29+
"id": 2,
30+
"name": "Non-Routable Component Analysis",
31+
"requires_approval": false,
32+
"response_format": "plain text with markdown syntax wrapped with <non_routable_analysis> tags, maximum 200 tokens, NO file generation",
33+
"steps": [
34+
"IDENTIFY NON-ROUTABLE COMPONENTS: From the files list, identify components without direct route definitions (modals, dialogs, library components, child components).",
35+
"ROUTABLE PARENT DISCOVERY: For non-routable components, traverse the component hierarchy upward through multiple levels to find the first routable parent component. Handle multi-level chains where non-routable components are nested within other non-routable components.",
36+
"MODAL/LIBRARY TRIGGER ANALYSIS: For modal and library components, identify the parent component where they are used, triggered, or instantiated (MatDialog.open, component selectors, service calls).",
37+
"USAGE RELATIONSHIP MAPPING: Document the complete relationship chain including all intermediate levels: Non-routable Component → Intermediate Parent(s) → Final Routable Parent → Route Path. Show the full traversal path for multi-level hierarchies.",
38+
"NON-ROUTABLE VALIDATION: Confirm all non-routable components have identified parent relationships before proceeding to route construction."
39+
]
40+
},
41+
{
42+
"id": 3,
43+
"name": "Exhaustive Route Construction & Verification",
44+
"requires_approval": false,
45+
"response_format": "plain text with markdown syntax wrapped with <bottom_up_connection> tags, maximum 200 tokens, NO file generation",
46+
"steps": [
47+
"COMPREHENSIVE REDIRECT MAPPING: Scan ALL routing files in the complete hierarchy for 'redirectTo' declarations. Create redirect mapping table with [original_path] → [redirectTo_path], including application-level, legacy, and inter-module redirects. Check for conflicting redirects and redirect loops.",
48+
"BOTTOM-UP EXHAUSTIVE TRACING: For each component from Phase 1, trace ALL upward paths to build complete route chains: (1) Direct bottom-up routes from component class to routing hierarchy, (2) Indirect bottom-up routes from template selector through parent components to routing hierarchy. Cross-reference both upward traces to ensure no paths are missed.",
49+
"MULTI-SCENARIO PATH CONSTRUCTION: Build complete paths for every routing scenario discovered. Apply redirect resolution at each level. Document all paths: direct routes, redirected routes, and parent-access routes for non-routable components.",
50+
"ROUTE COMPLETENESS VERIFICATION: Cross-check that all component routing scenarios from Phase 1 have corresponding path constructions. Verify no discovered routes were omitted from path building.",
51+
"MANDATORY PHASE 3 EXAMPLES: Provide 1-3 concrete route examples per routing scenario (not just per file). If component has both direct and indirect routes, show examples for BOTH. Include realistic culture codes and parameters."
52+
]
53+
},
54+
{
55+
"id": 4,
56+
"name": "Parameter & Visibility Analysis",
57+
"requires_approval": false,
58+
"response_format": "plain text with markdown syntax wrapped with <parameter_analysis> tags, maximum 200 tokens, NO file generation",
59+
"steps": [
60+
"Extract parameter constraints from TypeScript files using ALL established routing connections from Phase 3.",
61+
"Scan for visibility conditions: @if, *ngIf directives, route guards, resolvers, route data, permissions, and feature flags along ALL discovered route paths.",
62+
"HUMAN-FRIENDLY VISIBILITY SUMMARY: Produce a concise developer-friendly object with keys such as: 'authorization' ('required' | 'not required'), 'guards' (array of guard class names), 'resolvers' (string like 'A or B' when multiple), 'redirectBehavior' (e.g., '/old redirects to /new'), 'featureFlags' (array), 'conditions' (bullet-like phrases distilled from *ngIf/@if and route data), and optional 'notes'. Normalize common patterns (e.g., allowAnonymous: true → authorization: 'not required'). Include inherited conditions across the bottom-up chain.",
63+
"Provide realistic examples with different culture codes and parameter values for ALL traced paths (direct and indirect).",
64+
"Validate that all routing scenarios maintain parameter inheritance and visibility constraints across different access methods."
65+
]
66+
},
67+
{
68+
"id": 5,
69+
"name": "MANDATORY Comprehensive Summary Generation",
70+
"requires_approval": false,
71+
"response_format": "plain text with markdown syntax wrapped with <quick_access_summary> tags",
72+
"steps": [
73+
"COLLECT ALL SCENARIOS: Gather route examples from Phase 3 for EVERY routing scenario discovered. Include both direct routes and parent-access routes. MANDATORY: Every component must have at least one URL example for each routing scenario identified.",
74+
"GENERATE SUMMARY STRUCTURE: Create '🎯 QUICK ACCESS SUMMARY' section with exact format: Header 'Files Analyzed: [List all files]' followed by subsections '## File: [Filename.extension]' for each file.",
75+
"FORMAT VALIDATION: Use MANDATORY bullet list format with markdown bullets (-) for route examples. CRITICAL: Each route example MUST start with '- /' (markdown bullet + forward slash). FORBIDDEN: NO tables, NO pipes (|), NO table formatting whatsoever.",
76+
"COMPLETE SCENARIO COVERAGE: Include ALL discovered routing scenarios: direct routes, redirected routes, and parent-access routes. Add clear notation: '(direct route)', '(redirects to X)', '(non-routable, found in parent component at URL)'. MANDATORY: Cover every routing scenario from Phase 1 discovery.",
77+
"FINAL VERIFICATION AND PERSISTENCE (MANDATORY): Confirm the summary contains ALL files AND ALL routing scenarios. Then, for each analyzed component, WRITE a JSON file at `.cursor/tmp/discovered-urls/{{component-name}}.json` with schema: { \"component\": { \"urls\": [from summary], \"visibilityConditions\": <human-friendly object from Phase 4, or an array of such objects when scenarios differ> } }. Use the component TypeScript class name when available for {{component-name}}, otherwise the component file basename without extensions. Create the target directory if it does not exist and overwrite existing files."
78+
]
79+
}
80+
]
81+
}

docs/ds-refactoring-flow.md

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -598,3 +598,121 @@ While this rule operates independently, it can inform the main refactoring flow:
598598
### Preferred model
599599

600600
Claude-4-Sonnet
601+
602+
603+
## discover-affected-urls.mdc (Independent Step)
604+
605+
### Goal
606+
607+
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.
608+
609+
### Process
610+
611+
To start this process, drag file `discover-affected-urls.mdc` to the cursor chat and provide the required parameters:
612+
613+
```
614+
app_directory=src/app
615+
files=["src/app/components/user.component.ts", "src/app/dialogs/confirmation.component.ts"]
616+
617+
@discover-affected-urls.mdc
618+
```
619+
620+
This rule implements a comprehensive five-phase analysis process:
621+
622+
**Phase 1: Routing Hierarchy Discovery & Bottom-Top Point Identification**
623+
- Scans the complete app directory to identify ALL routing files and build routing hierarchy tree
624+
- Discovers top point (complete app routing structure) and bottom point (file parent routes)
625+
- Classifies each file as either directly routable or non-routable
626+
- Validates that both routing points are properly identified before proceeding
627+
628+
**Phase 2: Non-Routable Component Analysis**
629+
- Identifies components without direct route definitions (modals, dialogs, library components)
630+
- Traverses component hierarchy upward through multiple levels to find routable parent components
631+
- Analyzes modal/dialog trigger mechanisms (MatDialog.open, component selectors, service calls)
632+
- Maps complete relationship chains from non-routable components to their accessible routes
633+
634+
**Phase 3: Bottom-Up Route Connection & Path Construction**
635+
- Creates comprehensive redirect mapping from all routing files in the hierarchy
636+
- Traces routable components upward through routing hierarchy with full redirect resolution
637+
- Resolves non-routable component paths using parent relationships from Phase 2
638+
- Constructs complete paths with redirect audit trails and concrete URL examples
639+
640+
**Phase 4: Parameter & Visibility Analysis**
641+
- Extracts parameter constraints from TypeScript files using established connections
642+
- Scans for visibility conditions (@if, *ngIf directives, route guards, permissions)
643+
- Provides realistic examples with culture codes and parameter values
644+
- Validates parameter inheritance and visibility constraints along routing paths
645+
646+
**Phase 5: Quick Access Summary Generation**
647+
- Collects and organizes all route examples from previous phases
648+
- Generates structured summary with mandatory bullet list format
649+
- Provides 1-3 concrete URL examples per file with realistic parameters
650+
- Ensures complete coverage of all analyzed files with proper formatting
651+
652+
### Tools used
653+
654+
None - This rule uses pure Angular routing analysis without external MCP tools
655+
656+
### Flow
657+
658+
> You don't need to manually perform any of the listed actions except providing the initial parameters.
659+
660+
1. **Parameter Setup**: User provides `{{APP_DIRECTORY}}` and `{{FILES}}` array for analysis
661+
2. **Routing Discovery**: Scan app directory for complete routing hierarchy and classify files
662+
3. **Non-Routable Analysis**: Identify parent relationships for components without direct routes
663+
4. **Route Construction**: Build complete paths with redirect resolution and concrete examples
664+
5. **Parameter Analysis**: Extract constraints and visibility conditions along routing paths
665+
6. **Summary Generation**: Create quick access summary with formatted URL examples for all files
666+
7. **Validation**: Ensure complete coverage and proper formatting of all analyzed components
667+
668+
### Output Structure
669+
670+
The rule provides structured output across five tagged sections:
671+
672+
**Routing Discovery Section** (`<routing_discovery>`)
673+
- Complete app routing hierarchy tree
674+
- File classification (routable vs non-routable)
675+
- Top and bottom point identification
676+
677+
**Non-Routable Analysis Section** (`<non_routable_analysis>`)
678+
- Parent component relationships
679+
- Multi-level hierarchy traversal results
680+
- Modal/dialog trigger analysis
681+
682+
**Bottom-Up Connection Section** (`<bottom_up_connection>`)
683+
- Comprehensive redirect mapping
684+
- Complete path construction with examples
685+
- Redirect audit trails
686+
687+
**Parameter Analysis Section** (`<parameter_analysis>`)
688+
- Parameter constraints and visibility conditions
689+
- Realistic examples with culture codes
690+
- Guard and permission analysis
691+
692+
**Quick Access Summary Section** (`<quick_access_summary>`)
693+
- Structured summary with bullet format
694+
- 1-3 URL examples per file
695+
- Complete coverage verification
696+
697+
### Use Cases
698+
699+
This rule is particularly useful for:
700+
701+
- **Component Migration Planning**: Understanding where components are accessible before refactoring
702+
- **Testing Strategy**: Identifying all URLs that need testing after component changes
703+
- **Documentation**: Creating comprehensive route documentation for components
704+
- **Debugging**: Troubleshooting routing issues and finding component access points
705+
- **Impact Analysis**: Understanding the scope of changes when modifying routable components
706+
707+
### Integration with Main Flow
708+
709+
While this rule operates independently, it complements the design system refactoring flow:
710+
711+
- **Before Refactoring**: Identify all URLs where legacy components are accessible
712+
- **During Planning**: Understand routing impact of component changes
713+
- **After Migration**: Verify that refactored components remain accessible at expected URLs
714+
- **Testing Phase**: Use discovered URLs for comprehensive component testing
715+
716+
### Preferred model
717+
718+
Claude-4-Sonnet

0 commit comments

Comments
 (0)