Execution / Runtime
Workflow-Ausführung und operative Prozessmotorik.
Shuttle übersetzt geordnete Arbeit in echte Abläufe, statt sie als gute Absicht stehen zu lassen.
Workflow Engineering bis operatorische Zustellung
Workflows zu bauen ist schnell. Später brechen Validierung, Live-Betrieb, Upgrade-Sicherheit und belastbare Zustellung. Genau dort wird aus Automatisierung plötzlich Risiko.
jhf-shuttle deckt den ganzen Weg ab: Workflows finden, verstehen, bauen, validieren, live gegen n8n betreiben, Upgrade-Auswirkungen sichtbar machen und Agenten robust zustellen. Nicht als Einzeltool. Sondern als operative Surface für reale Verantwortung.
Shuttle wird wertvoll, sobald Workflows nicht nur gebaut, sondern verantwortbar betrieben werden müssen.
jhf-shuttle verbindet vier Dinge in einem Produktbild: Workflow-Engineering-Core, Live-Operator-Surface, durable Messaging-Layer und upgrade-aware Operations.
Es baut, validiert und betreibt Workflow-Pfade, sodass Übergaben nicht nur gedacht, sondern tatsächlich ausgeführt werden.
Workflow-Ausführung und operative Prozessmotorik.
Nicht als lose Featureliste. Sondern als harter Betriebsweg von Design bis Recovery.
Workflows finden und entwerfen. Shuttle durchsucht Templates, liest Node-Fähigkeiten und hilft beim Aufbau neuer Flows, statt mit leerem JSON zu beginnen.
Vor dem Deploy validieren und reparieren. Struktur, Expressions, riskante Muster und veraltete Nodes werden sichtbar, bevor daraus ein Live-Problem wird.
Live n8n mit Evidenz betreiben. Health, Workflow-Zustand, Executions, Webhooks und reale Fehlermeldungen bleiben lesbar. Nicht geraten. Gelesen.
Upgrade-Auswirkungen sichtbar machen. Version-Gaps, Katalog-Freshness und Workflow-Impact werden vor Änderungen sichtbar, damit Rollouts nicht im Blindflug passieren.
Agenten robust zustellen. Im On-Prem Messaging Mode wird aus best effort eine durable Mailbox mit NATS JetStream, Recovery und geordneter Zustellung pro Session.
Kontrolle unter Druck erzwingen. Flow Control, Policy Enforcement, Probe-Trennung und Restart Recovery halten den Betrieb stabil, wenn Last und Fehler gleichzeitig auftreten.
Im Helpifyr-Bild ist Shuttle die operative Automations- und Delivery-Surface. Nicht Business-Truth. Nicht zentrale Portfoliosteuerung. Nicht reine Companion-Funktion.
operative Automations- und Delivery-Surface für das Portfolio
arbeitet mit Fabric, Warp und Bobbin im Kernbundle zusammen
liefert Mission Control und Upgrade Intelligence sichtbar mit
bleibt klar getrennt von Spindle als Business-Truth
bleibt klar getrennt von Beam als Companion außerhalb der Runtime
Shuttle hat zwei saubere Modi. Du kannst mit dem Core starten und tiefer gehen, wenn Betrieb und Zustellung es verlangen.
Shuttle durchsucht Templates, liest Node-Fähigkeiten und hilft beim Aufbau neuer Flows, statt mit leerem JSON zu beginnen.
Struktur, Expressions, riskante Muster und veraltete Nodes werden sichtbar, bevor daraus ein Live-Problem wird.
Health, Workflow-Zustand, Executions, Webhooks und reale Fehlermeldungen bleiben lesbar. Nicht geraten. Gelesen.
Version-Gaps, Katalog-Freshness und Workflow-Impact werden vor Änderungen sichtbar, damit Rollouts nicht im Blindflug passieren.
Shuttle steht nicht allein. Es verbindet sich mit den benachbarten Modulen, damit aus einer Funktion verlässliche Erledigung wird.
Shuttle bleibt in seiner Rolle als Workflow-Ausführung und operative Prozessmotorik begrenzt. Es ersetzt keine anderen Module, sondern macht seinen Teil des Systems klar prüfbar, anschlussfähig und nachvollziehbar.
Die Breite des Produkts wird schnell falsch gelesen. Diese Abgrenzung ist bewusst hart.
kein reiner Workflow-Builder
kein Ersatz für n8n
kein bloßes Messaging-Tool
kein bloßes Monitoring-Frontend
keine generische AI- oder Automation-Plattform
Diese Erklärung folgt der aktuellen Modul-Truth und bleibt an den echten Systemgrenzen, Rollen und Verträgen orientiert.
Shuttle ist die Ausführungsschicht, in der geordnete Arbeit in reale Prozesse und Workflows übergeht.
README.md
Diese Seite wird aus der repo-eigenen Projektions-Truth gerendert und bleibt an README, Modulgrenzen und Status gebunden.
GitHub JaddaHelpifyr/jhf-shuttleIm Helpifyr-Bild ist Shuttle die operative Automations- und Delivery-Surface. Nicht Business-Truth. Nicht zentrale Portfoliosteuerung. Nicht reine Companion-Funktion.