Close the gaps in DORA's deployment automation checklist

[atkrad]

docs/comparison.md now points at DORA's deployment automation capability, so we should be able to back that up. This issue tracks the gap until we can walk the whole checklist and tick every box.

Reference: https://dora.dev/capabilities/deployment-automation/

The checklist, roughly: ship the same package to every environment, keep environment config separate, deploy with no manual steps, run any deploy-time tasks (migrations included), test the deployment afterwards, and keep a record of what is running where.

Already there

• Same image and same spec everywhere. Only the resolution differs per environment.
• No manual steps. deployah deploy <env> -y plus --output json and --detailed-exitcode is enough for CI.
• Deploy blocks until resources settle and rolls back on failure (WaitStrategy and RollbackOnFailure in internal/helm/helm.go), bounded by the 10m default --timeout.
• Environment config lives outside the app spec: contexts, domains, TLS, and profiles in deployah.platform.yaml.

Open

• env never reaches the container. It passes schema validation and then goes nowhere. Environment-specific config is half of this checklist, so this is the big one. (Related later: proposal: support SOPS-encrypted env files #78 for SOPS-encrypted env files, once plaintext env actually works.)
• Nowhere to run deploy-time tasks. Tracked in proposal: support role: job workloads #17 (role: job). Schema and init copy already talk about migrations; deploy still rejects the role.
• No real deployment test. The default probes say the container is up. They do not say the app can reach its database or that the ingress serves traffic. We should decide whether to add a smoke check or document that the probes are as far as we go.
• We do not record what is running. list and status print PROJECT / ENV / STATUS / REV / AGE / NAMESPACE. The revision is a Helm counter, not a build. You cannot answer "which image is in staging" without going to the cluster yourself. (Pairs with proposal: support deployah rollback #29: rollback needs a clear picture of what you are rolling back to.)
• Alpha schemas. Hard to call the process repeatable while v1-alpha.4 can break between releases.

Related

• proposal: support role: job workloads #17 – role: job (deploy-time tasks / migrations)
• proposal: support deployah rollback #29 – deployah rollback (deliberate undo after a bad successful deploy)
• proposal: support SOPS-encrypted env files #78 – SOPS-encrypted env files (depends on env actually applying)

Not doing

Image builds and test automation stay in CI. That boundary is deliberate, and docs/comparison.md explains why. Blue/green (#33) and canary (#34) are separate promotion models; they are not required to close this checklist.

Done when

Every box above is ticked, and the audit is worth writing up: walk the DORA checklist item by item, including the parts we decided against.