Ce qu'est un workflow

Un workflow est un graphe d'étapes sauvegardé et versionné — lectures, appels au modèle, travail de coder, gates d'approbation — qu'une mission peut exécuter à la place d'une planification ad hoc. Quatre règles définissent le comportement des workflows dans ARDS. Apprenez-les sur cette page ; toutes les autres pages de cette section s'appuient dessus.

Un workflow n'exécute rien par lui-même

Un workflow n'exécute rien par lui-même. C'est un plan, pas un processus. La seule chose qui s'exécute dans ARDS est une mission : le workflow décrit ce qui doit se passer, et il reste inerte tant qu'une mission ne le fait pas tourner.

Un workflow rencontre une mission de deux façons exactement :

  • L'attacher à une mission. Vous choisissez un workflow publié (et sa version) pour une mission — typiquement dans le dialogue d'attache à la création de la mission — et la mission le fait tourner.
  • L'invoquer directement. Vous partez du workflow lui-même, et ARDS crée une nouvelle mission autour, parce qu'un run a toujours besoin d'une mission pour exister.

Les deux chemins mènent au même endroit : une mission, faisant tourner un workflow, sur la branche propre de la mission. Il n'existe pas de troisième chemin où un workflow « tournerait tout seul » en arrière-plan.

Les runs proposent ; vous acceptez

Chaque exécution d'un workflow au sein d'une mission est un run. Un run travaille sur sa propre branche et naît Proposed. De là, c'est vous qui choisissez la suite : Accept run (« accepter le run ») fait atterrir ses changements en Accepted ; un run que vous déclinez finit Rejected — écarté par un agent, ou rejeté automatiquement quand un frère concurrent l'emporte. Les états d'un run sont résumés dans la cheatsheet des états.

Accepter un run pose exactement un changement — un delta unique et réversible — sur la branche de la mission. Écarter un run ne pose rien, donc il n'y a rien à défaire. La boucle complète, revert compris, est déroulée dans Runs, acceptation et changements.

Rien n'est automatique par défaut

Les workflows portent des gates : des points où le run se met en pause et attend une décision dans votre file Decisions (« Décisions »). Aucune gate ne s'auto-approuve sauf si cette gate précise a été explicitement configurée pour ça — l'auto-résolution se règle gate par gate, elle est tracée, et désactivée par défaut. Ce n'est jamais un interrupteur global de la plateforme.

Et l'approbation change toujours de mains : vous ne pouvez pas approuver votre propre proposition. Celui qui a proposé un travail — humain ou agent — ne peut pas être celui qui l'approuve. Les gates sont couvertes dans Flux de contrôle ; les règles plus larges vivent dans Gouvernance.

L'acceptation est physique

Quand vous cliquez sur Accept run, la fusion est validée mécaniquement avant que quoi que ce soit n'atterrisse : le système valide la branche du run en exerçant le résultat fusionné — jamais par le verdict d'un LLM — et il refuse plutôt que de laisser passer quand il ne peut pas vérifier. Voyez-y une exigence que la plateforme impose à chaque acceptation, pas un exploit qu'un run en particulier démontrerait : si la vérification mécanique ne peut pas aboutir, l'acceptation refuse, et le bon réflexe est de lancer un nouveau run. Un modèle qui dit « ça a l'air bon » ne vaut jamais acceptation.

Ce qu'il y a dans la boîte

Comment lire cette section

Choisissez le chemin qui correspond à votre situation :