For operators and campaign owners. Everything is one nested command tree —
httk workflow … — where every group and command answers --help:
httk workspace init | list | default | status | managers | workflows | settings | fsck | gc | seal | unseal | ...
httk job new | submit | request | delete | seal | unseal | list | show | log | why | debug
httk workflow runner publish | describe
httk workflow build (compiled packages: build and register binaries)
httk workflow list | describe | precheck | collect | postprocess
httk workflow seal verify
httk workflow manager run
httk workflow campaign init | show | submit | collect | start-"managers"
httk workflow remote list | add | configure | check | show | remove
httk workflow transfer [OPTIONS] SRC DST
httk project init | show | import-v1 | repair | manifest | seal | unseal | verify-seal (all core-owned; httk-workflow registers the workspace as a project member so these verbs cover it)
httk init | identity (core-owned: establish/manage per-user named operator identities)
httk workflow config | v1
{doc}quickstart walks the everyday sequence; {doc}taskmanager explains the
operator concepts behind it.
The full reference, {doc}details/workflow_cli, documents every command and
option — projects and signed manifests, configuration, remotes and transfers,
and the protocol spellings.
Manager capacities can be advertised with repeatable --worker-resource NAME COUNT options. --count N starts multiple managers at the workspace's launch
site. A local workspace uses its manager.launch setting; a remote workspace
is reached through its adapter, which invokes the same manager command on the
owning machine with --detach.