Avec ton accord, Google Analytics mesure l'usage du site pour nous aider à l'améliorer. Ton choix est mémorisé sur cet appareil et reste modifiable via « Cookies » en pied de page.
Prompts éditoriaux · statiques · vérifiés
Agis avec un prompt fiable
Choisis une intention et un domaine, vérifie les garde-fous, puis copie exactement l’instruction publiée. Rien n’est généré, envoyé ou exécuté par SkillCodex.
Chargement de la galerie de prompts…
86 prompts
Page 1 sur 4
UI·Créer·Infobulle
Construis Infobulle sans casser son comportement
# Implémenter Infobulle dans ton agent
## Objectif
Implémente Infobulle pour ce comportement vérifié : Une courte aide non interactive qui apparaît au survol ou lorsque le contrôle reçoit le focus clavier.
## 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 qu’Infobulle répond au besoin avant de coder.
## Comportement requis
- Le survol ou le focus clavier révèle l’information après un court délai.
- Échap ferme l’infobulle sans déplacer le focus hors de son déclencheur.
## États à couvrir
- Infobulle masquée
- Infobulle visible
## Accessibilité
- Rôle ARIA : tooltip
- Le contrôle principal ou la région nommée pour Infobulle possède un nom accessible stable issu d’un texte visible ou d’un libellé programmatique explicite.
- Le focus reste sur le déclencheur ; l’infobulle n’entre jamais dans l’ordre de tabulation.
- Elle se ferme avec Échap et lorsque le focus et le pointeur quittent le déclencheur et la surface.
- Le déclencheur référence la description de l’infobulle afin que la technologie d’assistance la lise sans déplacer le focus.
- Tab place le focus sur le déclencheur
- Échap ferme l’infobulle visible
## Quand ne pas utiliser
- L’information est indispensable pour terminer la tâche
- Le contenu nécessite des liens, boutons ou champs
## Critères d’acceptation
- La même aide est disponible au survol et au focus clavier
- L’infobulle ne contient aucun contrôle interactif
- Échap la ferme sans déplacer le focus
- Les utilisateurs tactiles ne perdent aucune information essentielle
## 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-tooltip
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 Infobulle sur un parcours réel
# Vérifier Infobulle après l’implémentation
## Objectif
Audite l’implémentation d’Infobulle 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.
# Déboguer Infobulle dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés d’Infobulle.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- La même aide est disponible au survol et au focus clavier
- L’infobulle ne contient aucun contrôle interactif
- Échap la ferme sans déplacer le focus
- Les utilisateurs tactiles ne perdent aucune information essentielle
## 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-tooltip
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction d’Infobulle
# Empêcher la régression d’Infobulle
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Infobulle aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
Construis Fenêtre contextuelle sans casser son comportement
# Implémenter Fenêtre contextuelle dans ton agent
## Objectif
Implémente Fenêtre contextuelle pour ce comportement vérifié : Une petite surface contextuelle ouverte volontairement pour afficher du contenu ou des contrôles sans rendre toute la page modale.
## 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 Fenêtre contextuelle répond au besoin avant de coder.
## Comportement requis
- Activer le déclencheur ouvre la surface, puis peut la refermer au second appui.
- Un appui hors de la surface non critique la ferme sans valider d’action.
- Échap ferme la surface temporaire et renvoie le focus vers un contrôle pertinent.
## États à couvrir
- Popover fermé
- Popover ouvert
## Accessibilité
- Rôle ARIA : dialog
- Le contrôle principal ou la région nommée pour Fenêtre contextuelle 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 reste sur le déclencheur pour un contenu simple ou va de façon prévisible vers le premier contrôle pertinent.
- Échap, le contrôle de fermeture ou un appui extérieur sans risque la ferme et restaure le focus sur le déclencheur.
- Le déclencheur expose l’état développé et référence la surface ; un dialogue nommé est annoncé lorsque ce pattern est utilisé.
- Entrée ou Espace ouvre depuis le déclencheur
- Tab parcourt le contenu interactif
- Échap ferme la fenêtre contextuelle
## Quand ne pas utiliser
- La tâche nécessite un flux large ou modal
- La surface n’est qu’une courte aide passive
## Critères d’acceptation
- Le panneau s’ouvre seulement après une activation volontaire
- Le contenu interactif suit un ordre de focus logique
- Échap et le contrôle de fermeture restaurent le focus
- L’arrière-plan reste utilisable car le panneau n’est pas modal
## 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-popover
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 Fenêtre contextuelle sur un parcours réel
# Vérifier Fenêtre contextuelle après l’implémentation
## Objectif
Audite l’implémentation de Fenêtre contextuelle 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.
Trouve et corrige le défaut de Fenêtre contextuelle
# Déboguer Fenêtre contextuelle dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Fenêtre contextuelle.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- Le panneau s’ouvre seulement après une activation volontaire
- Le contenu interactif suit un ordre de focus logique
- Échap et le contrôle de fermeture restaurent le focus
- L’arrière-plan reste utilisable car le panneau n’est pas modal
## 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-popover
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Fenêtre contextuelle
# Empêcher la régression de Fenêtre contextuelle
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Fenêtre contextuelle aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
Construis Menu d’actions déroulant sans casser son comportement
# Implémenter Menu d’actions déroulant dans ton agent
## Objectif
Implémente Menu d’actions déroulant pour ce comportement vérifié : Une liste compacte d’actions qui s’ouvre depuis un bouton et suit la navigation clavier d’un menu.
## 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 Menu d’actions déroulant répond au besoin avant de coder.
## Comportement requis
- Activer le déclencheur ouvre la surface, puis peut la refermer au second appui.
- Les flèches parcourent les actions, puis Entrée ou Espace en active une.
- Échap ferme la surface temporaire et renvoie le focus vers un contrôle pertinent.
## États à couvrir
- Menu fermé
- Menu ouvert
## Accessibilité
- Rôle ARIA : menu > menuitem
- Le contrôle principal ou la région nommée pour Menu d’actions déroulant 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.
- L’ouverture place le focus du menu sur un élément disponible ; la fermeture le restaure sur le déclencheur.
- Sélectionner une action, appuyer sur Échap ou cliquer sans risque à l’extérieur ferme le menu.
- Le déclencheur indique qu’il ouvre un menu, et les noms, états désactivés et états cochés des éléments sont annoncés.
- Entrée, Espace ou Flèche bas ouvre le menu
- Les flèches parcourent les éléments
- Entrée ou Espace active l’élément courant
- Échap ferme le menu
## Quand ne pas utiliser
- L’utilisateur sélectionne la valeur d’un champ
- Le contenu contient des paragraphes explicatifs ou un formulaire
## Critères d’acceptation
- Chaque élément est une action et non une valeur de formulaire
- La navigation par flèches suit le pattern menu
- Les éléments désactivés exposent leur état et ne peuvent pas être activés
- La fermeture restaure le focus sur le déclencheur
## 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-dropdown-menu
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 Menu d’actions déroulant sur un parcours réel
# Vérifier Menu d’actions déroulant après l’implémentation
## Objectif
Audite l’implémentation de Menu d’actions déroulant 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.
Trouve et corrige le défaut de Menu d’actions déroulant
# Déboguer Menu d’actions déroulant dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Menu d’actions déroulant.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- Chaque élément est une action et non une valeur de formulaire
- La navigation par flèches suit le pattern menu
- Les éléments désactivés exposent leur état et ne peuvent pas être activés
- La fermeture restaure le focus sur le déclencheur
## 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-dropdown-menu
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Menu d’actions déroulant
# Empêcher la régression de Menu d’actions déroulant
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Menu d’actions déroulant aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
Construis Boîte de dialogue modale sans casser son comportement
# Implémenter Boîte de dialogue modale dans ton agent
## Objectif
Implémente Boîte de dialogue modale pour ce comportement vérifié : Une surface ciblée pour une tâche délimitée qui rend le reste de la page temporairement inactif.
## 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 Boîte de dialogue modale répond au besoin avant de coder.
## Comportement requis
- Tant que la surface est modale, le focus clavier y reste jusqu’à sa fermeture.
- Échap ferme la surface temporaire et renvoie le focus vers un contrôle pertinent.
## États à couvrir
- Dialogue fermé
- Dialogue ouvert
## Accessibilité
- Rôle ARIA : dialog[aria-modal=true]
- Le contrôle principal ou la région nommée pour Boîte de dialogue modale 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.
- L’ouverture déplace le focus à l’intérieur, Tab n’atteint pas la page inerte et la fermeture restaure le focus sur le déclencheur logique.
- Annuler, le contrôle de fermeture nommé et Échap ferment sans enregistrer ; l’appui extérieur n’est permis que si une perte accidentelle est sans conséquence.
- La technologie d’assistance reçoit le rôle dialogue, le titre accessible, la description et les mises à jour de validation.
- Tab et Maj+Tab circulent dans le dialogue
- Échap ferme lorsque l’annulation est sûre
- Entrée envoie seulement depuis le contrôle prévu
## Quand ne pas utiliser
- Le parcours est assez long pour mériter sa propre page
- L’information peut rester non modale et contextuelle
## Critères d’acceptation
- La page derrière le dialogue est inerte
- Le dialogue possède un titre et une description accessibles
- Le focus est contenu puis restauré
- Chaque fermeture traite le travail non enregistré sans risque
## 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-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 Boîte de dialogue modale sur un parcours réel
# Vérifier Boîte de dialogue modale après l’implémentation
## Objectif
Audite l’implémentation de Boîte de dialogue modale 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.
Trouve et corrige le défaut de Boîte de dialogue modale
# Déboguer Boîte de dialogue modale dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Boîte de dialogue modale.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- La page derrière le dialogue est inerte
- Le dialogue possède un titre et une description accessibles
- Le focus est contenu puis restauré
- Chaque fermeture traite le travail non enregistré sans risque
## 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-dialog
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Boîte de dialogue modale
# Empêcher la régression de Boîte de dialogue modale
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Boîte de dialogue modale aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
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.
# Déboguer Dialogue d’alerte dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Dialogue d’alerte.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- 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 symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Dialogue d’alerte
# Empêcher la régression de Dialogue d’alerte
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Dialogue d’alerte aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
Construis Visionneuse modale sans casser son comportement
# Implémenter Visionneuse modale dans ton agent
## Objectif
Implémente Visionneuse modale pour ce comportement vérifié : Une visionneuse modale qui agrandit un média et peut permettre de parcourir une collection associée.
## 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 Visionneuse modale répond au besoin avant de coder.
## Comportement requis
- Tant que la surface est modale, le focus clavier y reste jusqu’à sa fermeture.
- Les contrôles précédent et suivant parcourent la collection sans quitter la visionneuse.
- Échap ferme la surface temporaire et renvoie le focus vers un contrôle pertinent.
## États à couvrir
- Vue galerie
- Média agrandi
## Accessibilité
- Rôle ARIA : dialog[aria-modal=true]
- Le contrôle principal ou la région nommée pour Visionneuse modale 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.
- L’ouverture place le focus sur la visionneuse ou le contrôle fermer, le contient, puis le rend à la miniature d’origine.
- Le contrôle fermer nommé et Échap ferment toujours ; l’appui extérieur est facultatif et jamais le seul moyen.
- Le titre de la visionneuse, la position du média, la légende, le texte alternatif et les échecs de chargement sont disponibles pour la technologie d’assistance.
- Tab atteint les contrôles de la visionneuse
- Gauche et Droite parcourent les médias lorsque prévu
- Échap ferme la visionneuse
## Quand ne pas utiliser
- Les médias doivent être comparés côte à côte
- Le contenu est un formulaire ou une décision sensible
## Critères d’acceptation
- Le média sélectionné et sa légende sont clairement identifiés
- Le clavier atteint la navigation et la fermeture
- Le focus revient à la miniature d’origine
- Les erreurs de chargement et de média ont une alternative textuelle
## 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-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 Visionneuse modale sur un parcours réel
# Vérifier Visionneuse modale après l’implémentation
## Objectif
Audite l’implémentation de Visionneuse modale 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.
# Déboguer Visionneuse modale dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Visionneuse modale.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- Le média sélectionné et sa légende sont clairement identifiés
- Le clavier atteint la navigation et la fermeture
- Le focus revient à la miniature d’origine
- Les erreurs de chargement et de média ont une alternative textuelle
## 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-dialog
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Visionneuse modale
# Empêcher la régression de Visionneuse modale
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Visionneuse modale aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
Construis Volet latéral sans casser son comportement
# Implémenter Volet latéral dans ton agent
## Objectif
Implémente Volet latéral pour ce comportement vérifié : Un panneau temporaire qui glisse depuis un bord de la fenêtre, recouvre la page et se ferme lorsque sa tâche ciblée est terminée.
## 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 Volet latéral répond au besoin avant de coder.
## Comportement requis
- Le panneau temporaire recouvre la page et arrive depuis un bord défini de la fenêtre.
- Tant que la surface est modale, le focus clavier y reste jusqu’à sa fermeture.
- Échap ferme la surface temporaire et renvoie le focus vers un contrôle pertinent.
## États à couvrir
- Volet fermé
- Volet ouvert
## Accessibilité
- Rôle ARIA : dialog[aria-modal=true]
- Le contrôle principal ou la région nommée pour Volet latéral 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.
- L’ouverture place le focus sur le titre ou le premier champ utile, le contient, puis le rend au déclencheur.
- Le contrôle fermer nommé et Échap fonctionnent toujours ; la fermeture par le voile est désactivée si elle peut perdre des changements.
- Le titre accessible et la description facultative identifient la tâche du volet à l’entrée du focus.
- Tab reste dans le volet pendant l’ouverture
- Échap ferme sans appliquer de changement involontaire
- Entrée active uniquement le contrôle focalisé
## Quand ne pas utiliser
- La navigation doit rester visible entre les pages
- La tâche nécessite toute la fenêtre ou plusieurs étapes
## Critères d’acceptation
- Le panneau est temporaire et recouvre la page
- Son bord et son comportement modal sont explicites
- Le focus est contenu puis restauré
- Dans la mise en page étroite, toutes les actions restent accessibles
## 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-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 Volet latéral sur un parcours réel
# Vérifier Volet latéral après l’implémentation
## Objectif
Audite l’implémentation de Volet latéral 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.
# Déboguer Volet latéral dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Volet latéral.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- Le panneau est temporaire et recouvre la page
- Son bord et son comportement modal sont explicites
- Le focus est contenu puis restauré
- Dans la mise en page étroite, toutes les actions restent accessibles
## 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-dialog
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Volet latéral
# Empêcher la régression de Volet latéral
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Volet latéral aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
Construis Feuille basse sans casser son comportement
# Implémenter Feuille basse dans ton agent
## Objectif
Implémente Feuille basse pour ce comportement vérifié : Une surface pensée pour mobile, attachée au bord inférieur, qui peut s’ouvrir à des hauteurs stables et accepter le glissement.
## 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 Feuille basse répond au besoin avant de coder.
## Comportement requis
- Le glissement tactile déplace la feuille entre des hauteurs stables, sans priver les contrôles du clavier.
- Tant que la surface est modale, le focus clavier y reste jusqu’à sa fermeture.
- Échap ferme la surface temporaire et renvoie le focus vers un contrôle pertinent.
## États à couvrir
- Feuille fermée
- Feuille à mi-hauteur
- Feuille en pleine hauteur
## Accessibilité
- Rôle ARIA : dialog[aria-modal=true]
- Le contrôle principal ou la région nommée pour Feuille basse 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 entre dans la feuille modale, y reste et revient au déclencheur Filtres après la fermeture.
- Le contrôle fermer, Échap et un geste vers le bas dépassant le seuil prévu ferment ; les petits glissements accidentels reviennent en place.
- Le titre de la feuille, son état modal, son état développé et les changements de chargement sont disponibles sans dépendre du mouvement.
- Tab atteint tous les contrôles
- Des boutons remplacent les gestes développer et replier
- Échap ferme la feuille modale
## Quand ne pas utiliser
- Le placement latéral sur ordinateur définit le comportement
- Le glissement est le seul moyen d’atteindre le contenu ou fermer
## Critères d’acceptation
- La surface est visiblement ancrée en bas
- Chaque glissement possède un équivalent bouton ou clavier
- Les positions stables révèlent des états utiles
- Les alternatives clavier et le retour du focus sont vérifiés
## 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.
vaul
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 Feuille basse sur un parcours réel
# Vérifier Feuille basse après l’implémentation
## Objectif
Audite l’implémentation de Feuille basse 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.
# Déboguer Feuille basse dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Feuille basse.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- La surface est visiblement ancrée en bas
- Chaque glissement possède un équivalent bouton ou clavier
- Les positions stables révèlent des états utiles
- Les alternatives clavier et le retour du focus sont vérifiés
## 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.
vaul
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Feuille basse
# Empêcher la régression de Feuille basse
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Feuille basse aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
Construis Barre latérale sans casser son comportement
# Implémenter Barre latérale dans ton agent
## Objectif
Implémente Barre latérale pour ce comportement vérifié : Une région persistante à côté du contenu principal, intégrée à la mise en page et généralement dédiée à la navigation ou à des outils complémentaires.
## 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 Barre latérale répond au besoin avant de coder.
## Comportement requis
- La région occupe une place dans la mise en page au lieu de recouvrir temporairement le contenu principal.
- Si le produit remplace la région persistante quand l’espace manque, ce remplacement est un contrôle de navigation temporaire nommé séparément.
## États à couvrir
- Barre latérale développée
- Barre latérale compacte
## Accessibilité
- Rôle ARIA : aside > nav[aria-label]
- Le contrôle principal ou la région nommée pour Barre latérale 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 circule normalement entre la barre et le contenu principal ; le repli conserve un contrôle logique focalisé.
- Une barre persistante se replie, elle ne se ferme pas ; son équivalent mobile temporaire suit son propre contrat Drawer.
- La région de navigation possède un nom unique et la destination actuelle utilise aria-current lorsque pertinent.
- Tab suit l’ordre normal du document
- Entrée active liens et contrôle de repli
- Aucun piège de focus n’est créé
## Quand ne pas utiliser
- La surface n’est utile que brièvement
- Le contenu restant devient trop étroit ou défile horizontalement
## Critères d’acceptation
- La barre occupe de l’espace au lieu de recouvrir le contenu
- Sa région de navigation possède un nom unique
- La position actuelle et l’état replié sont exposés
- Le remplacement sur petit écran est un pattern distinct explicite
## 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.
Web platform
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 Barre latérale sur un parcours réel
# Vérifier Barre latérale après l’implémentation
## Objectif
Audite l’implémentation de Barre latérale 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.
# Déboguer Barre latérale dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Barre latérale.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- La barre occupe de l’espace au lieu de recouvrir le contenu
- Sa région de navigation possède un nom unique
- La position actuelle et l’état replié sont exposés
- Le remplacement sur petit écran est un pattern distinct explicite
## 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.
Web platform
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Barre latérale
# Empêcher la régression de Barre latérale
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Barre latérale aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
Construis Liste de sélection sans casser son comportement
# Implémenter Liste de sélection dans ton agent
## Objectif
Implémente Liste de sélection pour ce comportement vérifié : Un contrôle de formulaire pour choisir une ou plusieurs valeurs parmi des options prédéfinies sans saisie libre ; une sélection simple apparaît souvent comme un sélecteur fermé, tandis qu’une sélection multiple peut afficher une liste.
## 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 Liste de sélection répond au besoin avant de coder.
## Comportement requis
- Le contrôle expose si une ou plusieurs valeurs peuvent être sélectionnées et met à jour chaque état sélectionné de façon cohérente.
- Les flèches parcourent les options selon le modèle déclaré du contrôle ; les états de focus et de sélection sont exposés de façon cohérente, y compris lorsque la sélection suit le focus.
## États à couvrir
- Exemple de sélection simple replié
- Exemple de sélection simple développé
## Accessibilité
- Rôle ARIA : select
- Le contrôle principal ou la région nommée pour Liste de sélection 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 contrôle natif délègue le focus et le parcours des options à la plateforme selon sa présentation simple ou multiple déclarée.
- Pour une sélection simple repliée, le sélecteur de la plateforme se ferme selon son comportement standard de validation ou d’annulation ; une présentation en liste n’implique pas de surface contextuelle à fermer.
- Le libellé, l’état obligatoire, la ou les valeurs sélectionnées, l’état désactivé, le mode de sélection et l’erreur sont exposés par la sémantique native.
- Tab place le focus sur la liste
- Les touches de la plateforme parcourent la présentation simple ou multiple actuelle
- La commande de sélection de la plateforme met à jour la ou les valeurs
## Quand ne pas utiliser
- L’utilisateur doit rechercher dans une longue liste
- Plusieurs options doivent rester visibles pour comparaison
## Critères d’acceptation
- Un libellé visible nomme la ou les valeurs choisies
- Seules les valeurs prédéfinies peuvent être validées
- Le mode de sélection simple ou multiple est explicite
- Les états obligatoire et erreur sont associés au contrôle
## 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.
Web platform
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 Liste de sélection sur un parcours réel
# Vérifier Liste de sélection après l’implémentation
## Objectif
Audite l’implémentation de Liste de sélection 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.
# Déboguer Liste de sélection dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Liste de sélection.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- Un libellé visible nomme la ou les valeurs choisies
- Seules les valeurs prédéfinies peuvent être validées
- Le mode de sélection simple ou multiple est explicite
- Les états obligatoire et erreur sont associés au contrôle
## 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.
Web platform
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Liste de sélection
# Empêcher la régression de Liste de sélection
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Liste de sélection aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
# Implémenter Combobox dans ton agent
## Objectif
Implémente Combobox pour ce comportement vérifié : Un contrôle de valeur avec une surface associée ; il peut être modifiable ou sans saisie, et cette surface peut être une listbox, une grille, une arborescence ou une boîte de dialogue.
## 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 Combobox répond au besoin avant de coder.
## Comportement requis
- Le contrôle de valeur possède ou contrôle une surface associée, expose son état développé et suit le modèle clavier du rôle de cette surface.
- Échap ferme la surface temporaire et renvoie le focus vers un contrôle pertinent.
## États à couvrir
- Combobox au repos
- Suggestions ouvertes
- Ville confirmée
## Accessibilité
- Rôle ARIA : combobox + popup (listbox | grid | tree | dialog)
- Le contrôle principal ou la région nommée pour Combobox 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.
- Dans cet exemple modifiable avec popup listbox, le focus DOM reste dans le champ tandis que la relation d’option active communique la navigation ; les autres rôles de surface suivent leur propre modèle de focus.
- Échap ferme une surface ouverte sans valider de nouvelle valeur ; la conservation du texte et les autres actions de fermeture dépendent de la variante de combobox.
- Le nom, la valeur, l’état développé, la relation à la surface et l’élément actif ou sélectionné pertinent sont exposés ; le chargement et le nombre de résultats s’appliquent lorsque la variante les fournit.
- Dans cet exemple modifiable avec popup listbox, la saisie modifie la requête
- Flèche bas et haut déplacent l’option active
- Entrée valide l’option active
- Échap ferme les suggestions sans effacer
## Quand ne pas utiliser
- Une courte liste Select native serait plus simple
- Aucune surface associée ni aide révélée n’est nécessaire
## Critères d’acceptation
- Le comportement modifiable ou sans saisie est explicite
- Le rôle de la surface et la relation de contrôle sont explicites
- Le focus et le clavier correspondent au rôle de la surface
- Échap ferme la surface sans valider de nouvelle valeur
## 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.
@base-ui/react
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 Combobox sur un parcours réel
# Vérifier Combobox après l’implémentation
## Objectif
Audite l’implémentation de Combobox 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.
# Déboguer Combobox dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Combobox.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- Le comportement modifiable ou sans saisie est explicite
- Le rôle de la surface et la relation de contrôle sont explicites
- Le focus et le clavier correspondent au rôle de la surface
- Échap ferme la surface sans valider de nouvelle valeur
## 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.
@base-ui/react
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Combobox
# Empêcher la régression de Combobox
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Combobox aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
Construis Liste d’options sans casser son comportement
# Implémenter Liste d’options dans ton agent
## Objectif
Implémente Liste d’options pour ce comportement vérifié : Un widget composite d’options nommées qui accepte une ou plusieurs sélections et peut être autonome ou servir de surface contextuelle à une combobox.
## 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 Liste d’options répond au besoin avant de coder.
## Comportement requis
- Les flèches parcourent les options selon le modèle déclaré du contrôle ; les états de focus et de sélection sont exposés de façon cohérente, y compris lorsque la sélection suit le focus.
- Le contrôle expose si une ou plusieurs valeurs peuvent être sélectionnées et met à jour chaque état sélectionné de façon cohérente.
## États à couvrir
- Période par défaut sélectionnée
- 30 derniers jours sélectionnés
## Accessibilité
- Rôle ARIA : listbox > option
- Le contrôle principal ou la région nommée pour Liste d’options 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 select natif affichant plusieurs lignes forme un seul arrêt de tabulation. Dans cet exemple à sélection simple, la sélection suit le focus clavier : états actif et sélectionné évoluent ensemble ; une listbox personnalisée doit déclarer son propre modèle.
- Dans cet exemple autonome, quitter avec Tab conserve la valeur sélectionnée ; lorsqu’une listbox est contextuelle, sa fermeture est coordonnée par le contrôle propriétaire.
- Le nom de la liste, ses quatre options, la sélection, l’état désactivé et le mode simple de cet exemple sont exposés par la sémantique native.
- Tab entre une fois dans le contrôle composite
- Dans cet exemple natif à sélection simple, les flèches mettent la sélection à jour avec le focus
- Cet exemple n’a pas de commande de validation séparée
- Les touches Début et Fin prises en charge par la plateforme atteignent les limites
## Quand ne pas utiliser
- L’espace manque et un Select natif suffit
- Les éléments sont des commandes plutôt que des valeurs
## Critères d’acceptation
- Les options appartiennent à une liste nommée, autonome ou contextuelle
- La relation entre focus et sélection est déclarée, notamment si la sélection suit le focus
- Les flèches, Début et Fin sont cohérents
- Le mode de sélection est explicite
## 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.
Web platform
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 Liste d’options sur un parcours réel
# Vérifier Liste d’options après l’implémentation
## Objectif
Audite l’implémentation de Liste d’options 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.
# Déboguer Liste d’options dans ton agent
## Symptôme observé
[DÉCRIS ICI LE SYMPTÔME]
## Contrôles observables
- Reproduis le problème avec le plus petit parcours pertinent.
- Compare le comportement aux états et transitions documentés de Liste d’options.
- Vérifie le clavier, le focus, le nom accessible et les annonces.
## Causes possibles
- La primitive employée ne correspond pas au comportement attendu.
- Un état, une transition ou un retour de focus manque.
- Le composant voisin capture un événement ou masque un signal accessible.
## Corrections bornées
- Corrige la cause reproduite sans recréer les composants voisins.
- Conserve le contrat public et ajoute un test ciblé de non-régression.
- N’installe aucune dépendance et ne modifie aucun état distant sans autorisation.
## Vérification finale
- Les options appartiennent à une liste nommée, autonome ou contextuelle
- La relation entre focus et sélection est déclarée, notamment si la sélection suit le focus
- Les flèches, Début et Fin sont cohérents
- Le mode de sélection est explicite
## 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.
Web platform
Prérequis · Accès au dépôt, au design system et aux tests
Pourquoi ça marche
Le symptôme explicite évite de partir d’une correction supposée.
Les contrôles séparent comportement, accessibilité et interférences voisines.
La correction reste bornée et doit produire une preuve de non-régression.
À essayer ensuite
Verrouille la correction de Liste d’options
# Empêcher la régression de Liste d’options
## Objectif
Transforme la cause reproduite en test de non-régression ciblé et compare Liste d’options aux concepts voisins avant d’élargir la correction.
## Contrôles
- Prouve que le test échoue avant la correction.
- Prouve qu’il passe après la correction bornée.
- Vérifie qu’aucun composant voisin n’a changé de comportement.
## 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.
