---
description: "Effectue une revue de code complète sur les fichiers modifiés"
---

# /review — Revue de code

Effectue une revue de code sur les fichiers modifiés, en contexte isolé (subagent).

## Procédure

1. Identifier les fichiers modifiés :
```bash
git diff --name-only HEAD
git diff --name-only --staged
```

2. Lire chaque fichier modifié et analyser selon la checklist ci-dessous.

3. Produire un rapport structuré.

## Exécution

Lancer la revue dans un subagent avec contexte isolé pour ne pas polluer la session :

```
Task(subagent_type=reviewer)
```

## Checklist

### PHP / WordPress
- [ ] Hooks et filtres correctement enregistrés/retirés
- [ ] Nonces vérifiés pour tout AJAX (`wp_verify_nonce`)
- [ ] Escaping des sorties (`esc_html`, `esc_attr`, `esc_url`, `wp_kses`)
- [ ] Sanitization des entrées (`sanitize_text_field`, `absint`)
- [ ] Utilisation correcte d'ACF (`get_field`, `get_sub_field`)
- [ ] Namespace et autoloading corrects
- [ ] Pas de requêtes SQL directes sans `$wpdb->prepare()`

### Système Composer dual easebook
- [ ] Si `composer.json` modifié seul (sans les fichiers full/prod) → critical
- [ ] Si `composer.json` ≠ `composer-prod.json` au moment du diff → critical (CI va planter)
- [ ] Si `packages/` modifié sans modif équivalente sur `composer-full.json` → warning (désynchro probable)

### Templates / Frontend
- [ ] Escaping par défaut `{{ }}` en Blade (raw `{!! !!}` justifié)
- [ ] Composants correctement structurés
- [ ] Responsive : classes mobile-first
- [ ] Pas de logique métier dans les templates

### JavaScript
- [ ] AJAX avec nonce et vérification de réponse
- [ ] Pas de jQuery (vanilla JS)
- [ ] Gestion d'erreurs sur les appels réseau

### Sécurité (OWASP)
- [ ] Pas d'injection SQL (utiliser `$wpdb->prepare()`)
- [ ] Pas de XSS (escaping systématique)
- [ ] Protection CSRF (nonces sur formulaires et AJAX)
- [ ] Pas de données sensibles exposées côté client
- [ ] Validation et sanitization à chaque boundary

### Accessibilité
- [ ] HTML sémantique (`<nav>`, `<main>`, `<article>`, `<section>`)
- [ ] Attributs `alt` sur les images
- [ ] Hiérarchie de headings logique (h1 → h2 → h3)
- [ ] Attributs ARIA quand nécessaire
- [ ] Focus visible sur les éléments interactifs
- [ ] Labels associés aux champs de formulaire

## Format du rapport

```markdown
## Revue de code — <date>

### Fichiers analysés
- `chemin/fichier.php` (modifié)
- ...

### Critical
> Problèmes bloquants à corriger avant merge.
- **[fichier:ligne]** Description du problème

### Important
> Problèmes significatifs à corriger.
- **[fichier:ligne]** Description du problème

### Suggestions
> Améliorations recommandées mais non bloquantes.
- **[fichier:ligne]** Description de la suggestion

### Résumé
X critical, Y important, Z suggestions
```

## Règles

- Ne reviewer que le code **modifié**, pas l'ensemble du projet
- Pas de nitpicking (style, formatage — c'est le rôle de Pint)
- Se concentrer sur la logique, la sécurité, les bonnes pratiques **et la cohérence du système composer dual**
- Lire les fichiers voisins pour comprendre le contexte