Swimlane · DeployFlow

How an application reaches a server

Four lanes, one direction. The agent writes, you approve, appctl delivers, and the guest proves the service answers before the run is called done.

How an application reaches a server Swimlane diagram of the DeployFlow workflow: you ask the agent for an application, the agent writes the manifest and role, you review the diff, appctl builds and installs the pinned artifact, the guest runs the application's own checks, and the service answers. A failed check refuses the install and names the fix. YOU AGENT APPCTL GUEST REQUEST THE DIFF APPROVE DELIVER PASS REFUSE Ask for an app one request Write the delivery manifest · role Review the diff app.yaml · apps/<name>/ Build artifacts appctl build <name> Install appctl install <name> Run the checks the role's own asserts Service answers changed=0 on a re-run the service answering is the proof LEGEND Flow Refusal Step Verified outcome

THE HEADLINE

The green play is not the proof

A run is not done when the playbook exits zero. It is done when the service answers a request — so the checks live in the role, and they run after every install.

One owner per step

  • You ask, the agent writes, appctl delivers
  • Crossing a lane is a handoff, never a shared step
  • A refusal names the fix and goes back to the agent

Run it twice

The second appctl install reports changed=0. That is the proof the run is repeatable rather than reinstalling itself.

how an application reaches a server · swimlane deployflow · diagram design