Validation Design (UAT)
Examinez l'implémentation visuelle d'un site web par rapport à ses références de design. Par défaut, générez un rapport HTML en anglais, centré sur les problèmes ; respectez la langue ou le format demandé. Le skill est réutilisable d'un projet à l'autre. Les URL du projet, les correspondances de trames, les écarts acceptés, les identifiants et les preuves d'exécution n'appartiennent pas à ce dossier de skill.
Commencez par le périmètre de l'utilisateur
Utilisez les liens du site web et de Figma fournis comme périmètre initial. Réutilisez un profil de projet existant s'il est présent ; sinon commencez la découverte sans exiger une liste de routes ou une configuration préparée. Lorsqu'une page Figma représente une remise de version, inventoriez toute la page et découvrez le chemin de test de chaque module. L'URL du site web fournie est un point d'entrée, pas une restriction de route. Respectez un périmètre explicite de page entière ; enregistrez les exclusions et les états bloqués au lieu de substituer silencieusement un échantillon. Pour un périmètre vaste non spécifié, énoncez une limite d'examen utile. Échantillonner un écran n'accepte pas un module entier.
Conservez les données du projet dans l'espace de travail inscriptible du projet actuel, en respectant les instructions du dépôt. Une valeur par défaut utile est design-uat/<projet>/project.json et runs/<id-run>/, mais conservez un emplacement établi. Consultez project-data.md lors de la création de correspondances, de la construction de l'entrée du rapport ou de l'enregistrement d'une réexécution.
Découvrez les outils réellement disponibles. Préférez un connecteur Figma pour la structure du design et les mesures, et le contrôle du navigateur pour l'UI en direct. Utilisez les instructions d'outil pertinentes et les skills prérequis si nécessaire ; ce skill ne fournit pas ces outils. Réutilisez une connexion déjà autorisée si possible. Si l'accès est bloqué, poursuivez un travail indépendant utile et signalez précisément quels états n'ont pas pu être examinés.
Découvrez la correspondance design-page
Inspectez la hiérarchie du design et la navigation en direct avant de comparer les images. Un canvas peut contenir des conteneurs de modules, des trames d'écran, des exemples d'états locaux, des notes, des annotations et des propositions alternatives. Identifiez la cible visuelle à l'intérieur de cette structure plutôt que d'exporter l'ensemble du tableau de documentation comme un écran.
Lisez les notes associées et les exemples d'états locaux. Ils peuvent spécifier un comportement responsive, des dimensions d'entrée, la troncature ou des détails de composant que la trame principale n'affiche pas. Utilisez le contenu de nœud visible/efficace ; le texte d'aide/erreur caché d'un composant n'est pas une exigence active simplement parce qu'il existe dans l'arbre.
Distinguez une véritable spécification de page d'une illustration d'interactions générales. Un exemple générique de tiroir peut révéler une divergence dans un module existant, mais n'établit pas les champs obligatoires de chaque catégorie. Conservez une constatation utile inter-module avec sa route réelle, son contexte de navigation et sa limitation de baseline ; étiquetez un statut hérité suspecté comme non confirmé à moins que son historique ne soit connu.
Faites correspondre en utilisant les preuves combinées du contexte du module, de la route, du titre de page visible, des étiquettes de champ, de la structure UI et de l'apparence rendue. Enregistrez les ID des trames, l'état page/trame, la région de comparaison, la confiance et le statut de correspondance dans les données du projet. Une URL peut avoir de nombreux états visuels. Ne confondez pas une liste, un tiroir ouvert, une entrée focalisée et un état vide.
Procédez avec les correspondances bien étayées marquées comme inférées lorsqu'elles ne sont pas confirmées humainement. Regroupez les choix vraiment ambigus pour l'utilisateur tout en poursuivant les cas non bloqués. Enregistrez les designs alternatifs/de secours comme hors du périmètre sélectionné avec une raison ; le nom seul n'établit pas la version acceptée. Vérifiez les correspondances précédemment sauvegardées par rapport au design actuel et à la page en direct avant de les réutiliser.
Pour les fichiers Figma volumineux, conservez les métadonnées brutes localement et renvoyez des résumés concis et peu profonds au contexte. Réduisez la portée en vous basant sur les ancêtres connus avant d'extraire des sous-arbres détaillés ou des captures d'écran. Évitez de charger le fichier entier à plusieurs reprises.
Capturez des preuves comparables
Lisez evidence-workflow.md avant la première capture ou lors du diagnostic d'un problème de comparaison. Il couvre le débordement de plan de travail, la correspondance d'état, l'exclusion d'annotation, le contenu dynamique, les recadrages locaux et l'acceptation des captures d'écran.
Exposez les états visuels nécessaires via la navigation, la focalisation et les modifications d'entrée réversibles. Ne soumettez pas de modifications métier uniquement pour obtenir une capture d'écran sans autorisation pour ces modifications. Si un état nécessite des données indisponibles ou une action d'écriture, enregistrez cette limitation plutôt que de la fabriquer.
Capturez la région de design exacte et l'état du navigateur à une fenêtre, une échelle et un thème compatibles. Vérifiez que les polices/le contenu ont chargé et que la cible est stable. Rejetez les captures de chargement transitoires à moins que le chargement ne soit l'état examiné. Inspectez les captures d'écran sauvegardées avant de les utiliser dans un rapport. Conservez les captures originales avec les recadrages, superpositions et annotations.
Fondez les différences sur les deux images ensemble et, si utile, sur la géométrie Figma et les limites des éléments du navigateur. Attribuez les valeurs mesurées à leur source. Utilisez scripts/compare_regions.py pour des paires de recadrages et repères optionnels à l'échelle native si Pillow est disponible. Le moteur de rendu du rapport ne nécessite que la bibliothèque standard de Python.
Inspectez les relations sur une ligne de contrôle ainsi que les dimensions individuelles : espacements adjacents, alignement, espace d'action restant et changements lorsque des contrôles de filtre actif apparaissent. Regroupez une correction de mise en page partagée et ses conséquences visuelles sous un seul problème stable lorsque cela est étayé par des preuves ou un retour explicite du réviseur. Distinguez ce regroupement d'un diagnostic de cause racine au niveau du code.
Distinguez le contexte des défauts : les données d'exemple, l'identité du compte, la navigation dépliée, les annonces globales et les versions ultérieures de composants peuvent modifier une capture d'écran. Enregistrez-les ; ne rejetez pas silencieusement leurs effets de mise en page. Les valeurs textuelles peuvent être exclues de la correspondance de copie tandis que leur habillage, débordement et alignement restent examinables. N'étirez jamais les captures d'écran pour masquer les différences et n'inventez pas un score de similarité de page entière.
Établissez des constatations exploitables
Classez chaque constatation selon ce que ses preuves soutiennent :
défaut-visuel: une défaillance visuelle reproductible telle qu'un rognage, un chevauchement ou une violation d'implémentation confirmée. Indiquez les conditions et la source de l'attente.divergence-de-baseline: une différence démontrée par rapport à la référence fournie dont le design/version actuellement accepté peut nécessiter une confirmation.clarification-de-design: une condition observée avec des directives de design insuffisantes ou contradictoires pour décider de l'acceptation.
Gardez séparés la confiance d'observation, la priorité suggérée et le statut de suivi. N'appelez pas une différence de capture d'écran à haute confiance un défaut accepté simplement parce que la différence est évidente. Utilisez le schéma de priorité du projet ; étiquetez les suggestions et laissez la priorité non définie lorsque la décision n'est pas résolue. N'inventez pas de propriétaires, de versions cibles, de déviations approuvées, d'achèvement d'implémentation ou de nouveaux tests réussis.
Chaque constatation a besoin d'un ID stable, d'un état page/écran, d'un titre concis, d'un résultat réel, d'un résultat attendu ou d'une incertitude explicite, d'une base de preuves, d'une action recommandée et d'étapes de reproduction. Joignez des preuves de comparaison ciblées et la capture complète de l'état actuel. Incluez les références Figma pertinentes. Les constatations sans preuve visuelle sont des limitations ou des questions, pas des défauts visuels confirmés.
Enregistrez les vérifications effectuées et les états bloqués/non examinés séparément. Gardez les mêmes ID de problème lors d'une réexécution. Fermez ou marquez une constatation comme résolue uniquement à partir de nouvelles preuves correspondantes ; conservez l'observation précédente et expliquez les critères d'acceptation modifiés.
Incorporez la revue de design
Par défaut, produisez un brouillon de revue, puis intégrez les décisions du designer avant de produire une livraison aux développeurs. Lisez review-workflow.md lors de la réception de retours, de la révision d'une baseline de design ou de la préparation du rapport formel. Une revue et une approbation explicites déjà données dans la conversation sont suffisantes ; ne demandez pas la même confirmation à nouveau.
Enregistrez les décisions de conservation, d'exclusion, d'acceptation, de fusion, de report et de mise à jour de design dans les données du projet avec leur source et leur périmètre. Une correction de référence de design n'est pas une correction d'implémentation. Les retours du réviseur concernant une modification de design n'autorisent pas eux-mêmes à modifier Figma. Conservez le brouillon et l'historique des décisions ; la livraison aux développeurs contient uniquement les actions retenues, y compris toute clarification expressément retenue ou tout suivi de module existant. Ne transformez pas les champs non attribués (priorité, propriétaire, version, nouveau test) en valeurs confirmées.
Livrez le rapport
Lisez report-format.md lors de la rédaction du rapport. Préservez l'ordre de lecture éprouvé : contexte cadré → registre concis des problèmes → preuves visuelles réelles/attendues du problème sélectionné → notes de couverture et de revue. Faites de la preuve visuelle la substance du rapport, pas une annexe détachée. Évitez de répéter de grandes captures d'écran pour chaque problème et pour chaque vérification réussie.
Écrivez les données structurées d'exécution décrites dans project-data.md, puis exécutez le rendu :
python3 <dossier-skill>/scripts/render_report.py <dossier-run>/report.json
Ceci produit report.html autonome, issue-register.csv et une acceptance-checklist.csv lorsque des critères sont fournis. Dans une livraison aux développeurs, chaque élément retenu nécessite une URL de test directe, une navigation/contexte, une action développeur et des critères d'acceptation observables. Le moteur de rendu prend directement en charge ces champs ; ne patchez pas le HTML généré pour les ajouter. Le moteur de rendu nécessite Python 3.9+ et aucun package tiers. Il valide l'entrée/les preuves mais n'infère pas de décisions de revue, n'accède pas à des systèmes externes et n'envoie pas le rapport aux développeurs.
Inspectez le rapport rendu, sa commutation/le filtrage des problèmes, son expansion d'image et ses contrôles de comparaison. Ouvrez le résultat à l'aide des outils d'aperçu local disponibles, en suivant leurs règles de navigateur. Utilisez un aperçu local sans conflit si nécessaire, lié à la boucle locale (loopback) ; ne publiez pas et n'écrivez pas sur des systèmes externes sauf demande explicite. Rétablissez les overrides temporaires de fenêtre du navigateur et les entrées de test lorsque c'est pratique, et signalez tout état restant modifié.
Livrez le lien du rapport, la couverture concise et le résultat clé dans la langue de la conversation. Expliquez les limitations matérielles. N'exigez pas d'approbation simplement pour produire le rapport déjà demandé. Une demande de discussion de l'approche n'est pas une demande d'exécution d'un test UAT.