Envoyer des demandes de fusion écrites par l’IA à un framework open source avec relecture humaine

## Signaler le travail de l’IA et pousser uniquement sur des branches créées par l’agent Considérez les écritures externes, la prise en charge des tickets, les branches et l’attribution comme des actions contrôlées. - Signalez clairement les descriptions de demandes de fusion, les commentaires de révision et les commentaires de tickets générés par l’IA, et nommez l’opérateur humain lorsque le projet l’exige. - Déterminez l’opérateur ou l’auteur à partir d’une source authentifiée. Ne devinez jamais une identité ; omettez-la si la recherche échoue. - Ajoutez aux commits assistés par l’IA la mention de coauteur requise pour l’IA. - N’ouvrez pas plus de 10 demandes de fusion par opérateur et par jour lorsque telle est la limite du projet ; privilégiez quelques changements complets et bien testés. - Ne travaillez que sur des tickets admissibles et non attribués. Attribuez le ticket à l’opérateur et faites-le passer à l’état actif avant l’implémentation. - Ne poussez que vers une branche créée par l’agent. Ne poussez pas vers la branche d’un contributeur sans autorisation explicite. - Préférez un fork personnel pour ne pas encombrer le dépôt en amont, choisissez un nom de branche explicite comprenant le sujet et l’identifiant du ticket, puis supprimez la branche après la fusion ou le rejet. Maintenez à jour les métadonnées de la demande de fusion. Après chaque push, actualisez son titre et sa description afin qu’ils décrivent toujours l’ensemble complet des changements. ## Lire l’historique du code et les tickets passés avant de modifier le code Ne supposez pas qu’un code qui semble incorrect est défectueux. Les systèmes anciens intègrent souvent des contraintes antérieures invisibles dans l’implémentation actuelle. 1. Reproduisez et validez le problème signalé ; remettez en question les hypothèses incomplètes ou erronées. 2. Examinez l’historique du fichier et les informations d’attribution ligne par ligne, puis lisez les messages de commit pertinents et les tickets liés afin de comprendre pourquoi le code existe. 3. Recherchez dans les tickets connexes les approches rejetées, les discussions antérieures et les décisions intentionnelles. 4. Lisez les documents de conception de la zone concernée, en particulier ceux relatifs à la sécurité, à la télémétrie, au contexte de journalisation et aux contrats publics de nommage. 5. Si un module en a remplacé un autre, distinguez les changements intentionnels des omissions accidentelles. 6. Si le correctif proposé annule un changement antérieur intentionnel, arrêtez-vous et réévaluez la situation. Si cette annulation reste justifiée, expliquez pourquoi malgré le raisonnement d’origine. Présentez à l’opérateur les conclusions, les risques, les ambiguïtés et la possibilité que le problème soit infondé avant l’implémentation. Appliquez la même rigueur lors de la révision d’une demande de fusion. Vérifiez les versions, publications et comportements actuels des dépendances externes auprès de sources faisant autorité. Ne formulez jamais d’affirmations faisant autorité sur des projets externes susceptibles d’évoluer en vous fondant uniquement sur les connaissances d’entraînement du modèle. ## Remplacer les délais fixes des tests par des attentes avec limite de temps N’utilisez jamais de délais fixes dans les tests. Ils rendent les tests lents, instables et non déterministes. - Pour un composant doté d’assertions temporisées natives, utilisez ces assertions pour les conditions qu’elles représentent déjà. - Utilisez un utilitaire d’attente asynchrone pour les autres conditions, par exemple pour attendre un décompte intermédiaire avant l’action suivante. - N’enveloppez pas une assertion bloquante native dans un utilitaire d’interrogation périodique ; cela ajouterait une interrogation redondante autour d’un mécanisme de synchronisation déjà existant. - Définissez toujours un délai maximal explicite lorsque vous utilisez un utilitaire d’attente. - Utilisez une condition faisant l’objet d’une assertion ou un prédicat clair, jamais une boucle d’attente active. - Lorsque vous modifiez un test contenant un délai fixe, remplacez-le par l’assertion temporisée native ou par l’utilitaire d’attente général. Par exemple, `MockEndpoint.assertIsSatisfied()` attend déjà en interne, tandis qu’Awaitility convient aux conditions que `MockEndpoint` ne peut pas exprimer. Les nouveaux tests ne doivent pas introduire `Thread.sleep()`. ## Définir à qui faire confiance et signaler les failles en privé Utilisez le modèle de menace de référence du projet pour déterminer qui est digne de confiance, où se situent les frontières de confiance et ce qui relève du framework. - Considérez les auteurs du code et les opérateurs de déploiement comme dignes de confiance lorsqu’ils configurent intentionnellement des routes exécutables, des expressions, des secrets, l’exposition réseau et les paramètres d’exécution. - Considérez comme non fiables les expéditeurs de messages externes et toutes les données circulant par une route de confiance. - Le framework ne doit pas, de lui-même, transformer des données non fiables en exécution de code, lecture de fichiers, falsification de requêtes ou contournement d’autorisation. - L’exécution intentionnelle de code par un auteur de confiance, une mauvaise configuration par un opérateur et un comportement dangereux activé par consentement explicite ne constituent pas, à eux seuls, des vulnérabilités du framework. Les constats valides démontrent le franchissement d’une frontière de confiance dans une configuration par défaut ou raisonnablement prévisible. Les catégories habituelles comprennent la désérialisation non sécurisée, XXE, l’injection d’expressions, la traversée de chemins, SSRF, l’exploitation abusive de la répartition par en-têtes, le contournement de l’authentification ou de l’autorisation, la divulgation de secrets, les paramètres par défaut non sécurisés et l’injection dans les requêtes construites par le framework. L’épuisement des ressources en l’absence de contrôles obligatoires, les interfaces d’administration délibérément exposées, les constats concernant des dépendances transitives inaccessibles et les résultats d’analyseur dépourvus de preuve de franchissement d’une frontière sont normalement hors du périmètre du framework. Ne divulguez jamais une vulnérabilité présumée au moyen d’un ticket public, d’une demande de fusion, d’une liste de diffusion ou de tout autre canal public. Suivez la procédure de signalement privé et cessez tout travail public. ## Bloquer les données entrantes non fiables et laisser désactivés les réglages de sécurité risqués Examinez chaque consommateur, analyseur syntaxique, format de données, convertisseur de types, stockage d’agrégation et option liée à la sécurité au regard de scénarios d’exploitation concrets. - Filtrez les en-têtes internes du framework dans les messages entrants non fiables avant leur acheminement, selon une stratégie stricte et insensible à la casse. - Ne désérialisez pas d’objets non fiables sans filtre d’entrée approprié. - Marquez les secrets comme métadonnées secrètes et classez les options de configuration dangereuses selon leur famille de risques. - Maintenez par défaut le refus des options sensibles à la sécurité, sauf activation explicite. Tout assouplissement d’un paramètre par défaut exige une note de mise à niveau et l’approbation explicite d’un responsable de maintenance. - Vérifiez que les options d’authentification et d’autorisation imposent l’émetteur, le public visé, la signature et chacun des sous-chemins annoncés qu’elles prétendent protéger. Pour les déploiements, utilisez le profil de sécurité de production, récupérez les secrets par l’intermédiaire d’un coffre-fort approuvé, configurez un chiffrement TLS vérifié, désactivez la sérialisation non sécurisée pour les consommateurs non fiables et réservez les consoles de gestion ainsi que l’administration de l’environnement d’exécution aux réseaux de confiance. La révision de sécurité doit distinguer le comportement d’une route de confiance de celui du framework, tout en empêchant les données non fiables de franchir la frontière. ## Joindre tests et documentation à chaque changement et committer les fichiers générés Chaque fonctionnalité ou correction de bogue doit inclure les tests appropriés et une documentation destinée aux utilisateurs. Documentez les modifications des valeurs par défaut, du comportement de découverte, des options renommées ou supprimées, des en-têtes, des API ou SPI, des dépréciations et des migrations dans le guide pertinent. - Exécutez les vérifications de référence du dépôt concernant le formatage, l’ordre des imports, le style, les tests unitaires, les tests d’intégration et les sources pour la surface modifiée. - Régénérez et commitez les artefacts générés ; ne laissez pas l’intégration continue découvrir des changements générés. - Évitez d’introduire de nouveaux défauts d’analyse statique, des régressions de maintenabilité, des faiblesses courantes et des API dépréciées, même lorsqu’une tâche de validation locale n’exécute pas tous les analyseurs. - Importez les classes et utilisez des noms simples plutôt que des noms de classes entièrement qualifiés, sauf lorsque deux classes portent le même nom simple. Conservez les exclusions explicites du code généré. - Ajoutez à chaque nouveau type et à chaque nouvelle méthode d’API publique la balise obligatoire indiquant la version d’introduction, utilisez la prochaine version publiée et placez-la après les autres balises de documentation. - Mettez à jour chaque registre de métadonnées qui découvre les extensions imbriquées ; un répertoire source ne suffit pas toujours à rendre une extension visible pour les compilations, les catalogues ou la documentation générée. - Pour les conteneurs de tests d’intégration, vérifiez chaque architecture prise en charge. Utilisez un miroir de registre approuvé ou des exclusions explicites propres à l’architecture lorsqu’aucune image n’existe. - Utilisez des références documentaires internes pour les pages internes et vérifiez les ancres interversions par rapport à la version publiée visée, pas seulement à la branche de développement. Lors de la dépréciation d’une fonctionnalité, mettez à jour simultanément les métadonnées de compilation, les annotations d’API, le titre de la documentation et le guide de mise à niveau. ## Demander deux relecteurs et un accord humain avant de fusionner Ne demandez une révision que lorsqu’une demande de fusion est prête, jamais tant qu’elle reste en brouillon. - Identifiez les responsables de maintenance actifs pertinents à partir de l’historique récent des fichiers et des données d’attribution ligne par ligne, puis sollicitez au moins 2 réviseurs appropriés. - Après avoir traité tous les commentaires et rétabli la réussite de tous les contrôles, sollicitez de nouveau les réviseurs existants. - Ne fusionnez jamais tant qu’une conversation de révision reste non résolue. - Exigez au moins 1 approbation humaine et n’approuvez jamais la propre demande de fusion de l’agent. - Déduisez le jalon de publication de la branche cible, puis définissez le jalon et la version du correctif du ticket avant de clore celui-ci. - Déterminez l’auteur de la demande de fusion par programme, attribuez correctement la demande de fusion et le ticket, puis appliquez le libellé de catégorie correspondant au ticket et au changement. - Subordonnez la publication et la fusion à la réussite d’une même chaîne de contrôles portant sur le formatage, les types, le lint, les tests et la sécurité. - Conservez la mention de coauteur requise pour l’IA dans le commit de fusion final. - Après la fusion, résolvez le ticket en indiquant la version du correctif et un lien vers la demande de fusion, puis supprimez la branche. Résumez le comportement visible par les utilisateurs, les validations significatives, l’incidence sur la documentation, les risques non résolus et tout contrôle qui n’a pas pu être exécuté. Un test local ne prouve pas la réussite de l’intégration continue, et des preuves incomplètes ne justifient pas de considérer la publication comme prête.