# R5.1 任务报告

## 结论

[UniDesk #1900](https://github.com/pikasTech/unidesk/issues/1900) 的直接断点不是 PR、Pipeline 定义或 AgentRun，而是 NC01 的 `pipelines-as-code-watcher` 未启动。GitHub merge、Gitea mirror/webhook 和 PaC 创建 PipelineRun 均正常；唯一负责把 `queued/PipelineRunPending` 推进为 `started` 的 watcher 不可用，因此自动链停在 0 TaskRun。

## 运行面证据

- watcher Deployment：`replicas=1`、`ready=0`、`unavailable=1`。
- 故障 Pod：`pipelines-as-code-watcher-7f6c87497c-h2dzz`，UID `7fe65fbe-a18e-4513-89f2-5fac37ae0b71`。
- projected ServiceAccount token 被 node authorizer 拒绝：`node requested token bound to a pod scheduled on a different node` / `no relationship found between node`。
- 同一控制面恢复窗口创建的 `tempo`、`todo-note` Pod 出现相同错误；稍后新建 Pod 已能正常挂载 token，排除 watcher ServiceAccount RBAC 和 AgentRun Pipeline 定义。
- AgentRun merge commit `4155132aa7e8de1936b2bf447ea889a607ee59d7` 的 PipelineRun 已由 PaC 创建并标记 `queued`，但长期 `startTime=null`、0 TaskRun。

## 有界临时恢复

在 issue 和 MDTODO 建立后，只删除上述精确 Pending watcher Pod，由既有 Deployment/ReplicaSet 自动重建。未修改、删除或重跑任何 PipelineRun，也未执行 mirror、sync、refresh、trigger 或 rollout。

新 Pod `pipelines-as-code-watcher-7f6c87497c-7lhfh` 随后 Ready，并接管 leader lease；既有 #347 PipelineRun 自动从 `queued` 进入 `Running`，产生 TaskRun。该证据证明恢复仍由原 PaC 自动权威完成。

## 长期归属

长期修复归 [#1900](https://github.com/pikasTech/unidesk/issues/1900) 的 NC01 k3s node-authorizer / Pod 生命周期恢复。不得把本次精确 Pod 重建固化为额外 delivery actor、补跑入口或自动围栏。