Why start here?
Shuttle turns ordered work into real execution instead of leaving it as good intention.
Execution / Runtime
The execution layer that does not forget
Workflow execution and operational process motion.
Shuttle turns ordered work into real execution instead of leaving it as good intention.
jhf-shuttle is the Helpifyr module for n8n-centered workflow engineering and runtime operations. It combines a large Python CLI and library surface (n8n_expert), an optional Mission Control-style API, upgrade and catalog intelligence, and an optional on-prem delivery runtime for OpenClaw-style agent messaging.
It is not a control plane that owns global contract truth. Instead, it owns its own runtime, verification, and operational evidence surfaces, while consuming Fabric-owned governance truth read-only where that boundary already exists.
Status Available now README sync 29 Apr 2026
When do I need this?
Start here when you want to see how the system translates work into actual flows and outcomes.
What role it plays here
Workflow execution and operational process motion.
Without Shuttle, orchestration stays theoretical. With Shuttle, plans become dependable execution.
What the module actually does
It builds, validates, and runs workflow paths so handoffs are not just planned but actually executed.
At the core
Searches nodes, templates, and workflow patterns for n8n operators.
Validates workflows, expressions, connections, readiness, and deployment safety.
Operates live n8n instances through CLI and optional API surfaces.
Produces upgrade intelligence, catalog freshness evidence, and Mission Control summaries.
Runs an optional durable mailbox path with NATS, a mailbox adapter, lane-wait observation, and restart recovery.
Verifies runtime contracts, port ownership, overlap guards, and CPU-safe shared-host behavior.
What role it plays in the stack
This repository owns:
the jhf-shuttle CLI and Python package surface the optional Mission Control API surface under /api/v1 the repo-owned runtime contract for the Shuttle on-prem and self-stack paths verification scripts, evidence paths, and runtime guardrails for this module
This repository consumes read-only truth from other modules:
Fabric contract governance and combination/profile truth OpenClaw environment/runtime materialization truth external n8n runtime state and upstream release truth
This repository explicitly does not own:
global Fabric contract truth OIDC/session truth OpenClaw host environment truth ERP/identity truth from other product modules
What this looks like in practice
Without Shuttle, orchestration stays theoretical. With Shuttle, plans become dependable execution.
A signal comes in.
The system assigns the right role and path.
Execution happens through controlled handoffs.
Result and evidence return together.
How it fits into the system
Shuttle does not stand alone. It connects to neighboring modules so a single capability becomes dependable follow-through.
Important boundary
Shuttle stays bounded to its role as Workflow execution and operational process motion. It does not replace other modules; it makes its part of the system traceable, connectable, and reviewable.
What comes next
Warp Runtime orchestration and controlled execution steering. Wire Delivery and integration layer for external handoffs. Tenter Runtime evidence, readiness, and provable execution. Loom The system’s governed content layer. Spindle Business truth and operational business logic. All modules Back to overview
What keeps this page honest
This explanation stays anchored to the module’s current truth, including its real boundaries, responsibilities, and contracts.
Shuttle is the execution layer where ordered intent turns into real processes and workflows.
It builds, validates, and runs workflow paths so handoffs are not just planned but actually executed.
Without Shuttle, orchestration stays theoretical. With Shuttle, plans become dependable execution.
Active part of the system with clearly defined boundaries.
Source and repo truth
This page is rendered from the repo-owned projection truth and remains tied to the README, module boundaries, and status.
GitHub JaddaHelpifyr/jhf-shuttleShuttle
Without Shuttle, orchestration stays theoretical. With Shuttle, plans become dependable execution.