IT current-state · DeployFlow

Where DeployFlow stands today

One destination is built. The checks that prove a service works still live inside each role rather than in one place, and every application carries its own. This is the picture the next destination starts from.

Where DeployFlow stands today Three zones show the current state of DeployFlow: authoring, where the agent writes a manifest and a role that carries its own checks; delivery, where appctl builds pinned artifacts and installs them; and the guests, where a build host and the omniroute service run. Two further destinations are named in the registry but not built. AUTHORING DELIVERY GUESTS app.yaml source · config · secrets · target apps/<name>/ — the role written by the agent · reviewed as a diff The checks per application not shared appctl build pinned · hashed appctl install Ansible · changed=0 on a re-run docker_vm · vm named in the registry builder toolchain · builds other apps omniroute answers · port 20128 appctl secrets mode 0600 · gitignored · never in argv — it reaches the guest as a file LEGEND delivery declaration proof named, not built the point of the workflow proxmox_lxc is the only implemented target. docker_vm and vm are named so a manifest can ask for them and get a clear answer instead of a failure. Each application carries its own checks, so a new application means writing new asserts — there is no shared check library yet. MANIFEST ROLE ASSERTS ARTIFACT BLOCKED BUILD DEPLOY BUILDS PROVES

THE HEADLINE

The proof is per-application

  • Checks live inside each role, not in one place.
  • A new application means new asserts.
  • That is correct, but it is repeated work.

One destination, built

proxmox_lxc is implemented and carries the shipped applications. docker_vm and vm are named in the registry but not built — the gap the next destination closes.

What survives

The manifest, the role contract and the checks do not change when the destination does. Only src/appctl/targets/ grows a file.