AI Agent de codage Orchestration: porte à chaque fusion par des preuves

Les agents de codage parallèle ne doivent pas fusionner parce que chaque session dit done. Le défaut raisonnable est plus strict: donner à chaque agent mutant un arbre de travail et une branche isolés, déclarer ce qu'il peut changer, et admettre sa branche seulement lorsque les vérifications, l'examen, la fraîcheur de base et un reçu livrable se réfèrent tous à l'engagement de tête exact. C'est le noyau opérationnel de AI orchestration de l'agent de codage . L'orchestrateur peut planifier le travail et l'activité d'affichage, mais la préparation à fusion est une décision de preuve. Une succursale peut être en activité, en attente légitime, bloquée, obsolète, hors de portée ou complète mais non vérifiée. L'effondrement de ces états en fin est la façon dont le parallélisme se transforme en échec silencieux de l'intégration. Ce guide crée un reçu de fusion libre de contenu et repose huit cas contre elle. Le résultat est délibérément inconfortable: un seul cas est prêt. Les autres conservent la raison d'attendre ou de refuser au lieu de la cacher derrière un badge vert. Orchestration pour l'admission à la fusion, pas pour la fin de la session Le paysage actuel des outils facilite l'exécution parallèle. Le L'équipe VS Code décrit les modes d'agent local, de fond et de cloud dans la version 1.109; ses agents de fond utilisent l'isolement de l'arbre de travail, tandis que les subagents parallèles gardent l'exploration hors du contexte principal. Le code open source Projet Agent Orchestrator met de même des sessions de codage dans des arbres de travail isolés et des routes d'échec de l'IC, d'examen des commentaires et de fusion des conflits à la session pertinente. Ce sont des propriétés d'exécution utiles. Ils ne sont pas, en eux mêmes, un verdict de fusion. La documentation Gits git worktree explique la frontière importante. Les arbres de travail liés partagent des données de référentiel, mais chacun a l'état par arbre de travail tel que HEAD et l'index. Git refuse également de vérifier une branche dans plusieurs arbres de travail à moins que les mesures de sécurité ne soient écartées. Cela empêche une classe de systèmes de fichiers et de collisions d'index. Il ne prouve pas que deux patchs sont compatibles, qu'un agent est resté dans son affectation, ou que le résultat du test d'hier s'applique à la tête d'aujourd'hui. Utilisez un reçu par branche candidate: Les identifiants sont synthétiques. Aucun prompt, fichier source, secret, diff ou journal de test n'est requis. Le reçu ne contient que les informations minimales nécessaires pour décider si le chef de la filiale exact peut avancer. Cinq vérifications rendent utile le paramètre par défaut: 1. Isolation: l'arbre de travail et la branche appartiennent à une session mutante active. 2. O propriété: chaque chemin modifié est à l'intérieur de l'affectation déclarée. 3. Freshness: le candidat est basé sur la base attendue, et chaque chèque se réfère à son chef actuel. 4. Review: une approbation s'applique à la même tête, sans demande de modification non résolue. 5. Ooutcome: un artefact déterministe prouve le travail demandé, pas seulement l'achèvement de la commande. Documentation de branche protégée de GitHub prend en charge le milieu de ce contrat: les succursales peuvent exiger des examens et des vérifications de statut réussies, et des vérifications strictes peuvent exiger qu'une succursale soit à jour avec la base. La réception du résultat étend ce mécanisme. Une construction réussie prouve qu'une commande de construction a été passée; elle ne prouve pas nécessairement que l'exportation demandée existe, que le contrat API fonctionne ou que le comportement visible par l'utilisateur est correct. Effectuer l'audit de préparation à la fusion en huit cas J'ai codé le contrat dans un petit classifiateur Node.js et reproduit huit reçus de branche. L'appareil utilise une base actuelle, deux vérifications requises et aucun contenu de référentiel. Faites le avec: Le classeur applique les portes dans cet ordre: L'ordre est important. Une attente légitime ne devrait pas devenir un échec de construction simplement parce que les contrôles n'ont pas commencé. La dérive de portée devrait arrêter la branche avant une évaluation coûteuse. Les preuves périmées ne doivent pas être réinterprétées comme un échec actuel: il dit "Retourner contre cette tête", pas "le code est cassé". L'expérience a produit un verdict dans chaque catégorie: Le cas de l'accusé Le verdict Des preuves décisives Branche complète merge ready Tête courante, chemins de propriété, nouveaux contrôles, approbation, artefact vérifié Espaces de travail partagés isolation failed Une autre session mutante possède l' espace de travail Édition d'auteur supplémentaire scope drift src/auth.ts est en dehors de l'affectation des docs Décision du régime waiting Le réviseur nommé, la raison et la date limite sont présents Vieille base de fusion stale base Le candidat a vu base 101 ; la base actuelle est base 104 Nouveau engagement après CI stale evidence Les contrôles et les examens appartiennent à cli 8 et non à cli 9 Modifications demandées review blocked L'examen s'applique à la tête mais n'est pas approuvé Aucune preuve délivrable outcome unverified Construire et passer l'essai, mais le résultat demandé n'est pas vérifié Il s'agit d'un résultat opérationnel plus fort que sept échecs. Le cas du schéma n'échoue pas; il attend une décision explicite. L'affaire de la vérification périmée peut contenir un code parfaitement bon; ses preuves sont sur le mauvais acte. Le cas d'absence de résultat peut avoir passé tous les tests génériques tout en échouant toujours à la tâche qui justifiait la succursale. L'audit est falsifiable. Si le classificateur marque un cas incomplet prêt, la thèse échoue. S'il refuse la réception complète, le contrat est trop strict ou incorrectement exécuté. Pendant cette période, un cas sur huit est devenu merge ready . Attachez tous les signaux verts à la tête du candidat. La règle la plus réutilisable de l'appareil est simple: Supposons qu'un agent passe IC à commit cli 8 , puis fait un petit cleanup commit cli 9 . Un tableau de bord peut toujours afficher des contrôles verts et une revue approuvée. L'état correct n'est ni vert ni rouge. C'est une preuve périmée. Retourner les contrôles concernés et renouveler le réexamen ou utiliser un mécanisme de plateforme qui annule les approbations lorsque les différences examinées changent. Appliquer la même identité obligatoire à la livraison. Les reçus utiles comprennent: un test contractuel qui appelle la nouvelle API et valide sa réponse; un hash d'artefact généré plus un décodeur ou un contrôle parseur; une affirmation du navigateur contre le trajet intégré; une répétition de migration par rapport à une base de données jetable; un test d'importation et de fumée du colis construit et non de l'arbre source; une recherche de destination prouvant qu'un effet externe a atteint l'enregistrement prévu. Évitez un résumé LLM comme seul reçu de résultat lorsque le résultat est déterministe. Un agent de codage peut affirmer avec confiance qu'il a créé un fichier qui n'existe pas, qu'il a effectué des tests qui ont ensuite été annulés ou qu'il a corrigé un commentaire de révision sur une autre branche. Je préfère l'inspection directe. Utilisez un juge modèle uniquement pour les propriétés qui ne peuvent pas être vérifiées mécaniquement, et enregistrez la version du juge, la rubrique, l'identité de l'entrée et l'incertitude. Attendre a aussi besoin d'identité. Enregistrez le propriétaire, la raison, la date limite, et la condition de la livraison. En attendant une révision sans propriétaire, on peut rester assis pour toujours. Attendez que le réviseur de la plate forme approuve la compatibilité du schéma jusqu'à 12h00 UTC; reprendre à schema 3 est actionable et doit rester hors de la file d'attente des défaillances jusqu'à ce que sa date limite ou les preuves changent. Savoir où s'arrête la porte La propriété du chemin est un filtre précoce, pas la détection de conflits sémantiques. Deux branches peuvent éditer des fichiers différents et toujours ne pas être d'accord sur un type partagé, un schéma d'événement, un client généré, un ordre de migration, un drapeau de fonctionnalités ou un comportement API. L'isolement de l'arbre de travail empêche les collisions concomitantes entre l'état du fichier; il ne peut pas prouver que les corrections de patch se composent de manière indépendante. Par conséquent, lancez une porte d'intégration finale contre le candidat à la fusion réelle: 1. mettre à jour ou recréer le candidat à partir de la base prévue; 2. combiner les modifications approuvées sans contourner les conflits; 3. effectuer les vérifications requises contre la tête combinée; 4. répéter la vérification déterministique des résultats; 5. joindre les éléments de preuve qui en résultent à cette tête combinée; 6. nécessiter l'approbation humaine pour la fusion ou toute étape de récupération irréversible. Ça ajoute du travail. La fraîcheur stricte de la base peut également provoquer des reconstructions répétées tandis que d'autres branches atterrissent. GitHub documents qui négocient: les vérifications strictes requises améliorent l'alignement de base mais peuvent nécessiter plus de constructions; les vérifications lourdes réduisent les reconstructions mais peuvent permettre l'incompatibilité d'apparaître après la fusion. Choisissez la police en fonction du coût de l'échec, pas en fonction du désir de garder chaque agent occupé. Le contrat de fusion ne remplace pas non plus l'examen du code, l'examen de la sécurité, les contrôles de déploiement ou la réponse aux incidents. Il donne à ces systèmes une identité de candidat digne de confiance et une raison claire pour laquelle le travail n'est pas prêt. Sidewisp est actuellement en préversion privée. Sa direction de produit est une couche de santé autour des temps d'exécution existants des agents, avec des preuves utiles de progrès, d'attente, d'outil et de résultats maintenues distinctes; les adaptateurs de collecte et de récupération des agents de production santé ne sont généralement pas expédiés. Si vous exploitez des agents de codage parallèle, ce reçu de fusion est le type de contrat de santé limité qui mérite d'être testé maintenantavant d'ajouter une intervention autonome. La règle finale est intentionnellement conservatrice: l'arrêt de l'agent an est une activité; une branche à tête, examinée, vérifiée par les résultats est un progrès qui peut être approuvé pour l'intégration.