kkestell/xauto

Orchestrer le flux x-workflow complet

La session actuelle est le coordinateur parent. Lisez references/workflow.md avant de dispatcher. Lisez les trois autres compétences si nécessaire ; leur sémantique d'étape et le contrat partagé s'appliquent à chaque travailleur. N'exécutez pas un flux kauto sans rapport à cause d'une faute de frappe dans une requête.

Préparer et allouer

1. Établissez le résultat attendu, les contraintes et le périmètre. Trouvez la racine Git, la branche/HEAD actuelle, les instructions applicables et l'état de l'index/des modifications non commitées. Git est obligatoire ; arrêtez-vous plutôt que de l'initialiser silencieusement. Choisissez un checkout de tâche propre et exclusif. Préservez le travail sans rapport ; isolez quand c'est possible, sinon demandez la disposition nécessaire. Ne promettez pas un commit sur la branche d'origine de l'utilisateur lorsque vous travaillez sur une branche séparée.
2. Allouez l'ID de tâche et les chemins d'artefacts canoniques. Un planificateur peut proposer plusieurs unités délimitées ainsi qu'une conception partagée ; le parent assigne les IDs supplémentaires de manière centralisée et préserve la couverture de la requête complète.
3. Découvrez les outils de délégation disponibles. Utilisez les sessions enfants en premier ; seulement en leur absence utilisez les sous-agents. Suivez les règles de délégation/cycle de vie de l'hôte. Ne supposez pas un nom d'outil et ne créez pas un faux contexte frais avec un autre message dans le parent. Si aucun mécanisme n'existe, arrêtez-vous et expliquez que le flux de travail orchestré indépendant est indisponible ; n'exécutez pas silencieusement chaque rôle en ligne.
4. Héritez du modèle/du harnais/de l'effort sauf si l'utilisateur ou les instructions applicables les sélectionnent. Utilisez un contexte de relecteur frais, pas un fork contenant le raisonnement privé de l'auteur. Le relecteur peut voir la requête, le code, les artefacts et les constats publics antérieurs, mais n'est pas le travailleur qui a écrit le plan/la mise en œuvre revus.
5. Capturez la provenance de la session parent en utilisant le contrat partagé. Demandez l'ID coordinateur de chaque travailleur et l'ID de conversation natif dans son handoff ; préservez-les dans le journal de travail avant le nettoyage, pas seulement les noms de travailleurs transitoires.

Dispatcher des briefs d'étape explicites

Chaque travailleur reçoit l'objectif, les contraintes utilisateur pertinentes, la compétence et l'invocation, l'ID de tâche, le checkout exact et la HEAD de départ, les chemins d'entrée/sortie, les modifications autorisées, l'autorité de commit, les exigences de vérification et les preuves de vérification existantes, le handoff attendu (y compris la provenance de session) et la condition d'arrêt. Incluez où le résultat sera utilisé. Fournissez un plan ou une requête, pas des hypothèses que le travailleur est censé vérifier de manière indépendante.

Les étapes sont séquentielles dans un checkout partagé. Par défaut, un seul scripteur à la fois ; exécutez des unités séparées simultanément uniquement lorsque leurs fichiers et dépendances sont vraiment indépendants et que la propriété de l'intégration/de la revue est explicite. Confirmez le répertoire/HEAD réel de chaque enfant ; intégrez les commits de handoff des travailleurs isolés avant l'étape suivante, comme décrit dans le contrat partagé. Ne supprimez jamais un résultat non transféré.

Planifier → revoir le plan

• Démarrez un planificateur avec xplan <requête> et sans autorisation de modification de code de production. Le planificateur recherche les questions délicates, tranche les décisions d'ingénierie et renvoie des plans prêts, un brief de micro-tâche ou des blocages concrets.
• Inspectez les artefacts renvoyés et la couverture. Commitez les enregistrements plan/conception partagée en tant que plan, puis envoyez chaque plan d'exécution à un travailleur indépendant en utilisant xreview plan .agents/plans/ID.md. Commitez son cycle de revue en tant que plan-review.
• Pour les constats, renvoyez une assignation de correction concrète au planificateur. Commitez le plan révisé. Le parent vérifie les corrections par rapport aux constats et aux preuves pertinentes, enregistre leur disposition et les blobs finaux du plan/des directives, et procède lorsqu'aucun défaut conséquent ne subsiste. C'est la décision d'exécution du parent, pas une affirmation que le relecteur a approuvé des révisions non vues. N'envoyez pas chaque révision via une autre revue complète du plan. Une évaluation indépendante supplémentaire nécessite une question conséquente spécifique que la revue antérieure et la vérification de correction ne peuvent pas résoudre ; nommez cette question et demandez uniquement l'évaluation nécessaire. Le libellé, les métadonnées et les corrections de routine ne justifient pas de redémarrer la revue. Les modifications de conception partagée nécessitent de vérifier les unités affectées, pas de commander automatiquement une autre revue de chacune d'elles.
• Pour un travail vraiment minuscule, conservez le brief délimité du planificateur pour xwork et sautez les artefacts de plan/revue séparés ; le journal de travail ultérieur enregistre la raison. Ne contournez pas la normalisation en appelant une affectation importante non résolue un brief.
• Une requête scindée n'est pas terminée après sa première unité. Suivez les dépendances des unités dans la conception partagée, exécutez chaque unité demandée dans l'ordre, et revérifiez les interfaces/états intermédiaires partagés lorsqu'une dépendance change.

