Erreurs de formulaire : expliquer, corriger et réessayer

# Applique le guide « Erreurs de formulaire : expliquer, corriger et réessayer » dans ton agent

## Objectif
Relie chaque valeur refusée à une explication utile, conserve la saisie valide et propose une reprise claire. Relie le résumé aux champs, vérifie le focus au clavier et distingue le refus serveur de la panne réseau. Confirme le succès seulement après acceptation de l’opération par le serveur.

## Prérequis
- Inspecte le dépôt, la documentation et les conventions existantes.
- Confirme que le besoin correspond au périmètre du guide : Construis un parcours de validation avec erreurs de champ et serveur, focus et reprise sûre.
- Préserve les décisions correctes déjà en place.

## Étapes du guide
- 1. 1. Prépare un formulaire simple à tester — Relie chaque valeur refusée à une explication utile, conserve la saisie valide et propose un chemin clair pour renvoyer le formulaire. Une bordure rouge seule ne dit pas quoi corriger.
- 2. 2. Explique l’erreur du champ — Utilise un label natif et un type de champ adapté, avec required ou les contraintes pertinentes. Explique le format avant l’envoi. Commence par valider à l’envoi ; si tu ajoutes une validation à la sortie du champ, évite d’interrompre une valeur inachevée à chaque frappe.
- 3. 3. Rends les erreurs accessibles — Après un envoi refusé, affiche un résumé au-dessus du formulaire avec des liens vers les champs concernés. Choisis et teste une stratégie : focus sur ce résumé, rendu focalisable par programme, pour plusieurs erreurs ; ou sur le premier champ invalide pour un formulaire court. Ne déplace pas le focus pendant la saisie normale.
- 4. 4. Traite le refus serveur et les résultats incertains — Le serveur doit valider indépendamment. Relie un refus propre à un champ à ce champ ; présente une panne du service au niveau du formulaire avec une action de reprise. Ne marque pas tous les champs invalides parce que le réseau est coupé. Conserve les valeurs non sensibles et explique toute valeur sensible à ressaisir.
- 5. 5. Exécute le scénario de reprise — Dans l’environnement de test, envoie un formulaire vide, puis un e-mail mal formé, puis une valeur apparemment valide refusée par le serveur. Suis les liens du résumé au clavier, corrige une erreur et vérifie que les autres valeurs restent présentes. Simule une panne, rétablis le service et termine un enregistrement réussi.
- 6. Vérifie la reprise après une deuxième erreur — Saisis un nom valide et un e-mail incorrect, envoie puis corrige seulement l’e-mail. Si un autre champ est refusé, son message doit le nommer et expliquer la correction. Suis le lien d’erreur au clavier et vérifie que le nom valide reste présent.

## Critères d’acceptation — Preuves à conserver
- L’erreur explique une correction et reste associée au champ.
- La reprise au clavier conserve les valeurs valides et atteint un succès confirmé.
- Refus serveur, panne et enregistrement incertain ont des issues distinctes.
- Chaque lien du résumé déplace le focus clavier vers le champ correspondant.
- Un champ corrigé perd son erreur périmée sans effacer les autres valeurs.
- L’envoi en cours empêche les doublons et expose un statut lisible.

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

# Diagnostique une application ratée du guide « Erreurs de formulaire : expliquer, corriger et réessayer »

## 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. 1. Prépare un formulaire simple à tester — Relie chaque valeur refusée à une explication utile, conserve la saisie valide et propose un chemin clair pour renvoyer le formulaire. Une bordure rouge seule ne dit pas quoi corriger.
- 2. 2. Explique l’erreur du champ — Utilise un label natif et un type de champ adapté, avec required ou les contraintes pertinentes. Explique le format avant l’envoi. Commence par valider à l’envoi ; si tu ajoutes une validation à la sortie du champ, évite d’interrompre une valeur inachevée à chaque frappe.
- 3. 3. Rends les erreurs accessibles — Après un envoi refusé, affiche un résumé au-dessus du formulaire avec des liens vers les champs concernés. Choisis et teste une stratégie : focus sur ce résumé, rendu focalisable par programme, pour plusieurs erreurs ; ou sur le premier champ invalide pour un formulaire court. Ne déplace pas le focus pendant la saisie normale.
- 4. 4. Traite le refus serveur et les résultats incertains — Le serveur doit valider indépendamment. Relie un refus propre à un champ à ce champ ; présente une panne du service au niveau du formulaire avec une action de reprise. Ne marque pas tous les champs invalides parce que le réseau est coupé. Conserve les valeurs non sensibles et explique toute valeur sensible à ressaisir.
- 5. 5. Exécute le scénario de reprise — Dans l’environnement de test, envoie un formulaire vide, puis un e-mail mal formé, puis une valeur apparemment valide refusée par le serveur. Suis les liens du résumé au clavier, corrige une erreur et vérifie que les autres valeurs restent présentes. Simule une panne, rétablis le service et termine un enregistrement réussi.
- 6. Vérifie la reprise après une deuxième erreur — Saisis un nom valide et un e-mail incorrect, envoie puis corrige seulement l’e-mail. Si un autre champ est refusé, son message doit le nommer et expliquer la correction. Suis le lien d’erreur au clavier et vérifie que le nom valide reste présent.

## 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 — Preuves à conserver
- L’erreur explique une correction et reste associée au champ.
- La reprise au clavier conserve les valeurs valides et atteint un succès confirmé.
- Refus serveur, panne et enregistrement incertain ont des issues distinctes.
- Chaque lien du résumé déplace le focus clavier vers le champ correspondant.
- Un champ corrigé perd son erreur périmée sans effacer les autres valeurs.
- L’envoi en cours empêche les doublons et expose un statut lisible.

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