Exécuter et gérer les workflows

Les exécutions de workflow conservent leur progression, ce qui vous permet de partir et de revenir sans répéter le travail terminé. Dans IDE, CLI et Web, l'exécution reste liée à son clavardage parent tandis que Kiro enregistre l'état des nœuds, les extrants, les artéfacts, la progression des répétitions, les curseurs de veille et les sessions d'étape à des points de contrôle durables.

Un workflow en arrière-plan ne bloque pas la conversation principale. Kiro peut confirmer le lancement, communiquer la progression pendant l'exécution des étapes, inspecter l'exécution terminée et ses artéfacts, puis synthétiser le résultat dans le clavardage parent. La vue d'ensemble des workflows retrace une telle exécution de bout en bout.

Dans Kiro Web, la session parente et les détails de l'exécution restent visibles ensemble :

• Workflows affiche les exécutions, les nœuds imbriqués, l'état, le temps écoulé, l'agent, le modèle, l'effort et l'activité des étapes.
• Summary affiche le résultat synthétisé de la session.
• Files vous permet d'inspecter les fichiers de l'espace de travail produits ou modifiés pendant l'exécution.
• Artifacts affiche les extrants explicitement exposés par le workflow.

Une mise à jour de la progression dans le clavardage parent et un message direct à une étape sélectionnée ont des objectifs différents. Demandez à l'agent principal d'interpréter la progression, de résoudre un problème plus vaste ou de décider de la prochaine action. Envoyez un message à l'étape lorsque les directives concernent précisément la tâche actuelle de cet agent.

Le canal entre le clavardage parent et une étape fonctionne dans les deux sens, à tout moment de l'exécution. Une étape communique vers l'extérieur au moyen de ses signaux send_message. Les directives atteignent l'étape par l'une ou l'autre voie : envoyez directement un message à l'étape sélectionnée dans votre client, ou indiquez à l'agent principal dans le clavardage parent ce que l'étape doit faire et il transmet ces directives à la session de l'étape. Une étape en cours d'exécution prend connaissance des directives à son prochain tour; une étape en pause les traite comme la réponse qu'elle attendait.

Une exécution présente l'un de cinq états, et paused couvre trois situations différentes qui nécessitent des réponses distinctes. Les commandes offertes par un client diffèrent selon la surface; les états et les transitions entre ceux-ci sont les mêmes partout.

Les nœuds peuvent également être pending ou skipped. Chaque itération d'une répétition crée un nouvel ensemble d'entrées d'état pour son corps, de sorte qu'un même ID de nœud statique peut apparaître une fois par itération. Les commandes exposées par chaque client sont indiquées sous Choisir la bonne commande d'exécution.

Une étape peut demander des renseignements et se mettre en pause sans perdre le contexte de sa session. L'agent de l'étape le signale en appelant send_message avec le niveau de gravité warning; Kiro met l'étape et l'exécution en attente jusqu'à ce que vous répondiez.

Votre réponse doit atteindre la session de l'étape en pause. La voie directe consiste à ouvrir cette étape dans votre client et à y répondre; les onglets ci-dessous indiquent où. Vous pouvez également répondre par l'intermédiaire du clavardage parent en demandant à l'agent principal de transmettre votre réponse à l'étape en pause; il insère alors la réponse dans la session de l'étape pour vous. Un simple message saisi dans le clavardage parent sans cette directive constitue une conversation avec l'agent principal, et non une réponse à l'étape.

Quelle que soit la voie choisie, la réponse aboutit dans la propre session de l'étape en pause; le clavardage parent est tout au plus l'endroit où vous l'avez saisie. Trois éléments déterminent la suite, et la figure ci-dessous suit une réponse à travers chacun d'eux : l'étape continue avec son historique intact; son prochain signal send_message sélectionne la branche; et seul success fait passer l'exécution au nœud suivant dans une nouvelle session. Un signal warning remet la même session en pause, tandis qu'un signal error met fin à l'exécution.

Le flux ci-dessus représente la pause intégrée de Kiro lorsqu'une étape demande une entrée. L'auteur d'une recette peut aussi rendre une étape explicitement interactive au moyen de completion, qui garde l'étape ouverte après chaque réponse jusqu'à ce qu'une condition soit remplie :

