Vérifier un changement d’agent avant de l’accepter

# Applique le guide « Vérifier un changement d’agent avant de l’accepter » dans ton agent

## Objectif
Compare le résultat demandé au correctif réel et au comportement observable. Examine permissions, persistance et données sortantes. Utilise une revue indépendante pour les changements importants, avec des remarques liées à des défauts reproductibles ; distingue code accepté et résultat publié vérifié.

## Prérequis
- Inspecte le dépôt, la documentation et les conventions existantes.
- Confirme que le besoin correspond au périmètre du guide : Examine comportement, périmètre, effets sur les données et preuves plutôt qu’un résumé ou des tests verts seuls.
- Préserve les décisions correctes déjà en place.

## Étapes du guide
- 1. Partir du contrat demandé — Écris le changement attendu en une phrase et ce qui reste. Compare avec diff et fichiers. Un résumé soigné peut omettre une dépendance étrangère ou un nouveau défaut de configuration. Demande pourquoi chaque dépendance, endpoint ou champ persistant est nécessaire. Ne juge pas seulement la taille ; compare comportement et maintenance à la tâche.
- 2. Examiner les frontières de risque — Vérifie si une action locale envoie désormais des données, si une permission s’élargit ou si une reprise répète un effet. Lis l’échec modifié, pas seulement la capture du succès. Pour le stockage, examine les valeurs existantes. Pour l’interface, focus et reprise. Pour le contenu généré, vérifie source et régénération plutôt qu’une modification isolée des octets dérivés.
- 3. Exemple : un bouton Réessayer — Un correctif ajoute Réessayer après sauvegarde échouée. Vérifie si l’échec signifie refus, déconnexion ou résultat inconnu. Tout rejouer peut doubler une opération déjà acceptée. Demande une démonstration ciblée : réponse perdue après acceptation serveur. Le résultat attendu est un rapprochement ou une incertitude explicite, pas une seconde notification verte.
- 4. Rendre le retour actionnable — Indique déclencheur, conséquence et attente avec référence au fichier ou parcours. Distingue défaut bloquant et préférence de style. Garde la revue en lecture seule si un autre agent écrit. Une approbation prouve cette revue, pas une certification de sécurité. Nomme précisément la couverture manquante plutôt que demander des campagnes sans rapport pour supprimer toute incertitude.
- 5. Accepter le bon état de livraison — Vérifie que les contrôles portent sur le commit actuel. Après correction, rejoue les contrôles touchés ; n’attribue pas un ancien succès au nouveau comportement. Note limites et frontière de publication. PR fusionnée, déploiement réussi et parcours public sont distincts. Pour une tâche locale, arrête-toi à la frontière autorisée plutôt que publier pour finir une checklist.

## Critères d’acceptation — Vérifier dans ton produit
- Le diff correspond à la demande.
- Les changements étrangers sont identifiés.
- Les frontières sensibles sont examinées.
- Les échecs ont des contrôles observables.
- Les contrôles portent sur les octets actuels.
- L’approbation ne prétend pas prouver le déploiement.

## 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:b964a90ea77d31cea264a6f1a2dc4a5ff633ac976e2b8c16d3c99b05bab1767c

# Diagnostique une application ratée du guide « Vérifier un changement d’agent avant de l’accepter »

## 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. Partir du contrat demandé — Écris le changement attendu en une phrase et ce qui reste. Compare avec diff et fichiers. Un résumé soigné peut omettre une dépendance étrangère ou un nouveau défaut de configuration. Demande pourquoi chaque dépendance, endpoint ou champ persistant est nécessaire. Ne juge pas seulement la taille ; compare comportement et maintenance à la tâche.
- 2. Examiner les frontières de risque — Vérifie si une action locale envoie désormais des données, si une permission s’élargit ou si une reprise répète un effet. Lis l’échec modifié, pas seulement la capture du succès. Pour le stockage, examine les valeurs existantes. Pour l’interface, focus et reprise. Pour le contenu généré, vérifie source et régénération plutôt qu’une modification isolée des octets dérivés.
- 3. Exemple : un bouton Réessayer — Un correctif ajoute Réessayer après sauvegarde échouée. Vérifie si l’échec signifie refus, déconnexion ou résultat inconnu. Tout rejouer peut doubler une opération déjà acceptée. Demande une démonstration ciblée : réponse perdue après acceptation serveur. Le résultat attendu est un rapprochement ou une incertitude explicite, pas une seconde notification verte.
- 4. Rendre le retour actionnable — Indique déclencheur, conséquence et attente avec référence au fichier ou parcours. Distingue défaut bloquant et préférence de style. Garde la revue en lecture seule si un autre agent écrit. Une approbation prouve cette revue, pas une certification de sécurité. Nomme précisément la couverture manquante plutôt que demander des campagnes sans rapport pour supprimer toute incertitude.
- 5. Accepter le bon état de livraison — Vérifie que les contrôles portent sur le commit actuel. Après correction, rejoue les contrôles touchés ; n’attribue pas un ancien succès au nouveau comportement. Note limites et frontière de publication. PR fusionnée, déploiement réussi et parcours public sont distincts. Pour une tâche locale, arrête-toi à la frontière autorisée plutôt que publier pour finir une checklist.

## 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 diff correspond à la demande.
- Les changements étrangers sont identifiés.
- Les frontières sensibles sont examinées.
- Les échecs ont des contrôles observables.
- Les contrôles portent sur les octets actuels.
- L’approbation ne prétend pas prouver le déploiement.

## 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:b8e27fdb62618f3a05966fc07d4a108561d11db77951c52b76d8628b58cb0f24