JaddaHelpifyr
DEENFR
Retour à la vue d’ensemble

Execution / Runtime

La couche d'exécution qui n'oublie pas

Nom technique: Shuttle

Exécution de workflows et motorique opérationnelle des processus.

Shuttle transforme le travail ordonné en exécution réelle au lieu de le laisser au stade de l'intention.

De l'ingénierie de workflow à la delivery opérateur

Statut Disponible État README 22 mai 2026

Pourquoi commencer ici ?

Construire des workflows va vite. Ensuite, validation, exploitation en direct, sécurité d'upgrade et delivery fiable se fissurent. C'est là que l'automatisation devient un risque.

jhf-shuttle couvre tout le parcours : trouver des workflows, les comprendre, les construire, les valider, les faire tourner en direct contre n8n, rendre visibles les impacts de mise à niveau et assurer une delivery robuste des agents. Pas comme un outil isolé, mais comme une surface opérateur conçue pour de vraies responsabilités.

Quand en a-t-on besoin ?

Shuttle prend de la valeur dès que les workflows doivent non seulement être construits, mais exploités de manière responsable.

  • quand les workflows doivent être exploités, pas seulement construits
  • quand les erreurs doivent être comprises au lieu d'être devinées
  • quand les agents doivent collaborer de manière robuste
  • quand les changements n8n doivent être introduits avec contrôle et conscience des upgrades
  • quand le best-effort n'est plus acceptable

Le rôle qu’il joue ici

jhf-shuttle réunit quatre choses dans un seul produit : un cœur d'ingénierie de workflow, une surface opérateur en direct, une couche de messagerie durable et des opérations conscientes des upgrades.

Du design de workflow à la delivery operator-grade.

Exécution de workflows et motorique opérationnelle des processus.

Ce que le module fait concrètement

Pas comme une liste de fonctionnalités dispersées, mais comme un parcours d'exploitation solide du design à la reprise.

Au cœur

Trouver et concevoir des workflows. Shuttle recherche des templates, lit les capacités des nœuds et aide à construire de nouveaux flux au lieu de partir d'un JSON vide.

Valider et réparer avant le déploiement. Structure, expressions, motifs risqués et nœuds obsolètes deviennent visibles avant de se transformer en problème live.

Exploiter n8n en direct avec preuve. Health, état du workflow, exécutions, webhooks et vrais messages d'erreur restent lisibles. Pas supposés. Lus.

Rendre visibles les impacts d'upgrade. Écarts de version, fraîcheur du catalogue et impact sur les workflows deviennent visibles avant le changement.

Assurer une delivery durable des agents. En On-Prem Messaging Mode, le best effort devient une mailbox durable avec NATS JetStream, recovery et delivery ordonnée par session.

Imposer le contrôle sous pression. Flow control, policy enforcement, séparation des probes et restart recovery gardent l'exploitation stable quand charge et erreurs arrivent ensemble.

Le rôle qu’il joue dans l’ensemble

Dans l'image Helpifyr, Shuttle est la surface opérationnelle d'automatisation et de delivery. Pas la vérité métier. Pas le pilotage central du portefeuille. Pas une simple fonction companion.

surface opérationnelle d'automatisation et de delivery pour le portefeuille

travaille avec Fabric, Warp et Bobbin dans le bundle cœur

apporte visiblement Mission Control et l'intelligence d'upgrade dans l'exploitation

reste clairement séparé de Spindle comme vérité métier

reste clairement séparé de Beam comme companion hors runtime

À quoi cela ressemble en vrai

Shuttle a deux modes clairs. Vous pouvez commencer par le cœur puis aller plus loin quand l'exploitation et la delivery l'exigent.

01

Trouver et concevoir des workflows

Shuttle recherche des templates, lit les capacités des nœuds et aide à construire de nouveaux flux au lieu de partir d'un JSON vide.

02

Valider et réparer avant le déploiement

Structure, expressions, motifs risqués et nœuds obsolètes deviennent visibles avant de se transformer en problème live.

03

Exploiter n8n en direct avec preuve

Health, état du workflow, exécutions, webhooks et vrais messages d'erreur restent lisibles. Pas supposés. Lus.

04

Rendre visibles les impacts d'upgrade

Écarts de version, fraîcheur du catalogue et impact sur les workflows deviennent visibles avant le changement.

Comment cela s’insère dans le système

Shuttle ne fonctionne pas seul. Il se relie aux modules voisins pour transformer une capacité isolée en résultat fiable.

Warp Le chef d'orchestre qui répartit le travail Wire Le chemin vers l'extérieur qui ne finit pas en chaos Tenter La voie voix qui tient en exploitation Loom L'endroit où aucun document ne se perd Spindle La logique métier sur laquelle on peut compter

Limite importante

Shuttle reste limité à son rôle de Exécution de workflows et motorique opérationnelle des processus. Il ne remplace pas les autres modules; il rend sa partie du système traçable, connectable et vérifiable.

Ce qui reste volontairement hors périmètre

Il est facile de lire le produit de façon trop étroite. Ces frontières sont volontairement nettes.

pas un simple constructeur de workflows

pas un remplacement de n8n

pas seulement un outil de messagerie

pas seulement un frontend de monitoring

pas une plateforme générique d'IA ou d'automatisation

Ce qui garde cette page fiable

Cette explication reste liée à la vérité actuelle du module, avec ses vraies limites, responsabilités et contrats.

Shuttle est la couche d’exécution où l’intention ordonnée devient processus et workflows réels.

README.md

Source et vérité du dépôt

Cette page est rendue depuis la vérité de projection propre au dépôt et reste liée au README, aux limites du module et à son statut.

GitHub JaddaHelpifyr/jhf-shuttle

Shuttle

Dans l'image Helpifyr, Shuttle est la surface opérationnelle d'automatisation et de delivery. Pas la vérité métier. Pas le pilotage central du portefeuille. Pas une simple fonction companion.

Retour à la vue d’ensemble Contact