Déboguer avec un agent en vérifiant une cause à la fois

# Applique le guide « Déboguer avec un agent en vérifiant une cause à la fois » dans ton agent

## Objectif
Pars d’un symptôme reproductible et distingue observation et explication. Demande les causes possibles, puis le plus petit contrôle qui les départage avant modification. Vérifie l’échec initial après correction et conserve l’incertitude plutôt que prendre un récit plausible ou un test sans rapport pour une preuve.

## Prérequis
- Inspecte le dépôt, la documentation et les conventions existantes.
- Confirme que le besoin correspond au périmètre du guide : Passe d’un symptôme reproductible à un correctif borné sans modifications au hasard ni fuite de logs.
- Préserve les décisions correctes déjà en place.

## Étapes du guide
- 1. Figer la reproduction — Pour un enregistrement qui crée parfois un doublon, note étapes, nombre attendu, nombre observé et environnement. Utilise des données fictives dans un système de test autorisé. Situe l’échec avant ou après la réponse. Nettoie les logs avant partage : retire jetons, données personnelles et corps complets sauf nécessité autorisée. Garde dates ou références utiles sans prétendre que la suppression conserve tous les indices.
- 2. Choisir un contrôle discriminant — Deux hypothèses sont un événement client doublé ou une reprise serveur. Compte requêtes et opérations pour une action contrôlée. La capture d’un bouton désactivé ne départage pas ces causes. Écris l’observation attendue pour chaque hypothèse avant le contrôle. Si aucune ne correspond, révise l’explication au lieu d’élargir les modifications jusqu’à disparition du symptôme.
- 3. Exemple : réponses dans le désordre — La recherche A démarre puis B. Retarde A pour la terminer après B. Si A apparaît sous la requête B, le défaut est un rendu périmé ; modifier le vocabulaire ne le corrigera pas. Un correctif ciblé peut vérifier l’identité de requête ou annuler le travail périmé selon l’existant. Vérifie que B reste visible après A et qu’une vraie panne de B reste récupérable.
- 4. Utiliser l’historique utile — Avec une version bonne et mauvaise fiables, comparaison ou bisect peut isoler une régression. Utilise un checkout isolé et un résultat reproductible. Stabilise un test intermittent avant de classer des versions. Ne réinitialise pas le travail de l’utilisateur pour reproduire un ancien build. Si l’environnement est introuvable, annonce la limite et utilise les preuves actuelles sans inventer de référence.
- 5. Vérifier le correctif causal — Rejoue la reproduction et le succès voisin. Ajoute un test de régression s’il capture réellement l’échec. Note changement, hypothèse étayée et points non vérifiés. La méthode ne garantit pas une cause à tout incident intermittent. Une atténuation, une correction confirmée et une non-reproduction inexpliquée sont trois conclusions différentes.

## Critères d’acceptation — Vérifier dans ton produit
- Le symptôme est reproductible ou borné.
- Les logs sont bornés et nettoyés.
- Les hypothèses ont des prédictions distinctes.
- Le contrôle précède la correction.
- Le parcours initial est rejoué.
- L’incertitude reste explicite.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

• Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes

# Ancre le guide dans le projet

## Objectif
Transforme les étapes appliquées en conventions durables du dépôt.

## Contrôles
- Relie chaque décision prise à l’étape du guide qui la justifie.
- Ajoute la checklist aux revues concernées.
- Note les cas hors périmètre pour les guides voisins.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

sha256:ce9409607441933eaba59b54525fecfc3e13938c7a173cd2a357f658daf256fd

# Diagnostique une application ratée du guide « Déboguer avec un agent en vérifiant une cause à la fois »

## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]

## Contrôles observables
- Rejoue les étapes dans l’ordre et note la première qui diverge :
- 1. Figer la reproduction — Pour un enregistrement qui crée parfois un doublon, note étapes, nombre attendu, nombre observé et environnement. Utilise des données fictives dans un système de test autorisé. Situe l’échec avant ou après la réponse. Nettoie les logs avant partage : retire jetons, données personnelles et corps complets sauf nécessité autorisée. Garde dates ou références utiles sans prétendre que la suppression conserve tous les indices.
- 2. Choisir un contrôle discriminant — Deux hypothèses sont un événement client doublé ou une reprise serveur. Compte requêtes et opérations pour une action contrôlée. La capture d’un bouton désactivé ne départage pas ces causes. Écris l’observation attendue pour chaque hypothèse avant le contrôle. Si aucune ne correspond, révise l’explication au lieu d’élargir les modifications jusqu’à disparition du symptôme.
- 3. Exemple : réponses dans le désordre — La recherche A démarre puis B. Retarde A pour la terminer après B. Si A apparaît sous la requête B, le défaut est un rendu périmé ; modifier le vocabulaire ne le corrigera pas. Un correctif ciblé peut vérifier l’identité de requête ou annuler le travail périmé selon l’existant. Vérifie que B reste visible après A et qu’une vraie panne de B reste récupérable.
- 4. Utiliser l’historique utile — Avec une version bonne et mauvaise fiables, comparaison ou bisect peut isoler une régression. Utilise un checkout isolé et un résultat reproductible. Stabilise un test intermittent avant de classer des versions. Ne réinitialise pas le travail de l’utilisateur pour reproduire un ancien build. Si l’environnement est introuvable, annonce la limite et utilise les preuves actuelles sans inventer de référence.
- 5. Vérifier le correctif causal — Rejoue la reproduction et le succès voisin. Ajoute un test de régression s’il capture réellement l’échec. Note changement, hypothèse étayée et points non vérifiés. La méthode ne garantit pas une cause à tout incident intermittent. Une atténuation, une correction confirmée et une non-reproduction inexpliquée sont trois conclusions différentes.

## Causes possibles
- Une étape a été sautée ou exécutée hors ordre.
- Le besoin réel sort du périmètre du guide.
- Un critère de la checklist n’a jamais été vérifié.

## Corrections bornées
- Reprends uniquement l’étape divergente et ce qui en dépend.
- Documente l’écart si le périmètre du guide ne couvre pas le besoin.

## Vérification finale — Vérifier dans ton produit
- Le symptôme est reproductible ou borné.
- Les logs sont bornés et nettoyés.
- Les hypothèses ont des prédictions distinctes.
- Le contrôle précède la correction.
- Le parcours initial est rejoué.
- L’incertitude reste explicite.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

• Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes

# Préviens la prochaine dérive

## Objectif
Fais de la première étape divergente un contrôle explicite du projet.

## Contrôles
- Ajoute un contrôle ciblé sur l’étape qui a divergé.
- Vérifie la checklist sur un second cas réel.
- Documente la limite de périmètre rencontrée.

## Garde-fous
- Montre d’abord les changements envisagés avant toute action externe.
- Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite.
- Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu.

## Format de sortie
- Résultat obtenu ou verdict.
- Fichiers ou actions concernés.
- Vérifications exécutées et preuves observables.
- Blocages ou limites restantes.

sha256:1c70a7b12620ccb6ce45298cd794066b38a24ed9ba9c7dcb5a2f1e2fac957e7a