Refus et modes d'échec

Cette page est la surface de diagnostic des outils workflow et run : quand un appel est refusé, cherchez ici le token ou le code. Chaque entrée donne le token verbatim, l'outil qui le lève, la cause et la récupération. Les tables normatives de tokens vivent dans la référence agent ; les séquences d'appel canoniques dans les recettes agent.

Chaque refus de cette page est fail-closed : Genesis refuse et laisse l'état intact plutôt que de deviner — rien de partiel n'atterrit jamais.

Comment lire cette page

Les refus arrivent sous deux formes :

un token de statut dans la réponse — mission_run_start et mission_run_accept répondent par un token, et tout token autre que Started / Accepted signifie que l'opération n'a pas eu lieu ;
une enveloppe d'erreur portant un code — les outils d'authoring et de cycle de vie refusent avec VALIDATION_ERROR ou CONFLICT.

Un appel refusé n'exige jamais de nettoyage : corrigez la cause et retentez. Pour l'architecture derrière ces règles, voir le chapitre workflows.

Échecs de publication et de validation

Levés par workflow_validate_draft et workflow_publish, code VALIDATION_ERROR. Le validateur agrège : il signale tous les problèmes du graphe d'un coup ; traitez donc la liste entière avant de revalider — aucune file cachée de problèmes ne se trouve derrière le premier.

Problème	Ce que le validateur a vu	Correctif
Dominance de gate	Un chemin de dépendance atteint un node classé écriture sans traverser de gate.	Ajoutez une gate qui domine l'écriture — chaque chemin vers l'écriture doit en traverser une. Voir les gates.
Site llm non gouverné	Un node llm générique est lié à un site qui n'est pas un site deny-all enregistré.	Liez le node à un site deny-all enregistré. Les nodes llm génériques ne portent aucun outil, par construction.
Toolset d'agent hors politique	Le toolset d'un node agent n'est pas un sous-ensemble de la politique d'outils effective de son site.	Réduisez le toolset à la politique du site. Tout outil déclaré — écriture ou lecture — reclasse aussi le node en écriture à la publication (fail-closed ; seul un toolset vide garde un node classé lecture) — la dominance de gate s'applique alors à lui.
Stage manquant sur une écriture	Le graphe est gouverné et un node d'écriture ne porte aucun stage de développement.	Étiquetez le node avec l'un de `Design`, `Implementation`, `Integration`, `Verification`, `PreDeployment`. Voir le plancher de publication.
Node Legacy dans un nouveau draft	Le draft place un node dont le cycle de vie est Legacy — aujourd'hui exactement un : `service:research:llm`. Les nodes Legacy sont bloqués à la publication dans les nouveaux drafts.	Remplacez-le par le node Standard courant que le catalogue propose pour le même travail.
Reconvergence de bras	Des cas de branch, des décisions de gate ou des bras d'issue reconvergent vers un même node aval. Les bras ne reconvergent jamais.	Gardez la suite de chaque bras séparée. Un bras non routé est une impasse valide.
Forme du corps de fan-out	Un corps de fan-out enfreint ses règles de forme : un corps de MapFanOut avec plus d'une étape du catalogue ou d'une référence de sous-workflow, ou une région Loop Body de ForEach portant des nodes structurels.	Déplacez un corps multi-étapes dans son propre workflow et référencez-le — ou, pour ForEach uniquement, câblez-le en région Loop Body d'étapes simples du catalogue. Les nodes structurels ne s'imbriquent jamais dans un corps de fan-out.
Segment d'id réservé	Un id de node utilise un segment réservé (`__` ou `#`).	Renommez le node.
Contrôle non dérogeable	Une dérogation a été demandée sur un contrôle qui ne peut pas être levé.	Il n'existe aucun chemin de contournement — publiez avec le contrôle injecté en place. Voir les dérogations.

Conflits de cycle de vie

Code CONFLICT. Ces refus protègent le cycle de vie à trois états — Draft → Published → Archived, dans cet ordre uniquement.

Conflit	Levé par	Sens	Que faire
Édition hors `Draft`	`workflow_update_draft`, `workflow_delete_draft`	La version visée est `Published` ou `Archived`. Seul un draft peut être édité ou supprimé.	Créez un nouveau draft — les graphes publiés sont immuables, un changement atterrit donc toujours comme nouvelle version.
Archivage d'une version non publiée	`workflow_archive`	Seules les versions `Published` s'archivent. Un draft se supprime, il ne s'archive jamais.	Utilisez `workflow_delete_draft` sur les drafts.
Archivage bloqué par des références vivantes	`workflow_archive`	Un workflow publié embarque encore celui-ci comme sous-workflow.	Listez les consommateurs avec `workflow_referenced_by`, déplacez-les avec `workflow_rebind_flowref` (le rebinding invalide la ratification des gates — ils ré-approuvent), puis archivez.

Refus au démarrage d'un run

