Skip to main content
A workflow blob’s revision holds definitions, and a definition’s logic.code components normally have their code typed into the visual editor. The workflow command group moves that whole arrangement into a repository: the code becomes an ordinary Python package, the definition documents become files, and one manifest says which revision they belong to. The manifest is the unit of work. It names a blob and a revision, lists every definition that belongs on that revision, and binds each code component to a package entry point. Every command in this group starts by loading it.

​
The shape of a deployable project

Three parts, in one directory tree:
manifest.yaml, for a revision holding one workflow definition whose logic.code component (id: c1) is compiled from pkg/:
Every path in a manifest anchors to the manifest file’s own directory — source, code.base_path and value.source alike. entry_point is the one exception: it resolves against base_path, because it names a module inside the package rather than a file in the project. The full grammar is in the Manifest reference. This example runs through every command page in this group. Where a page says checkout_flow, it means this definition and this package.

​
The lifecycle

The definition file sits in the middle of everything, and it is always a complete, uploadable document: its code ports hold compiled content, not a reference to the package that produced it. That is what lets push work with no compiler in the path, pull work without knowing a package exists, and a reviewer see the compiled code in a pull request beside the sources it came from. build and deploy are the two commands that know Python exists. What they do to a package — resolving its local imports and flattening it into one import-less namespace — is the Compiler reference; what that namespace already contains, and what it refuses, is the Sandbox reference. pull and push are a symmetric pair: a document that goes out through one and comes back through the other comes back byte-symmetric. See Concepts for the verbatim/compiled split in full.

​
The ten commands

They sort into three bands. A reader arriving with a task is in exactly one of them.

​
Lifecycle

The six that move a definition between your repository and the revision, or report on the gap. deploy is the one to reach for day to day; the other five are what you use when you need one half of it.

​
Adoption and execution

​
Reconciliation

Definitions on the revision that the manifest does not mention are drift. No command in this group ever acts on them: they are left untouched, and the command still exits 0. Five report them on one line — pull, push, deploy, diff and check. The rest report them differently or not at all: build never talks to the platform and cannot; ls marks each drifted row in its table instead of printing the line; prune prints its own prune: summary of what it is about to delete; and eject and execute do not report drift at all. prune is the only command that removes them, and only when asked.

​
What every command shares

The manifest is always explicit. -f/--file is required everywhere; there is no default path and no search of the working directory. --definition <alias> narrows the set and is repeatable. It takes a bare alias, and because a definition is identified by the (category, alias) pair, an alias that names both a workflow and a playground definition selects both rather than erroring. --dry-run withholds every side effect on the five commands that carry it: pull, push, build, deploy and prune. diff, check and ls have nothing to withhold. eject and execute do have side effects and still have no dry run — eject guards its writes with --force instead. Global flags come before the group, since they belong to the binary rather than the command:
The revision gate depends on the direction. A write needs status ready and phase draft or managed; a read also allows commit. push, deploy and prune are the writes. Everything else in the group is a read, which is why diff still answers on a revision that deploy refuses — and why the CLI’s own hints point you at diff when a command stops.

​
See also

  • Manifest — the workflow_blob_deployment body in full, over the shared base every blob domain extends.
  • Compiler — how build and deploy turn a Python package into the flat namespace a logic.code component executes, and where that translation stops.
  • Sandbox — what that namespace pre-binds, what it refuses, and how the blob’s import allowlist extends it.
  • Concepts — manifests, the verbatim/compiled split, managed code ports, and the platform behaviours behind several messages in this group.
  • Configuration — credentials, the precedence ladder, output streams and the --json envelope.
  • Error codes — every code these commands can raise, with its remediation.
  • Workflow definition format — the document the definition file holds.
  • Component code — what the platform executes once you have deployed it.