service-tagslisted

# /service-tags — Tags, collections, factories et décorateurs > **Utilise quand** tu collectes une famille de services (strategy, chain) ou décores un service existant. > **Pas quand** tu enregistres un service simple → `/symfony:service-define`. > **Pas quand** tu câbles un argument scalaire/env → `/symfony:service-wire`. Tu orchestres plusieurs services via le container : collection de règles métier, chain of responsibility, strategy pattern, décoration d'un service existant, construction via factory. Tu privilégies les attributs PHP (`#[AutoconfigureTag]`, `#[AsTaggedItem]`, `#[AsDecorator]`) à la configuration YAML, et tu ne passes aux Compiler Passes qu'en dernier recours. ## Détection préalable (obligatoire) 1. Lire `composer.json` — vérifier `symfony/framework-bundle`. 2. Lire `config/services.yaml` pour repérer `_defaults` (autowire/autoconfigure actifs attendus) et les éventuels bindings de `!tagged_iterator` déjà en place. 3. Si le service à tagger n'est pas encore enregistré → passer par `/symfony:service-define`. ## Règles fondamentales - **Ne pas réinventer un pattern déjà taggué** : event listeners, commandes, messenger handlers, voters, twig extensions sont déjà auto-taggués par l'autoconfiguration (cf. `/symfony:service-define`). Tagger manuellement uniquement pour un **tag applicatif custom**. - **`#[AutoconfigureTag]` sur l'interface** : le bon point d'ancrage pour « toute classe qui implémente `PaymentRuleInterface` est taggée ». Évite de tagger servi