This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Ting workflows

The definition and execution layer that Ting's console presupposes: workflow definitions, the reusable parts they share, and the executor that runs them. Epic: Ting/workflows#1.

This wiki carries the architectural view: how the crates compose, where each boundary sits, and what each perimeter admits. Crate READMEs and doc-comments carry the per-function detail; this wiki does not repeat them.

Rulings the architecture implements

• Agents are A2A Agent Cards, sourced as YAML, served as JSON, living in larandar/agents.lar — one card per seat kind; running instances are contexts on a card, never cards of their own. This repository holds no card.
• A workflow is an Open Workflow Specification (CNCF, DSL 1.0) definition — the deployment layer: each step binds a card by reference, a model route, inputs, authority, and a gate. Its input schema is what Dispatch renders; Dispatch only starts a workflow.
• The executor is Ting's own, in Rust, deliberately small: parse and validate on the spec's Rust SDK, provision what each step's agent needs, start steps over ting-a2a, evaluate gates, emit run state. No general engine.
• Code gates are OpenSpec + Datalog, evaluated by the executor and callable by agents. The OpenSpec capabilities (contracts.ting.agent-card, contracts.ting.workflow-definition) live in Ting/contracts.
• The UI never legislates for the harness: everything the console shows about a run is what the executor or the harness emitted.

How the crates compose

One dependency direction, no cycles: everything depends on executor-core; wf-cli sits on top of the rest; the top-level executor crate is the façade that re-exports core types under one package name.

                    executor  (façade: re-exports executor-core)
                        |
  wf-cli  --------------+--------------+
   |  commands: wf run / wf check      |
   |  engine, JSON event stream        |
   v                                   v
executor-nu          executor-harness   executor-sandbox
 in-process Nushell   step transports    bwrap provisioning
   |                     |                  |
   +----------+----------+------------------+
              v
        executor-core
   OWS AST, parser, binding,
   native commands, projection

• executor-core — the one model. Typed OWS AST, parser with structured diagnostics, syntax normalizer, contextual binding with mutual exclusion, native commands, and projection of loaded workflows onto CLI commands and MCP tools. Every other crate surfaces failures through its error family; wf-cli maps that family to exit codes.
• executor-nu — in-process Nushell embedding. Steps expressed as Nushell evaluate inside the executor's process, with the run context injected as $env.TING_RUN.
• executor-harness — how a step reaches an agent: the DSH loopback HTTP transport, and sandboxed external CLI transports (Claude, Pi, Codex).
• executor-sandbox — how a step is contained: a deterministic bwrap argv assembled from probed mounts, masking, namespace and network containment, a UNIX-socket RPC bridge, PID 1 lifecycle, and the reaper law.
• wf-cli — the operator surface: wf run and wf check, JSON event lines on stdout, stable exit codes 0–6.

The catalog (catalog/) holds the public, reusable parts — versioned function library, seat and gate templates, sub-workflows. A part enters the catalog only when a second workflow reuses it.

Perimeter

The executor starts workflows; it is not a scheduler, queue, or general engine. Dispatch renders a workflow's input schema and starts it; the executor owns everything after that start and reports it as events. Nothing the console shows about a run originates anywhere but the executor or the harness.

Pages

• executor-core — executor-core: the shared workspace model every other crate depends on.
• executor-nu — executor-nu: Nu-script workflow steps and evaluation.
• executor-sandbox — executor-sandbox: sandboxed execution perimeters for untrusted steps.
• executor-harness — executor-harness: the executor that drives workflow runs end to end.
• wf-cli — wf-cli: the command-line front door to define, inspect, and run workflows.