Implémenter correctement
Construis Dialogue d’alerte sans casser son comportement
# Implémenter Dialogue d’alerte dans ton agent ## Objectif Implémente Dialogue d’alerte pour ce comportement vérifié : Un dialogue modal qui interrompt une action lourde de conséquences et exige une confirmation ou une annulation explicite. ## Prérequis - Inspecte d’abord le dépôt, le design system et les tests existants. - Préserve les changements sans rapport et borne les fichiers modifiés. - Confirme que Dialogue d’alerte répond au besoin avant de coder. ## Comportement requis - Tant que la surface est modale, le focus clavier y reste jusqu’à sa fermeture. - La surface reste ouverte jusqu’à ce que l’utilisateur confirme ou annule volontairement l’action sensible. ## États à couvrir - Décision fermée avec espace intact - Décision initiale de suppression ouverte - Décision fermée après annulation - Décision de suppression rouverte après annulation - Suppression en cours d’envoi - Décision fermée après confirmation - Décision de suppression rouverte après confirmation ## Accessibilité - Rôle ARIA : alertdialog[aria-modal=true] - Le contrôle principal ou la région nommée pour Dialogue d’alerte possède un nom accessible stable issu d’un texte visible ou d’un libellé programmatique explicite ; le placeholder et l’infobulle ne servent pas de nom. - Le focus initial va sur l’action utile la moins destructive, sauf s’il est plus sûr de lire d’abord de longues conséquences. - Seule une décision explicite ou une annulation sûre documentée ferme l’alerte ; aucun délai ni appui extérieur accidentel ne la ferme. - Le rôle dialogue d’alerte, le titre, la conséquence et les noms des deux actions sont annoncés à l’entrée du focus. - Tab circule seulement entre les contrôles de décision - Échap annule lorsque cela reste sûr - Entrée active uniquement l’action qui a le focus ## Quand ne pas utiliser - L’action peut être annulée sans risque - Le message rapporte seulement un résultat sans demander de décision ## Critères d’acceptation - Le message nomme la conséquence exacte - Confirmer et Annuler sont explicites et visuellement distincts - Le focus initial évite une confirmation destructive accidentelle - L’alerte ne peut pas disparaître avant une décision ## 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.
- @radix-ui/react-alert-dialog
- Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
- Le besoin est relié au comportement canonique avant toute décision technique.
- Les états, l’accessibilité et les non-objectifs empêchent une implémentation seulement visuelle.
- Les critères d’acceptation et le format de sortie rendent la vérification observable.
À essayer ensuite
Vérifie Dialogue d’alerte sur un parcours réel
# Vérifier Dialogue d’alerte après l’implémentation ## Objectif Audite l’implémentation de Dialogue d’alerte au regard de son comportement, de ses états et de ses exigences d’accessibilité sans la modifier automatiquement. ## Contrôles - Rejoue le plus petit parcours représentatif. - Contrôle le clavier, le focus, le nom accessible et les annonces. - Relie chaque écart à un critère d’acceptation précis. ## 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:7475b7c71a543deb099207caaea83ccfd2229a4751457bf74dffd871f7227cb1