Confirmer une action sans double envoi

# Applique le guide « Confirmer une action sans double envoi » dans ton agent

## Objectif
Relie le retour à l’opération : démarrée, acceptée, terminée, refusée ou résultat inconnu. Empêche les doublons accidentels sans fermer la reprise. Un Toast complète un résultat durable, sans devenir la seule preuve d’une sauvegarde importante ni le seul lieu de correction d’une erreur.

## Prérequis
- Inspecte le dépôt, la documentation et les conventions existantes.
- Confirme que le besoin correspond au périmètre du guide : Choisis statut local, Toast ou page de résultat et reprends les écritures lentes ou incertaines.
- Préserve les décisions correctes déjà en place.

## Étapes du guide
- 1. Définir la preuve de fin — Pour un export, un identifiant signifie en attente, pas fichier prêt. Pour une sauvegarde, recevoir la requête peut précéder la persistance. Nomme la preuve avant d’annoncer la fin. Garde le statut près de l’action. Utilise une page pour une référence durable et la suite. Un Toast est un complément qu’on peut manquer sans danger, pas l’unique trace d’un résultat important.
- 2. Empêcher le travail doublonné — Un bouton en attente réduit les clics sans garantir la déduplication serveur. Définis comment l’application identifie une même opération et consulte son résultat avant d’ajouter des reprises automatiques. Considère plusieurs onglets et une connexion perdue après acceptation. Garde les champs indépendants utilisables quand c’est sûr. Explique l’attente au lieu de faire disparaître l’action.
- 3. Exemple : préparer un rapport — Affiche Demande acceptée avec la référence du service. Annonce Rapport prêt seulement quand le fichier existe. Garde son lien dans la liste après fermeture du retour temporaire. Après réponse perdue, affiche Résultat non confirmé et consulte cette demande avant d’en créer une autre. Sans consultation possible, annonce l’incertitude plutôt que proposer une écriture potentiellement doublonnée.
- 4. Garder la reprise accessible — Les erreurs de validation préservent la saisie et indiquent les corrections. Les pannes conservent le contexte. Une connexion expirée ramène à la tâche sans affirmer à tort l’échec certain de l’opération. Annonce les mises à jour sans déplacement inutile du focus. Évite les doublons entre focus et régions dynamiques. L’action de reprise reste disponible après disparition de la notification.
- 5. Tester l’incertitude — Exerce acceptation lente, refus et réponse perdue après acceptation. Compte les opérations réelles plutôt que les clics. Vérifie que la reprise respecte le contrat sans transformer l’incertitude en succès. Ce n’est pas une implémentation de paiement ou de système distribué. Confirme déduplication et rapprochement avec le responsable du service avant une opération irréversible ou coûteuse.

## Critères d’acceptation — Vérifier dans ton produit
- Acceptation et fin diffèrent.
- Les clics répétés ne doublonnent pas.
- L’inconnu reste explicite.
- Les résultats importants restent lisibles.
- L’échec garde la saisie utile.
- La reprise suit le contrat réel.

## 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:1e46cf81f1b157889f0000e9e6af800660d2414d578221c9f6bc17126bcf23eb

# Diagnostique une application ratée du guide « Confirmer une action sans double envoi »

## 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. Définir la preuve de fin — Pour un export, un identifiant signifie en attente, pas fichier prêt. Pour une sauvegarde, recevoir la requête peut précéder la persistance. Nomme la preuve avant d’annoncer la fin. Garde le statut près de l’action. Utilise une page pour une référence durable et la suite. Un Toast est un complément qu’on peut manquer sans danger, pas l’unique trace d’un résultat important.
- 2. Empêcher le travail doublonné — Un bouton en attente réduit les clics sans garantir la déduplication serveur. Définis comment l’application identifie une même opération et consulte son résultat avant d’ajouter des reprises automatiques. Considère plusieurs onglets et une connexion perdue après acceptation. Garde les champs indépendants utilisables quand c’est sûr. Explique l’attente au lieu de faire disparaître l’action.
- 3. Exemple : préparer un rapport — Affiche Demande acceptée avec la référence du service. Annonce Rapport prêt seulement quand le fichier existe. Garde son lien dans la liste après fermeture du retour temporaire. Après réponse perdue, affiche Résultat non confirmé et consulte cette demande avant d’en créer une autre. Sans consultation possible, annonce l’incertitude plutôt que proposer une écriture potentiellement doublonnée.
- 4. Garder la reprise accessible — Les erreurs de validation préservent la saisie et indiquent les corrections. Les pannes conservent le contexte. Une connexion expirée ramène à la tâche sans affirmer à tort l’échec certain de l’opération. Annonce les mises à jour sans déplacement inutile du focus. Évite les doublons entre focus et régions dynamiques. L’action de reprise reste disponible après disparition de la notification.
- 5. Tester l’incertitude — Exerce acceptation lente, refus et réponse perdue après acceptation. Compte les opérations réelles plutôt que les clics. Vérifie que la reprise respecte le contrat sans transformer l’incertitude en succès. Ce n’est pas une implémentation de paiement ou de système distribué. Confirme déduplication et rapprochement avec le responsable du service avant une opération irréversible ou coûteuse.

## 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
- Acceptation et fin diffèrent.
- Les clics répétés ne doublonnent pas.
- L’inconnu reste explicite.
- Les résultats importants restent lisibles.
- L’échec garde la saisie utile.
- La reprise suit le contrat réel.

## 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:07a46487dc494f3bae6f93917601f8e7529bdfcda3cb10a73daa984f98590877