---
name: step-02-conformity
description: Evaluate conformity of each element and scan for anti-patterns
next_step: steps/step-03-report.md
---

# Step 2: Conformity Analysis

## MANDATORY EXECUTION RULES:
- Load `references/routing-pattern.md` FIRST for the reference pattern
- Read each element's FULL source code before evaluating
- NEVER judge developers — analyze code objectively
- Distinguish errors from conscious architectural choices
- If a deviation has a valid technical justification, say so explicitly
- Cross-reference manual findings with MCP results from `{mcp_results}` (step-00)

## YOUR TASK:
For each of the 5 elements found in Step 1, evaluate conformity against the reference pattern. Then scan the entire codebase for anti-patterns.

---

## EXECUTION SEQUENCE:

### Phase A: Conformity Evaluation (per element)

For each of the 5 elements, read the full source file and evaluate:

#### Rating Scale:
| Rating | Symbol | Meaning |
|--------|--------|---------|
| Conforme | ✅ | Implementation matches the pattern |
| Partiellement conforme | ⚠️ | Intent is correct but execution deviates |
| Non conforme | ❌ | Implementation contradicts the pattern |
| Absent | 🔴 | Element does not exist |

#### For each element, record:

**If ✅ Conforme:**
- Brief confirmation of what makes it compliant
- Any notable strengths or best practices observed

**If ⚠️ Partiellement conforme, ❌ Non conforme, or 🔴 Absent — answer ALL 5 questions:**

**a) Qu'est-ce qui a ete fait a la place ?**
Describe precisely the alternative implementation found in the code.
Include specific file paths and line numbers.

**b) Pourquoi est-ce que ca ne respecte pas le pattern ?**
Technical explanation of the deviation:
- Tight coupling (front depends on route structure)
- Static routes (hardcoded in JSX instead of API-driven)
- Missing guard (no permission check at route level)
- Non-lazy imports (eager loading bloats bundle)
- Incomplete implementation (partial API usage)

**c) Pourquoi le developpeur a probablement fait ca ?**
Formulate a benevolent hypothesis:
- Pattern unknown at development time?
- Technical constraint (bundler, framework limitation)?
- Deliberate MVP simplification?
- Misunderstanding of front/back responsibility separation?
- Legacy architecture inheritance?
- Confusion between static protected routes and dynamic routes?
- Migration in progress (intentional intermediate state)?

**d) Quelle est la consequence concrete de cette deviation ?**
Concrete impact:
- DB/front coupling (routes changes require front deploy)
- Potential security flaw (permission bypass)
- Rigidity (adding a route requires code change + deploy)
- Technical debt (maintenance burden)
- Bundle size impact (non-lazy loading)
- User experience (flash of wrong page, etc.)

**e) Comment migrer vers le pattern cible ?**
Concrete migration steps considering existing code:
- DO NOT propose a complete rewrite if a targeted refactor suffices
- Number the steps in priority order
- Estimate scope: small (1-2 files), medium (3-5 files), large (6+ files)
- Note any prerequisites or dependencies between migration steps

---

### Phase B: Anti-Pattern Scan

Scan the ENTIRE codebase (not just routing files) for these anti-patterns:

#### B1. Hardcoded Routes in JSX
```
Grep patterns (in {web_root}):
  - <Route\s+path=      (outside DynamicRouter)
  - path:\s*['"/]       (in non-config files)
  - navigate\(['"]\/    (hardcoded navigation targets)
  - to=['"]\/           (Link/NavLink with hardcoded paths)
  - href=['"]\/(?!http) (internal links with hardcoded paths)
```

**IMPORTANT**: Exclude legitimate cases:
- DynamicRouter.tsx itself (it generates routes dynamically)
- Test files
- Constants files that define route patterns for DynamicRouter consumption
- Documentation files

#### B2. Hardcoded Permissions in Components
```
Grep patterns (in {web_root}):
  - hasPermission\(['"]   (string literal permission checks)
  - permission.*===       (direct comparison)
  - role.*===.*['"]admin  (role-based instead of permission-based)
  - canAccess\(['"]       (string literal access checks)
```

**Distinguish**: Permission checks using API-provided data (OK) vs hardcoded permission strings (anti-pattern).

**NOTE**: Components checking `permissionPath` from the menu API or from `useRouteConfig` data are CONFORMING — this is defense in depth, not hardcoding.

#### B2bis. MCP-detected Hardcoded Paths (cross-reference)
```
If {mcp_results.frontend_routes} is available:
  - Merge MCP apiClients.issues (type: 'invalid-path') with manual B1 findings
  - Add any MCP-detected hardcoded navigate()/Link paths not found by manual grep
  - Deduplicate: same file:line from both sources counts as ONE finding
  - Mark source: [MANUAL], [MCP], or [BOTH] for each finding
```

#### B3. Non-Lazy Imports in Registry
```
Grep patterns (in componentRegistry files):
  - ^import .* from      (eager imports of page components)
  - require\(             (CommonJS require of pages)
```

**Expected pattern**: `lazy(() => import(...))`

#### B4. Missing Suspense Boundaries
```
Grep patterns (in {web_root}):
  - Check DynamicRouter and App.tsx for <Suspense> wrapping
  - Check if lazy components are rendered without Suspense parent
```

#### B5. Route/Permission Path Misalignment
```
Cross-reference:
  - Backend: permission paths in navigation seed data
  - Frontend: permission checks in components
  - Look for mismatches between API-provided paths and frontend expectations
```

#### B6. Duplicate Route Definitions
```
Check for routes defined in multiple places:
  - DynamicRouter + another router file
  - Static route config + dynamic route config
  - Multiple files registering the same path
```

---

### Phase C: Compile Conformity Summary

```
## Conformity Results

| # | Element | Rating | Key Finding |
|---|---------|--------|-------------|
| 1 | componentRegistry | ✅/⚠️/❌/🔴 | {one-line summary} |
| 2 | ProtectedRoute | ✅/⚠️/❌/🔴 | {one-line summary} |
| 3 | DynamicRouter | ✅/⚠️/❌/🔴 | {one-line summary} |
| 4 | useRouteConfig | ✅/⚠️/❌/🔴 | {one-line summary} |
| 5 | Navigation API | ✅/⚠️/❌/🔴 | {one-line summary} |

## Anti-Patterns Detected: {count}

| # | Anti-Pattern | File:Line | Severity | Description |
|---|-------------|-----------|----------|-------------|
| 1 | {type} | {file}:{line} | HIGH/MED/LOW | {description} |
| ... | | | | |

-> Proceeding to final report...
```

---

## SUCCESS METRICS:
- Each element rated with justification
- All 5 causal questions answered for every deviation
- Anti-pattern scan covers entire web_root (not just routing files)
- False positives excluded (legitimate uses identified)
- Conformity summary table complete

## NEXT STEP:
After displaying conformity results, proceed directly to `./step-03-report.md`
