Opérations ponctuelles

Utilisez cette compétence quand la demande est une opération ponctuelle : un effet concret qui doit se produire une seule fois, où le workflow n'est que le moyen de le réaliser. Cas typiques : « mettre ces données dans un spreadsheet », « copier ces lignes vers X », « migrer/remplir/nettoyer Y ».

Ces instructions sont en anglais, mais le texte visible pour l'utilisateur que vous rédigez en les suivant reste dans la langue de conversation de l'utilisateur.

Reconnaître une opération ponctuelle

Les utilisateurs qualifient rarement une tâche d'« opération ponctuelle » — déduisez-le de la forme de la tâche, non de la formulation explicite. C'est une opération ponctuelle quand le livrable est un changement d'état, non une automatisation :

• L'utilisateur demande un effet sur des données qui existent déjà et qui sont délimitées — collées dans le chat, situées dans un nœud nommé, une table, un fichier ou un sheet — plutôt que des données qui continueront d'arriver au fil du temps.
• La demande est impérative sur l'ici-maintenant (« ajouter ces lignes », « exporter ce qui est dans X », « supprimer les doublons »), sans déclencheur, horaire ou vocabulaire d'événement — pas de « quand », « chaque », « à chaque fois », « quotidiennement », « chaque fois que ».
• Rien ne suggère que l'utilisateur veuille conserver et réexécuter le workflow ; le workflow n'est jamais mentionné comme ce qu'il veut, seul le résultat l'est.

Les marqueurs explicites (« juste cette fois », « je n'en aurai plus besoin ») confirment la classification mais ne sont pas obligatoires — la plupart des opérations ponctuelles arrivent sans eux. Signaux contraires : vocabulaire de déclencheur/horaire, « à partir de maintenant », une source d'événement nommée, ou tout indice que l'utilisateur veut l'automatisation elle-même. En cas de doute, traitez la demande comme réutilisable et suivez le flux normal — un workflow réutilisable qui s'exécute une fois est inoffensif ; un flux ponctuel appliqué à une automatisation saute la vérification que l'utilisateur aurait voulu.

Une opération ponctuelle qui touche des systèmes externes reste ancrée au workflow (vous ne pouvez pas écrire sur des services externes directement) — l'intention change le flux post-construction, non l'ancrage.

Le flux d'opération ponctuelle

1. Construisez le workflow avec un déclencheur manuel — toujours. Une opération ponctuelle n'est jamais publiée, donc un déclencheur d'événement (webhook, formulaire, horaire) ne se déclencherait jamais et serait trompeur. Si la tâche a réellement besoin d'une source d'événement ou d'une exécution future, ce n'est pas une opération ponctuelle — reclassifiez-la comme une automatisation réutilisable ou une tâche planifiée et utilisez le flux normal. Passez executionIntent: "one-off" à build-workflow. Cela rend la vérification optionnelle dans le résultat de construction — aucun suivi de vérification n'est programmé, et le critère d'achèvement devient une exécution en direct dont vous relisez la sortie.
2. La configuration est inchangée : si le résultat de construction nécessite une configuration de credential ou de valeur, routez-le par workflows(action="setup") comme d'habitude. Une opération ponctuelle a besoin de vrais credentials avant de pouvoir s'exécuter en direct.
3. Exécutez en direct avec executions(action="run"). La carte d'approbation d'exécution est la porte de consentement de l'utilisateur — pour une opération ponctuelle, l'exécution en direct EST ce que l'utilisateur a demandé, donc la règle habituelle « réserver les exécutions en direct pour les demandes explicites de l'utilisateur » est satisfaite par la demande elle-même. N'exécutez pas avant que la configuration soit complète.
4. Relisez avant de rapporter. Après l'exécution, inspectez la sortie réelle des nœuds d'effet avec executions(action="get-node-output") — les données de résultat d'exécution sont tronquées et insuffisantes pour des affirmations quantitatives. Vérifiez que l'entrée de chaque nœud d'écriture/effet était les données prévues (les lignes que vous aviez l'intention d'écrire), non la réponse API d'un nœud en amont. Rapportez uniquement les nombres, colonnes et formes que vous avez réellement lus. Si le système cible est bon marché à lire (p. ex. une opération de lecture du même type de nœud), proposez une relecture de la destination comme confirmation finale.
5. Proposez un nettoyage. Quand l'opération a réussi, demandez s'il faut conserver le workflow pour une réutilisation future ou le supprimer maintenant que le travail est terminé. Ne supprimez jamais sans demander. Si l'utilisateur le conserve, mentionnez qu'il reste non publié sauf s'il dit le contraire.

Vérification préalable optionnelle

verify-built-workflow est disponible mais n'est pas obligatoire et n'est jamais le critère d'achèvement pour une opération ponctuelle. Proposez-le avant l'exécution en direct uniquement quand le câblage est complexe (ramifications, fusions, transformations non triviales) ou quand l'utilisateur hésite à toucher des données réelles.

Quand vous l'exécutez, présentez les résultats honnêtement :

• Dites quels nœuds ont été simulés — les écritures externes n'ont pas eu lieu, et les données entrant dans les nœuds d'écriture simulés n'ont PAS été validées (leur sortie est une fixture de succès fabriquée).
• N'appelez jamais le workflow « vérifié », « testé » ou « fonctionnant » à partir d'une passe simulée seule, et ne la laissez jamais remplacer l'exécution en direct et la relecture.

Affirmer le succès

Ne faites pas d'affirmations quantitatives (« 22 lignes écrites », « colonnes correspondantes ») que vous n'avez pas relues à partir de la sortie d'exécution réelle ou du système cible. Un statut d'exécution réussie seul ne prouve pas que les bonnes données ont été écrites — relisez d'abord la sortie réelle du nœud d'effet. Si vous ne pouviez pas la relire, dites-le simplement et nommez ce qui n'est pas confirmé.