Un prompt peut-il remplacer Integrately ?

Construis un exécuteur d’automatisation dont l’unité de travail est un fichier de recette déclaratif, pas un canevas visuel.

Format de recette : un fichier YAML, versionné et lisible, déclarant :

- un déclencheur : un service, un événement, et un intervalle de polling ou un chemin de webhook
- un filtre : une condition optionnelle sur la charge utile du déclencheur
- une correspondance : des champs cibles vers des expressions sur la charge utile du déclencheur, en utilisant un petit langage d’expression sûr (accès aux champs, concaténation de chaîne, une poignée de fonctions comme lower, trim, format de date). Aucune évaluation de code arbitraire.
- une action : un service, une opération, et les champs correspondus
- une expression de clé d’idempotence, pour que le même événement déclencheur ne puisse pas produire deux actions

Une recette est un fichier dans un répertoire. En importer une, c’est la copier ; en partager une, c’est l’envoyer. C’est ce qui remplace un catalogue à l’échelle perso, et c’est pourquoi le format doit être lisible par un humain, pas généré.

Services : chacun est un module adaptateur avec des identifiants stockés chiffrés, exposant les opérations qu’il prend en charge et un schéma JSON pour les entrées de chaque opération. Implémente deux services complètement pour prouver la forme, et documente l’ajout d’un troisième dans le README avec un exemple travaillé. Valide une recette contre les schémas déclarés au chargement, pour qu’une faute de frappe dans un nom de champ échoue à l’import plutôt qu’à 3 heures du matin.

Exécution : interroge les déclencheurs sur leur intervalle, ou accepte des webhooks à un chemin par recette avec un secret partagé. Pour chaque événement, évalue le filtre, construis la correspondance, vérifie la clé d’idempotence contre la table des exécutions, et appelle l’action. Enregistre chaque exécution : la charge utile du déclencheur, la correspondance évaluée, la requête et réponse de l’action, le résultat, et la durée.

Gestion des échecs : réessaie avec recul exponentiel sur les erreurs transitoires, arrête et marque comme échoué sur un 4xx qui n’est pas une limite de débit, et place les exécutions définitivement échouées dans une liste de lettres mortes. Chaque exécution en lettre morte peut être rejouée après avoir corrigé la recette, en utilisant sa charge utile de déclencheur stockée — c’est la fonctionnalité qui rend une automatisation self-hosted fiable, parce que l’alternative, c’est perdre les événements arrivés pendant qu’elle était cassée.

Exécution à blanc : exécute une recette contre les N derniers vrais événements déclencheurs, en montrant chaque correspondance et chaque action prévue sans en exécuter aucune. Exige qu’une exécution à blanc réussisse avant qu’une nouvelle recette puisse être activée.

Hors périmètre : un constructeur visuel, un flux de contrôle avec branchement ou boucle, plus d’une action par recette, et tout déploiement multi-tenant hébergé. Si une tâche a besoin de branchement, ce sont deux recettes.