Cattle, not pets

A ZTD VM is cattle: created for a task, run unattended, and destroyed. It is never a pet — a long-lived box you nurture, patch, and fear losing.

The lifecycle

up ─▶ provision ─▶ inject ephemeral key + synced secrets ─▶ sync/clone repo
   ─▶ launch agent (YOLO) ─▶ agent works autonomously
   ─▶ push result branch [+ open MR] ─▶ export audit ─▶ down (manual, v1)

The operator initiates; the run is autonomous. Results are durable because they land in git — a branch or merge request. The VM itself holds nothing of value, so destroying it costs nothing.

Why this matters

  • It’s what makes YOLO mode safe. If the box is disposable and the only thing that escapes is a reviewed git branch, an agent running without approval prompts can’t cause lasting harm. Isolation plus disposability is the safety story.
  • “Fixing” a VM means recreating it. A bad run? ./ztd reset gives you a clean box from cloud-init. There’s no state to debug or repair.
  • No drift. Every VM comes from the same image and cloud-init, so “works on my VM” means it works on everyone’s.

Implications for your workflow

  • Don’t store anything in the VM you aren’t willing to lose — push it.
  • Treat ./ztd down as routine, not scary.
  • Per-instance state (Terraform state, the ephemeral SSH key) lives host-side under .ztd/state/, isolated per instance so multiple cattle can coexist.

Teardown is manual in Phase 0. Automatic lifecycle — destroy on completion, on MR open, or on a TTL — is on the roadmap.

Backward Architecture Roadmap Forward