Construire un système de design que l'IA sait utiliser et vérifier les composants qu'elle crée

## Repérer quels paquets gèrent les composants et la documentation avant tout changement Traitez le système de design comme un contrat de produit partagé, et non comme une collection de fragments visuels. Identifiez les paquets responsables des composants, de la documentation, des exemples, des surfaces de prévisualisation, des bancs de test et des utilitaires de migration avant toute modification. Considérez la branche courante du dépôt comme l’autorité pour les API et les conventions disponibles. Ne déduisez pas une prise en charge à partir de connaissances générales de la plateforme Web, d’une autre branche ou d’une version plus récente de la bibliothèque. Conservez le gestionnaire de paquets, l’environnement d’exécution, le format de modules et l’exécuteur de tests configurés, sauf si la tâche modifie explicitement la chaîne d’outils. ## Lire la documentation et la liste des composants de la branche actuelle avant de commencer Avant de travailler sur un composant : 1. Lisez les instructions du dépôt et du paquet qui régissent la cible. 2. Consultez l’aide locale de la ligne de commande et dressez la liste des sujets de documentation disponibles. 3. Chargez les principes de design, les tokens, les règles de thème et l’inventaire des composants. 4. Examinez les modèles de page lorsque la tâche concerne la mise en page plutôt qu’un seul élément de base. 5. Lisez l’API actuelle, les variantes, l’anatomie, les exemples et les contraintes du composant cible. Répétez cette préparation sur chaque branche, car la documentation générée et les API prises en charge peuvent différer. Après la mise à niveau d’une dépendance du système de design, exécutez l’utilitaire de migration du dépôt avant d’effectuer des modifications manuelles sans rapport avec cette mise à niveau. ## Mettre à jour ensemble l'en-tête de chaque fichier et la documentation du composant Maintenez deux couches de documentation complémentaires. Placez des métadonnées concises sur les entrées, les sorties et la position architecturale dans l’en-tête de chaque fichier source. Conservez les propriétés détaillées, les fonctionnalités, les exemples, les remarques d’accessibilité et les conseils de composition dans un fichier de documentation appartenant au composant. Lorsque l’implémentation change, mettez à jour les deux couches et suivez les marqueurs de synchronisation qui identifient les fichiers liés. Utilisez le format de documentation réellement accepté par le moteur de rendu ; par exemple, utilisez des blocs d’exemple sans balise de langage lorsque les blocs balisés par langage perturbent l’analyseur actif de documentation automatique. Vérifiez le résultat rendu au lieu de supposer qu’une syntaxe source valide produit une documentation valide. ## Noter quelles fonctions CSS l'outil de style prend vraiment en charge Consignez la version du moteur de styles et sa prise en charge vérifiée des at-rules, pseudo-classes, pseudo-éléments, sélecteurs composés, valeurs, animations, variables, thèmes, valeurs dynamiques et sélecteurs conditionnels. Distinguez la syntaxe prise en charge de celle qui se compile mais produit du CSS invalide ou inutilisable. Préférez les solutions natives de CSS lorsque la matrice confirme leur prise en charge. Les possibilités courantes comprennent les requêtes de média, de fonctionnalité et de conteneur ; les styles initiaux ; la portée ; les pseudo-classes d’interaction et de structure ; les pseudo-éléments de contenu généré ; les fonctions modernes de couleur et de dimensionnement ; les transitions ; et les images clés. Ne créez pas de solution de contournement en JavaScript simplement parce qu’une ancienne table de capacités ne répertoriait pas la fonctionnalité. ## Garder les effets de survol et de focus dans leur propre composant Représentez l’état des ancêtres, descendants et éléments frères au moyen du mécanisme de sélecteurs conditionnels pris en charge par le moteur de styles. Lorsque ce mécanisme exige un marqueur, appliquez-le à l’ancêtre réel et conservez sa définition près du composant responsable. Utilisez des marqueurs limités au composant pour les contrôles de formulaire et les autres éléments interactifs imbriqués. N’utilisez jamais de marqueur global par défaut lorsque des fenêtres contextuelles, panneaux ou conteneurs externes pourraient faire fuiter l’état de survol ou de focus vers le contrôle. Respectez les contrats de sélecteurs, notamment les conditions d’ancêtre composées uniquement de pseudo-classes, et ne simulez pas une imbrication CSS non prise en charge. Protégez les effets propres au survol par une requête de média vérifiant cette capacité afin que les appareils tactiles n’héritent pas d’états d’interaction persistants. Préservez le focus au clavier et le comportement de l’état désactivé indépendamment du survol. ## Faire la mise en page et l'animation en CSS plutôt qu'en JavaScript Utilisez directement grid, flexbox avec des espacements, les proportions, les contrôles de débordement et les propriétés de barre de défilement lorsqu’ils sont pris en charge. Préférez les requêtes de conteneur pour rendre les composants adaptatifs plutôt que de mesurer les éléments avec des observateurs, et utilisez des pseudo-classes structurelles pour les bandes alternées plutôt qu’un JavaScript fondé sur les indices. Implémentez les transitions d’entrée avec la prise en charge de starting-style plutôt qu’avec un état associé à une orchestration des images d’animation. Exprimez les solutions de repli CSS ordonnées par l’abstraction de fallback du moteur de styles plutôt que par une détection manuelle à l’exécution. Utilisez une prise en charge spécialisée du positionnement uniquement lorsque le CSS généré a été vérifié dans l’ensemble des navigateurs compatibles. ## Rendre liens et thèmes remplaçables pour ne pas copier les composants Acheminez les valeurs dépendantes de l’exécution par des fonctions de style typées plutôt que par des styles inline. Composez les styles conditionnels au moyen du mécanisme de propriétés de style du système au lieu d’alterner des noms de classe improvisés. Conservez les variables de thème et la création des thèmes dans les types de fichiers exigés par le compilateur, et utilisez des variables typées ou des constantes de compilation lorsqu’elles améliorent la validation. Rendez la navigation au moyen d’une abstraction de lien injectable plutôt qu’en codant en dur des éléments d’ancrage. Les utilisateurs peuvent ainsi fournir leur routeur sans créer de fork des composants. Respectez les contrats du dépôt concernant les ressources, les polices, le chemin public et le fournisseur de thème afin que les composants empaquetés restent portables. ## Tester si l'IA crée de bons composants, même tard dans une longue conversation Mesurez si les directives destinées à l’agent aident les modèles à générer un code de composant valide. Exécutez soit l’ensemble complet de prompts, soit un échantillon stratifié pour obtenir un retour rapide. Pour chaque prompt, utilisez un worker isolé qui lit la tâche, génère un composant à l’aide du système documenté, identifie lui-même les échappatoires et enregistre à la fois le code et les métadonnées d’évaluation. Ajoutez un mode de dégradation pour mesurer la rétention du contexte au cours d’une conversation de 10 tours comportant des tours de remplissage, de distraction et de récupération. Sondez des points représentatifs, tels que les tours 0, 6, 8 et 10, puis comparez la trajectoire de chaque prompt plutôt que de ne rapporter que le dernier tour. Associez les prompts de test, les résultats générés et les captures d’écran à un identifiant d’itération stable. Parallélisez les prompts indépendants, mais ne laissez pas les workers partager des fichiers de résultats modifiables. ## Garder chaque résultat de test et trouver où l'IA a contourné le système de design Stockez suffisamment de métadonnées structurées pour reproduire et comparer chaque cas : identifiants d’itération et de prompt, horodatage, modèle, persona, catégorie du prompt, profondeur de la trajectoire, prompt, réponse générée, jugement de réussite, composants utilisés et échappatoires détectées. Créez des pages de prévisualisation et réalisez des captures d’écran avant l’agrégation. Évaluez à la fois la réussite fonctionnelle et le fait que la sortie ait ou non contourné le système de design au moyen d’éléments bruts, de styles inline, d’une navigation codée en dur, de sélecteurs non pris en charge, d’éléments de base dupliqués ou de solutions de contournement en JavaScript pour du CSS pris en charge. Considérez l’autoévaluation du modèle comme un signal, et non comme une preuve. Combinez les contrôles mécaniques, les preuves de prévisualisation et un examen humain par échantillonnage. N’utilisez les résultats agrégés pour améliorer la documentation ou les API qu’après avoir identifié le mode de défaillance récurrent. ## Faire de petites vérifications après chaque changement et signaler ce qui a réussi Avant de modifier un composant, examinez sa documentation actuelle et déterminez si le besoin est mieux satisfait par une configuration, une composition, une nouvelle variante ou une éjection explicite du code source pour une personnalisation approfondie. Préservez les contrats publics et évitez de créer un élément de base parallèle lorsqu’un point d’extension établi existe déjà. Après la modification, mettez à jour la documentation synchronisée et exécutez les tests unitaires, contrôles de types et de lint, analyses des capacités de style et prévisualisations du composant les plus ciblés. N’étendez la vérification à l’ensemble complet que si la modification traverse des contrats partagés. Si la version du paquet principal a changé, exécutez l’étape de migration documentée et examinez son diff. Indiquez le comportement modifié, la documentation mise à jour, les contrôles réussis, toute capacité non prise en charge découverte et toute validation qui n’a pas pu être exécutée.