diff --git a/docs/reference/dev-runtime-hotfix-runbook.md b/docs/reference/dev-runtime-hotfix-runbook.md
index aafd9c43..a4d53f3d 100644
--- a/docs/reference/dev-runtime-hotfix-runbook.md
+++ b/docs/reference/dev-runtime-hotfix-runbook.md
@@ -60,6 +60,8 @@ NODE
 - pod 内部、D601 host、FRP 公网入口可能使用不同端口语义。`127.0.0.1:6667` 是 HWLAB 内部 cloud-api 常用端口，但 `6667` 属于 WHATWG bad port；Node/undici `fetch` 会在发包前直接报 `bad port`，包括临时 gateway 自己 poll `http://127.0.0.1:6667` 的场景。运行面实验脚本和 gateway 传输层必须用 Node `http/https` 原生 request，或改走公网 `http://74.48.78.17:16667` / service mesh 中不被 bad-port 拦截的入口。
 - 遇到 `fetch failed`、`bad port`、公网通而 pod loopback 不通时，先判断是不是实验工具栈限制，不要立即归因 cloud-api、FRP、k3s Service 或 gateway 离线。issue 复盘要记录具体 URL、调用库、错误字符串和替代入口。
 - 清理临时进程时不要用会匹配到清理脚本自身 `cmdline` 的宽泛字符串，例如 `hwlab-gateway-hotfix`；`node -e` 本身会把该字符串放进 `/proc/<pid>/cmdline`。清理脚本应匹配真实入口和参数组合，并显式排除 `process.pid`，或由启动脚本写 pidfile 后按 pidfile 清理。
+- 正式 smoke/check 不在 master server 上执行。master server 只负责源码编辑、Git、日志和指挥；仓库级 `check`、`node --test`、browser/layout smoke、`web/hwlab-cloud-web/scripts/check.mjs` 等正式验证必须改在 D601 hotfix worktree、repo-owned CI 或其他获批执行面运行。
+- 验证 gateway 非阻塞或长命令并发时，不要把同一路 wrapper 的长轮询 `job-status`/状态查询当作唯一证据；忙碌 gateway 可能把后续短状态查询和只读调用一起排队，导致“状态检查卡住”掩盖真实根因。优先使用 repo-owned probe：保持一个慢命令在飞，再提交一个短命令测量 quick path 延迟；完成态判断优先读 job state/log/artifact 时间戳或 quick path 结果，而不是重复发同一路长轮询。
 - 不要对已经很大的 hotfix ConfigMap 使用 `kubectl apply -f -`；`apply` 会尝试写入 `kubectl.kubernetes.io/last-applied-configuration`，可能超过 Kubernetes annotation 256 KiB 限制。局部更新用 `patch --type merge --patch-file`。
 - 多文件运行面覆盖第一次创建 ConfigMap 时也不要默认用 `kubectl apply -f -`；如果 data 可能超过 annotation 限制，先 `kubectl delete configmap <name> --ignore-not-found`，再 `kubectl create configmap <name> --from-file=...`，随后用 Deployment annotation 记录 hotfix 版本并 rollout。正式 CD 收口时必须删除这些 unmanaged ConfigMap/volumeMount，不让热修覆盖继续漂在运行面。
 - 不要通过会截断 stdout 的控制 CLI 把 `kubectl get configmap -o json` 回读到本地再 `replace`；大 data 可能被日志/截断污染成非法 JSON。只有在确认完整无截断的原生通道中，才允许对完整对象做 `kubectl replace -f -`。