docs: clarify d601 transient failure triage

docs/reference/code-queue-supervision.md

@@ -85,6 +85,16 @@ PR 支持本身是 Code Queue 能力的一部分。当前 UniDesk CLI 支持 `gh
 
 队列诊断中的 `split-brain` 表示控制面/执行面观测分裂，不自动证明任务已经死亡。如果任务 heartbeat 新鲜且 trace 仍在推进，应把任务视为 live，继续监督，而不是 interrupt 或替换。队列摘要应显示 `effectiveLiveness=live`、`splitBrainLive=true` 和 `recommendedAction=continue-supervision`；如果 heartbeat expired/missing 或满足 stale-recovery 条件，应显示 `effectiveLiveness=at-risk`。
 
+单次 `provider is not online`、SSH 超时、proxy 超时或 registry 请求失败只能证明“当前观察路径失败”，不能单独升级为 D601 全局离线、CI/CD 全局阻塞或业务任务不可推进。指挥官和 runner 必须用多信号裁决运行面状态，至少区分以下观察面：
+
+- backend-core 节点视图和 provider heartbeat，例如 `debug health` 中的 D601 `status`、`lastHeartbeat` 和 gateway 版本；
+- Host SSH / WSL SSH 维护桥，例如 `ssh D601 hostname` 或短 argv 命令；
+- D601 artifact registry health、k3sctl-adapter health、目标 microservice health；
+- Code Queue scheduler heartbeat、任务 heartbeat、trace/output 是否持续入库；
+- 当前 runner 容器内 CLI/proxy 路径是否只是局部不可达。
+
+只有多个独立观察面同时失败，或同一关键路径在明确时间窗口内持续失败，才能把问题判为全局阻塞。否则应记录为 transient 或 runner-local observation gap，优先重试、steer 任务纠偏或拆出基础设施 follow-up；不得让业务 worker 把单次局部失败作为最终 blocker。CLI 和 runtime 后续应把错误输出结构化为 `scope=runner-local|provider-gateway|ssh|registry|k3s|scheduler|service-proxy`、`observedAt`、`retryable` 和建议的交叉验证命令。
+
 对于 trace 或 heartbeat 新鲜的长任务，通常应保持运行。每几分钟轮询一次优于反复 interrupt/retry。
 
 对于大规模 CI/CD 迁移波次，除非发生事故，否则使用固定监督节奏。默认是 5 分钟轮询循环：读取 `codex queues`，读取 terminal 或可疑任务摘要，然后决定接受、retry、拆分 blocker，或让健康任务继续运行。循环期间指挥官可以做不重叠的有用工作，例如文档或 issue 梳理，但这些辅助工作不能接管 worker 已分配的实现。
@@ -150,6 +160,7 @@ Code Queue task 不是只要 push 代码就算完成。
 - deploy job 报失败但服务 API 实际健康；
 - 指挥侧突发 submit 打满 Code Queue manager 或低内存主机，导致队列还没确认任务就被压垮；
 - Code Queue 容器缺少监督所需的基础工具或凭证路径，例如 `gh`、`hub` 或 GitHub token 注入路径。
+- D601、provider-gateway、registry、k3sctl-adapter 或 service proxy 的单路径瞬时失败被 worker 放大为全局阻塞，而缺少多信号健康裁决和可重试错误分类。
 
 这些缺陷应分配给基础设施队列，prompt 中要包含具体观测失败、期望长期合同，以及原交付任务继续所需的恢复动作。