standardize user-service artifact CD

docs/reference/artifact-registry.md

@@ -64,6 +64,14 @@ bun scripts/cli.ts artifact-registry deploy-backend-core --commit <full-sha>
 
 `deploy-backend-core` 是 production backend-core 的 CD 入口。它必须先通过 CNCF Distribution HTTP API 确认 D601 registry 中已经存在 `unidesk/backend-core:<commit>`，随后通过 provider-gateway Host SSH 流式执行 `docker save | gzip`，在 master server 侧 `docker load`、retag、Compose `--no-build` recreate 和 live commit 验证；如果镜像不存在，应失败并要求先运行 CI artifact publication。
 
+`deploy-service` 是标准化后的最小通用 artifact consumer。它目前只支持 `backend-core` 和 `decision-center`，并且必须先通过 D601 registry 的 commit-pinned manifest 校验，再执行拉取、导入、部署和健康验证：
+
+```bash
+bun scripts/cli.ts artifact-registry deploy-service --service decision-center --commit <full-sha> --run-now
+```
+
+dry-run 输出会暴露 registry probe URL、required labels、目标 image、部署形态和回滚信息。`decision-center` 的 prod 路径会在 D601 上验证 `unidesk-decision-center:<commit>` 是否存在、导入 native k3s containerd、更新 `decision-center` Deployment image/env/annotations，并通过 Kubernetes API service proxy 验证 `/health` 中的 `deploy.commit`。回滚信息通过同一 artifact consumer 的 `rollback` 字段暴露，提示操作者重新对一个旧 commit 运行相同命令，而不是切回 legacy maintenance-channel 构建。
+
 `status` 和 `health` 通过：
 
 ```bash
@@ -106,6 +114,8 @@ docker compose -p unidesk-artifact-registry -f /home/ubuntu/.unidesk/artifact-re
 6. master server retag 为 Compose 使用的 backend-core 镜像名，并执行 `docker compose up -d --no-build --no-deps --force-recreate backend-core`。
 7. 部署后通过 image label、runtime env、health payload 验证 live commit。
 
+Decision Center follows the same artifact-consumer pattern, except the runtime target is native k3s on D601 instead of the master-server Compose stack. The consumer must check the registry manifest, pull the commit-pinned image, import it into `/run/k3s/containerd/containerd.sock`, set the Deployment image to the commit tag, stamp `UNIDESK_DEPLOY_*` env/annotations, and reject an old healthy revision if the live commit does not match.
+
 这个 CD 路径必须满足：
 
 - source commit 来自 pushed Git，不来自 dirty worktree。