Problem
Re-promoting a prior SHA is possible by dispatching promote.yaml with a target SHA, but there's no first-class command for the rollback intent. Operators reach for git + the dispatch UI; the manifest's per-env state isn't queried to surface candidate rollback targets.
Proposed
Add cascade rollback --env <env> --to <version|sha>:
- Read
state.<env> (and the published-release list) to validate the target is a known-good prior deployment
- Trigger the existing promote pipeline against the chosen SHA (no new code path — just orchestration)
- Mark the rollback in state for observability (e.g.,
state.<env>.rollback_from: <prior_sha>)
Pairs with per-deployable tracking — once that lands, rollback can scope to a single sub-artifact.
Impact
Rollback becomes a documented operation, not tribal knowledge. Prerequisite for any on-call runbook that names this framework as the rollback mechanism.
Problem
Re-promoting a prior SHA is possible by dispatching
promote.yamlwith a target SHA, but there's no first-class command for the rollback intent. Operators reach forgit+ the dispatch UI; the manifest's per-env state isn't queried to surface candidate rollback targets.Proposed
Add
cascade rollback --env <env> --to <version|sha>:state.<env>(and the published-release list) to validate the target is a known-good prior deploymentstate.<env>.rollback_from: <prior_sha>)Pairs with per-deployable tracking — once that lands, rollback can scope to a single sub-artifact.
Impact
Rollback becomes a documented operation, not tribal knowledge. Prerequisite for any on-call runbook that names this framework as the rollback mechanism.