Créer et mettre à jour une bibliothèque de composants UI qui suit les règles de design

## Lire la spécification de chaque tâche et suivre le code si la documentation diverge Classez la tâche avant toute modification et lisez la source qui la régit. - Pour le comportement des composants ou les API, lisez le guide de l’API publique, l’implémentation et un composant approuvé situé à proximité. - Pour les styles, lisez la spécification détaillée des styles, le fichier de jetons de compilation, le fichier de thème d’exécution et les styles délimités adjacents. - Pour les modifications de build, lisez la configuration de build et le contrat de chaque plugin personnalisé avant de changer la chaîne de traitement. - Pour les tests, lisez leur configuration dédiée et les tests proches ; pour la documentation, lisez la matrice de synchronisation. - Résolvez les conflits dans cet ordre : code source et configuration active, règles du dépôt, documentation spécialisée, puis expérience générale. - Lorsque le code source et la documentation divergent, suivez le code source et corrigez la documentation obsolète dans le même périmètre approuvé. - Traitez les tableaux de référence rapide comme des renvois vers les sections de référence, et non comme des copies autonomes des règles. - N’inventez jamais une API et ne vous fiez pas à votre mémoire pour un comportement sensible à la version ; vérifiez la version installée et sa documentation fournie. Avant l’implémentation, répertoriez les exports, styles, tests, registres de démos, documents et invariants de build concernés. ## Donner à chaque composant son propre dossier avec code, styles et tests Attribuez à chaque composant un dossier propre contenant son implémentation, son fichier de styles délimités, son point d’entrée d’export et son test unitaire placé à côté du code. Ajoutez séparément les exports publics de valeurs et de types, puis enregistrez toute surface de démo nécessaire. - Utilisez des composants fonctionnels typés, définissez les valeurs par défaut dans la déstructuration des paramètres et attribuez un nom d’affichage stable. - Étendez les attributs de l’élément natif approprié et omettez uniquement les champs en conflit. - Respectez la casse canonique du dépôt pour les noms de composants et de types, la forme de nom de fichier configurée pour les fichiers de style et la convention configurée pour les noms de classes délimitées. - Conservez la vérification stricte de null et les règles de modules isolés ; évitez les échappatoires non typées et utilisez des exports explicites réservés aux types. - Placez les import en tête, utilisez les alias de projet configurés et ne mettez aucun sélecteur global dans les styles délimités d’un composant. - Composez les classes au moyen de la table de styles délimités ou de l’utilitaire de classes approuvé, plutôt que d’écrire en dur les noms de classes générés. - Gardez les utilitaires réutilisables centrés sur une tâche et placez-les à l’endroit prévu par les conventions du dépôt. Ne modifiez pas l’interface publique d’un composant sans mettre à jour simultanément ses exports, ses tests, ses exemples et sa documentation d’API. ## Utiliser des valeurs de design communes pour les couleurs et les arrondis, pas des valeurs brutes Maintenez des couches de jetons distinctes pour des fonctions distinctes : les variables de compilation prennent en charge les calculs et les mixins, tandis que les propriétés CSS personnalisées à l’exécution permettent aux consommateurs de remplacer les thèmes. Ne considérez pas ces deux couches comme interchangeables. - Maintenez la cohérence du nommage de CSS Modules et de l’injection des jetons entre les configurations de build et de test. - Privilégiez les jetons sémantiques d’exécution dans les styles des composants ; n’utilisez les variables de compilation que lorsqu’un prétraitement est nécessaire. - Exprimez la couleur, le focus, le rayon, l’élévation, la typographie, la graisse et le mouvement au moyen des rôles sémantiques du système, plutôt que par des valeurs brutes isolées. - Évitez les extrêmes purs et les valeurs par défaut froides et génériques lorsque le langage visuel définit des surfaces teintées, un texte aux tons chauds ou des états de focus propres à la marque. - Préservez les silhouettes intentionnelles des composants, les traitements d’état et les règles d’ombre, au lieu de les aplatir en un seul modèle générique. - Regroupez les polices globales, les variables de thème et les réinitialisations derrière un unique point d’entrée de styles globaux. - Respectez les préférences de réduction des animations et préservez un focus visible, l’usage au clavier, un contraste lisible et les rôles d’accessibilité documentés. Prenez les valeurs exactes et les exceptions propres aux composants dans la spécification visuelle de référence et le code source actuel, jamais dans votre mémoire. ## Tester le clavier et l'accessibilité de chaque composant Utilisez la configuration de test dédiée du dépôt avec l’environnement DOM, les fichiers d’initialisation, les comparateurs, les alias et le traitement de CSS Modules qu’elle déclare. Ne déplacez pas les réglages de test vers une configuration de build ignorée par l’outil de test actif. - Placez les tests avec les composants et utilisez les utilitaires approuvés de rendu, de requête et d’interaction utilisateur. - Couvrez le rendu, les classes pilotées par les props, les fonctions de rappel, le comportement désactivé, les changements d’état et les rôles d’accessibilité pertinents. - Exercez le comportement au clavier avec les touches requises par le modèle du composant, notamment le déplacement du focus, l’activation, la fermeture et le contrôle directionnel. - Vérifiez les classes délimitées au moyen de la table de styles importée, plutôt qu’avec des littéraux de chaîne générés. - Testez les API impératives en les invoquant dans la frontière d’état du framework de test et en attendant leur résultat monté ; ne rendez pas en JSX une API qui n’est pas un composant. - Centralisez les utilitaires de test partagés et utilisez des interactions utilisateur réalistes plutôt que des raccourcis d’événements de bas niveau. - Atteignez les seuils de couverture configurés et documentez toute exclusion intentionnelle, au lieu de gonfler la couverture avec des cas de faible valeur. Pour un défaut, exécutez d’abord un test ciblé qui échoue, puis la suite concernée et, enfin, toute la suite requise avant de terminer. ## Garder un build modulaire pour ne charger que les composants utilisés Traitez les plugins de build personnalisés, les exports de paquets et les règles de ressources comme des contrats avec les consommateurs. - Préservez des sorties ES-module et CommonJS distinctes, avec des limites de modules intactes, afin que les composants inutilisés restent éliminables par tree shaking. - Gardez le framework et les paquets utilitaires approuvés externes lorsqu’ils constituent des peer dependencies ; n’ajoutez aucune runtime dependency sans exigence explicite. - Préservez le découpage du code CSS et le mécanisme qui associe les styles de chaque composant à son point d’entrée JavaScript. - Gardez le point d’entrée de la feuille de styles globale complet tout en empêchant les ressources de composants inutilisés d’entrer dans les bundles des consommateurs. - Suivez la politique du dépôt concernant la copie et l’intégration des ressources, y compris les exigences de format de police et de public path. - Maintenez les tables d’exports du paquet, les fichiers publiés et les déclarations d’effets de bord alignés sur la structure générée. - Ne modifiez la logique de build qu’après avoir lu les contrats des plugins personnalisés, puis vérifiez à la fois les import au niveau des composants et le point d’entrée des styles globaux. Les répertoires générés de distribution, de build des démos et de couverture sont des sorties, non des surfaces de création, et ne doivent pas être inclus dans un commit sauf si la politique du dépôt l’exige explicitement. ## Mettre à jour la documentation et les démos à chaque changement de composant Mettez à jour chaque surface de référence affectée par une modification de composant. - Les modifications d’API ou de props mettent à jour le manuel de l’API à partir du code source ; les modifications de style mettent à jour la spécification détaillée des styles. - Les changements du langage visuel mettent à jour la synthèse de conception, et les nouveaux composants mettent à jour le prompt destiné à l’utilisateur ou la spécification du catalogue. - Les changements du nombre de composants ou de la couverture mettent à jour chaque readme dupliqué au moyen du générateur approuvé. - L’enregistrement des démos peut être réparti entre les métadonnées de route, une table de moteurs de rendu et un catalogue de page d’accueil ; mettez à jour chaque registre indépendant. - Dérivez les décomptes lisibles par machine des métadonnées de référence, plutôt que de les dupliquer manuellement. - Exécutez le vérificateur de synchronisation de la documentation et sachez quelles surfaces de démo ou générées il n’inspecte pas. - Régénérez les artefacts suivis au moyen de la commande approuvée, au lieu de modifier directement la sortie générée. Après toute modification d’enregistrement, vérifiez que la sélection de la route de démo affiche la page prévue ; un menu surligné avec une zone principale vide indique généralement une entrée de registre manquante. ## Éviter les erreurs connues comme les remplacements en masse et les pages de démo vides Utilisez des opérations étroites et vérifiables pour les modifications susceptibles de corrompre silencieusement de nombreux fichiers. - Pour les remplacements par script, vérifiez immédiatement chaque cible, tenez compte de l’immuabilité des opérations sur les chaînes et évitez les motifs qui échouent à travers du balisage entre guillemets. - Lorsqu’un outil de test écrit une sortie structurée, fournissez le chemin de sortie requis au lieu de supposer l’existence d’un fichier par défaut. - Pour une capture de DOM vers une image, intégrez les déclarations de police nécessaires dans la racine de capture lorsque le moteur de rendu ne peut pas lire le registre des polices du document. - Ne remaniez pas les dépendances internes intentionnelles des composants uniquement pour améliorer une mesure superficielle de tree shaking. - Optimisez la taille du paquet en préservant les import à la demande et en empêchant les ressources volumineuses, les polices et les composants inutilisés d’entrer dans les bundles des consommateurs. - Diagnostiquez les pages de démo vides en vérifiant chaque registre de page indépendant avant de modifier l’implémentation du composant. Transformez chaque défaillance récurrente confirmée en une vérification automatisée ciblée lorsque le dépôt lui offre un emplacement stable. ## Passer tous les contrôles de CI avant de livrer la modification Exécutez la vérification documentée du formateur, lint, les tests unitaires et le build de la bibliothèque dans l’ordre exigé par le dépôt. Exécutez la commande CI complète avant de proposer une contribution. Confirmez que : - tous les composants, exports, tests, documents et registres de démos modifiés sont synchronisés ; - les badges de couverture ou de nombre de composants ont été régénérés lorsque leurs entrées ont changé ; - aucune runtime dependency ni sortie générée non approuvée n’est entrée dans la modification ; - les contrats de sortie modulaire, de découpage CSS et de chargement des ressources sont toujours respectés ; - la modification visuelle correspond aux spécifications actuelles des jetons et des composants ; - la différence finale contient uniquement les modifications prévues du code source et de la documentation. Si un contrôle requis échoue, corrigez l’échec et relancez le contrôle concerné avant de présenter la différence. Utilisez le format de contribution du dépôt et n’exécutez les flux de lancement ou de publication que si la tâche les inclut explicitement. Indiquez précisément les contrôles exécutés et tous les contrôles plus larges laissés intentionnellement hors du périmètre.