feat: add devops-controlled dev ci flow

docs/reference/codex-deploy.md

@@ -1,25 +1,22 @@
 # Code Queue Deploy
 
-`bun scripts/cli.ts codex deploy <commitId>` 是兼容入口。新的正式部署入口是 `bun scripts/cli.ts deploy apply --service code-queue`；兼容入口会生成一个只包含 Code Queue repo 与 commit 的临时 desired manifest，再调用同一个 deploy reconciler。命令只在主 server 工作区执行；它会立即返回异步 job id，后台 job 通过 backend-core 的 `host.ssh` dispatch 在 D601 完成实际部署。
+`bun scripts/cli.ts codex deploy <commitId>` 是旧兼容入口，现已禁用。原因是它会通过 backend-core `host.ssh` 维护通道直连 D601 部署 Code Queue，绕过 DevOps 控制面；维护通道直连 D601 现在只允许部署或修复 DevOps 本身。
+
+Code Queue 后续正式部署必须由 DevOps 控制面执行：CLI 读取 `origin/master:deploy.json#environments.dev` 或生产 desired-state 后，经 backend-core、k3sctl-adapter 和 DevOps 触发 target-side build、k3s image import、rollout、stamp 和 live commit 验证。
 
 ## Command
 
 ```bash
-bun scripts/cli.ts deploy apply --service code-queue
 bun scripts/cli.ts codex deploy <commitId>
-bun scripts/cli.ts job status <jobId> --tail-bytes 30000
 ```
 
-- `commitId` 必须是已经 push 到 remote 的 7-40 位 hex commit SHA。
-- `--provider-id D601` 是默认值；当前部署路径只支持 D601 active instance。
-- `--timeout-ms N` 控制后台部署总超时，默认 `900000`。
-- `--skip-build` 不再支持；target-side Docker build 是强制步骤。
+该命令必须返回结构化错误，提示改用 DevOps 控制面；不得再创建后台部署 job。`--skip-build` 不再支持。
 
 ## Pipeline
 
-部署 job 的步骤固定为：
+历史部署 job 曾固定为以下步骤；它们现在只能作为 DevOps 控制面实现 Code Queue CD 时的目标行为，不能由 `codex deploy` 或维护通道直连触发：
 
-1. 对 Code Queue 部署先确保 PostgreSQL 中存在 `unidesk_deploy_ssh_identities(id='github.com')`，该记录保存 GitHub deploy SSH identity 的 private key、public key fingerprint 和 github.com `known_hosts` 行。`codex deploy` 会用主 server 当前 `/root/.ssh/id_ed25519` 种子化这条记录，然后通过 backend-core `/ws/ssh` 交互通道把 identity 流式分发到 D601 WSL `/home/ubuntu/.ssh/id_ed25519`、`id_ed25519.pub` 和 `known_hosts`，并在 D601 侧执行 `ssh -T git@github.com` 验证；secret 不得写入 `host.ssh` task payload、deploy 日志、Docker image 或 Kubernetes Secret。
+1. 对 Code Queue 部署先确保 PostgreSQL 中存在 `unidesk_deploy_ssh_identities(id='github.com')`，该记录保存 GitHub deploy SSH identity 的 private key、public key fingerprint 和 github.com `known_hosts` 行。DevOps 控制面不得把 secret 写入 task payload、deploy 日志、Docker image 或 Kubernetes Secret。
 2. 在 D601 的 deploy cache 中通过本机 provider-gateway WS egress proxy 执行 `git fetch` remote，并用 `git archive <commitId>` 导出 tracked files 到一次性 export 目录；不得让 D601 直连 GitHub，也不得临时创建 SSH SOCKS、公网 master proxy 或 backend-core/provider-ingress fallback。
 3. 用 `rsync --delete` 同步导出的 repo 到 `/home/ubuntu/cq-deploy`，保留 `.state/`、`logs/`、`.git/`、`node_modules/` 和 `dist/`。
 4. 在 D601 用目标 Docker daemon 的本地 BuildKit builder 构建 `unidesk-code-queue:d601`，复用 D601 上已有基础镜像、inline cache 和 Code Queue build-base；provider-gateway WS egress 是唯一允许的构建代理通道，只作为本次 build 的环境变量与 build-arg 注入，并配合本次 build 的 `--network host` 让 RUN 阶段访问 D601 宿主 loopback proxy，不能污染 D601 宿主 Docker/HTTP proxy 配置，不能新建 SSH SOCKS、公网 master proxy 或直连 fallback。
@@ -31,9 +28,9 @@ bun scripts/cli.ts job status <jobId> --tail-bytes 30000
 
 ## Observability
 
-`codex deploy` 本身不阻塞等待部署结束。返回 JSON 中的 `statusCommand` 和 `tailCommand` 是唯一状态入口。后台 job 的 stderr 是 JSONL progress，每个长步骤会记录远端 `/tmp/unidesk-deploy-*.log` 和 sentinel 文件；失败时 `job status` 会显示最后日志尾部。
+DevOps 控制面实现 Code Queue CD 后，部署触发本身不应阻塞等待完成。返回 JSON 中必须包含 run id、status command 或等价查询入口；后台日志必须有界可查，失败时能显示最后日志尾部。
 
-`job status` 到 `succeeded` 时，部署 job 已经完成 live commit 验证。需要人工复核时可用以下命令确认 `deploy.commit`：
+部署 run 到 `succeeded` 时，必须已经完成 live commit 验证。需要人工复核时可用以下命令确认 `deploy.commit`：
 
 ```bash
 bun scripts/cli.ts microservice health code-queue
@@ -44,7 +41,7 @@ D601 原生 k3s 的人工诊断必须显式使用 host kubeconfig：`KUBECONFIG=
 
 ## Boundaries
 
-Code Queue 由 D601 k3s/k8s 控制面代管，不再通过 `server rebuild` 或手工 `docker compose up` 作为正式部署路径。`codex deploy` 可以在 Code Queue 自身正在执行任务时运行；服务重启后由 restart-recovery 恢复任务状态，不能等待当前 Code Queue task 退出后再部署。
+Code Queue 由 D601 k3s/k8s 控制面代管，不再通过 `server rebuild`、`codex deploy`、维护通道直连 D601 或手工 `docker compose up` 作为正式部署路径。Code Queue 部署必须在自身正在执行任务时仍可运行；服务重启后由 restart-recovery 恢复任务状态，不能等待当前 Code Queue task 退出后再部署。
 
 ## TCP Egress Gateway