chukaofili/agent-plugins

Vérifier l'interface utilisateur

Construire les écrans n'est que la première moitié. Un changement d'interface n'est pas terminé tant qu'il n'a pas été piloté dans un vrai navigateur et que ses captures d'écran ne sont pas dans la PR. Une vérification de type propre, une exécution de lint et une suite de tests unitaires indiquent que le code compile et que sa logique tient. Aucun d'eux ne dit que le panneau s'affiche, ni que le pied de page se trouve là où le design le place. Les relecteurs qui n'exécutent jamais la branche jugent le travail à partir des captures d'écran, ou pas du tout.

1. Pilotez-le dans un vrai navigateur, avec de vraies données

Utilisez une application en cours d'exécution avec une base de données réelle (amorcée), pas des simulations, et pas seulement une capture d'écran du scénario idéal. Parcourez chaque état que le design nomme, plus ceux qu'il ne nomme pas :

• Les deux thèmes. Les couleurs écrites à la main sont l'endroit où les variantes sombres sont oubliées.
• Mobile et desktop. Les mises en page se réorganisent aux points de rupture, et les pieds de page et barres d'outils peuvent orpheliner la moitié de leur contenu.
• Les états vides, de chargement, de limite et d'échec, pas seulement l'état peuplé.
• Chaque transition où un dialogue ou une vue se ferme et un autre s'ouvre.
• Ouvrez chaque menu, popover et liste déroulante que vous avez ajoutés. Un menu que vous n'ouvrez jamais a la même apparence qu'un menu qui fait planter la page lorsqu'il s'ouvre.
• Vérifiez la console du navigateur et le panneau réseau pour détecter les erreurs pendant que vous y êtes.

2. Effectuez une revue de conformité

Révisez le changement par rapport aux directives de design et du framework utilisées par le dépôt (système de design, accessibilité, bonnes pratiques du framework). Si votre agent peut générer des sous-agents, exécutez un réviseur par directive en parallèle sur un modèle moins cher. C'est un travail de reconnaissance de motifs, pas de jugement.

• Donnez aux réviseurs les propres règles du dépôt. Un réviseur qui ne les a pas lues signalera les décisions documentées comme des violations.
• Demandez-leur de seulement signaler. Ensuite, jugez chaque constatation vous-même en fonction de la probabilité réelle. Rejetez les constatations qui seraient vraies pour un autre produit, comme un conseil de virtualisation pour une liste limitée à une douzaine de lignes.

3. Capturez des captures d'écran pour la PR

Pas une description des écrans : les écrans. Les capturer est également le moyen le moins coûteux de détecter un état que vous n'avez pas réellement regardé.

• Pilotez la vraie application. Un script de navigateur jetable qui atteint chaque état est acceptable. Utilisez les aides d'amorçage du cadre E2E pour atteindre des états qu'aucun flux d'interface ne produit, puis supprimez le script une fois les images créées. Il n'asserte rien et ne constitue pas une couverture.
• Reconstruisez avant de capturer. Sinon, vous pourriez capturer le bogue que vous venez de corriger.
• Attendez les animations avant le déclencheur. « Visible » se résout lorsqu'un élément est disposé, pas lorsque sa transition d'entrée se termine, donc une capture naïve montre des dialogues à moitié fondus sans fond. Attendez la fin des animations finies (filtrez les animations infinies telles que les pulsations de squelette), avec un délai d'attente.
• Atteignez chaque état comme le ferait un utilisateur là où vous le pouvez. Forcer un drapeau ignore la course qui pourrait exposer un bogue.
• Validez-les dans docs/screenshots/<sujet>/, à côté du design qu'elles implémentent s'il y en a un.
• Référencez-les par SHA de commit, pas par branche, par exemple https://github.com/<org>/<repo>/blob/<sha>/<path>?raw=true. Une URL de branche meurt lorsque la branche est supprimée à la fusion et laisse la PR pleine d'images cassées.

Pas de navigateur disponible

Si l'environnement ne peut vraiment pas exécuter l'interface (pas d'outillage navigateur, identifiants manquants, infrastructure que vous ne contrôlez pas), dites-le dans la section Test de la PR. Nommez ce qui a bloqué et ce que vous avez vérifié à la place. Le silence se lit comme « vérifié ».

Publiez les correctifs de la revue comme un étage au-dessus

Les correctifs trouvés par ce passage vont dans une nouvelle PR empilée au-dessus de la fonctionnalité, afin que la construction et le passage de révision restent séparément révisables (voir stacked-prs).

Ce que ce passage détecte

Aucun de ces éléments ne provenait d'un vérificateur de type, d'un linter ou d'une suite de tests unitaires :

• Un squelette de chargement qui ne correspondait pas à sa page. Il squelettait une barre d'outils que la page n'a pas, donc chaque navigation sautait entre deux mises en page. Miroitez la mise en page réelle ligne par ligne, ou n'expédiez pas de squelette.
• Deux dialogues peints en même temps lors d'une transition, parce que chaque dialogue était monté et seulement son indicateur open était basculé. Caché n'est pas démonté.
• Un flash de mauvaise identité : la propre ligne de l'utilisateur proposait de le supprimer pendant une peinture, parce que le client lisait la session après le premier rendu. L'identité que le serveur connaît déjà devrait descendre avec la page.
• Un état vide erroné : « Aucun résultat trouvé » s'affichait pendant une trame avant que la requête ne se résolve, parce que zéro ligne signifiait à la fois « chargement » et « vide ».
• Un jeton de design échangé contre un autre similaire, visiblement différent dans l'un des thèmes.
• Une étiquette codée en dur à côté de quatre autres sites d'appel qui lisaient la même étiquette à partir d'un catalogue partagé.
• Un menu qui plantait la page à l'ouverture, parce qu'un sous-composant nécessitait un parent qu'il n'avait pas. Un clic manuel l'a manqué deux fois, parce que personne n'a ouvert le menu.
• Un élément de spécification ignoré silencieusement, et un autre supprimé pour une bonne raison mais laissé non documenté. Toute déviation par rapport au design nécessite une note expliquant pourquoi.
• Un dialogue se contredisant, trouvé en regardant la capture d'écran : un avis disait « tous les sièges sont utilisés » tandis que le pied de page à côté offrait encore « 2 sièges restants ».