Analyze App

For other frameworks, adapt the discovery strategy based on their routing patterns.

1.2 Identify Page Components

For each route, identify the main page component:

• Follow lazy import references
• Use get_symbols_overview to understand component structure
• Record the component file path

Step 2 – Build Page-Module Inventory

For each discovered page, analyze its structure to build a comprehensive inventory:

2.1 Component Files

Find associated files for each page:

• Main component file (e.g., sbom-list.tsx)
• Context provider (e.g., sbom-list-context.tsx)
• Sub-components directory (e.g., sbom-list/components/)
• Table component (if applicable)
• Toolbar component (if applicable)

2.2 Query Hooks

Identify API data fetching:

• Search for TanStack Query hooks (e.g., useFetchSboms, useQuerySbomById)
• Use search_for_pattern with pattern useFetch|useQuery|useMutation
• Record which query hooks are used by each page

2.3 API Dependencies

Map frontend pages to backend endpoints:

• Parse query hook implementations to extract API calls
• Identify endpoints (e.g., GET /api/v1/sbom, POST /api/v1/advisory)
• Record API client methods used (from auto-generated client)

2.4 Component Complexity

Estimate complexity for each page:

• Count of sub-components
• Number of API calls
• Presence of tables with filtering/sorting/pagination
• Presence of forms

Step 3 – Create Module Dependency Map

Build a cross-reference map between frontend and backend:

3.1 Frontend to Backend

For each page, list:

• All API endpoints it calls
• HTTP methods used
• Query parameters or request body shapes

3.2 Shared Components

Identify components used across multiple pages:

• Use find_referencing_symbols to find component usage
• Record which components are reused
• Flag opportunities for shared optimization work

3.3 Shared Utilities

Find common utilities, hooks, and helpers:

• Table control hooks (reused across list pages)
• Custom hooks for data fetching patterns
• Utility functions

Step 4 – Generate Application Map Report

Create a structured report with:

4.1 Summary Table

4.2 Page Inventory

For each page:

• Page Name: {{name}}
• Route: {{path}}
• Main Component: {{file-path}}
• Query Hooks: {{list}}
• API Dependencies: {{list-of-endpoints}}
• Complexity: {{low/medium/high}}

4.3 Dependency Map

Frontend → Backend Mapping:

Page: sbom-list
  ├─ GET /api/v1/sbom (list SBOMs)
  ├─ GET /api/v1/package (list packages)
  └─ DELETE /api/v1/sbom/:id (delete SBOM)
  
Page: advisory-details
  ├─ GET /api/v1/advisory/:id (fetch advisory)
  ├─ GET /api/v1/vulnerability (list related vulnerabilities)
  └─ GET /api/v1/package (list affected packages)

4.4 Shared Resources

Reusable Components:

• ConditionalTableBody - used by 5 pages
• FilterToolbar - used by 8 pages
• SimplePagination - used by 12 pages

Reusable Hooks:

• useTableControlState - used by all list pages
• useFetchPaged - used by 10 pages

4.5 Observations

Note any structural patterns or concerns:

• Pages with high API call counts (potential over-fetching)
• Pages with complex component trees (potential rendering issues)
• Shared components that appear in critical paths
• Consistency in patterns across pages

Store the report as docs/performance/reports/app-map-{{date}}.md.

Include version footer with plugin version from .claude-plugin/plugin.json.

Step 5 – Prioritize Modules for Analysis

Ask the user which modules they want to analyze first, OR auto-prioritize based on:

1. Baseline data (if available):

   • Slowest page load times
   • Highest API call counts
   • Largest bundle sizes

2. Structural complexity:

   • Most API dependencies
   • Most sub-components
   • Presence of tables with complex state

3. User input:

   • User-reported slow pages
   • Pages under active development

Present the prioritized list to the user and ask which module to analyze first using /performance-analysis:analyze-module.

Important Rules

• If Serena is unavailable for the repository, fallback to Grep and Read tools
• Never modify code during discovery — this is read-only analysis
• If a page cannot be analyzed (e.g., file not found), note it in the report and continue
• Always complete the full inventory even if some pages have incomplete information
• Store the application map in the configured reports directory