Flux post-build

Utilise cette skill après le succès de build-workflow sur un build d'orchestrator direct, ou quand le message courant contient <workflow-verification-follow-up> ou <workflow-setup-required>.

Pour les formes inputData du trigger, consulte knowledge-base/reference/trigger-input-data-shapes.md dans l'espace de travail sandbox si disponible, ou charge le fichier lié references/trigger-input-data-shapes.md de cette skill.

Suivi de vérification

Quand le message courant contient <workflow-verification-follow-up>, vérifie immédiatement à partir de l'obligation du payload — ne confirme pas d'abord. Si l'obligation est ready_to_verify ou verifying, appelle verify-built-workflow. Ne pas appeler workflows(action="setup") dans ce tour et ne pas déclarer le workflow terminé si outcome.setupRequirement.status === "required" — la configuration est routée automatiquement comme une étape <workflow-setup-required> distincte après la vérification.

Suivi de configuration

Quand le message courant contient <workflow-setup-required>, ta seule action est d'appeler workflows(action="setup") avec le workflowId du payload. Ne vérifie pas, ne demande pas, n'écris pas de message en premier — la carte de configuration en ligne dans le panneau AI Assistant est la surface visible pour l'utilisateur. Si elle retourne deferred: true, respecte le choix de l'utilisateur et ne réessaie pas avec d'autres outils de configuration.

Publication et tests

La publication n'est jamais requise pour les tests. À la fois executions(action="run") et verify-built-workflow injectent inputData comme sortie du trigger — le workflow n'a pas besoin d'être actif. Les triggers basés sur formulaire, webhook, chat et autres événements sont tous testables pendant que le workflow est non publié. Ne publie jamais un workflow comme précondition pour l'exécuter.

Après le succès de build-workflow

1. Lis workflowId, workItemId, triggerNodes, verificationReadiness et setupRequirement de la sortie de l'outil. Si la sortie manque un workflowId, explique que la compilation n'a pas été soumise.
   • Avant de traiter un workflow sauvegardé comme terminé, inspecte le workflow persisté avec workflows(action="get-json", workflowId) et compare le graphe réel au résultat demandé par l'utilisateur. Le succès build/save signifie seulement qu'un workflow a été sauvegardé ; cela ne prouve pas que le workflow sauvegardé est correct.
   • Si le workflow persisté manque le résultat demandé, a une forme de brouillon avec impasse évidente, ou que la preuve de vérification est faible, charge la skill workflow-builder et corrige le même workflow avec build-workflow en utilisant le workflowId et workItemId existants ; puis inspecte et vérifie à nouveau.
   • Si verificationReadiness.status === "already_verified", traite le workflow comme vérifié et ne pas appeler verify-built-workflow à nouveau.
   • Si verificationReadiness.status === "ready", appelle verify-built-workflow avec le workItemId / workflowId et la forme inputData appropriée au trigger.
   • Si verificationReadiness.status === "needs_setup", appelle workflows(action="setup") avec le workflowId pour que l'utilisateur puisse le configurer via la carte de configuration en ligne dans le panneau AI Assistant.
   • Si verificationReadiness.status === "not_verifiable", ne déduis pas les conditions de vérification de niveau inférieur ; utilise les indications de disponibilité pour donner un avertissement clair ou une note de test manuel. C'est un état d'achèvement d'avertissement, pas un état vérifié et pas un bloqueur infini.
2. Après la gestion de la vérification, si setupRequirement.status === "required" et la configuration n'a pas déjà été exécutée pour cette compilation, appelle workflows(action="setup") avec le workflowId.
3. Quand workflows(action="setup") ouvre la carte de configuration en ligne, la carte est la surface visible pour l'utilisateur. Ne dis pas à l'utilisateur d'ouvrir l'éditeur, d'utiliser le canevas, ou de cliquer sur un bouton Setup ; l'utilisateur n'a besoin de naviguer nulle part.
4. Quand workflows(action="setup") retourne deferred: true, respecte la décision de l'utilisateur — ne réessaie pas avec credentials(action="setup") ou n'importe quel autre outil de configuration. L'utilisateur a choisi de configurer plus tard.
5. Demande à l'utilisateur s'il veut tester le workflow (ignore cette étape si verify-built-workflow a déjà prouvé qu'il fonctionne de bout en bout).
6. Appelle workflows(action="publish") seulement quand l'utilisateur demande explicitement de publier. Ne publie jamais automatiquement.

Identifiants avant build

Appelle credentials(action="list") d'abord pour savoir ce qui est disponible. Construis le workflow immédiatement — le builder préserve les identifiants valides explicites et auto-simule les identifiants manquants ou non sélectionnés. Ne demande pas s'il faut compiler maintenant et configurer les identifiants plus tard ; la compilation en premier et le routage de la configuration après vérification est le chemin par défaut. La vérification du workflow est automatique à partir du résultat de la compilation ; l'orchestrator gère la configuration du workflow après vérification quand le workflow sauvegardé a encore des identifiants simulés ou des espaces réservés.

Demande une seule fois quand un service a plusieurs identifiants du même type. Si credentials(action="list") montre plus d'une entrée du type dont une intégration demandée a besoin (par ex. deux comptes openAiApi, trois comptes Google Calendar), utilise ask-user avec un sélecteur à choix unique pour laisser l'utilisateur en choisir un avant la compilation, et utilise le nom d'identifiant choisi dans le code du workflow. Exception : l'utilisateur a déjà nommé l'identifiant dans son message — utilise-le directement. Avec un seul candidat, applique automatiquement et ne demande pas.

Demande quel type d'authentification utiliser quand un service en supporte plus d'un. credentials(action="setup") ouvre un sélecteur verrouillé à un seul credentialType — l'utilisateur ne peut pas changer de type d'authentification depuis là. Donc quand credentials(action="search-types") retourne plus d'une option d'authentification pour un service (par ex. notionApi et notionOAuth2Api, ou slackApi et slackOAuth2Api), utilise ask-user avec un sélecteur à choix unique pour laisser l'utilisateur choisir le type d'authentification avant d'appeler credentials(action="setup"). Liste OAuth2 en premier et présente-le comme l'option recommandée. Exception : l'utilisateur a clairement indiqué un type d'authentification (par ex. « clé API », « oauth », « token personnel ») — mappe-le au credentialType correspondant et utilise-le directement sans demander.