Modifier un dépôt multimodule avec du code généré sans dépasser ce qui est autorisé

## Lire les consignes de la racine et de chaque dossier avant de modifier Commencez par repérer les consignes du dépôt qui régissent les fichiers que vous pouvez modifier. Considérez la documentation du projet et les fichiers d'instructions imbriqués comme les références pour les conventions locales, au lieu de supposer que les valeurs par défaut de l'écosystème s'appliquent. - Lisez les consignes à la racine ainsi que toute instruction plus précise dans le répertoire cible. - Consultez la présentation du dépôt, le guide de contribution, la préparation de l'environnement de développement, les consignes de test et la documentation de publication qui concernent la tâche. - Suivez l'instruction applicable la plus proche lorsque les consignes générales du dépôt diffèrent de celles du module. - Retrouvez les politiques citées dans les fichiers maintenus du projet au lieu de vous fier à des commandes mémorisées. - Repérez les fichiers d'attribution des responsabilités et les personnes chargées de revoir la zone concernée. - Consignez le processus pris en charge, les approbations requises et les attentes de validation avant toute modification. - Ne posez une question que lorsque des sources faisant autorité se contredisent ou qu'une décision lourde de conséquences reste irrésolue. ## Trouver le module responsable du changement et ses relecteurs Comprenez la répartition de la base de code avant de choisir où implémenter un comportement. Dans un dépôt multimodule, les limites de compilation, les manifestes de dépendances, les zones générées, les exemples, les tests et les unités de publication peuvent varier selon le répertoire. - Repérez le module responsable du comportement public et les composants de niveau inférieur dont il dépend. - Distinguez l'implémentation écrite manuellement du code généré, des modèles, des spécifications, des jeux de données de test et des exemples. - Examinez les manifestes des modules pour comprendre les limites des dépendances directes et indirectes. - Utilisez les règles d'attribution pour identifier les responsables du code, des services et de l'infrastructure partagée. - Déterminez si un changement affecte un seul paquet, une famille de modules ou une surface de compatibilité partagée. - Respectez l'arborescence et les conventions de nommage établies au lieu d'inventer des structures parallèles. - Laissez les modules sans rapport hors du changement, sauf si une dépendance vérifiée exige des mises à jour coordonnées. ## Utiliser les versions d’outils et les commandes de tâches du projet Utilisez la chaîne d'outils déclarée par le dépôt et le module cible. Les versions prises en charge, les exécuteurs de tâches, les générateurs et la préparation de l'environnement sont des décisions du projet, et non des valeurs à déduire de l'installation locale la plus récente. - Confirmez les versions du langage et des outils actuellement prises en charge à partir d'une politique ou d'une configuration maintenue. - Préférez les tâches gérées par le dépôt aux commandes directes du langage lorsqu'elles effectuent une préparation supplémentaire. - Exécutez les commandes depuis le répertoire du module ou de l'espace de travail prévu par le processus documenté. - Préservez la sélection de l'environnement, les options de compatibilité, les ressources générées et toute autre préparation effectuée par les tâches canoniques. - N'installez des prérequis globaux que lorsque le processus documenté l'exige explicitement. - Alignez les versions du générateur et du compilateur sur les versions verrouillées ou prises en charge par le projet. - Signalez les prérequis manquants comme un obstacle concret au lieu de modifier silencieusement le processus. ## Demander l’accord avant une publication, un changement de CI ou l’usage d’identifiants Les agents peuvent lire le code, expliquer son comportement, proposer des changements, réaliser des modifications autorisées, ajouter des tests, améliorer la documentation et contribuer à l'analyse des incidents ou des revues. Les opérations à plus fort impact restent soumises à une autorité humaine explicite. - Ne déclenchez pas de publication, n'approuvez aucune étape de publication et ne publiez aucun paquet sans approbation. - Ne modifiez pas l'intégration continue, les chaînes de déploiement ni les contrôles du processus de façon incidente dans le cadre d'un autre changement. - Ne modifiez pas les licences, les mentions légales ni les politiques de conformité sans autorisation explicite. - N'utilisez pas d'identifiants d'accès, ne contactez pas de services externes et ne modifiez pas d'état distant au-delà de la tâche accordée. - Traitez le tri des incidents, les suggestions d'étiquettes et la détection de doublons comme des recommandations, sauf si les changements d'état sont autorisés. - Arrêtez-vous avant toute opération destructrice ou modification d'un environnement protégé et demandez la décision requise. - Poursuivez l'implémentation et la validation ordinaires qui relèvent du périmètre sans demander de confirmation inutile. ## Modifier la spécification et régénérer au lieu d’éditer les fichiers générés Les paquets générés nécessitent une procédure de modification différente de celle du code écrit manuellement. Les modifications manuelles des résultats générés sont généralement écrasées et peuvent désolidariser l'implémentation de sa spécification de référence. - Repérez les fichiers générés grâce aux marqueurs du dépôt, aux manifestes, aux fichiers indiquant leur emplacement ou aux règles documentées des répertoires. - Ne corrigez pas manuellement les résultats générés lorsque le projet exige une régénération pilotée par les spécifications. - Modifiez la spécification, le modèle ou l'entrée du générateur qui fait autorité lorsque la documentation la désigne comme source de vérité. - Utilisez la commande de génération prescrite par le projet et les versions d'outils requises. - Examinez les différences générées pour détecter des fichiers inattendus, des variations de formatage ou des changements d'API sans rapport. - Maintenez les points d'extension manuels séparés des zones générées conformément aux conventions du dépôt. - Si la régénération est indisponible ou non autorisée, expliquez cette limite au lieu de présenter une modification temporaire comme une correction durable. ## Faire de petits changements qui restent rétrocompatibles Privilégiez les changements ciblés qui respectent les conventions de code établies et préservent la compatibilité. Un correctif limité et facile à examiner est plus sûr qu'une vaste refactorisation lorsque les deux répondent au besoin. - Lisez les implémentations voisines avant de choisir les utilitaires, les noms, les modèles d'erreur et l'emplacement des fichiers. - Préservez la compatibilité descendante, sauf si un changement incompatible est explicitement approuvé et documenté. - Suivez les conventions locales pour les noms exportés, les sigles, les commentaires et la documentation des API publiques. - Utilisez des erreurs descriptives qui conservent le contexte utile sans exposer de secrets. - Conservez intacts les en-têtes de droits d'auteur et de licence requis. - Respectez la politique de dépendances du module et n'ajoutez pas de dépendance externe pour un comportement déjà disponible localement. - Séparez le nettoyage sans rapport du changement demandé afin que les personnes chargées de la revue puissent évaluer clairement l'intention. ## Compiler et tester d’abord le module concerné, puis élargir si besoin Exécutez d'abord les plus petites commandes qui exercent le module concerné, puis élargissez la validation uniquement lorsque le comportement partagé ou la politique du dépôt l'exige. La réussite d'une commande n'a de valeur que si celle-ci couvre le chemin modifié. - Compilez le module cible au moyen de sa tâche documentée ou de la commande du langage. - Exécutez les tests unitaires directement pertinents avant les suites plus larges du paquet ou de l'espace de travail. - Ajoutez les vérifications de types, l'analyse statique, le formatage et la vérification des fichiers générés lorsque le module les exige. - Confirmez que la sélection des tests a bien inclus le paquet et les cas visés. - Examinez les variables d'environnement requises avant d'essayer des tests d'intégration ou en environnement réel. - Ne prétendez pas avoir validé un changement à partir d'une commande qui a ignoré des cibles ou dépendait d'un état externe indisponible. - Consignez les commandes exécutées, les résultats observés et les vérifications qui n'ont pas pu être menées à bien. ## Écrire des tests indépendants du réseau et de l’ordre, et des exemples qui fonctionnent Les tests doivent démontrer le changement de comportement et rester fiables d'une machine à l'autre. Les exemples doivent illustrer un usage pris en charge tout en respectant les conventions du dépôt relatives aux exemples exécutables. - Réutilisez la bibliothèque d'assertions et la structure de test déjà établies dans le module. - Lorsque vous corrigez un défaut, confirmez que le nouveau test échoue pour la raison attendue avant d'appliquer la correction. - Gardez les tests unitaires indépendants du réseau, des identifiants, d'un état sensible au temps et de l'ordre d'exécution. - Stockez les jeux de données dans l'emplacement prévu pour les données de test et limitez-les au strict nécessaire. - Isolez les paramètres des tests en environnement réel dans des fichiers d'environnement approuvés et ne consignez jamais de secrets. - Ajoutez des messages aux assertions lorsqu'ils améliorent sensiblement le diagnostic. - Placez les exemples dans la structure de nommage et de paquet attendue, et vérifiez qu'ils se compilent ou s'exécutent dans le processus de test documenté. ## Mettre à jour la doc du module et le journal des changements quand le comportement change La documentation fait partie de la surface d'implémentation. Mettez-la à jour lorsque, sans cela, les utilisateurs, les responsables de maintenance ou les outils de publication recevraient une vision incomplète ou trompeuse du changement. - Mettez à jour la présentation du module lorsque la préparation, le comportement pris en charge ou l'usage public change. - Ajoutez ou révisez les commentaires d'API conformément au style documentaire du projet. - Consignez les changements visibles par les utilisateurs dans l'historique requis. - Fournissez des exemples pour les nouvelles API publiques lorsque la politique du dépôt l'exige. - Synchronisez les instructions de préparation, de génération, de migration et de publication avec les commandes réelles. - Vérifiez que les références restent valides et n'orientent pas les lecteurs vers des emplacements privés ou obsolètes. - Évitez les modifications documentaires inutiles lorsque le comportement et le processus restent inchangés. ## Ouvrir la demande de changement depuis la branche approuvée après relecture du diff complet Utilisez la voie de contribution approuvée du dépôt et rendez le changement complet facile à examiner. Une contribution doit relier l'implémentation, les tests, la documentation et la justification sans modifier l'historique partagé protégé. - Créez le travail à partir de la branche de base approuvée et publiez-le par l'intermédiaire du fork ou du dépôt distant autorisé. - Examinez toutes les différences de la branche avant d'ouvrir une demande de changement. - Utilisez un titre descriptif et faites référence aux travaux associés lorsqu'ils existent. - Incluez les tests qui protègent contre de futures régressions et la documentation exigée par la politique. - Traitez les retours de revue au moyen de changements de suivi traçables, sauf si les responsables demandent une autre stratégie d'historique. - Vérifiez toutes les analyses automatisées requises et recherchez la cause des échecs au lieu de les contourner. - Ne modifiez pas les branches protégées, les branches de publication ni l'historique partagé sans autorisation explicite. ## Relire le code pour repérer les changements incompatibles et les erreurs de fichiers générés La revue de code doit privilégier l'exactitude, la compatibilité, l'intégrité de la génération, la qualité des tests, la sécurité et la maintenabilité. Appliquez les consignes propres au projet plutôt qu'une liste générique de règles de style. - Vérifiez que le changement appartient au module choisi et respecte son architecture. - Recherchez les changements incompatibles d'API ou de comportement, y compris les modifications subtiles des valeurs par défaut. - Vérifiez que les tests couvrent, selon les besoins, la réussite, l'échec, les limites et la reproductibilité. - Confirmez que les fichiers générés proviennent de la source et du processus de génération approuvés. - Examinez les changements de dépendances et de manifestes pour détecter les violations de politique ou les ajouts inutiles. - Vérifiez que la documentation et les historiques de changement sont complets et exacts. - Transmettez les constats aux responsables concernés et distinguez les défauts bloquants des améliorations facultatives. ## Signaler les failles de sécurité en privé et transmettre les résultats des tests Les signalements de sécurité, les publications, les approbations de pipeline, les licences et les identifiants d'accès nécessitent une gestion dédiée. Terminez le travail ordinaire par un transfert fondé sur des preuves tout en laissant les opérations protégées aux personnes autorisées. - Signalez les vulnérabilités de sécurité par le canal privé du projet, et non dans un ticket ou une discussion publics. - N'incluez jamais de secrets, de coordonnées privées ni de données de reproduction sensibles dans des artefacts publics. - Laissez les déclencheurs de publication, les approbations de déploiement et les décisions de licence aux responsables explicitement autorisés. - Expliquez les choix d'implémentation importants et reliez-les aux consignes applicables du projet. - Résumez les chemins modifiés, les tests effectués, les résultats observés et les limites restantes. - Identifiez les responsables appropriés du code ou du service lorsqu'une revue supplémentaire est nécessaire. - Indiquez clairement lorsqu'un accès externe, un outil indisponible ou une limite d'approbation a empêché une vérification complète.