Créer un service d'agents de programmation qui reçoit des demandes du chat et du suivi des tickets

## Donner une seule tâche à chaque rôle d'exécution et laisser le relecteur en lecture seule Attribuez une responsabilité claire à chaque rôle d’exécution : - un graphe principal d’agents de programmation crée un nouvel agent pour chaque fil, tandis que l’état durable reste dans l’environnement isolé et les métadonnées du fil ; - un graphe réviseur effectue une revue de code en lecture seule au moyen d’un modèle de constats et d’une action de publication dédiée, sans outil de modification, de commit, de push ou d’ouverture de revue ; - un graphe analyseur élabore des consignes de revue propres au dépôt dans les modes d’amorçage et d’apprentissage continu, puis les enregistre à l’aide d’un seul outil dédié ; - une application web reçoit les webhooks de la plateforme d’hébergement de code, du système de suivi des tickets et du service de discussion, détermine un fil stable, puis démarre ou diffuse l’exécution du graphe correspondant ; - un tableau de bord gère la connexion, les profils utilisateur, les valeurs par défaut de l’équipe, les dépôts activés, l’administration du style de revue et l’API des fils utilisée par l’interface. Fournissez les procédures de l’analyseur sous forme de capacités virtuelles versionnées et accessibles en lecture seule, au lieu de les copier dans chaque environnement isolé. N’enregistrez le raffinement continu planifié qu’après la fin de l’amorçage. Regroupez tous les points d’entrée des graphes et toutes les routes de l’application dans un même manifeste d’exécution, tout en autorisant un environnement de développement complet et un processus plus restreint réservé à l’application web. ## Choisir un seul jeu d'outils de développement et lancer d'abord le plus petit test Déclarez un seul gestionnaire de dépendances, exécuteur de tests, analyseur statique de style, formateur, vérificateur de types, une version minimale du langage et une version de l’environnement d’exécution déployé. Le dépôt doit rester valide pour la version minimale prise en charge comme pour toute version plus récente fixée dans les métadonnées de déploiement. Fournissez des commandes documentées pour : 1. installer les dépendances de développement ; 2. démarrer l’environnement complet des graphes et de l’application web ; 3. démarrer uniquement l’application web ; 4. exécuter l’intégralité du répertoire des tests unitaires ; 5. exécuter un seul fichier ou cas de test ; 6. vérifier le style et le formatage sans modification ; 7. appliquer le formateur et les corrections automatiques sûres ; 8. vérifier les types du code de production et de test. Utilisez les tests unitaires par défaut. Réservez un répertoire dédié aux tests d’intégration et traitez l’absence d’une suite d’intégration comme une opération nulle explicite plutôt que comme un échec ambigu. Pendant le développement, exécutez un seul test ou la plus petite suite pertinente avant les vérifications générales du dépôt. ## Garder un environnement isolé par fil et le recréer quand il échoue Conservez en mémoire un cache d’environnements isolés indexé par l’identifiant du fil et persistez l’identifiant de l’environnement isolé dans les métadonnées du fil. Gérez explicitement l’état du cycle de vie : 1. Si un environnement isolé est en cache, testez-le ; recréez-le si le test échoue et, s’il est sain, actualisez son proxy réseau authentifié. 2. Si les métadonnées contiennent une sentinelle de création, mais qu’aucun environnement isolé n’est en cache, effacez cette sentinelle obsolète avant de créer un remplacement. 3. S’il n’existe aucun environnement isolé, écrivez la sentinelle de création, créez l’environnement, puis remplacez la sentinelle par l’identifiant réel. 4. Si les métadonnées contiennent un identifiant, mais que le cache du processus est vide, rétablissez la connexion et recréez l’environnement si la reconnexion échoue. Pour les fournisseurs qui prennent en charge un proxy authentifié, obtenez de nouveaux identifiants d’installation à courte durée de vie lors de chaque création ou actualisation. Laissez le proxy injecter l’authentification de la plateforme d’hébergement de code et de l’API, afin que les commandes exécutées dans l’environnement isolé puissent employer une valeur de remplacement inoffensive au lieu de stocker les véritables identifiants. Les fournisseurs dépourvus de cette fonction doivent ignorer explicitement le chemin du proxy. Réappliquez la configuration de l’identité d’automatisation à chaque exécution. Les environnements réutilisés ou reconnectés peuvent perdre leurs paramètres globaux, et les vérifications de déploiement ultérieures peuvent refuser les commits dont l’identité de l’auteur n’est pas reconnue. ## Exécuter les intergiciels autour des appels au modèle dans un ordre fixe Exécutez les intergiciels autour des appels au modèle selon une séquence délibérée : 1. assainir et normaliser les entrées des outils ; 2. limiter le nombre d’appels au modèle et terminer proprement une fois la limite atteinte ; 3. convertir les exceptions des outils en messages d’outil ; 4. ajouter aux lectures de fichiers les instructions applicables des répertoires ancêtres, une seule fois par exécution ; 5. injecter avant le prochain appel au modèle les messages de ticket ou de discussion arrivés en cours d’exécution ; 6. mettre à jour les indicateurs externes d’état de l’assistant ; 7. remplacer une réponse vide du modèle par un appel d’outil synthétique demandant la poursuite ou la confirmation de l’achèvement ; 8. avertir le canal d’origine lorsque la limite globale d’étapes est atteinte ; 9. déclencher un coupe-circuit après des défaillances répétées de l’environnement isolé ; 10. ajouter un modèle de repli uniquement si un modèle de repli distinct est configuré ; 11. supprimer les blocs de raisonnement mal formés propres au fournisseur immédiatement avant les appels à ce fournisseur. Associez l’instruction système qui impose de continuer à agir à la protection contre les réponses vides, afin que le travail ne se termine pas silencieusement. Allégez les intergiciels du réviseur lorsqu’il n’a pas besoin d’instructions de fichier limitées à une portée, d’injection de la file de messages, de modèle de repli ou de récupération de l’environnement isolé. L’existence d’un composant d’intergiciel inutilisé ne l’active pas ; enregistrez explicitement tout nouvel intergiciel à la bonne position. ## Ne donner à chaque rôle que les outils dont il a besoin Maintenez un petit registre plat d’outils personnalisés. L’agent principal peut recevoir des requêtes réseau approuvées, des outils de recherche, des actions du système de suivi des tickets, des demandes de revue, des reprises planifiées et des réponses dans le service de discussion. Le réviseur ne doit recevoir que des outils réseau orientés vers la lecture, ainsi que la création, la mise à jour et la liste des constats et la publication des revues. L’analyseur ne doit recevoir que l’action nécessaire à l’enregistrement des consignes de revue. Laissez l’infrastructure d’agents fournir les primitives génériques de gestion de fichiers, de terminal, de recherche, de tâches et de planification. Ne dupliquez pas ces outils dans le registre personnalisé. Ne comptez pas sur un filet de sécurité postérieur à l’agent pour publier le travail. Le flux de travail de l’agent doit effectuer explicitement chaque commit, chaque push, chaque ouverture ou mise à jour de revue autorisée et chaque réponse au canal d’origine. Un réviseur en lecture seule ne doit jamais hériter de ces capacités de modification. ## Choisir le modèle dans un ordre fixe et chiffrer les identifiants Déterminez le modèle et le niveau d’effort de raisonnement de chaque exécution dans l’ordre suivant : 1. la configuration propre au fil fournie par l’événement déclencheur ou l’interface ; 2. la substitution définie dans le profil de l’utilisateur identifié ; 3. la valeur par défaut de l’équipe. Centralisez les identifiants de modèles pris en charge, les règles d’effort de raisonnement, les arguments des fournisseurs, la construction des modèles et le choix du modèle de repli. Conservez les indicateurs de comportement, tels que l’autorisation de créer automatiquement des revues, dans le profil utilisateur au lieu de les disperser dans le code des webhooks. Chiffrez les identifiants d’autorisation des utilisateurs au repos et ne les conservez en cache que dans le processus pendant une exécution. Lorsqu’aucun identifiant utilisateur n’est disponible, utilisez à la place un identifiant d’installation de l’application à courte durée de vie. Utilisez ce même identifiant d’application pour configurer un proxy authentifié dans l’environnement isolé, mais ne persistez jamais l’identifiant brut dans cet environnement. Vérifiez l’authenticité du webhook avant de router un événement. Conservez les vérifications de signature de la plateforme d’hébergement de code, la vérification du service de discussion, la vérification du système de suivi des tickets et la gestion de la connexion au tableau de bord dans leurs modules respectifs. ## Renvoyer les messages de suivi vers le même fil et le même environnement isolé Dérivez des identifiants de fil stables à partir de l’identité de la conversation externe, afin que chaque interaction de suivi concernant le même ticket, fil de discussion, branche ou revue retrouve le même état de l’agent et le même environnement isolé. Attribuez aux exécutions du réviseur un espace de noms déterministe distinct et indiquez leur type de fil dans les métadonnées. Lorsque des messages arrivent pendant une exécution, placez-les dans la file du fil et injectez-les avant le prochain appel au modèle. Cela préserve la continuité sans abandonner l’exécution en cours ni créer un agent concurrent. Alignez les mises à jour d’état sur les limites des appels au modèle, afin que les utilisateurs externes puissent distinguer le travail en cours, l’achèvement et l’arrêt dû à la limite d’étapes. ## Ne lancer la réparation automatique de CI que lorsqu'elle est activée Un flux de réparation automatisé peut réagir à des vérifications échouées, à des conflits de fusion ou à des retours exploitables sur une revue créée par un agent. Localisez le fil d’origine grâce aux métadonnées durables de la revue, puis lancez sur le graphe de l’agent principal une exécution de réparation soumise à un seuil de confiance. Exigez une activation multicouche : - un indicateur d’automatisation par utilisateur ; - l’adhésion explicite du dépôt ; - une substitution par revue permettant l’activation ou la désactivation. Centralisez les règles d’exclusion relatives aux échecs déjà présents sur la branche de base, aux commits créés par des humains, au traitement répété de la même révision de tête, au regroupement pendant qu’une autre exécution de réparation est active et à une limite stricte de boucles. N’utilisez un moniteur périodique qu’en solution de repli pour parcourir les revues ouvertes créées par des agents à la recherche d’événements manqués. ## Ajouter fournisseurs et outils dans leurs registres et garder le code asynchrone Ajoutez un fournisseur d’environnements isolés dans son module d’intégration et enregistrez-le dans la table de correspondance de la fabrique de fournisseurs. Ajoutez un outil personnalisé dans le paquet d’outils, exportez-le une seule fois et incluez-le uniquement dans la liste d’outils propre au rôle qui en a besoin. Ajoutez un intergiciel dans son propre module, exportez-le et placez-le délibérément dans la pile ordonnée. Ajoutez les points de terminaison du tableau de bord au routeur monté et les nouveaux graphes au manifeste d’exécution. Conservez le caractère asynchrone d’une application exclusivement asynchrone. Ne créez pas d’implémentations synchrones parallèles. Omettez la méthode synchrone lorsque l’interface le permet ; lorsqu’un contrat abstrait l’exige, ne fournissez qu’une méthode minimale qui déclenche une erreur d’opération non prise en charge. Utilisez les tests unitaires par défaut, réservez la zone dédiée aux tests d’intégration aux véritables intégrations et limitez les commentaires. Ceux-ci doivent expliquer une raison non évidente ou une contrainte d’ordre, et non répéter l’implémentation.