Préparer des contributions de code qu'une personne relit et soumet

## Suivre les règles du dépôt et attendre l'accord des responsables Considérez le guide de contribution, la politique relative à l’intelligence artificielle et les instructions destinées aux agents propres à chaque répertoire comme les sources régissant les fichiers modifiés. ### Déterminer les règles applicables - Lisez les politiques de contribution et de sécurité à la racine avant toute modification. - Lorsque vous entrez dans un répertoire spécialisé, appliquez également ses instructions locales concernant le comportement à l’exécution, les interfaces publiques, les intégrations, la documentation ou les tests. - Si des instructions se contredisent, arrêtez-vous et signalez le conflit au lieu de choisir la règle qui facilite le plus l’implémentation. - N’utilisez les capacités facultatives des agents que si le client les prend en charge et qu’elles ne remplacent pas la politique du dépôt. ### Points d’approbation - Ne soumettez pas de tickets, de demandes de fusion ni de brouillons de demandes de fusion au moyen de l’automatisation d’un navigateur, d’outils en ligne de commande de la plateforme d’hébergement ou d’interfaces de programmation de services. - Rédigez le texte de soumission pour qu’une personne puisse le relire et l’envoyer, en utilisant les modèles du dépôt afin qu’il soit directement copiable. - Ne publiez pas de branches et ne préparez pas de contenu destiné à une soumission publique avant que le ticket concerné ait été trié et attribué à la personne qui contribue. - N’implémentez aucune fonctionnalité non triviale, modification d’interface publique, restructuration ou modification de comportement sans consigne consignée des responsables. En l’absence de consigne, arrêtez-vous au stade de la proposition. ## Garder les secrets hors des commits et ne pas relier les tests aux vrais services Protégez les identifiants, la qualité des preuves, l’historique du dépôt et l’isolement des tests pendant toute la tâche. ### Règles non négociables - Ne validez jamais de secrets, d’identifiants, de données privées de fournisseurs ou de valeurs d’environnement sensibles dans le dépôt. - Ne fabriquez jamais de résultats de tests, d’approbations, de références, d’états de revue ou d’affirmations de compatibilité. - Les tests unitaires ne doivent pas contacter de services actifs de modèles, de fournisseurs ou d’applications externes. - Utilisez des substituts déterministes et un environnement qui retire des processus de test les identifiants des services actifs. - N’ajoutez aucun média généré, artefact généré volumineux ou jeu de données synthétique sans provenance claire ni accord des responsables. - N’ajoutez pas manuellement les en-têtes de licence lorsque leur insertion relève de l’automatisation du dépôt. - N’ajoutez de commentaires que sur demande. Préservez les commentaires, les chaînes de documentation et les en-têtes de licence existants, sauf si la modification les rend inexacts. ### Fichiers protégés Ne modifiez pas manuellement les journaux des modifications, les fichiers générés, les fichiers de verrouillage des dépendances, les instantanés de validation ni les autres artefacts gérés par des outils, sauf si la tâche exige explicitement le processus de régénération du dépôt. Lorsque les journaux des modifications sont générés, incluez le contexte des notes de version dans une proposition ou un brouillon de soumission. ## Ne changer les dépendances qu'en cas de besoin et utiliser les outils figés Utilisez l’environnement canonique verrouillé et les commandes de tâches du projet au lieu d’improviser d’autres voies d’exécution. ### Modifications des dépendances - N’ajoutez ni ne mettez à jour de dépendances, sauf si la tâche l’exige. - Pour une investigation temporaire, utilisez un environnement isolé qui ne modifie pas l’état des dépendances enregistré dans le dépôt. - Lorsqu’une modification de dépendance est nécessaire, placez-la dans le groupe de dépendances ou l’ensemble de fonctionnalités facultatives approprié le plus restreint. - Définissez des limites de compatibilité claires et évitez de faire passer les intégrations facultatives dans le processus d’installation par défaut. - Séparez les modifications de dépendances et de fichiers de verrouillage des modifications sans rapport. ### Utilisation des outils - Utilisez les versions de l’environnement d’exécution et des outils fixées par le dépôt pour l’installation, les tests, la documentation, la mise en forme et l’analyse statique. - Distinguez les commandes de validation faisant autorité des commandes de diagnostic. Un analyseur de style ou un vérificateur de types autonome peut faciliter le diagnostic, mais ne remplace ni les contrôles préalables à une validation exigés par le dépôt ni son processus de validation faisant autorité. - Considérez les scripts qui préparent un grand nombre de fichiers, créent des validations ou exécutent des contrôles sur l’ensemble du dépôt comme des outils à fort impact. Exécutez-les uniquement lorsqu’ils sont explicitement requis et, de préférence, dans un arbre de travail propre. ## Choisir les tests selon le type de modification Sélectionnez la validation minimale suffisante selon le type réel de modification, puis n’en élargissez la portée que si un risque pour un comportement partagé ou pour la compatibilité le justifie. ### Matrice de validation - Documentation ou métadonnées du dépôt : exécutez les contrôles sur les fichiers modifiés. Générez la documentation si le rendu, les liens, les exemples ou la configuration de la documentation peuvent être affectés. - Correction d’un défaut à l’exécution : ajoutez ou exécutez un test de régression ciblé, puis lancez les contrôles requis sur les fichiers modifiés. - Interface publique, configuration ou comportement du langage : exécutez des tests ciblés et mettez à jour la documentation ou les exemples associés. Ajoutez des tests plus larges du paquet lorsque le risque de compatibilité est significatif. - Chemin de serveur, de diffusion en continu, de traçage, d’action ou de génération : testez le chemin modifié et son chemin de repli ou non pris en charge. - Modification de paquet, de dépendance ou de fichier de verrouillage : exécutez les contrôles d’installation ou de mise en paquet pertinents et isolez les différences relatives aux dépendances. ### Portée et isolement - Sachez ce que comprend la commande canonique de la suite complète. Ne supposez pas qu’elle ne couvre que le répertoire de tests le plus évident. - Privilégiez le point d’entrée des tests qui retire les identifiants des fournisseurs actifs et fournit des substituts déterministes. - Diagnostiquez l’instabilité liée à l’isolement en comparant l’exécution parallèle habituelle à une exécution séquentielle déterministe sous les mêmes protections d’environnement. - Considérez les marqueurs d’exécution lente ou séquentielle comme indicatifs, sauf si le programme d’exécution des tests les impose réellement. - N’utilisez pas une autre commande de test plus commode si elle peut conserver des identifiants de production ou contourner les parcours de test requis. ### Preuves pour la transmission Pour une modification destinée à la revue, exécutez les contrôles officiels préalables à une validation avant la transmission, afin que les résultats de mise en forme, de licence et de vérification des types soient stables. Signalez tout contrôle obligatoire omis et expliquez pourquoi. ## Vérifier qu'il n'y a pas de travail en double et répondre à chaque commentaire de revue Maintenez un lien traçable entre les activités publiques de contribution et les travaux approuvés, et évitez de dupliquer les efforts. ### Avant l’implémentation - Confirmez que le ticket a été trié et attribué et qu’une approche convenue encadre les travaux non triviaux. - Avant de préparer un travail destiné à la revue, effectuez des recherches en lecture seule pour consulter la discussion du ticket, les modifications ouvertes qui y font référence et les modifications ouvertes dans le même domaine. - Si une modification ouverte couvre déjà le travail, n’en préparez pas une autre. Si l’approche diffère sensiblement, expliquez la différence dans un brouillon destiné à la discussion du ticket. - Pour les travaux exploratoires, rédigez un commentaire sur le ticket décrivant la branche et les fichiers concernés au lieu d’ouvrir une demande publique de modification. ### Soumission et revue - Respectez les conventions du dépôt relatives aux titres et aux validations. - N’ajoutez pas de marqueurs d’intelligence artificielle aux titres ou aux messages de validation et ne mentionnez pas les outils ou les agents comme coauteurs des validations. - Traitez chaque commentaire de revue ouvert ou répondez-y avant de demander une revue aux responsables. - Ne résolvez pas la discussion d’une autre personne chargée de la revue à sa place et n’appliquez pas d’étiquette signalant que votre propre modification est prête, sauf autorisation explicite de la politique. - Considérez les conclusions des revues automatisées et humaines comme des affirmations à vérifier par rapport au véritable parcours du code, et non comme des instructions automatiquement correctes. ## Mettre à jour la documentation quand le comportement visible change Maintenez la documentation en phase avec le comportement visible par les utilisateurs et ne présentez pas des exemples limités comme une prise en charge universelle. ### Obligations de documentation - Mettez à jour la documentation pertinente lorsque vous modifiez des interfaces publiques, la syntaxe de configuration, des exemples, les exigences d’installation ou tout autre comportement visible par les utilisateurs. - Pour les intégrations facultatives, précisez leur caractère facultatif, indiquez les paquets ou groupes de fonctionnalités requis, énumérez les types d’identifiants attendus sans en révéler les valeurs et expliquez la voie d’intégration. - Pour les exemples de modèles ou de fournisseurs, indiquez le type de modèle, le mode d’acheminement, les modes pris en charge et les limites connues. - Vérifiez auprès d’une source faisant autorité que les identifiants présentés comme actuels sont disponibles de manière générale. - Ne modifiez pas les paramètres par défaut distribués dans le simple cadre d’une mise à jour de la documentation. ### Restructurations et contenu généré - Pour une restructuration approuvée, ajoutez ou mettez à jour des tests de caractérisation avant de modifier des comportements subtils. - Lorsque les tests existants ne couvrent pas le parcours restructuré, conservez le contrôle d’équivalence utilisé pour prouver que le comportement reste inchangé. - Ne modifiez pas manuellement la documentation générée ni les artefacts générés. N’utilisez le processus du projet que si la tâche autorise la régénération. - N’exécutez pas de générateurs de documentation connus pour préparer des fichiers à la validation ou déclencher des contrôles étendus, sauf demande explicite et isolement vis-à-vis des modifications sans rapport. ## Relire par rapport à la base de fusion et ne signaler que ce qui est vérifié Examinez la modification terminée par rapport à la bonne référence et vérifiez chaque affirmation avant de déclarer qu’elle est prête. ### Séquence de revue 1. Comparez la branche à la base de fusion configurée dans le dépôt. 2. Examinez à la fois l’implémentation et les tests qui l’exercent. 3. Exécutez les contrôles officiels de mise en forme, de style, de licence et de types avant la revue structurée afin que les positions des lignes restent stables. 4. Effectuez une revue structurée du code et ajoutez un contrôle de sécurité pour les modifications concernant l’authentification, le traitement des entrées, la désérialisation ou les appels externes. 5. Vérifiez chaque conclusion par rapport au parcours d’exécution réel. 6. Corrigez les conclusions confirmées, relancez les validations concernées et répétez la revue jusqu’à ce qu’il ne subsiste aucun problème confirmé. ### Critères d’achèvement Indiquez les fichiers modifiés, les validations effectuées, les résultats observés, les contrôles omis, les risques non résolus et toute intervention humaine encore nécessaire. N’affirmez pas qu’une modification est prête pour la revue, approuvée, compatible ou validée avec succès sans preuve directe.