Shunqiang/skills

Figma vers Page Frontend

Périmètre et résultat attendu

Implémenter le design sélectionné dans le projet existant et vérifier le résultat dans un navigateur. Une URL Figma est normalement suffisante pour commencer ; déduire les conventions du projet à partir du dépôt. Accepter les captures d'écran ou les exports fournis comme preuve de repli lorsque le design est inaccessible.

Les instructions de l'utilisateur prévalent sur ces directives. Préserver les modifications existantes et limiter les modifications au périmètre demandé. Identifier si la tâche concerne une nouvelle page, une mise à jour d'une page existante, une section ou un composant réutilisable avant de choisir les fichiers ou les routes. Ne pas transformer un composant ou une correction locale en une nouvelle page.

Contraintes principales

• Lire le code du dépôt concerné avant de modifier. Réutiliser son framework, son routeur, son style, ses tokens, ses composants, ses assets et ses conventions de données lorsque c'est approprié.
• Traduire la géométrie du design en règles de mise en page. Privilégier le flux normal, flex et grid ; utiliser le positionnement absolu pour les superpositions, décorations ou overlays réels. Les groupes Figma sont des indices, pas des limites de composants obligatoires.
• Réutiliser les assets identiques et les composants mappés appropriés. Préserver les images et icônes distinctives plutôt que de les remplacer par des symboles approximatifs. Ne pas rendre une section interactive entière sous forme de capture d'écran.
• Implémenter le comportement pris en charge par les exigences, les prototypes ou le comportement existant du produit. Ne pas déduire le positionnement sticky, la sémantique des filtres, les contrats d'API ou les destinations de navigation à partir de la seule apparence.
• Préserver les contrôles sémantiques, les noms accessibles, le fonctionnement au clavier et le comportement de focus approprié. Exclure les éléments de chrome de l'appareil (comme une barre d'état du système d'exploitation) sauf si demandé.
• Ne pas revendiquer une parité visuelle sans comparer la cible implémentée avec le design. Signaler explicitement les exigences bloquées ou non vérifiées.

Compatibilité CSS

• Utiliser margin pour l'espacement entre les éléments flex, grid et les éléments répétés. Ne pas utiliser gap, row-gap ou column-gap. Placer l'espacement sur une classe d'élément nommée ; donner au premier ou au dernier élément une classe de modification explicite lorsque sa marge diffère. Ne pas remplacer gap par des sélecteurs tels que > * + *, :first-child ou :last-child.
• Écrire les sélecteurs en ciblant des classes de composants explicites. Éviter les sélecteurs universels et les combinateurs de fratrie (+, ~) dans les styles qui peuvent être compilés en WXSS. Vérifier la prise en charge des sélecteurs de la plateforme cible avant d'utiliser d'autres pseudo-classes ou combinateurs ; ne pas supposer que la prise en charge CSS du navigateur implique la prise en charge WXSS.
• Pour les masques et les panneaux fixes, utiliser des déclarations explicites top, right, bottom et left au lieu de inset. Lors de l'utilisation de env(safe-area-inset-*), placer un repli de valeur simple immédiatement avant la déclaration qui utilise env(). Définir box-sizing: border-box là où des largeurs fixes et des espacements intérieurs doivent s'ajuster ensemble.
• Dans Taro H5, le style intégré taro-button-core:active peut rendre un bouton enfoncé gris même lorsque sa classe de survol est désactivée. Si le design ne prévoit aucun changement de couleur lors de l'enfoncement, remplacer les couleurs de fond et de texte actives pour les classes de bouton spécifiques, en préservant les couleurs normales de chaque bouton. Ne pas réinitialiser les boutons globalement ni modifier le style désactivé.

Preuves et décisions

Lire le fichier design-evidence.md lors de la collecte ou de l'actualisation des preuves de design. Conserver un résumé de travail concis de la cible, des conventions du projet, du mappage des assets, des capacités applicables et des incertitudes. Les notes de contexte sont suffisantes pour les petites tâches ; ne pas générer un fichier de spécification sauf si cela est utile ou demandé.

Classifier les décisions :

• Confirmé : exigences explicites de l'utilisateur, propriétés de design sélectionnées, comportement du prototype ou contrats de produit existants pertinents.
• Inféré : adaptation de mise en page ordinaire, retour à la ligne et limites de composants locaux cohérents avec le projet. Choisir l'implémentation la plus petite raisonnable et divulguer les hypothèses matérielles.
• Inconnu : contrats de soumission manquants, destinations ambiguës, frames cibles conflictuelles ou comportement métier conséquent. Inspecter d'abord les preuves disponibles ; poser une question ciblée si encore nécessaire. Continuer le travail indépendant en attendant une réponse.

Un contrôle visible seul n'établit pas son comportement métier. Ne pas simuler des soumissions réussies, inventer des points de terminaison ou substituer silencieusement un comportement factice. Utiliser des fixtures uniquement lorsque la tâche ou la convention d'aperçu existante les prend en charge et identifier cette limitation.

Exécution

Suivre les dépendances plutôt que de répéter une séquence fixe. Pour une correction locale, réutiliser les preuves encore valides et inspecter la région modifiée ainsi que le comportement partagé affecté. Les lectures indépendantes du dépôt et du design peuvent être regroupées.

1. Identifier la cible et le projet

Analyser la clé du fichier et l'ID du nœud. Inspecter le type, les dimensions et le contexte environnant du nœud sélectionné. Si l'ID du nœud est absent, inspecter les candidats de premier niveau ; sélectionner uniquement lorsque la cible est claire.

Utiliser des recherches et des lectures ciblées pour établir :

