Demander un petit changement à un agent sans refonte

# Applique le guide « Demander un petit changement à un agent sans refonte » dans ton agent

## Objectif
Décris un changement observable, ce qui doit rester et la preuve du succès. Fais inspecter les composants existants avant d’en proposer de nouveaux. Lie l’autorisation à ce changement : une correction locale ne permet ni de remplacer la stack, ni de publier des secrets, ni de nettoyer le travail voisin.

## Prérequis
- Inspecte le dépôt, la documentation et les conventions existantes.
- Confirme que le besoin correspond au périmètre du guide : Borne le comportement souhaité, préserve le travail existant et examine le plus petit correctif utile.
- Préserve les décisions correctes déjà en place.

## Étapes du guide
- 1. Nommer la différence de comportement — Au lieu de « améliore le formulaire », demande « après un email invalide, affiche une correction persistante en conservant les autres champs ». Donne un exemple avant/après et nomme l’écran. Liste ce qui reste : règles, données envoyées, traductions et tokens visuels. Ces contraintes guident l’implémentation ; elles ne demandent pas un nouveau dossier d’architecture.
- 2. Inspecter avant d’écrire — Demande composant, appelants et tests concernés. Identifie le travail non committé et ses propriétaires. Un correctif ne doit pas absorber formatage général ou mises à jour de dépendances étrangères. Préfère un composant d’erreur existant s’il convient. Sinon explique le comportement manquant et modifie cette frontière localement plutôt que copier toute la page.
- 3. Exemple : conserver la saisie — Fournis un email fictif invalide et le message attendu. Demande de démontrer que la correction conserve le nom, permet l’envoi correct et ne double pas la soumission. Le livrable est le composant modifié, le contrôle pertinent et une explication courte. Une capture seule ne prouve ni conservation des valeurs ni résultat serveur.
- 4. Maîtriser l’extension du périmètre — Si l’agent trouve un autre défaut, note son effet. Corrige-le ici seulement s’il conditionne le résultat ou est autorisé. Évite de transformer chaque petite demande en nettoyage général. Avant une action destructive ou externe, vérifie l’autorisation réelle. Le prompt n’est pas une barrière d’exécution : outils et environnement déterminent les possibilités effectives.
- 5. Examiner le correctif réel — Lis le diff pour repérer fichiers et effets imprévus, puis exerce le cas initial et un échec voisin. Choisis les tests selon le risque en gardant les contrôles nécessaires à sécurité, stockage et runtime partagé. Sépare implémentation, tests et publication. Ce guide fournit un brief réutilisable, pas une garantie d’obéissance ni l’affirmation que moins de lignes signifie toujours moins de risque.

## Critères d’acceptation — Vérifier dans ton produit
- Un comportement est explicite.
- Le comportement préservé est listé.
- Les composants existants sont inspectés.
- Le travail voisin reste hors du correctif.
- Les échecs importants sont contrôlés.
- Les affirmations correspondent aux preuves.

## 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:8ccc0e70c42a9534bb3588f9b0127743b7fe508156aee372413a9476d4d9d761

# Diagnostique une application ratée du guide « Demander un petit changement à un agent sans refonte »

## 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. Nommer la différence de comportement — Au lieu de « améliore le formulaire », demande « après un email invalide, affiche une correction persistante en conservant les autres champs ». Donne un exemple avant/après et nomme l’écran. Liste ce qui reste : règles, données envoyées, traductions et tokens visuels. Ces contraintes guident l’implémentation ; elles ne demandent pas un nouveau dossier d’architecture.
- 2. Inspecter avant d’écrire — Demande composant, appelants et tests concernés. Identifie le travail non committé et ses propriétaires. Un correctif ne doit pas absorber formatage général ou mises à jour de dépendances étrangères. Préfère un composant d’erreur existant s’il convient. Sinon explique le comportement manquant et modifie cette frontière localement plutôt que copier toute la page.
- 3. Exemple : conserver la saisie — Fournis un email fictif invalide et le message attendu. Demande de démontrer que la correction conserve le nom, permet l’envoi correct et ne double pas la soumission. Le livrable est le composant modifié, le contrôle pertinent et une explication courte. Une capture seule ne prouve ni conservation des valeurs ni résultat serveur.
- 4. Maîtriser l’extension du périmètre — Si l’agent trouve un autre défaut, note son effet. Corrige-le ici seulement s’il conditionne le résultat ou est autorisé. Évite de transformer chaque petite demande en nettoyage général. Avant une action destructive ou externe, vérifie l’autorisation réelle. Le prompt n’est pas une barrière d’exécution : outils et environnement déterminent les possibilités effectives.
- 5. Examiner le correctif réel — Lis le diff pour repérer fichiers et effets imprévus, puis exerce le cas initial et un échec voisin. Choisis les tests selon le risque en gardant les contrôles nécessaires à sécurité, stockage et runtime partagé. Sépare implémentation, tests et publication. Ce guide fournit un brief réutilisable, pas une garantie d’obéissance ni l’affirmation que moins de lignes signifie toujours moins de risque.

## 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
- Un comportement est explicite.
- Le comportement préservé est listé.
- Les composants existants sont inspectés.
- Le travail voisin reste hors du correctif.
- Les échecs importants sont contrôlés.
- Les affirmations correspondent aux preuves.

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