Yeeted in AI development loops

The loop

The intended cycle, all over MCP:

// the agent's iteration cycle
validate      // dry-run: stack detection, port, missing-database warnings, before any build
deploy        // to development (default): a safe test space, seeded from prod data on Small Business and up (after the beta)
smoke_test    // platform-side HTTP probes against the live dev URL
diagnose      // one internally-consistent verdict + recommended_action when anything looks off
promote       // the EXACT tested image goes live under its yeeted.yaml; health-gated blue/green
rollback      // retained git hash: app only; data-bearing production checkpoint: data may restore too

Blameless failure classification

The most expensive agent failure mode is misattribution: a platform hiccup that the agent "fixes" by rewriting healthy code. Every Yeeted failure carries two machine-readable fields:

{
  "cause_category": "build_error | crash | health_check | image_missing | platform | dependency",
  "self_fixable":   true | false
}

self_fixable: false means do not touch the app: retry or wait, it's ours. When it's the code, the failure includes the file and line parsed from the stack or compiler output, so the agent's next edit is aimed, not guessed. Errors are also flagged new since the last deploy, which is the signal for "roll back" versus "fix forward."

Safe retries, safe batches

Deploys are idempotent by content: re-sending identical files returns the existing deploy instead of stacking a second build, so an agent retry loop can't stampede the pipeline. For batch work, project_context reports the platform's live capacity headroom ("development: room for ~6 more instances") so an agent can pace itself, and a deploy sent with queue_on_capacity: true parks on a capacity miss and places automatically when a slot frees (bounded wait), instead of failing the tail of the batch.

Memory for the loop

Every deploy is a numbered version with its source snapshotted. versions_list is the agent's deploy log, whats_changed diffs any two versions, and checkpoint names a known-good state to return to. A fresh agent session starts with one project_context call and has the whole picture: status, URL, versions, databases, secret names, health, and capacity. The code itself is a git repository the agent can read and edit over MCP; see Version control.