docs: specify v02 PR auto CD workflow

docs/reference/spec-v02-cicd.md

@@ -2,7 +2,7 @@
 
 本文是 HWLAB `v0.2` 在 G14 上接入 CI/CD 的长期规格。目标是把 `v0.2` 作为独立加法 lane 接入现有 G14 k3s、Tekton、GitOps 和 Argo CD 体系，同时保持 `G14` DEV/PROD 发布面稳定。
 
-实施跟踪见 [pikasTech/HWLAB#530](https://github.com/pikasTech/HWLAB/issues/530)，env 容器复用、三变量启动和 git mirror 加速设计见 [pikasTech/HWLAB#572](https://github.com/pikasTech/HWLAB/issues/572)。原 `docs/plan/hwlab-v02-namespace-cicd.md` 阶段计划全文已迁入 #530 评论。本文只记录稳定规格、边界和判定标准；不要把一次性执行记录、排障流水账或临时证据写入本文。
+实施跟踪见 [pikasTech/HWLAB#530](https://github.com/pikasTech/HWLAB/issues/530)，env 容器复用、三变量启动和 git mirror 加速设计见 [pikasTech/HWLAB#572](https://github.com/pikasTech/HWLAB/issues/572)，PR 合并后自动 CD 迁移计划见 [pikasTech/HWLAB#848](https://github.com/pikasTech/HWLAB/issues/848)。原 `docs/plan/hwlab-v02-namespace-cicd.md` 阶段计划全文已迁入 #530 评论。本文只记录稳定规格、边界和判定标准；不要把一次性执行记录、排障流水账或临时证据写入本文。
 
 ## 在系统中的职责划分
 
@@ -10,7 +10,9 @@
 
 ## 内部架构
 
-CI/CD 内部由 UniDesk 手动触发入口、CI/CD 专用 source repo、devops-infra git mirror、PipelineRun、component planner、BuildKit publish、GitOps promotion、Argo sync、GitHub flush 和公网验收构成。`v0.2` 不设置 branch poller、control-plane reconciler 或其他 CronJob；source branch 只保存源码和人写配置；`v0.2-gitops` branch 保存 catalog 和 rendered runtime desired state；live runtime 是最终通过证据。固定开发 workspace 只服务人工开发和短连接源码工具，不参与 CI/CD source commit 选择。
+CI/CD 内部由 UniDesk 受控触发入口、CI/CD 专用 source repo、devops-infra git mirror、PipelineRun、component planner、BuildKit publish、GitOps promotion、Argo sync、GitHub flush 和公网验收构成。标准触发方式是 UniDesk CLI 合并 base=`v0.2` PR 后自动进入 v02 CD；`trigger-current` 手动入口和 `auto-cd --once` 类补偿入口保留用于人工重跑、漏触发修复和迁移期验证。`v0.2` 不设置 k8s branch poller、control-plane reconciler 或其他 CronJob；source branch 只保存源码和人写配置；`v0.2-gitops` branch 保存 catalog 和 rendered runtime desired state；live runtime 是最终通过证据。固定开发 workspace 只服务人工开发和短连接源码工具，不参与 CI/CD source commit 选择。
+
+首期自动化不要求 GitHub webhook。PR 创建、预检和 merge 已由 UniDesk CLI 控制时，merge 成功后的同一受控流程应直接解析最新 `origin/v0.2` head 并调用现有 v02 control-plane。若未来接入 webhook，它只能作为唤醒信号；发布 source commit 仍必须由 `/root/hwlab-v02-cicd.git` fetch 到的 `refs/remotes/origin/v0.2` 决定，不能直接信任 webhook payload 创建 PipelineRun。
 
 `v0.2` 的 GitOps 写路径采用真正写 mirror：promotion 先把 `v0.2-gitops` 写入 `devops-infra` 本地 git mirror/relay，Argo CD 从本地 mirror/relay 读取该 revision 并 rollout，CI 关键路径不等待 GitHub push。GitHub `pikasTech/HWLAB` 仍是长期源码与归档上游，但对 `v0.2-gitops` 来说是由 mirror/relay 负责 flush 的异步上游，不再是 promotion task 的同步写入目标。
 
@@ -19,6 +21,7 @@ CI/CD 内部由 UniDesk 手动触发入口、CI/CD 专用 source repo、devops-i
 | 接口 | 说明 |
 | --- | --- |
 | `scripts/g14-gitops-render.mjs --lane v02` | v02 GitOps render 入口，负责 namespace、runtime path、catalog 和 endpoint 固定。 |
+| UniDesk v02 PR auto-CD monitor | 观察并合并 base=`v0.2` 的 ready PR，merge 后调用现有 `trigger-current`、定点 `status` 和 `git-mirror flush`。 |
 | Tekton `hwlab-v02-ci-image-publish` | 构建 affected images、复用 unchanged digest，并 promotion 到 `v0.2-gitops`。 |
 | `devops-infra` git mirror/relay | 读写 `v0.2` allowlist refs；CI 读 source/catalog、写 `v0.2-gitops`，并通过手动 CLI flush 到 GitHub。 |
 | Argo `argocd/hwlab-g14-v02` | 从 `devops-infra` 本地 mirror/relay 的 `v0.2-gitops:deploy/gitops/g14/runtime-v02` 同步到 `hwlab-v02`。 |
@@ -45,8 +48,10 @@ CI/CD 内部由 UniDesk 手动触发入口、CI/CD 专用 source repo、devops-i
 | Runtime path | `v0.2-gitops:deploy/gitops/g14/runtime-v02` |
 | Runtime namespace | `hwlab-v02` |
 | Tekton Pipeline | `hwlab-ci/hwlab-v02-ci-image-publish` |
-| Manual trigger | UniDesk CLI `bun scripts/cli.ts hwlab g14 control-plane trigger-current --lane v02 --confirm` |
-| Scheduler/CronJob | 不创建、不保留 v02 CronJob；发布只由手动 CLI 创建 commit-pinned PipelineRun |
+| PR merge auto-CD | UniDesk CLI v02 PR monitor 合并 base=`v0.2` PR 后自动调用 `trigger-current`，并定点观察 merge head |
+| Manual trigger | UniDesk CLI `bun scripts/cli.ts hwlab g14 control-plane trigger-current --lane v02 --confirm`，仅作为人工重跑和迁移期补偿入口 |
+| Reconcile fallback | UniDesk CLI v02 `auto-cd --once` 或等价补偿入口，对齐当前 `origin/v0.2` head、PipelineRun、GitOps 和 mirror flush 状态 |
+| Scheduler/CronJob | 不创建、不保留 v02 k8s CronJob；PipelineRun 只能由 UniDesk CLI PR monitor、manual trigger 或 once reconcile 创建 |
 | Tekton ServiceAccount | `hwlab-ci/hwlab-v02-tekton-runner` |
 | PipelineRun prefix | `hwlab-v02-ci-poll-<short12>` |
 | Argo CD AppProject | `argocd/hwlab-v02` |
@@ -108,31 +113,36 @@ devops-infra git mirror 仍是 PipelineRun 和 Argo CD 的集群内读写源。`
 
 标准链路如下：
 
-1. UniDesk CLI `hwlab g14 control-plane trigger-current --lane v02 --confirm` 通过 `/root/hwlab-v02-cicd.git` 自动 fetch 并解析当前 `origin/v0.2` 完整 source commit SHA，先复核 `devops-infra` mirror 的 `localV02` ref，必要时自动执行一次 bounded manual `git-mirror sync` Job，再创建 commit-pinned `hwlab-v02-ci-poll-<short12>` PipelineRun；默认 `--dry-run` 只返回将要创建的 manifest 和 mirror pre-sync 计划。
-2. `prepare-source` 通过 `devops-infra` mirror checkout `v0.2` source，并从 mirror 中的 `v0.2-gitops` 读取上一版 `deploy/artifact-catalog.v02.json`。
-3. CI/CD 校验只保留最小构建、TypeScript 语义检查、自动单元测试、打包和必要冒烟检查；旧 DEV/D601/main gate、运行时内部证明型校验、健康诊断重断言和历史预检不进入 lane。
-4. planner 根据 component input 判断 affected/reused services。
-5. affected service 通过 BuildKit 发布到 G14 本地 registry；reused service 复用 catalog digest。
+1. PR open/update 阶段只运行 source CI、检查和 PR preflight，不修改 `hwlab-v02` runtime，也不写 `v0.2-gitops`。
+2. UniDesk CLI v02 PR monitor 只观察 `pikasTech/HWLAB` base=`v0.2` 的 ready PR；merge 成功后重新 fetch `/root/hwlab-v02-cicd.git` 的 `origin/v0.2`，以 fetch 后的完整 source commit SHA 作为待发布目标。
+3. monitor 调用现有 `hwlab g14 control-plane trigger-current --lane v02 --confirm`。该入口自动复核 `devops-infra` mirror 的 `localV02` ref，必要时执行一次 bounded `git-mirror sync` Job，再创建 commit-pinned `hwlab-v02-ci-poll-<short12>` PipelineRun；默认 `--dry-run` 只返回将要创建的 manifest 和 mirror pre-sync 计划。人工重跑和 `auto-cd --once` 补偿必须复用同一入口，不得直接创建 PipelineRun。
+4. `prepare-source` 通过 `devops-infra` mirror checkout `v0.2` source，并从 mirror 中的 `v0.2-gitops` 读取上一版 `deploy/artifact-catalog.v02.json`。
+5. CI/CD 校验只保留最小构建、TypeScript 语义检查、自动单元测试、打包和必要冒烟检查；旧 DEV/D601/main gate、运行时内部证明型校验、健康诊断重断言和历史预检不进入 lane。
+6. planner 根据 component input 判断 affected/reused services。
+7. affected service 通过 BuildKit 发布到 G14 本地 registry；reused service 复用 catalog digest。
    所有 selected service 的 build TaskRun 都只依赖 `plan-artifacts`，不按 service 串行排队，也不设置 8 并发或其他 Pipeline 级限流。
    实际并发由 Tekton controller、G14 节点资源、PVC I/O、BuildKit sidecar 和本地 registry 承载能力决定。
    `hwlab-cloud-web`、`hwlab-agent-worker` 和 `hwlab-device-pod` 必须使用 `env-reuse-git-mirror-checkout`。
    只有 package/runtime/env 输入变化时才构建 `<service>-env` 镜像。
    纯前端源码、Device Pod 源码或 boot code 变化只更新三变量和 GitOps desired state，
    不再重新构建业务镜像。
-6. promotion 刷新 `deploy/artifact-catalog.v02.json`，render `deploy/gitops/g14/runtime-v02/**`，只推送到 `devops-infra` mirror/relay 的 `v0.2-gitops`。
-7. `hwlab-g14-v02` 从本地 mirror/relay 的 `v0.2-gitops:deploy/gitops/g14/runtime-v02` 同步到 `hwlab-v02`。
-8. UniDesk CLI 或 mirror/relay flush 操作把本地 `v0.2-gitops` 推送到 GitHub canonical remote；flush 不在 CI runtime-ready 的关键路径内，但必须可查询 pending、lastFlushed 和 failure。
-9. 验收只观察 `hwlab-v02` runtime 和 `19666/19667`。
+8. promotion 刷新 `deploy/artifact-catalog.v02.json`，render `deploy/gitops/g14/runtime-v02/**`，只推送到 `devops-infra` mirror/relay 的 `v0.2-gitops`。
+9. `hwlab-g14-v02` 从本地 mirror/relay 的 `v0.2-gitops:deploy/gitops/g14/runtime-v02` 同步到 `hwlab-v02`。
+10. UniDesk CLI auto-CD 观察定点 `control-plane status --lane v02 --source-commit <merge-head>` 或 `--pipeline-run <name>`，确认 PipelineRun、Argo、runtime workload、public probes 和 planArtifacts build/reuse 摘要。
+11. UniDesk CLI 或 mirror/relay flush 操作把本地 `v0.2-gitops` 推送到 GitHub canonical remote；flush 不在 CI runtime-ready 的关键路径内，但自动 CD 收口必须查询 pending、lastFlushed 和 failure，必要时执行 `git-mirror flush --confirm` 并等待 `pendingFlush=false`。
+12. 验收只观察 `hwlab-v02` runtime 和 `19666/19667`，并把 source commit、PipelineRun、GitOps revision、build/reuse 摘要、Argo/runtime/public probe 状态写回 PR 或关联 issue。
 
 `trigger-current --lane v02 --confirm` 默认返回异步 job，不等同于 PipelineRun 已经创建完成。调用方必须先运行返回的 `job status <jobId>`，等 `progress.stage=create-pipelinerun` 且 `progress.pipelineCreated=true` 后，再用 `control-plane status --lane v02 --pipeline-run <name>` 做定点发布观察。`progress.pipelineRun` 可以在 control-plane refresh 或 mirror pre-sync 阶段提前给出预期名称；此时如果重型 status 报 `target-pipelinerun-not-found-or-unreadable`，只能说明 PipelineRun 尚未创建，不能作为发布失败、mirror 失败或 runtime 回归结论。
 
 定点发布观察优先使用 `--pipeline-run <name>` 或 `--source-commit <full-sha>`，避免 branch 后续推进导致历史 run 被最新 head 口径误判。`control-plane status` 会同时做 source/mirror/TaskRun/Argo/runtime/web asset 汇总，可能比普通只读查询慢；高频轮询时先看异步 job progress 和 TaskRun 条件摘要，只在阶段收口或异常定位时再跑完整 status。
 
-GitOps promotion 成功后，本地 mirror/relay 的 `v0.2-gitops` 可立即被 Argo 消费；GitHub 上游 flush 是归档与跨节点同步步骤，不在 runtime-ready 关键路径内。`git-mirror status.pendingFlush=true` 时应运行 `git-mirror flush --confirm`，再用该 flush job 的 `job status` 或 `git-mirror status` 确认 `pendingFlush=false`、`localGitops=githubGitops`。不要把 pending flush 误判为 runtime 未发布，也不要在 flush job 仍运行时反复做全量 status。
+GitOps promotion 成功后，本地 mirror/relay 的 `v0.2-gitops` 可立即被 Argo 消费；GitHub 上游 flush 是归档与跨节点同步步骤，不在 runtime-ready 关键路径内。`git-mirror status.pendingFlush=true` 时自动 CD 和人工收口都应运行 `git-mirror flush --confirm`，再用该 flush job 的 `job status` 或 `git-mirror status` 确认 `pendingFlush=false`、`localGitops=githubGitops`。不要把 pending flush 误判为 runtime 未发布，也不要在 flush job 仍运行时反复做全量 status。
 
 `v0.2` 可以复用 G14 的 registry、proxy、BuildKit、工具镜像和脚本库；不得复用 `hwlab-g14-ci-image-publish`、`hwlab-g14-branch-poller`、`hwlab-g14-control-plane-reconciler`、`G14-gitops` runtime path 或 DEV/PROD Argo Application 作为 `v0.2` 发布入口。运行时不得为每个版本硬编码 namespace、catalog、runtime path 或健康判断；版本差异只通过 `deploy.json.lanes[profile]`、GitOps render 输入和实际 runtime 对象表达，新增版本不得新增运行时代码分支。
 
-`v0.2` 不设自动轮询发布。历史上若存在 `hwlab-v02-branch-poller`、`hwlab-v02-control-plane-reconciler` 或等价 CronJob，均视为迁移残留，应由 UniDesk control-plane apply 清理；后续发布、重跑、暂停和恢复都通过手动 CLI 触发或停止创建新的 PipelineRun 完成，不新增替代 CronJob。
+`v0.2` 不设 k8s 自动轮询发布。历史上若存在 `hwlab-v02-branch-poller`、`hwlab-v02-control-plane-reconciler` 或等价 CronJob，均视为迁移残留，应由 UniDesk control-plane apply 清理。PR 合并后的自动 CD 只能由 UniDesk CLI monitor 或一次性 reconcile job 驱动，并且必须复用 `trigger-current`、定点 `status` 和 `git-mirror flush`。暂停发布时停止 UniDesk monitor 或停止创建新的 PipelineRun；不要通过新增 CronJob 维持重试。
+
+v02 auto-CD 必须有 lane 级互斥与补偿语义。同一个 source commit 已有运行中或成功 PipelineRun 时不得重复创建；旧 run 仍在运行时如果 `origin/v0.2` 又推进，只记录最新 pending head，等待旧 run 结束后再部署最新 head。`auto-cd --once` 或等价补偿入口用于处理人工 GitHub merge、直接 push、monitor 重启或上次触发失败：它比较 `origin/v0.2` head、PipelineRun、Argo/GitOps 和 mirror flush 状态，缺什么补什么，但仍不绕过标准 control-plane 入口。
 
 `devops-infra` git mirror/relay 同样不设周期 CronJob。标准触发命令 `bun scripts/cli.ts hwlab g14 control-plane trigger-current --lane v02 --confirm` 会在创建 PipelineRun 前按需同步 mirror；`bun scripts/cli.ts hwlab g14 git-mirror sync --confirm` 只作为显式 mirror 维护或诊断入口。promotion 成功后可执行 `bun scripts/cli.ts hwlab g14 git-mirror flush --confirm` 把本地 `v0.2-gitops` 推送到 GitHub。`git-mirror apply` 维护 mirror 的 PVC、读服务、写服务、同步/flush 脚本和旧 CronJob 清理；`git-mirror sync` 创建一次性 Job，只同步 allowlist refs `v0.2`、`v0.2-gitops`、`G14` 和 `G14-gitops`，先 fetch 到隐藏 staging refs，校验 commit/tree/object closure，再用 `update-ref` 发布到公开 refs。这样 mirror read path 与 GitOps write path 都落在本地磁盘和集群网络，同时避免 CI 看到 ref 已更新但对象还不可 checkout 的半发布窗口。
 
@@ -483,6 +493,7 @@ registry 与 git mirror/relay 分属不同基础设施边界。registry 保持
 以下边界是 `v0.2` CI/CD 的最小硬约束：
 
 - source branch 必须是 `v0.2`。
+- PR 自动 CD 只能观察和合并 base=`v0.2` 的 PR；其他 base branch 不得触发 v02 runtime rollout。
 - GitOps branch 必须是 `v0.2-gitops`。
 - runtime namespace 必须是 `hwlab-v02`。
 - artifact catalog 必须是 `deploy/artifact-catalog.v02.json`。
@@ -491,9 +502,12 @@ registry 与 git mirror/relay 分属不同基础设施边界。registry 保持
 - source branch publish 后不得出现 `deploy/artifact-catalog.v02.json` 或 `deploy/gitops/g14/runtime-v02/**` 变更。
 - GitOps promotion 的 changed paths 只能落在 `deploy/artifact-catalog.v02.json` 与 `deploy/gitops/g14/runtime-v02/**` 及必要的 v02 Argo/GitOps 元数据。
 - 公网验收只能使用 `19666/19667`。
-- `v0.2` 不得创建或依赖 CronJob；`hwlab-v02-branch-poller`、`hwlab-v02-control-plane-reconciler` 或同类调度器出现时应清理，而不是接入发布链路。
+- `v0.2` 不得创建或依赖 k8s CronJob；`hwlab-v02-branch-poller`、`hwlab-v02-control-plane-reconciler` 或同类调度器出现时应清理，而不是接入发布链路。
+- GitHub webhook 不是 v02 首期自动 CD 的必需入口；若未来接入，只能作为唤醒信号，不能直接决定发布 commit 或创建 PipelineRun。
+- 自动 CD、手动 trigger 和 once 补偿都必须复用 UniDesk `trigger-current`、定点 `status` 和 `git-mirror flush`；不得绕到裸 `kubectl`、Argo、Tekton 或手写 GitHub API。
 - 旧 DEV/D601/main gate、fallback、legacy mode 和双路径兼容不得进入 `v0.2` 调用链。
 - env 容器复用 fast lane 中，`HWLAB_BOOT_REPO`、`HWLAB_BOOT_COMMIT` 和 `HWLAB_BOOT_SH` 必须由 CI/CD 自动推导并写入 GitOps desired state，不得作为人工发布参数或 runtime 临时 patch。
+- `deploy/deploy.json` 只保存人写运行意图，不得被 auto-CD、promotion 或 flush 回写 `commitId`、service `image`、`HWLAB_COMMIT_ID`、`HWLAB_IMAGE` 或 `HWLAB_IMAGE_TAG` 等发布产物字段。
 - git mirror/relay 必须来自独立 `devops-infra` 服务；`hwlab-v02` runtime namespace 不部署 mirror、不持有 GitHub deploy key、不在 mirror miss 时直连 GitHub fallback。
 - GitOps promotion 必须写入 `devops-infra` 本地 mirror/relay 的 `v0.2-gitops`；除 mirror/relay flush 外，不得在 CI 关键路径直接 push GitHub canonical remote。
 - mirror/relay write 必须只允许 allowlist refs，拒绝 non-fast-forward，拒绝越界 changed paths，并在 receive 成功前完成 object closure 校验。
@@ -511,19 +525,21 @@ registry 与 git mirror/relay 分属不同基础设施边界。registry 保持
 - DEV `17666/17667` 与 PROD `18666/18667` FRP 入口。
 - D601 legacy 回溯路径和旧运行面边界。
 
-如果 `v0.2` 接入失败，回滚或暂停只能作用于 `hwlab-v02` lane：停止手动触发新的 v02 PipelineRun、暂停或删除 `hwlab-g14-v02`、回滚 `v0.2-gitops` runtime path、关闭 `hwlab-v02-frpc` 或清理 `hwlab-v02` namespace 资源；不得通过新增 CronJob 维持重试，也不得重启、删除或回滚 DEV/PROD 运行面。
+如果 `v0.2` 接入失败，回滚或暂停只能作用于 `hwlab-v02` lane：停止 UniDesk v02 monitor、停止手动触发新的 v02 PipelineRun、暂停或删除 `hwlab-g14-v02`、回滚 `v0.2-gitops` runtime path、关闭 `hwlab-v02-frpc` 或清理 `hwlab-v02` namespace 资源；不得通过新增 CronJob 维持重试，也不得重启、删除或回滚 DEV/PROD 运行面。
 
 ## 验收标准
 
 `v0.2` CI/CD 通过必须同时满足：
 
 - `hwlab-ci` 中存在 `hwlab-v02-ci-image-publish` 和 `hwlab-v02-tekton-runner`；不存在 v02 CronJob。`hwlab-v02-branch-poller` 与 `hwlab-v02-control-plane-reconciler` 不再作为 v02 标准对象，若历史残留应由 UniDesk control-plane apply 清理。
+- base=`v0.2` 的 ready PR 由 UniDesk CLI 合并后，会自动触发对应 merge head 的 v02 PipelineRun；同一个 source commit 已有运行中或成功 PipelineRun 时不重复创建。
+- 自动 CD 在旧 run 运行期间遇到新 `origin/v0.2` head 时，只保留最新 pending head，旧 run 收口后再部署最新 head，避免并行 PipelineRun 同时争用 `v0.2-gitops`。
 - 最新 `v0.2` source commit 对应的 PipelineRun 完成，且 promotion 写入 `v0.2-gitops`。
 - `v0.2-gitops` 中存在 `deploy/artifact-catalog.v02.json` 与 `deploy/gitops/g14/runtime-v02/**`。
 - `argocd/hwlab-g14-v02` 指向 `devops-infra` 本地 mirror/relay 的 `v0.2-gitops:deploy/gitops/g14/runtime-v02`，sync revision 与目标 GitOps revision 对齐。
 - `hwlab-v02` 中长驻 workload ready，没有把 DEV/PROD namespace 当成 `v0.2` 通过证据。
 - `gitops-promote` 推送本地 mirror/relay 的 `v0.2-gitops` 后应触发 `argocd/hwlab-g14-v02` hard refresh，减少 GitOps push 与 Argo 仓库发现之间的漂移窗口；refresh 触发失败只作为低噪声事件输出，最终通过仍由 `runtime-ready` 判定。
-- mirror/relay status 必须能显示本地 `v0.2-gitops` revision、GitHub 已 flush revision、pending flush revision 和最近一次 flush 错误；CI 通过不要求 GitHub flush 已完成，但运维观察必须能看到上游是否落后。
+- mirror/relay status 必须能显示本地 `v0.2-gitops` revision、GitHub 已 flush revision、pending flush revision 和最近一次 flush 错误；CI 通过不要求 GitHub flush 已完成，但 auto-CD 收口必须在 `pendingFlush=true` 时触发 flush 并最终观察到 `pendingFlush=false`。
 - `runtime-ready` 必须以 workload Pod template 的 source commit 判断 Argo 刷新，并在 Argo 刷新超时、observer RBAC 不足或 workload 未就绪时失败；不得把 CrashLoop、未刷新或公网不可用的 runtime 标成绿色。
 - 启用 env 容器复用的服务必须在 catalog、Pod template annotation/env 和 `/health/live` 或等价 runtime identity 中同时暴露 env image digest 与 `HWLAB_BOOT_REPO`/`HWLAB_BOOT_COMMIT`/`HWLAB_BOOT_SH`；只暴露镜像 digest 不能证明 code-only rollout 已生效。
 - code-only rollout 的 PipelineRun 必须能证明没有发布新 env image、复用了上一版 env digest、只更新 boot commit/code identity，并由 Kubernetes Pod template hash 触发滚动。
@@ -531,6 +547,8 @@ registry 与 git mirror/relay 分属不同基础设施边界。registry 保持
 - `http://74.48.78.17:19666/` 返回 `v0.2` Cloud Web。
 - `http://74.48.78.17:19667/health/live` 返回 `v0.2` runtime health，payload 中的 namespace、revision 或 runtime identity 能与 `hwlab-v02`/`v0.2` 对齐。
 - `trigger-current` 的异步 job 或 `--wait` 输出必须能显示 trigger 阶段进度；若 control-plane refresh、mirror pre-sync 或 delete/create PipelineRun 卡住，日志必须能定位阶段名和状态。
+- 自动 CD 回写 PR 或关联 issue 的 rollout 评论必须包含 source commit、PipelineRun、GitOps revision、planArtifacts build/reuse 摘要、Argo/runtime/public probe 状态和耗时；该评论不能替代需要用户原入口验收的问题关闭证据。
+- 自动 CD 过程中 source branch 的 `deploy/deploy.json` 不得出现 `commitId`、service `image`、`HWLAB_COMMIT_ID`、`HWLAB_IMAGE` 或 `HWLAB_IMAGE_TAG` 回写。
 - no-op env-reuse fast lane 必须输出完整证据链：`g14-ci-plan` 全复用、`skipped-runtime-unchanged`、`gitops-commit`/`gitops-push` skipped、`runtime-ready` skipped。
   不能只用 PipelineRun `Completed` 或总耗时证明没有退化。
 - 真实 rollout 的 `runtime-ready` 必须输出 `started`、周期性 `progress` 和最终 `argo-refresh`/`argo-sync-health`/`workload-ready` 类事件；缺少这些事件时应按可见性回归处理。
@@ -576,12 +594,17 @@ GitOps branch 已更新、source branch render 通过、PipelineRun 名称存在
 
 阅读 docs/reference/spec-v02-cicd.md，然后用 cli 手动测试以下内容：确认默认 v0.2 CI 没有重新加入 Playwright、旧 layout smoke、旧 quick prompt、旧 M3 evidence 或 DEV/D601 browser gate；若这些旧门禁重新进入最小 check plan 或 PipelineRun，应直接删除入口并保留 Cloud Web semantic check 与单元测试。
 
+## T10
+
+阅读 docs/reference/spec-v02-cicd.md，然后用 cli 手动测试以下内容：用一个低风险 base=`v0.2` PR 验证 UniDesk v02 PR monitor 的端到端链路，确认 merge 后自动触发对应 merge head 的 `hwlab-v02-ci-poll-<short12>`，定点 status 通过，`pendingFlush=true` 时自动 flush，PR 或关联 issue 评论包含 source commit、PipelineRun、GitOps revision、build/reuse 摘要、Argo/runtime/public probe 状态和耗时，且 `deploy/deploy.json` 没有发布产物回写。
+
 ## 规格的实现情况
 
 | 规格项 | 状态 | 说明 |
 | --- | --- | --- |
 | v02 独立 source/GitOps/runtime lane | 已实现 | `v0.2`、`v0.2-gitops`、`hwlab-v02` 和 `runtime-v02` 已固定。 |
 | 手动 CLI trigger/pipeline/promotion | 已实现 | 通过 UniDesk `trigger-current` 创建 commit-pinned PipelineRun；v02 不设 CronJob，由 `hwlab-v02-ci-image-publish` 与 GitOps promotion 管理。 |
+| PR merge 后自动 CD | 待迁移 | 目标见 #848：UniDesk CLI v02 PR monitor 合并 base=`v0.2` PR 后复用 `trigger-current`、定点 `status` 和 `git-mirror flush`；首期不要求 GitHub webhook，也不创建 k8s CronJob。 |
 | v02 runtime readiness fail-closed | 已实现 | `gitops-promote` 推送后触发 Argo hard refresh；`runtime-ready` 读取 workload Pod template source commit，timeout、observer RBAC 不足或未就绪会让 PipelineRun 失败。 |
 | v02 裁撤服务不进入发布面 | 已实现 | v02 Tekton build service set、artifact catalog 和 runtime render 只包含保留服务；v02 Argo 开启 prune 清理旧 live 对象；裁撤服务仍可保留在 DEV legacy 源码中。 |
 | Argo v02 Application | 已实现 | `hwlab-g14-v02` 指向 v02 GitOps path 和 namespace。 |