Adapters

Adapters are how action and utility nodes reach the outside world. Each adapter is a self-contained module that plugs into the orchestration engine and is selected by name.

How the engine sees an adapter

The executor resolves node.data.adapter against a registry of named adapters, then hands the adapter the whole node. The adapter reads actionId and per-node configuration from the node’s data. Streaming adapters emit live log events while they run, and non-streaming ones return a single output. Every adapter also publishes a descriptor of its actions and fields. That descriptor is the catalog that validation and the DSL adapter references are generated from, so the documentation always matches the live action surface.

The Rust trait behind this and the recipe for writing a new adapter live in the development docs: Rust API: adapters.

Registered adapters

Name	Implementation	Status
`shell`	Real streaming adapter	Local CLI tools with audit and sandboxing
`fs`	Real adapter	Workspace-confined filesystem operations
`cli`	Real adapter	Vendor-neutral: runs any CLI tool named by `node.data.bin`
`mock`	Mock	Always-available demo/test adapter
`zosmf` / `ssh` / `send-email`	Mock	Placeholders that return synthetic payloads

The CLI adapter

One vendor-neutral adapter drives every CLI-backed node. The binary comes from node.data.bin rather than a per-vendor adapter, so the platform stays vendor-unlocked. It shells out argv-only and never through a shell:

<bin> <command path> <positionals...> <flags...>

Output handling is opportunistic. If stdout parses as JSON, it becomes the payload directly. Otherwise the payload is { stdout, exitCode }. Catalog presets such as Zowe Command and GitHub Command are cli nodes with bin pre-stamped, plus a command catalog for the inspector’s picker. If bin is not on PATH, the adapter returns a clear command-not-found error, and downstream fail edges can fire. See the CLI adapter reference.

The shell adapter

The shell adapter lets a flow run a local CLI command. It streams stdout and stderr live, captures the final output into execution history, and appends an audit JSON line for every invocation. The curated actions are run-command, which runs via sh -c, along with git, npm, pnpm, cargo, kubectl, and curl, which are argv-split. Optional per-node fields control cwd, timeoutMs, maxOutputBytes, env policy, and sandbox capabilities. See the shell adapter reference and Sandboxing.

The execution workspace

Every run resolves one shared workspace root, which is forwarded to the shell, cli, and fs adapters. A node defaults its cwd and workspaceRoot to that root. An explicit value wins, and a relative one anchors to it. The root is the stored per-flow folder if one is set, and otherwise it is the edition default. That default is a per-flow scratch directory on desktop and server, or the launch directory for the CLI. The workspace is an execution concern only and is never sent to a model.

The utility adapter

The utility adapter provides built-in primitives that need no external adapter. These are sleep, log, set-variable for session memory, merge for fan-in, cron as a schedule marker, and download. The download primitive fetches a URL into the downloads directory, refuses non-HTTP(S) schemes, blocks path traversal, and caps the response body. Vendor-specific install flows belong in Template Hub catalog data, not in the adapter.

Flows and nodes
Execution model
DSL adapter references
Rust API: adapters, which covers the Adapter trait and how to write one.