{
  "type": "step",
  "id": "triage",
  "agent": "wf-planner",
  "prompt": "Investigate the flaky test and refine a fix plan with the user.",
  "completion": {
    "completionSignal": "success"
  }
}

Après chaque tour, Kiro évalue completion. Si elle reste fausse, l'étape attend un autre message dans sa session.

Les étapes interactives ne peuvent pas s'exécuter dans parallel, car Kiro ne peut pas mettre une branche en attente d'une entrée pendant que ses nœuds frères continuent.

La pause est coopérative. L'acceptation d'une demande de pause ne signifie pas que l'exécution est déjà arrêtée. Le tour de l'agent actif peut se poursuivre jusqu'à ce que Kiro atteigne la prochaine limite de nœud. Inspectez l'exécution jusqu'à ce que son état devienne paused avant de supposer que tout travail de l'agent a cessé.

Une répétition mise en pause par onMaxIterations: "pause" a épuisé son budget fixe. Reprendre n'ajoute aucune itération; la répétition atteint le même plafond et se remet en pause. Révisez le plan restant, ou arrêtez l'exécution et lancez la recette corrigée comme une nouvelle exécution.

Utilisez Arrêter, /workflow cancel ou Ctrl+X uniquement lorsque le travail doit s'arrêter immédiatement. L'annulation peut interrompre une étape entre des opérations sur les fichiers. Les fichiers déjà modifiés le restent. Inspectez l'espace de travail et utilisez la gestion de versions pour annuler les modifications partielles indésirables avant de recommencer.

CLI peut réessayer tout le travail infructueux ou un nœud en échec ou abandonné sélectionné :

/workflow retry <workflowId>
/workflow retry <workflowId> <nodeId>

Kiro réinitialise chaque cible à réessayer à pending et efface sa session d'étape, ses horodatages, son extrant capturé, ses artéfacts de nœud, ses métadonnées d'échec, ses métadonnées d'achèvement, son état interactif et son état de veille. Il rouvre les ancêtres dans un état final afin que l'exécution puisse atteindre la cible tout en conservant le travail terminé des nœuds frères.

Réessayer n'annule pas les modifications apportées aux fichiers de l'espace de travail. Inspectez les modifications partielles avant de réessayer. Une exécution terminée ne peut pas être réessayée dans l'interface CLI actuelle; relancez la recette pour créer une nouvelle exécution.

Chaque exécution possède son propre ID de workflow et sa propre arborescence d'état. Les fichiers de recette n'isolent pas les chemins d'extrant, les branches Git ni les worktrees, de sorte que deux exécutions peuvent tout de même modifier la même copie de travail ou écraser le même artéfact.

• Dans IDE, utilisez la liste des exécutions sous Workflows dans les détails de la session parente.
• Dans CLI, utilisez l'historique /workflow ou /workflow list, puis sélectionnez ou transmettez l'ID du workflow.
• Dans Web, ouvrez Workflows à côté de la conversation parente et sélectionnez une exécution dans la liste.
• Attribuez des chemins run_dir et d'artéfact distincts aux exécutions simultanées.
• Utilisez des worktrees ou des espaces de travail distincts lorsque les exécutions peuvent modifier les mêmes fichiers.

L'achèvement est un transfert, pas seulement un changement d'état. L'agent principal peut inspecter l'exécution, lire ses artéfacts déclarés et les fichiers pertinents, vérifier les éléments de preuve demandés et résumer le résultat dans la conversation parente.

Un résumé d'achèvement utile indique :

• le résultat et l'ID du workflow;
• les étapes terminées et les boucles ou révisions effectuées;
• les fichiers créés ou modifiés;
• les artéfacts et les verdicts lisibles par machine;
• les validations effectuées et tout ce qui reste à vérifier.

Dans Kiro Web, utilisez Summary, Files et Artifacts pour inspecter directement ces éléments de preuve. Une recette ou un agent d'étape doit produire et exposer un artéfact; les fichiers créés au cours d'une exécution ne deviennent pas tous automatiquement des artéfacts déclarés.

