用途：把 duckgres 控制面镜像提升到生产环境。按策略生产发布为人工操作，state/duckgres.yaml 中 require_prod_approval: true，唯一路径是 charts 仓库的 promote-to-prod.yml 工作流，并由 prod-promote-<team> GitHub 环境上的必需审批人把关，结果发到 #alerts-managed-warehouse。
镜像如何进入状态文件（无需手动）：duckgres main 合并后 container-image-cd.yml 构建各架构镜像与多架构清单，再 repo-dispatch commit_state_update 到 PostHog/charts，部署机器人写入 state.duckgres.image.sha 并自动提升 image.dev（mw-dev 立即滚动）。可提升的 ref 是状态文件中的多架构清单摘要，绝不能用单架构摘要或 CD 运行中的 .dockerbuild 产物。
步骤：先用 gh api 拉取状态文件，用 yq 读取 image.dev 与 image.prod，核对 dev 的 git sha 前缀是否为预期合并；用 git log 查看 prod 与 dev 之间的差异提交；执行 gh workflow run promote-to-prod.yml -R PostHog/charts -f app=duckgres -f image="$DEV" 提交发布，此时停在审批门不会部署；随后用 gh run list 取最近运行 URL 并打开审批页。审批必须由必需审批人手动完成，不得以程序方式代替。审批后用 gh run watch <run-id> -R PostHog/charts --exit-status 观察至完成，再用 gh api 读状态文件确认 image.prod 已更新。ArgoCD 会拾取新 image.prod 并滚动生产控制面，如需额外验证可 kubectl -n duckgres get pods -w。
注意：Actions 列表中运行名显示为 promoted duckgres to prod；运行页头部显示的提交是派发时 main 的 HEAD，并非该运行创建的提交，创建的提交从作业摘要链接查看。cache-proxy 是独立部署目标，同一工作流加 -f app=duckgres-cache-proxy，状态文件为 state/duckgres-cache-proxy.yaml。回滚即通过同一工作流重新提升先前已知可用的 ref（可在 charts 仓库 git log -- state/duckgres.yaml 中查看）。