Publier un changement et vérifier ce que les utilisateurs reçoivent

# Applique le guide « Publier un changement et vérifier ce que les utilisateurs reçoivent » dans ton agent

## Objectif
Identifie le candidat exact, valide son comportement important et publie dans le périmètre autorisé. Après déploiement, vérifie la version servie et le parcours public modifié. Prépare le déploiement immuable précédent et les limites de compatibilité des données avant de parler d’un plan de retour arrière.

## Prérequis
- Inspecte le dépôt, la documentation et les conventions existantes.
- Confirme que le besoin correspond au périmètre du guide : Sépare tests locaux, CI, Preview, Production et décision de retour arrière maîtrisée.
- Préserve les décisions correctes déjà en place.

## Étapes du guide
- 1. Identifier le candidat — Note dépôt, branche, commit et environnement cible. Vérifie fichiers étrangers ou privés avant commit. Un build local peut réussir tandis qu’un autre commit est déployé. Choisis selon le risque modifié : comportement, échec important et intégrité. Respecte les contrôles du projet sans rejouer des matrices étrangères après un simple ajustement documentaire.
- 2. Comprendre les environnements — La Preview valide un candidat avec son accès et sa configuration. La Production peut différer en variables, domaines et données. Confirme le projet cible plutôt que choisir un homonyme. Ne copie jamais de secrets dans le rapport pour prouver la configuration. Indique présence ou résultat fonctionnel borné. Une Preview protégée inaccessible reste non vérifiée même si son build réussit.
- 3. Exemple : publier un guide — Pour un guide bilingue, vérifie routes, liens canoniques et instruction copiée. Après fusion et déploiement, lis l’identité publique et ouvre le guide depuis son hub. Une réponse de santé ne prouve que ses contrôles. Elle ne prouve pas toute interaction ni une migration. Vérifie séparément l’action publique modifiée sans écriture destructive réelle.
- 4. Préparer les limites du retour arrière — Note le déploiement immuable précédent et la réaffectation prise en charge. Vérifie sa compatibilité avec données et migrations. Revenir au code ancien n’annule pas une migration destructive et ne récupère pas les données supprimées. Exécute le retour arrière avec autorisation et déclencheur défini. Préfère un déploiement existant vérifié si possible ; reconstruire un ancien commit peut changer dépendances ou configuration.
- 5. Rapporter la chaîne de preuves — Sépare contrôle local, commit distant, CI, déploiement et vérification publique. Si une étape bloque, nomme-la et donne l’action suivante plutôt que déclarer toute la livraison terminée. Ce parcours est un guide indépendant du fournisseur, pas un script ni une permission de publier. Store, utilité humaine et performance terrain sont des preuves distinctes.

## Critères d’acceptation — Vérifier dans ton produit
- Le commit candidat est connu.
- L’environnement cible est vérifié.
- Les contrôles pertinents sont liés.
- L’identité publique correspond au déploiement.
- Le parcours modifié fonctionne.
- Les limites de données du retour arrière sont explicites.

## 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:36aae5144fe7f56176cb0f2ad1ce4b7a660b409011d41ce338c7660dc87cc92e

# Diagnostique une application ratée du guide « Publier un changement et vérifier ce que les utilisateurs reçoivent »

## 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. Identifier le candidat — Note dépôt, branche, commit et environnement cible. Vérifie fichiers étrangers ou privés avant commit. Un build local peut réussir tandis qu’un autre commit est déployé. Choisis selon le risque modifié : comportement, échec important et intégrité. Respecte les contrôles du projet sans rejouer des matrices étrangères après un simple ajustement documentaire.
- 2. Comprendre les environnements — La Preview valide un candidat avec son accès et sa configuration. La Production peut différer en variables, domaines et données. Confirme le projet cible plutôt que choisir un homonyme. Ne copie jamais de secrets dans le rapport pour prouver la configuration. Indique présence ou résultat fonctionnel borné. Une Preview protégée inaccessible reste non vérifiée même si son build réussit.
- 3. Exemple : publier un guide — Pour un guide bilingue, vérifie routes, liens canoniques et instruction copiée. Après fusion et déploiement, lis l’identité publique et ouvre le guide depuis son hub. Une réponse de santé ne prouve que ses contrôles. Elle ne prouve pas toute interaction ni une migration. Vérifie séparément l’action publique modifiée sans écriture destructive réelle.
- 4. Préparer les limites du retour arrière — Note le déploiement immuable précédent et la réaffectation prise en charge. Vérifie sa compatibilité avec données et migrations. Revenir au code ancien n’annule pas une migration destructive et ne récupère pas les données supprimées. Exécute le retour arrière avec autorisation et déclencheur défini. Préfère un déploiement existant vérifié si possible ; reconstruire un ancien commit peut changer dépendances ou configuration.
- 5. Rapporter la chaîne de preuves — Sépare contrôle local, commit distant, CI, déploiement et vérification publique. Si une étape bloque, nomme-la et donne l’action suivante plutôt que déclarer toute la livraison terminée. Ce parcours est un guide indépendant du fournisseur, pas un script ni une permission de publier. Store, utilité humaine et performance terrain sont des preuves distinctes.

## 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 commit candidat est connu.
- L’environnement cible est vérifié.
- Les contrôles pertinents sont liés.
- L’identité publique correspond au déploiement.
- Le parcours modifié fonctionne.
- Les limites de données du retour arrière sont explicites.

## 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:603ff0ade07f09b3fad10479d39157aaa5522b349bbd2ce314036f28da64ba95