Modifiez un grand monorepo de plateforme en gardant tous les clients concernés synchronisés

## Lisez les règles de la racine, puis les instructions de chaque dossier Utilisez la racine du dépôt comme point de coordination et le fichier d’instructions local le plus proche comme autorité propre à la tâche. Appliquez d’abord les règles de la racine, puis ajoutez celles dont relève chaque répertoire affecté, au lieu de supposer que les conventions d’un module régissent toute la modification. Pour les zones dépourvues de fichier d’instructions local, utilisez le guide de développement maintenu le plus proche, le fichier README du module et le processus d’intégration continue comme sources de référence suivantes. Lisez chaque guide applicable avant de modifier un élément transversal. ## Repérez quel module gère chaque partie avant de modifier Déterminez quels modules sont responsables du plan de contrôle, des composants d’exécution, des spécifications publiques, des bibliothèques clientes, des ressources de déploiement, de l’interface en ligne de commande, des tests de bout en bout, de la documentation, des exemples et des propositions d’architecture. Confiez le cycle de vie et le comportement de configuration au responsable du plan de contrôle, le comportement des processus d’exécution au guide du composant le plus proche, les modifications de schémas publics au responsable des spécifications, la génération des clients au responsable des bibliothèques, le comportement de déploiement à son responsable opérationnel ou de mise en paquet, et le comportement des commandes au responsable de la CLI. Pour une modification qui touche un contrat, son implémentation et ses clients, commencez par la spécification publique, puis consultez tous les guides des consommateurs affectés. Maintenez les API des composants, les hypothèses des tests et l’intégration du déploiement en accord avec le même contrat. ## Confirmez l’objectif et ne changez que les lignes nécessaires Énoncez les hypothèses, rendez les ambiguïtés visibles et demandez une orientation lorsque la requête admet des interprétations contradictoires. Transformez les travaux non triviaux en critères de réussite observables avant l’implémentation et arrêtez-vous lorsqu’une décision est nécessaire. Choisissez la solution la plus limitée qui satisfait la demande. Évitez les fonctionnalités spéculatives, les abstractions à usage unique, la configurabilité superflue, les remaniements sans rapport et la suppression de travaux préexistants. Ne touchez qu’aux fichiers et aux lignes nécessaires à la tâche, respectez le style local, ajoutez ou mettez à jour des tests ciblés lorsque le comportement change, et poursuivez les itérations jusqu’à ce que les vérifications réussissent ou que le blocage restant soit explicite. ## Mettez à jour clients et docs quand la spécification publique change Considérez les spécifications publiques comme les sources contractuelles faisant autorité. Lorsque le comportement visible par l’utilisateur change, maintenez synchronisés la spécification, l’implémentation, les bibliothèques clientes, la documentation, les exemples, la configuration, le comportement des commandes et les livrables de publication. Lorsque les API de déploiement ou les ressources de l’orchestrateur changent, mettez également à jour ou vérifiez les manifestes générés, les paquets de déploiement, le comportement du contrôleur, l’intégration au serveur et la documentation opérationnelle. Ne laissez pas un contrat diverger volontairement d’une implémentation sans approbation explicite. Mettez à jour la documentation destinée aux utilisateurs et aux opérations avant ou en même temps que l’implémentation, afin que le comportement documenté reste la promesse publique de référence. ## Corrigez la source, puis régénérez les fichiers générés Ne modifiez jamais une sortie générée comme unique correctif. Repérez et modifiez le schéma, le modèle, la configuration ou l’entrée du générateur qui fait autorité, puis régénérez tous les clients, manifestes, références, exemples et artefacts mis en paquet affectés au moyen du processus pris en charge. Examinez la différence générée pour détecter les changements inattendus et vérifiez les consommateurs en aval par rapport au contrat régénéré. Gardez les adaptateurs écrits à la main séparés du code généré et préservez la limite de responsabilité que le dépôt établit entre eux. Si la régénération est bloquée, signalez l’outil ou l’environnement manquant et laissez la source et les sorties dérivées dans un état incomplet clairement identifié, au lieu de les présenter comme synchronisées. ## Demandez avant tout changement public incompatible Privilégiez les modifications additives et rétrocompatibles pour les API publiques, les interfaces clientes, la configuration, les protocoles, le comportement des commandes, les ressources de déploiement, les annotations, les libellés et les valeurs des paquets. Demandez confirmation avant d’apporter une modification publique incompatible, d’introduire une divergence contractuelle intentionnelle ou de modifier un comportement visible sans voie de migration claire. Décrivez les consommateurs affectés, les conséquences sur la compatibilité, les exigences de migration et les effets sur la publication avant de solliciter l’approbation. Ne dissimulez jamais une modification incompatible dans une différence générée et ne mélangez pas des travaux sans rapport sur d’autres composants dans la même modification. Rendez la décision de compatibilité approuvée explicite dans l’implémentation, la documentation, les tests et les notes de publication. ## Vérifiez d’abord la plus petite portée, puis élargissez Exécutez les outils de formatage, les analyseurs de style, les tests unitaires, les vérifications de contrats et les assertions sur les sorties de commandes à l’échelle du fichier ou du paquet avant une validation plus large. Étendez ensuite la vérification à l’intégration, aux différents langages, au déploiement ou à la construction de la documentation lorsque la modification franchit ces limites. Vérifiez l’aide et la sortie des commandes avec les tests de la CLI, les exemples de contrats avec les vérifications de schémas, le comportement des clients dans toutes les langues prises en charge et la sortie de déploiement sur la plateforme affectée. Mettez à jour les tests ciblés chaque fois qu’un comportement change ou qu’un défaut est corrigé. Mentionnez chaque vérification non exécutée ou bloquée dans le compte rendu final. Ne déclarez pas le travail terminé tant qu’une vérification obligatoire échoue ou qu’un consommateur affecté demeure non vérifié sans limitation explicite. ## Gardez chaque doc à un seul endroit et mettez un lien au lieu de copier Conservez les guides détaillés destinés aux utilisateurs et aux opérations dans l’arborescence de documentation prévue. Réservez le fichier README racine au point d’entrée du dépôt et les fichiers README des paquets publiables à l’installation, aux démarrages rapides et aux points d’entrée des paquets. Gardez les fichiers README internes des composants minimaux lorsqu’une page de documentation maintenue existe. Stockez les exemples exécutables dans l’arborescence des exemples et leurs pages explicatives dans celle de la documentation ; utilisez les documents de proposition comme autorité et les pages communautaires uniquement comme index lorsque telle est la convention du dépôt. Créez des liens vers les politiques communautaires et de développement au lieu de les dupliquer. Privilégiez dans les fichiers du dépôt les liens relatifs à la version afin que la documentation suive la branche ou l’étiquette extraite, et n’utilisez pas un site Web public comme seule source depuis du code versionné. ## Suivez les règles de pages du site de docs et compilez sans erreur Utilisez le moteur de documentation configuré et la configuration du site statique sans introduire de génération non documentée lors de la construction. Placez les images dans le répertoire public de ressources prévu et référencez-les selon la convention de chemin approuvée du site. Attribuez à chaque page publiée les métadonnées requises, employez le style configuré pour les liens internes et utilisez des liens sources complets pour pointer hors de l’arborescence de documentation. Appliquez de manière cohérente les conventions approuvées pour les encadrés, les groupes de code et la navigation. Excluez du site publié les instructions réservées aux contributeurs. N’ajoutez des copies localisées que lorsque la politique de localisation les autorise, et exécutez la construction de la documentation sans aucune erreur avant de considérer les modifications comme prêtes à être publiées. ## Examinez les changements incompatibles et signalez les risques restants Examinez en priorité les modifications incompatibles des spécifications publiques, des interfaces clientes, de la configuration, du comportement des commandes, des ressources de déploiement et des protocoles. Signalez les modifications inutiles, incohérentes en interne, difficiles à implémenter pour les consommateurs ou dépourvues d’une voie de migration crédible. Recherchez les ruptures des limites des sources de référence, les violations du découpage en couches, les sorties générées obsolètes, les tests manquants, les comportements non documentés et les régressions de compatibilité. Distinguez les défauts confirmés des risques non vérifiés et citez le contrat ou le consommateur affecté. Terminez par un rapport fondé sur des preuves couvrant les zones modifiées, les consommateurs synchronisés, les vérifications exécutées, les validations bloquées, les décisions de compatibilité et les risques restants.