Levés par mission_run_start. Tout token autre que Started signifie qu'aucun run n'a été créé. Le vocabulaire complet des 11 tokens est dans la référence agent ; la séquence qui les traite est attacher et lancer.

Token	Sens	Que faire
`RunAlreadyOpen`	La mission a déjà un run ouvert, et les runs sont strictement séquentiels par défaut.	Acceptez ou écartez d'abord le run ouvert — ou utilisez la compétition par `groupId` dès le départ quand vous voulez des candidats en parallèle.
`ChildSpawnerDisallowed`	Le graphe contient un node qui engendre des missions enfants ; ces nodes ne peuvent pas tourner dans un run de mission.	Retirez ou remplacez le node en question, republiez, puis retentez.
`FeatureDisabled`	`Workflows:MissionRuns:StartEnabled` est désactivé dans cet environnement.	Demandez à votre opérateur de l'activer ; aucun paramètre d'appel ne contourne un flag désactivé.
`MissionNotPlanned`	La mission n'a pas encore de plan approuvé.	Laissez la planification se terminer et faites approuver le plan, puis retentez.
`MissionTerminal`	La mission est finie — terminée, échouée ou annulée.	Démarrez une nouvelle mission, ou créez-en une directement avec `workflow_invoke`.
`AgenticMissionUnsupported`	Le type de cette mission ne peut pas accueillir de runs de workflow.	Utilisez une mission qui le peut, ou créez-en une neuve avec `workflow_invoke`.
`TipUnavailable`	Le tip de la branche de mission n'a pas pu être résolu pour l'instant.	Retentez. Si ça persiste, demandez à votre opérateur.
`WorkflowNotFound`	L'id de workflow et la version ne résolvent vers aucun workflow connu.	Vérifiez l'id avec `workflow_list` et la version avec `workflow_get`.
`NotInvocable`	La version existe mais n'est pas exécutable — c'est un draft, ou elle est archivée.	Publiez d'abord ; un run démarre toujours d'une version publiée explicite.
`MaterializationFailed`	La construction de l'instantané d'exécution figé pour ce run a échoué.	Validez le workflow et ses liaisons de paramètres, puis retentez. Si ça persiste, demandez à votre opérateur.

Refus à l'acceptation

Levés par mission_run_accept. Tout token autre que Accepted signifie que rien n'a fusionné : aucun changement n'a été créé et le tip de la mission n'a pas bougé. Le vocabulaire complet est dans la référence agent.

Token	Sens	Que faire
`StaleRefused`	Le tip de la mission a bougé après le démarrage de ce run ; sa base est périmée.	Démarrez un run neuf depuis le nouveau tip. Ne tentez jamais de forcer un accept périmé.
`MergeConflict`	La branche du run ne fusionne plus proprement sur le tip de la mission.	Démarrez un run neuf depuis le tip courant et laissez-le proposer à nouveau la modification.
`GroupAlreadyWon`	Un autre run du même groupe de compétition a déjà été accepté. Les runs perdants sont rejetés et leurs branches supprimées.	Rien à récupérer — le groupe a son gagnant. Démarrez un nouveau run s'il vous faut encore la modification.
`NotProposed`	Le run n'est pas en `Proposed` — il s'exécute encore, ou a déjà été accepté ou écarté.	Interrogez `mission_run_get` jusqu'à ce qu'il atteigne `Proposed`, en résolvant les gates en attente avec `decision_respond`.
`TipUnavailable`	Le tip de la branche de mission n'a pas pu être résolu pour l'instant.	Retentez. Si ça persiste, demandez à votre opérateur.

Le dernier token mérite sa propre entrée, parce qu'il découle de la doctrine d'acceptation et non de l'état du run :

ValidationRefused — L'acceptation est physique : avant qu'un run ne fusionne, Genesis valide la branche du run en l'exerçant — jamais par un verdict de LLM. Le contrôle est fail-closed : si aucun backend de validation n'est joignable dans votre environnement, l'acceptation est refusée plutôt que laissée passer. Le run reste intact en Proposed ; rien ne fusionne. Récupération : confirmez qu'un backend de validation est disponible (demandez à votre opérateur), puis retentez l'acceptation.

Le revert refuse sur conflit

Levé par mission_revert. Un revert défait les changements en ordre inverse, en cascadant sur les dépendants. Il est fail-closed sur conflit : si un changement de la cascade ne peut pas être défait proprement, toute la cascade s'interrompt et le refus nomme le membre fautif. Rien de partiel n'atterrit — la branche de mission est exactement comme avant l'appel.

Récupération :

Lancez d'abord mission_revert_preview — il montre la cascade complète de dépendants avant que vous ne vous engagiez.
Inspectez le changement nommé dans la pile (mission_changement_stack) et résolvez ce qui le fait entrer en conflit.
Retentez. Un revert refusé n'a rien changé ; retenter est donc toujours sûr.

Voir la pile de changements pour la façon dont les changements se composent sur la branche de mission.

Premiers pas avec ARDS