Skip to content

Create and Publish Flow

Flow publishing follows the CLI build workflow used by asactl.

Collect agreements first

List local agreements:

asactl agreement listmy

It scans:

  • ~/.asactl/build/flow/agreements/

Search and pull:

asactl agreement search -q '{"tags":["payment"]}'
asactl agreement get -q '{"agreementName":"shop","version":"v1.0.0"}'

Working directory notes:

  • ~/.asactl/build/flow/agreements/: local agreement copies referenced while writing a flow
  • asactl agreement listmy: lists locally known agreements
  • asactl agreement get: fetches a remote agreement into the local workspace

Build flow.md

Create:

  • ~/.asactl/build/flow/flow.md
  • ~/.asactl/build/flow/meta.json

Recommended content:

  • title / version / description
  • referenced agreements (name + version)
  • internal flow
  • external flow
  • testing and exception handling notes
  • installation success condition
  • asactl call command used to verify the generated service
  • service usage document placed in the project directory
  • service usage document covering start, stop, restart, verification, and later requirement changes
  • post-install prompt asking whether to publish the service to ASAHub

For service-building flows, treat the default installation success condition as:

  • the generated service can be called successfully through asactl

Typical verification shape:

asactl call <agreement> -a <action> -v <version> -h <service-host>

Publish flow

asactl flow post -q '{"name":"sample-flow","summary":"flow summary","content":"..."}'

Publication notes:

  • publish payload content comes from your authored flow.md
  • meta.json is local tracking metadata and is not the published artifact
  • after the flow is executed successfully, the agent should ask whether the generated service should be published to ASAHub

Record meta

Create or update:

  • ~/.asactl/build/flow/meta.json

Keep at least:

  • version, created, lastModified, author
  • flows[] with name, summary, flowId, created, tags