Un workflow en cours ou en pause peut remplacer son plan de premier niveau restant tout en conservant les nœuds qui ont déjà été exécutés.

• Le travail terminé et celui en cours d'exécution restent immuables.
• Si une étape est active, Kiro met le remplacement en file d'attente jusqu'à la prochaine limite d'étape.
• Si aucune étape n'est active, y compris lorsque l'exécution est en pause, Kiro peut appliquer le remplacement immédiatement.
• L'arborescence révisée complète doit toujours respecter les validations du schéma, des ID, de l'imbrication, du nombre d'étapes, des modèles, des agents et des veilles.
• Si un remplacement en attente échoue à la validation, Kiro le rejette et poursuit l'exécution du plan d'origine.

La structure de l'exécution détermine qui peut réviser un plan :

Les agents utilisent update_workflow pour les deux actions. Pour les résultats ordinaires, une étape devrait toujours envoyer un signal au moyen de send_message; update_status sert aux dérogations intentionnelles. La révision d'un plan est une capacité de l'agent et de l'environnement d'exécution et ne signifie pas que chaque client offre une commande de révision manuelle.

Un nœud watch interroge une ressource externe sans dépenser de tours de modèle pendant que la ressource est inactive. Son gestionnaire renvoie l'un de trois résultats :

Kiro conserve le curseur de veille et l'état final avec l'exécution, de sorte que le suivi des nouveautés survit à un redémarrage. Après une interruption et une récupération, la livraison a lieu au moins une fois; un répondant doit donc tolérer un élément répété. Si idleTimeoutSec est défini, une veille inactive se termine avec un résultat final après cette durée; sinon, la veille peut attendre indéfiniment.

Deux gestionnaires sont intégrés. github-pr assure lui-même le suivi de ce qu'il a déjà signalé. command exécute un programme que vous écrivez une fois par interrogation et stocke le curseur renvoyé par le programme, de sorte que votre programme détermine ce qui constitue une nouveauté; consultez Surveiller autre chose avec command.

L'exemple publish-pr associe une veille github-pr à un répondant dans une répétition; consultez Publier et répondre.

Kiro conserve l'état complet du workflow après les transitions de nœud. Les étapes terminées, les résultats finaux enregistrés, l'état de pause pour une entrée, les extrants capturés, les artéfacts et les curseurs de veille survivent à leur dernière limite durable. Une étape interrompue sans signal final se poursuit dans sa session d'étape existante au lieu de répéter sa requête initiale comme une nouvelle étape.

Une exécution qui indique toujours running n'accepte pas Reprendre. Rouvrez sa session parente ou son moniteur et inspectez son étape active. Si elle reste running sans nouvel extrant, notez l'ID du workflow et recueillez les diagnostics du client avant de lancer une exécution en double; le client ne dispose d'aucune commande manuelle distincte pour récupérer l'exécution.

Kiro limite les échecs répétés des tentatives de poursuite et fait échouer l'étape au lieu de réessayer indéfiniment. La disposition exacte du stockage et les enregistrements de propriété des processus sont des détails de mise en œuvre, et non des éléments de l'API des recettes.

• Les recettes prennent en charge jusqu'à 8 niveaux d'imbrication et 50 nœuds step statiques.
• Chaque repeat possède une valeur maxIterations positive.
• Les conditions de répétition s'exécutent après une itération, de sorte que chaque répétition s'exécute au moins une fois.
• parallel fournit à chaque branche son propre contexte et une stratégie de jointure (all, allSettled ou any). Kiro démarre les branches simultanément; utilisez-le pour l'isolation et la sémantique de jointure plutôt que de présumer une réduction du temps écoulé.
• Les workflows n'isolent pas les branches Git et ne créent pas de worktrees.
• La fermeture du client et le comportement de rattachement entre clients ne font pas partie du contrat des recettes décrit ici.

• Revenez à Créer des workflows pour consulter le schéma complet des recettes, les types de nœuds et les variables de modèle.
• Adaptez un graphe de départ à partir des exemples de workflows.
• Revenez à la vue d'ensemble des workflows pour comprendre le lien entre une exécution et le clavardage parent.