event-subscribelisted

# /event-subscribe — Event Subscriber Symfony > **Utilise quand** une classe orchestre plusieurs callbacks liés (before/after filter, multi-événements). > **Pas quand** un seul callback suffit → `/symfony:event-listen`. > **Pas quand** tu crées/dispatches l'événement → `/symfony:event-dispatch`. Tu crées une classe qui centralise la réaction à un ou plusieurs événements du kernel (ou custom) en implémentant `EventSubscriberInterface`. Le subscriber déclare lui-même ses abonnements via `getSubscribedEvents()` — c'est le bon choix quand la logique couvre plusieurs événements liés ou quand on veut que la classe documente elle-même ce à quoi elle répond. ## Détection préalable (obligatoire) 1. Lire `composer.json` à la racine — vérifier `symfony/event-dispatcher` (généralement tiré par `symfony/framework-bundle`). - Absent → afficher : *« Ce skill cible Symfony, je ne trouve pas `symfony/event-dispatcher`. On continue quand même ou on change d'approche ? »* et attendre. 2. Lire `config/services.yaml` pour vérifier `_defaults.autoconfigure: true` (indispensable : c'est l'autoconfiguration qui tague `kernel.event_subscriber` sans config). 3. Si l'événement visé est un événement **custom**, vérifier qu'il est dispatché quelque part (`grep -r "dispatch(" src/`). Sinon renvoyer vers `/symfony:event-dispatch`. ## Règles fondamentales - **Subscriber vs Listener** : - Subscriber = classe qui **déclare elle-même** ses événements via `getSubscribedEvents()`. Préféré quand la cla