Modifier une boîte à outils d’UI en console selon sa doc actuelle et vérifier l’écran réel

## Suivre la doc actuelle du dépôt, pas les modèles des anciennes versions - Lorsqu'un projet annonce une réécriture majeure, supposer que les pratiques apprises auparavant peuvent être incompatibles, même si leurs noms semblent familiers. - Lire l'introduction actuelle à la migration du dépôt avant de concevoir, modifier ou examiner du code. - Utiliser le modèle minimal d'application, la terminologie, le cycle de vie et les notes de compatibilité actuels issus de la documentation versionnée du code source. - Privilégier la constitution du projet, le guide de contribution, le contexte lisible par machine et les règles imbriquées plutôt que la mémoire ou les exemples de versions antérieures. - Si la documentation actuelle contredit les connaissances antérieures, suivre le dépôt actuel et consigner l'écart au lieu de mélanger les deux conceptions. ## Avant de commencer, distinguer la création d’une app d’une modification de la boîte à outils - Commencer par classer la demande comme création d'application, contribution à la boîte à outils, correction de défaut, ou enregistrement et vérification visuels. - Utiliser le guide dédié aux applications et le recueil de modèles pour les applications consommatrices. - Utiliser la procédure de contribution pour les fonctionnalités et les défauts de la bibliothèque. - Utiliser la procédure d'enregistrement pour les changements visibles de l'interface et les preuves d'interaction. - Lire la documentation des concepts essentiels concernant le cycle de vie, la hiérarchie des vues, la mise en page, les événements annulables et la terminologie du domaine avant de modifier ces aspects. - Ne pas appliquer les mécanismes internes réservés aux contributeurs aux exemples d'applications, ni les raccourcis propres aux applications aux travaux sur la bibliothèque centrale. ## Passer les checklists avant chaque modification et après l’écriture du code - Avant chaque modification de fichier, parcourir la liste de contrôle d'actualisation du dépôt afin de détecter les erreurs courantes et les contraintes locales. - Après avoir écrit ou modifié du code, appliquer l'intégralité de la liste de validation postérieure à la génération. - Lire la règle détaillée de chaque sujet concerné, notamment le formatage, les déclarations de types, la syntaxe de construction, les modèles d'événements, le texte Unicode, l'organisation du code, la documentation, les tests, les diagnostics et les zones fragiles. - En mode planification, créer dans le répertoire prévu un plan Markdown comprenant les étapes de mise en œuvre, les fichiers concernés, les possibilités de réutilisation et la vérification. - Maintenir le plan en accord avec la portée réelle et le mettre à jour lorsque les preuves modifient le chemin de mise en œuvre. ## Mettre par défaut les nouveaux tests dans la suite parallèle - Restaurer les dépendances, effectuer une seule compilation et exécuter des tests ciblés sans recompiler tant que la compilation reste à jour. - Placer par défaut les nouveaux tests dans la suite exécutable en parallèle. - N'utiliser la suite non parallèle que lorsqu'un état statique à l'échelle du processus est inévitable, et expliquer cette dépendance. - Ne jamais ajouter de nouvelle couverture à une ancienne suite dont la réécriture ou la suppression est prévue. - Sélectionner une seule méthode ou classe pendant l'itération, puis étendre les tests au projet concerné une fois le résultat ciblé validé. - Consulter l'inventaire des tests avant de choisir une couverture d'intégration, de contrainte, de performance, parallèle ou non parallèle. ## Enregistrer le terminal en marche pour vérifier les changements d’UI - Ne pas livrer de changement visuel sans avoir observé l'interface en cours d'exécution. - Exécuter l'application dans un pseudoterminal, injecter des frappes représentatives et capturer la session affichée. - Lire l'enregistrement exploitable par machine image par image pour vérifier ce qui est réellement apparu, au lieu de se fier uniquement à un aperçu humain. - Joindre un artefact visuel lorsque les personnes chargées de l'examen doivent évaluer l'apparence ou l'interaction. - Pour des assertions déterministes, utiliser l'injection d'entrée dans le processus, le temps virtuel et la capture d'écran au niveau du pilote. - Vérifier la mise en page, le focus, la gestion des entrées, les graphèmes Unicode, l'annulation et le réaffichage au niveau affecté par le changement. ## Respecter les règles exactes d’espacement et de types du dépôt - Préserver les espacements exigés par le dépôt autour des appels et de l'indexation, le placement des accolades et les règles relatives aux lignes vides. - Utiliser des types explicites, sauf pour le petit ensemble de types primitifs intégrés autorisé par le guide local. - Privilégier la construction dont le type cible est déduit et la syntaxe des expressions de collection lorsqu'elles sont exigées. - N'utiliser qu'un seul type public ou internal par fichier. - Ordonner les membres et les champs de stockage selon la règle d'organisation du code. - Pour les paramètres de fonction de rappel inutilisés, suivre la convention de rejet du dépôt. - Exécuter l'outil de formatage et les contrôles postérieurs à la génération du dépôt ; ne pas minimiser les différences de style en les qualifiant de purement esthétiques. ## Utiliser des sorties anticipées et les termes propres au projet - Privilégier les clauses de garde et les sorties anticipées ; inverser les conditions plutôt que d'enfermer le chemin de réussite dans une imbrication profonde. - Appliquer la même règle de sortie anticipée aux méthodes, fonctions de rappel et boucles. - Employer systématiquement les termes du projet qui désignent la contenance et réserver les termes relationnels génériques aux références sans contenance. - Écrire un code qui s'explique par ses noms, ses types et sa structure avant d'ajouter des commentaires. - Dans la documentation de référence, les guides pratiques et la documentation d'API, énoncer l'objectif puis donner une instruction impérative directe. - Documenter les contrats publics, le comportement des procédures annulables, la gestion des graphèmes Unicode et les invariants non évidents dans le format exigé par le dépôt. ## Ajouter des tests de régression sans réduire la couverture - Marquer les tests produits par des agents avec l'annotation d'agent et de modèle acceptée par le dépôt. - Ne jamais réduire la couverture pour faire accepter un changement. - Éviter l'initialisation globale de l'application dans les tests, sauf si le comportement exige expressément un état à l'échelle du processus. - Privilégier une préparation isolée, des entrées déterministes, le temps virtuel et des assertions observables. - Placer chaque test dans la suite correspondant à son modèle d'état, et non simplement dans celle dont le nom de fichier est le plus proche. - Ajouter une couverture de régression pour le défaut ou le comportement visible par l'utilisateur, y compris les cas de mise en page et d'ordre des événements lorsqu'ils sont pertinents. ## Utiliser la journalisation du dépôt et ne pas toucher au code fragile ou sans rapport - Utiliser les fonctions de journalisation, de journalisation des tests et de traçage du dépôt ; ne pas écrire directement dans la console depuis le code de la bibliothèque ou des tests. - Ne pas remanier à titre de nettoyage accessoire un sous-système documenté comme fragile. - Ne pas modifier de code sans rapport avec le travail lors de la mise en œuvre d'une fonctionnalité ou d'une correction ciblée. - Ne pas introduire de nouveaux avertissements du compilateur, de l'analyseur, de la documentation ou des tests. - Relire les différences pour vérifier le formatage, la terminologie, le placement des tests et toute extension accidentelle de la portée avant d'annoncer la fin du travail. - Si une zone fragile doit être modifiée, isoler la modification minimale nécessaire et vérifier son comportement propre avant d'exécuter des tests plus larges.