# Dev full source-build recovery

Dev full uses one reusable generated Session Tiltfile per session. Starting a new
session does not require renaming or copying that Tiltfile; select a new unique
session name in `cp9.yaml` and let `cp9 up` materialize the session-owned runtime.

`cp9 up` is also the supported resume command. It verifies the persisted Tilt
PID and command before acting. A dead owned Tilt process resets only the runtime
handoff steps, a dead owned kube tunnel is replaced in place, and a reused PID
that belongs to another command fails closed. Editing `.cp9` state by hand is not
a recovery procedure.

## Source-build prerequisites

Docker requirements depend on the chosen source path:

- remote EC2 K3D builds run Docker and K3D on the remote host; the workstation
  needs Git, Go for the authenticated module cache, SSH, and the CP9 tools;
- a path that explicitly builds a local image still requires a working local
  Docker engine;
- image-pinned services do not require a local source build.

The Dev full and imported Starter build paths use the same Git manifest. Tracked
files and non-ignored untracked files are included; ignored dependency caches
such as `node_modules` are excluded. The archive and fingerprint are derived
from that same ordered manifest.

## Timeouts and exit 137

An external CI/agent timeout and CP9's internal readiness deadline are separate
limits. Increasing the outer timeout does not change CP9 readiness, and changing
CP9 readiness does not extend the caller's execution budget.

Exit 137 is not automatically an out-of-memory diagnosis. CP9 reports
`host-oom` only with kernel OOM evidence, `pod-oom` or `container-oom` only
with service-scoped Kubernetes/Docker `OOMKilled` evidence, and otherwise
`unknown-sigkill`. A source-sync process killed by CP9's own timeout watchdog is reported separately as
`external-kill-by-timeout-watchdog`. Keep `m7i.xlarge` and the current readiness
deadline until captured host, container/Pod, kernel, duration, and concurrency
measurements justify a change.

## Starter readiness boundaries

Before Starter activation, the absence of an activation-created target such as
`dbaas-proxy` is a prerequisite state, not proof of a broken rollout. A
persistent `restore_jobs` failure after activation is a separate workload
readiness failure and must retain its named check and retry command. Use
`cp9 starter status` to distinguish these states.

Destroy is asynchronous for Dev full: CP9 first persists the accepted cleanup
workflow run and scope, then stops Tilt, tunnels, and K3D without contacting the
Dedicated API. The workflow owns tag and persisted-ID deletion across every
enabled AWS region and must finish its exact zero check. The receipt under
`.cp9/destroy-handoffs` remains after the session directory is removed.