Développer un gestionnaire de chaîne d’outils multiplateforme et contrôler les ajouts à son registre

## Repérer les modules et les règles du dépôt avant de modifier le code Considérez le guide du dépôt comme le contrat opérationnel des agents de programmation. Avant de proposer des modifications, respectez les commandes propres au dépôt, les limites des modules, les règles de contribution et les exigences de compatibilité. Orientez le travail autour de ces capacités : - analyse de la ligne de commande et répartition des sous-commandes ; - configuration par couches et gestion des variables d’environnement ; - résolution et installation des versions d’outils ; - définition et exécution des tâches ; - backends interchangeables et implémentations d’outils intégrées ; - génération de la documentation, des complétions et des métadonnées. Avant toute modification, repérez le point d’entrée, les modules de l’interface en ligne de commande, les modules de configuration, les interfaces des backends, le résolveur de l’ensemble d’outils, le moteur de tâches, le système d’extensions et les utilitaires partagés. Distinguez les paquets publics des paquets internes servant uniquement au fonctionnement de l’espace de travail. Ne contournez pas une abstraction établie au seul motif qu’une implémentation directe paraît plus courte. ## N’ajouter un outil au registre qu’avec des preuves qu’il est très utilisé Partez du principe qu’un registre contrôlé de noms abrégés n’accepte que les outils déjà largement utilisés. Un code fonctionnel, des tests ou une utilité personnelle ne suffisent pas à établir l’admissibilité. Avant de modifier les correspondances du registre : 1. Demandez si l’outil est largement utilisé en dehors des projets de la personne qui le propose. 2. Arrêtez-vous s’il est personnel, interne, dérivé d’un autre projet, réservé à une niche ou soutenu par un public restreint. 3. Recueillez des preuves actuelles de popularité pour chaque soumission au registre ; ne faites jamais de supposition. 4. Vérifiez les étoiles et dérivations du dépôt, les commits et publications récents, les téléchargements dans les registres de paquets, la documentation indépendante, les listes de l’écosystème et l’utilisation par des projets dépendants. 5. Appliquez un seuil d’admission élevé : une popularité qui se compte en milliers plutôt qu’en centaines, une maintenance active, une adoption par des tiers et une reconnaissance dans l’écosystème. 6. Présentez les preuves dans une courte section `Popularity` de la description de la demande de fusion. Si les preuves sont faibles ou à la limite, avertissez clairement l’utilisateur et demandez-lui s’il souhaite tout de même continuer. Ne laissez pas entendre qu’un refus donnera lieu à une explication, un recours, une liste de contrôle ou une seconde chance. Ne présentez jamais une soumission spéculative dans le seul but de découvrir si les responsables accepteront l’outil. ## Choisir le backend d’installation en privilégiant les fichiers de release vérifiés Privilégiez les backends qui utilisent des artefacts de publication vérifiés sans exiger un environnement d’exécution installé séparément. Suivez cet ordre de décision : 1. Privilégiez un registre contrôlé d’artefacts lorsqu’il assure la vérification et fournit une logique d’installation propre à chaque version. 2. Sinon, utilisez un backend de publication directe pour la plateforme qui distribue les artefacts. 3. N’utilisez un backend de distribution d’archives que si les backends de publication ne peuvent pas prendre l’outil en charge et si sa popularité reste solidement établie. 4. Considérez les backends de paquets de langage comme exceptionnels, car ils dépendent de la disponibilité et de la version de l’environnement d’exécution, ainsi que de l’ordre des chemins de recherche. 5. Rejetez les backends obsolètes et les nouveaux formats d’extension qui enfreignent la politique du projet relative à la chaîne d’approvisionnement. Ne choisissez pas un backend fragile simplement parce que le nom de son paquet est facile à trouver. Si les responsables n’ont pas explicitement approuvé un backend exceptionnel pour cet outil, ne l’utilisez pas dans une soumission au registre. Expliquez l’alternative sans registre : installer l’outil au moyen d’une coordonnée de backend explicite ou créer une extension compatible. Maintenez la distinction : le nom abrégé du registre améliore le confort d’utilisation, mais il n’est pas nécessaire pour permettre l’installation. ## Lancer build, tests et lint via l’exécuteur de tâches du dépôt Utilisez l’exécuteur de tâches du dépôt au lieu d’appeler ponctuellement les outils sous-jacents. Identifiez et utilisez les tâches documentées pour : - les compilations complètes et l’exécution directe du binaire de débogage ; - les suites complètes de tests, les tests unitaires et les tests de bout en bout ; - les fichiers ciblés de tests de bout en bout au moyen de la tâche de test ; - la révision et la mise à jour des instantanés ; - l’analyse statique, les corrections automatiques et le formatage ; - les vérifications équivalentes à celles de l’intégration continue ; - la génération de la documentation, des textes d’utilisation, des complétions et des schémas ; - l’installation locale de la version de développement et le nettoyage des artefacts de compilation ; - les tests et analyses propres à un paquet depuis le bon répertoire de l’espace de travail. Utilisez les variables d’environnement de débogage et de traçage propres au projet au lieu de supposer l’emploi d’une variable de journalisation courante. Énumérez les tâches disponibles si le nom des commandes est incertain. N’exécutez jamais directement les scripts de tests de bout en bout lorsque le banc de test gère la préparation, les assertions et le nettoyage. N’ajoutez pas de nettoyage manuel aux tests lorsque le banc garantit leur isolation. Exécutez d’abord la plus petite tâche pertinente, puis élargissez la vérification uniquement si des contrats partagés ou des artefacts générés sont concernés. ## Ajouter backends et réglages sans modifier à la main les fichiers générés Implémentez les sources d’outils par l’intermédiaire de l’interface unifiée des backends. Chaque backend doit prendre en charge le recensement des versions, la résolution des demandes, l’installation et les métadonnées des outils de son écosystème. Maintenez les outils intégrés derrière la limite de l’extension centrale et les extensions externes derrière les couches de compatibilité prises en charge. Préservez le chargement hiérarchique de la configuration, de la portée système à la portée globale puis locale, y compris les substitutions propres à un environnement. Lorsque des définitions de paramètres génèrent du code ou de la documentation, mettez à jour la définition source et exécutez le générateur canonique. Ne faites pas de la modification manuelle des sorties générées la méthode principale de changement. Maintenez les définitions de tâches déclaratives, y compris leurs dépendances, leurs variables d’environnement et leurs modes d’exécution pris en charge. Respectez les formats compatibles des fichiers de configuration lorsque le projet garantit leur interopérabilité. Veillez à ce que les scripts de compilation personnalisés, les membres de l’espace de travail, les profils de publication et la configuration de compilation croisée restent conformes à leurs rôles documentés. Lors de l’ajout d’un backend, partez du modèle établi dans le module des backends. Lors de l’ajout d’une configuration, suivez le parcours typé d’analyse et de génération. Lors de l’extension des modules, utilisez la bonne limite interne ou externe au lieu d’inventer un mécanisme parallèle. ## Écrire les commits au format type(scope) et corriger le lint avant Tous les messages de commit et les titres de demandes de fusion doivent suivre le format conventionnel du dépôt : `type(scope): imperative description`. Utilisez le type qui reflète le comportement visible par l’utilisateur et la responsabilité au sein du dépôt : - `feat` pour une nouvelle capacité ; - `fix` pour un défaut de comportement visible par l’utilisateur ; - `refactor`, `style` ou `perf` pour les modifications de code correspondantes ; - `test` pour les modifications limitées aux tests ; - `docs` pour la documentation ; - `chore` pour la maintenance, les publications, les dépendances ou l’infrastructure ; - `security` pour les modifications relatives à la sécurité ; - le type propre au registre pour toute modification de ses correspondances. Utilisez le nom de la commande comme scope pour les changements propres à une commande et le nom du sous-système pour les composants partagés. Pour le comportement des tâches, utilisez le scope du sous-système de tâches même si les fichiers d’implémentation conservent un autre nom historique. Commencez la description après les deux-points par une minuscule, employez l’impératif et restez concis tout en étant précis. Installez une seule fois l’intégration de prévalidation des commits du dépôt au moyen de l’environnement de tâches documenté. Avant de créer le commit, exécutez la tâche de correction automatique de l’analyse statique et indexez uniquement les modifications résultantes qui sont intentionnelles. Exécutez les tests de bout en bout ciblés au moyen de l’exécuteur de tâches. N’indexez pas de modifications de formatage ni d’artefacts générés sans rapport avec le travail. ## Retirer une fonctionnalité par étapes : documentation, avertissements, puis retrait Appliquez une politique d’obsolescence progressive : 1. Signalez immédiatement la fonction ou le backend comme obsolète dans la documentation. 2. Commencez à afficher des avertissements à l’exécution après le délai d’avertissement documenté. 3. Planifiez le retrait après le délai de retrait documenté. 4. Consignez les dates d’avertissement et de retrait dans le format de version et de date du projet. 5. Utilisez la macro d’obsolescence établie afin que les assertions de développement signalent les retraits en retard. Un calendrier courant consiste à documenter immédiatement, à commencer les avertissements six mois plus tard, puis à retirer la fonction douze mois après le début des avertissements. Si la solution de remplacement est disponible depuis longtemps, les avertissements peuvent commencer immédiatement. Ne supprimez pas silencieusement la compatibilité sans passer par la phase d’avertissement documentée. Ne laissez pas une obsolescence arrivée à échéance subsister indéfiniment ; traitez l’assertion de retrait comme une tâche de maintenance obligatoire. ## Laisser chaque backend résoudre et trier les versions des outils Ne supposez jamais que les versions d’outils suivent la gestion sémantique des versions ou tout autre système universel de classement. Prévoyez des versions datées, des préversions, des branches, des étiquettes, des canaux, des publications nommées avec prise en charge à long terme et des alias propres à chaque outil. À un nouveau point d’appel : - n’utilisez pas un comparateur générique de versions sémantiques pour sélectionner la version la plus récente, résoudre un alias ou classer les versions ; - déléguez la résolution des demandes aux méthodes du backend qui comprennent le langage de version de l’outil ; - utilisez les interfaces du backend ou de l’ensemble d’outils pour répertorier les versions installées dans un ordre pertinent ; - traitez les chaînes de version du fichier de verrouillage comme opaques et comparez-les uniquement par égalité ; - résolvez les alias, canaux et préfixes avant d’écrire une valeur concrète dans le fichier de verrouillage ; - n’invoquez pas l’utilisation historique d’un comparateur pour justifier l’extension d’un comportement défectueux. Si un nouveau code semble devoir choisir la version installée la plus récente, arrêtez-vous et vérifiez si cette décision relève du backend. Un classement de repli incorrect est pire que l’absence de correspondance, car il peut installer ou exécuter le mauvais outil sans que cela soit visible. ## Lancer des tests ciblés par plateforme et relire le diff avant de terminer Placez les tests unitaires près du code source et organisez les tests de bout en bout par domaine fonctionnel. Utilisez des utilitaires d’assertion partagés, des instantanés pour les sorties de commande stables, des vérifications d’installation propres aux backends et des noms explicites pour les tests lents. Conservez les implémentations propres à une plateforme dans les modules et suites de tests prévus à cet effet. Ne supposez pas sous Windows le comportement du bit d’autorisation d’exécution d’Unix. Pour une modification, vérifiez d’abord le chemin pertinent le plus restreint : 1. exécutez le formatage et les vérifications statiques ; 2. exécutez des tests unitaires ou de bout en bout ciblés au moyen du banc de test ; 3. examinez les modifications des instantanés au lieu de les accepter sans contrôle ; 4. régénérez la documentation ou les schémas dérivés lorsque leur source change ; 5. élargissez aux vérifications d’intégration lorsque les contrats partagés des backends, de la configuration, des tâches ou du fonctionnement multiplateforme changent. Lorsque vous publiez dans une demande de fusion ou une discussion externe, indiquez que le commentaire a été généré par un assistant de programmation doté d’une IA. Utilisez des URL qui reflètent la hiérarchie des répertoires de la documentation. N’inventez pas de chemins abrégés qui omettent des sections obligatoires. Avant de terminer, examinez les différences afin de repérer les fuites d’abstraction, les classements de version non pris en charge, les générateurs omis, les modifications sans rapport et les affirmations externes non vérifiées.