Travailler → revoir la mise en œuvre

• Dispatchez un implémenteur avec xwork .agents/plans/ID.md, ou le brief de micro-tâche explicite. Fournissez les blobs de directives/de plan accepté et lié. Autorisez uniquement le code et les commits de journal propriétaires de la tâche. xwork enregistre une base de Code fixe, commit le code vérifié, puis commit séparément son journal avec une tête de Code connue.
• Vérifiez le handoff par rapport à Git et à la sortie de test enregistrée ; le message « done » d'un enfant n'est pas une preuve de l'arbre correct, des vérifications terminées ou des fichiers commités. Résolvez les correspondances d'intégration et utilisez les hachages du checkout de tâche dans le journal final.
• Démarrez un relecteur indépendant avec xreview work .agents/work/ID.md. Donnez la requête, le plan/le brief, la plage complète de la base de Code .. la tête de Code, le journal de travail et les instructions de dépôt pertinentes. Le relecteur lit le code et les tests, pas seulement le journal, et écrit une revue sans corriger la mise en œuvre. Commitez sa revue en tant que work-review.
• Transmettez les résultats de vérification inspectables pour la tête de Code enregistrée. Demandez au relecteur d'inspecter/réutiliser cette preuve en premier et d'identifier toute incertitude restante avant de sélectionner de nouvelles vérifications. Ne demandez pas systématiquement des répétitions ciblées, une exécution complète du package et la suite du dépôt à nouveau pour le même code inchangé. Les exigences explicites de nouvelle exécution s'appliquent toujours.
• Envoyez les constats exploitables à l'implémenteur. Il commit des correctifs et une entrée de journal ajoutée, en conservant la base d'origine. Renvoyez le changement complet mis à jour au relecteur indépendant ; les constats antérieurs nécessitent des preuves de résolution, pas une nouvelle liste de contrôle vide. Préservez tous les cycles de revue. Le relecteur peut être réutilisé tant qu'il est indépendant de l'auteur ; aucun rôle ne peut approuver le code qu'il vient d'écrire.
• Si la mise en œuvre expose une conception invalide, redirigez la décision via le planificateur et le parent avant de continuer. Appliquez la même vérification de correction aux unités dépendantes affectées ; une évaluation indépendante supplémentaire nécessite une incertitude conséquente spécifique, pas simplement un blob de plan modifié. Ne laissez pas xwork étendre silencieusement le périmètre ou laisser le choix difficile à la phase de codage.

Résoudre les constats et terminer honnêtement

Procédez sans confirmation de routine, mais demandez quand l'intention, le périmètre, les autorisations ou un compromis matériel nécessite véritablement l'utilisateur. Arrêtez-vous en cas d'outils/vérifications requis indisponibles ou de décisions contestées. Continuez les réparations ordinaires tant qu'elles progressent ; si un cycle répète la même approche échouée, nécessite une décision de l'utilisateur ou dépasse un budget explicite, arrêtez-vous et signalez les preuves non résolues plutôt que de générer une boucle de revue indéfinie. N'acceptez jamais un défaut pour terminer le cycle.

Avant le succès, le parent vérifie :

1. Chaque unité d'exécution demandée est implémentée, les vérifications requises ont réellement réussi, et son code final a une revue de travail acceptée indépendante.
2. Chaque modification de code/test/config après la tête de code revue d'une unité est couverte par la plage de revue acceptée d'une unité ultérieure sur le checkout de tâche intégré, ou repasse par la vérification et la revue de travail. Les modifications connues de seulement le journal de flux n'ont pas besoin de nouvelle relecture de code. Rendez compte de tous les commits/diffs, pas seulement des noms de chemin correspondants. Les correctifs de conflit d'intégration et les contrats antérieurs brisés nécessitent des vérifications/revues renouvelées ; une unité ultérieure acceptée ne les excuse pas automatiquement.
3. Les journaux de travail contiennent le plan/le brief accepté, la base fixe, la tête revue finale, les commits réels, les IDs de conversation natifs parent/travailleur (ou les raisons explicites d'indisponibilité), les preuves de vérification exécutées/réutilisées et les chemins de revue. Mettez-les complete et commitez les enregistrements restants propriétaires de la tâche en tant que complete.
4. Toutes les modifications propriétaires de la tâche et les nouveaux enregistrements sont commités sur la branche rapportée. Vérifiez avec Git, préservez le travail sans rapport, et ne poussez pas ou ne fusionnez pas automatiquement dans une branche différente. Les têtes de code d'origine n'ont pas besoin d'être égales à la HEAD finale car les commits ultérieurs contiennent des enregistrements ou d'autres unités acceptées indépendamment.
5. Sauvegardez la provenance de session de chaque enfant et intégrez/sauvegardez chaque résultat avant de mettre fin aux sessions qui suppriment leurs branches/arbres de travail. Laissez un résultat commité accessible et suivez les règles de nettoyage de l'hôte. Les cycles échoués rapportent les commits partiels et les bloqueurs, pas le succès.

Retournez un résultat concis, les IDs de tâche, les chemins d'artefacts, la branche et les IDs de commit finaux, les vérifications, les verdicts de revue et les limitations restantes. Le parent possède cette vérification et ce rapport final ; ne concaténez pas simplement les résumés des travailleurs.