Chargement, vide ou panne : proposer la bonne suite

# Applique le guide « Chargement, vide ou panne : proposer la bonne suite » dans ton agent

## Objectif
Traite séparément chargement, compte vide, filtres sans résultat et panne. Préserve le contexte et propose une action utile. Un squelette décrit une attente sans prouver que des données existent. Réessayer conserve requête et filtres plutôt que de réinitialiser la tâche.

## Prérequis
- Inspecte le dépôt, la documentation et les conventions existantes.
- Confirme que le besoin correspond au périmètre du guide : Distingue attente, premier usage vide, aucun résultat et panne du service.
- Préserve les décisions correctes déjà en place.

## Étapes du guide
- 1. Cartographier les états — Pour une liste de projets, distingue non demandé, attente, rempli, vide et échec. Ajoute l’actualisation avec anciennes données si nécessaire. Associe chaque état à une réponse réelle. Ne transforme pas chaque panne en tableau vide. Aucun projet est un résultat valide ; une requête échouée laisse le contenu inconnu. Un accès refusé est encore différent.
- 2. Choisir le retour d’attente — Utilise un libellé d’attente si la durée est inconnue. Un squelette réserve une forme connue ; un pourcentage exige une quantité et un total mesurables. N’invente pas de taux d’avancement. Garde les commandes indépendantes utilisables. Identifie les anciens résultats pendant l’actualisation pour éviter la confusion. Ne répète pas les annonces à chaque image d’animation.
- 3. Exemple : trois listes vides — Un nouvel espace propose Créer un projet. Un filtre sans résultat montre ses critères et Effacer les filtres. Une panne propose Réessayer en conservant la requête. Ne propose pas les trois actions indistinctement. Si la création est interdite, explique la limite et le contact disponible sans prétendre envoyer automatiquement une demande.
- 4. Écarter les réponses périmées — Quand une requête remplace la première, annule ou ignore l’ancienne réponse. Son succès tardif ne remplace ni panne ni résultats actuels. Aligne requête et données affichées. L’annulation navigateur n’annule pas le travail serveur. Pour une liste elle évite un rendu périmé ; une écriture demande un contrat de reprise distinct. Évite les tentatives automatiques infinies.
- 5. Vérifier chaque action suivante — Exerce une réponse par état et deux réponses dans le désordre. Vérifie que chaque action change la bonne condition. Si Réessayer disparaît avec le focus, prévois une destination cohérente. Garde le statut compréhensible sans mouvement et à 320 px. Les rôles DOM ne prouvent pas les annonces réelles d’un lecteur d’écran ; distingue cette qualification.

## Critères d’acceptation — Vérifier dans ton produit
- L’attente n’est pas un vide.
- Vide initial et filtré diffèrent.
- La panne conserve la saisie.
- La reprise a un effet borné.
- Les données tardives ne remplacent pas les actuelles.
- Le statut reste sans mouvement.

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

# Diagnostique une application ratée du guide « Chargement, vide ou panne : proposer la bonne suite »

## 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. Cartographier les états — Pour une liste de projets, distingue non demandé, attente, rempli, vide et échec. Ajoute l’actualisation avec anciennes données si nécessaire. Associe chaque état à une réponse réelle. Ne transforme pas chaque panne en tableau vide. Aucun projet est un résultat valide ; une requête échouée laisse le contenu inconnu. Un accès refusé est encore différent.
- 2. Choisir le retour d’attente — Utilise un libellé d’attente si la durée est inconnue. Un squelette réserve une forme connue ; un pourcentage exige une quantité et un total mesurables. N’invente pas de taux d’avancement. Garde les commandes indépendantes utilisables. Identifie les anciens résultats pendant l’actualisation pour éviter la confusion. Ne répète pas les annonces à chaque image d’animation.
- 3. Exemple : trois listes vides — Un nouvel espace propose Créer un projet. Un filtre sans résultat montre ses critères et Effacer les filtres. Une panne propose Réessayer en conservant la requête. Ne propose pas les trois actions indistinctement. Si la création est interdite, explique la limite et le contact disponible sans prétendre envoyer automatiquement une demande.
- 4. Écarter les réponses périmées — Quand une requête remplace la première, annule ou ignore l’ancienne réponse. Son succès tardif ne remplace ni panne ni résultats actuels. Aligne requête et données affichées. L’annulation navigateur n’annule pas le travail serveur. Pour une liste elle évite un rendu périmé ; une écriture demande un contrat de reprise distinct. Évite les tentatives automatiques infinies.
- 5. Vérifier chaque action suivante — Exerce une réponse par état et deux réponses dans le désordre. Vérifie que chaque action change la bonne condition. Si Réessayer disparaît avec le focus, prévois une destination cohérente. Garde le statut compréhensible sans mouvement et à 320 px. Les rôles DOM ne prouvent pas les annonces réelles d’un lecteur d’écran ; distingue cette qualification.

## 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
- L’attente n’est pas un vide.
- Vide initial et filtré diffèrent.
- La panne conserve la saisie.
- La reprise a un effet borné.
- Les données tardives ne remplacent pas les actuelles.
- Le statut reste sans mouvement.

## 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:9c55cf643a7600bc34ba56ccd49de1eda8ee9a0fd719fd92266219392a815db3