Runs, acceptation et changements
Un workflow ne fait jamais rien atterrir tout seul. Le travail se fait dans un run, et un run ne produit jamais qu'une proposition. Un run propose ; rien n'atterrit sans votre acceptation.
La boucle en un coup d'œil
Vous attachez un workflow à une mission — ou vous en invoquez un, ce qui crée sa mission pour vous. Vous démarrez un run ; le run exécute le graphe sur sa propre branche, à l'écart du travail déjà accumulé par la mission. Quand il termine, il reste en Proposed, ses changements prêts pour vous. Vous inspectez le résultat et décidez : Accept run (« accepter le run » — les libellés du tableau s'affichent en anglais dans l'interface) fait atterrir le travail sur la mission sous forme d'un changement ; une proposition que vous n'acceptez pas ne fait rien atterrir, et la mission reste exactement comme elle était (décliner n'est pas un bouton).
Démarrer un run
Les runs se démarrent depuis la page mission. Le tableau Runs & acceptance liste tous les runs de cette mission, passés et présents — l'étiquette live de son en-tête signifie qu'il se rafraîchit au rythme de la mission — et chaque nouveau run part de l'état courant de la mission.
Chaque ligne de run montre son issue et, quand ils s'appliquent, deux petits badges : dormant — le run n'a pas encore de cible provisionnée, rien n'a tourné contre lui — et stale — la base du run est derrière la pointe de la mission, donc une acceptation refuserait tant qu'un run frais n'est pas démarré.
Un run peut refuser de démarrer. Les raisons que vous rencontrerez vraiment :
- Un run est déjà ouvert. Un run à la fois par mission — attendez-le, ou acceptez-le / écartez-le d'abord.
- La mission n'est pas encore planifiée. Son plan n'est pas en place ; laissez-la y arriver d'abord.
- La mission est terminée. Une mission terminée ou annulée ne prend plus de nouveaux runs.
Tout ce qui est plus exotique relève des refus côté agent ; la liste complète vit sur les pages agent.
Pendant le run
Pendant qu'un run s'exécute, ses gates se mettent en pause dans votre file de Decisions : le run attend au gate jusqu'à votre réponse (ou, si le gate a été conçu avec un timeout, jusqu'à son expiration), puis reprend. Tout le reste d'un run en cours — la vue graphe, le statut par node, le panneau de session coder — se trouve dans la visionneuse de run ; voir Suivre un run.
Un run propose des changements
Un run naît Proposed et y reste jusqu'à ce que vous décidiez.
| Issue | Sens |
|---|---|
Proposed | Les changements du run existent sur sa propre branche et attendent votre décision. |
Accepted | Vous avez accepté ; les changements ont atterri sur la mission sous forme d'un changement. |
Rejected | Le run a été décliné — écarté par le verbe agent, ou un frère concurrent a été accepté à sa place. Rien n'a atterri, et la branche du run disparaît. |
Superseded | Le run a été remplacé par un autre run et n'est plus en jeu. |
La cheatsheet complète est sous issues d'un run.
Accepter
Accept run fait trois choses, dans l'ordre — et refuse plutôt que d'en faire une à moitié :
- Contrôle de fraîcheur. Le run est parti d'un état précis de la mission. Si la mission a bougé depuis, l'acceptation refuse.
- Validation physique. Le résultat fusionné doit être vérifié mécaniquement avant d'atterrir. C'est fail-closed : si le système ne peut pas vérifier mécaniquement la fusion, il refuse — il ne fait jamais atterrir du travail sur parole, pas même la sienne.
- Fusion. Les changements atterrissent sur la branche de la mission, et un changement est créé pour les consigner comme une unité réversible.
Sur le tableau, un run proposé porte deux boutons : Accept run — il affiche Accepting… pendant qu'il travaille — et Close-out…, qui ouvre la checklist de clôture du run. Tout ce que le run a laissé ouvert — une tâche restante, un gate ouvert, un node en échec — doit y recevoir une note de disposition datée avant que l'acceptation ne se déverrouille ; un run propre répond « No leftovers — every node landed terminal and clean. » (« aucun reste — chaque node a terminé proprement », affiché en anglais).
Pourquoi une acceptation peut refuser :
- Le sol a bougé. La mission a avancé depuis le départ du run. Démarrez un run frais.
- Conflit de fusion. Les changements du run ne s'appliquent plus proprement. Démarrez un run frais depuis l'état courant.
- Un autre run a déjà gagné. Si des runs étaient en compétition (ci-dessous), un seul est accepté.
Une acceptation refusée ne fait rien atterrir et ne casse rien — la mission reste intacte.
Décliner une proposition
Il n'y a pas de bouton d'écart sur le tableau des runs : un run proposé est soit accepté, soit laissé tel quel. Le laisser est sans danger — rien n'est arrivé à la mission, il n'y a donc rien à défaire — mais la mission ne prend pas de nouveau run tant qu'une proposition reste ouverte.
Une proposition non voulue se règle de deux façons. Accepter une proposition rejette automatiquement les autres runs proposés de son groupe concurrent, et leurs branches sont supprimées — c'est la réponse à « que deviennent les autres ? » pour les runs concurrents. Et les agents peuvent écarter un run explicitement avec le verbe MCP mission_run_discard (référence agent) : le run est marqué rejeté et sa branche supprimée. Dans les deux cas, c'est la façon peu coûteuse de dire « pas celui-ci » — rien n'a jamais atterri.
La pile de changements
Sur le tableau, c'est la pile Accepted changements (« changements acceptés ») — vide, elle affiche « Nothing accepted onto the tip yet. » (« rien d'accepté sur la pointe pour l'instant », en anglais dans l'interface). Chaque run accepté devient exactement un changement, et les changements s'empilent dans l'ordre sur la branche de la mission. La merge request de la mission est cette pile composée — pas un tas de commits bruts, mais une séquence de deltas acceptés et validés. Comme chaque acceptation est validée avant de fusionner, la pointe de la mission est toujours un état qui a passé la validation.
Le revert
N'importe quel changement peut être annulé par un revert — son bouton Revert… montre un aperçu avant que quoi que ce soit ne soit défait. L'aperçu montre la cascade : les changements ultérieurs qui touchent les mêmes fichiers dépendent de celui que vous annulez, et ils sont annulés avec lui, en ordre inverse. Si un revert entraînait un conflit, ARDS refuse plutôt que de deviner une résolution. Et rien ne s'évapore : le changement annulé et le revert lui-même restent dans l'historique de la mission, datés et attribués.
Runs concurrents
Avancé, mais bon à savoir : vous pouvez démarrer plusieurs runs depuis le même point de départ — workflows différents, paramètres différents, instructions différentes — en un groupe concurrent. Inspectez-les côte à côte et acceptez celui que vous préférez ; les perdants sont rejetés et leurs branches supprimées. C'est de l'A/B testing où le juge, c'est vous, sur des résultats réels et validés.