• les instructions applicables du dépôt et les modifications en cours ;
• le gestionnaire de paquets, les commandes de développement et de vérification ;
• les fichiers de destination probables et l'implémentation existante la plus proche ;
• le routeur, le style, les tokens, les polices, la gestion de la fenêtre d'affichage/des unités et les conventions de composants ;
• les mappages existants du design vers le code et les assets disponibles.

Pour un travail sur une page ou un composant existant, préserver son point d'entrée. Pour une nouvelle page, suivre la famille de routes existante et les conventions de paramètres, en vérifiant les conflits. Utiliser le nom de la frame uniquement comme indication de nom de repli ; ne pas imposer une route de détail générique.

2. Acquérir suffisamment de preuves de design

Privilégier les outils Figma disponibles pour les métadonnées, les captures d'écran, les variables, les mappages de composants et les assets. Suivre les prérequis de compétence d'outil spécifiques requis avant d'utiliser ces outils. Si l'accès échoue, essayer un navigateur authentifié disponible, puis les captures d'écran ou les exports fournis. Ne pas utiliser la recherche web comme substitut au design réel.

Commencer par la capture d'écran cible et l'aperçu structurel, puis récupérer les détails des sous-arbres pertinents. Inspecter le contenu situé en dessous de la ligne de flottaison. Ne pas récupérer à plusieurs reprises l'intégralité du fichier ou des frames non liées. Enregistrer les mesures ou états indisponibles comme incertitude plutôt que comme faits exacts.

3. Mapper et implémenter

Mapper le design en modules significatifs, en choisissant des composants existants lorsque leur comportement et leur apparence correspondent. Extraire un composant lorsque la réutilisation, le comportement indépendant ou la complexité le justifie ; ne pas diviser chaque wrapper ni créer un système de design pour une seule page.

Résoudre les polices et les assets majeurs tôt. Préserver le rapport hauteur/largeur, la transparence et la résolution appropriée des assets ; utiliser les conventions de stockage du dépôt et des noms de fichiers sémantiques. Vérifier que les assets d'exécution se chargent depuis un emplacement durable pris en charge par le projet.

Dériver les dimensions fluides, les largeurs maximales, le retour à la ligne et les points de rupture à partir des variantes fournies et du comportement existant du projet. Avec une taille de design unique, implémenter une adaptation conservative et la distinguer d'une mise en page responsive spécifiée par un designer. Tester la plateforme demandée ; ne pas créer une refonte de bureau ou mobile non demandée.

Pour les projets Taro qui partagent les styles entre les builds H5 et mini-programmes, inspecter le WXSS généré ainsi que la feuille de style source. Vérifier l'espacement et les états enfoncés sur chaque environnement d'exécution demandé lorsqu'il est disponible.

Activer uniquement les branches de comportement pertinentes :

• Navigation : utiliser les destinations établies et le comportement de routage.
• Formulaires et collections : utiliser les contrats de données existants ; implémenter les états de validation, chargement, vide, erreur et succès requis.
• Onglets et filtres : établir la propriété de l'état et la sémantique de sélection à partir des preuves. Le comportement de brouillon/validation s'applique uniquement lorsqu'il est pris en charge.
• Tableaux : préserver l'alignement et les bordures affichées ; fournir un débordement approprié à la fenêtre d'affichage cible.
• Overlays ou UI sticky : lire le fichier overlays-and-sticky.md.
• Mouvement ou médias : reproduire le comportement confirmé et gérer le chargement et le mouvement réduit si applicable.

4. Vérifier et itérer

Réutiliser un serveur en cours d'exécution approprié, ou démarrer la commande de développement documentée sur un port disponible. Utiliser une surface d'automatisation de navigateur disponible, en privilégiant le navigateur intégré lorsqu'il est adapté, puis un navigateur externe authentifié ou les outils de navigateur du projet. Inspecter la route pertinente ou l'aperçu du composant existant.

Lire le fichier acceptance-checklist.md pour la comparaison visuelle, les vérifications d'interaction applicables et les critères de complétion. Corriger les grandes différences structurelles avant le polissage local. Après chaque modification, vérifier la région affectée ; effectuer une vérification finale de l'ensemble de la cible.

Exécuter les vérifications pertinentes du dépôt, inspecter le diff final et distinguer les échecs préexistants de ceux introduits. Éviter d'ajouter des dépendances ou des refontes larges uniquement pour effectuer la vérification. Préserver les sessions de serveur préexistantes et rendre intentionnel l'état de tout serveur démarré pour cette tâche.

Récupération et achèvement

Si l'accès ou la vérification d'exécution échoue, inspecter l'erreur concrète et essayer une alternative pertinente disponible. Cesser de répéter un échec inchangé sans nouvelle preuve. Continuer le travail qui peut être effectué indépendamment, puis signaler le blocage exact, ce qui a été implémenté et ce qui reste non vérifié. Les outils ou identifiants manquants ne sont pas une preuve de vérification réussie.

Terminer lorsque la cible demandée est implémentée, les vérifications applicables sont réussies et aucun défaut requis connu ne persiste. Les différences mineures de rendu peuvent être documentées ; les erreurs de mise en page non résolues, le comportement requis manquant ou les vérifications de navigateur bloquées ne doivent pas être présentés comme une complétion totale.

Rapporter de manière concise :

• la cible implémentée et le point d'entrée, y compris une route uniquement le cas échéant ;
• les changements de comportement et de composants significatifs ;
• l'emplacement de l'aperçu et les vérifications réellement effectuées ;
• les hypothèses matérielles, les différences non résolues ou les blocages.