diff --git a/docs/reference/code-agent-chat-readiness.md b/docs/reference/code-agent-chat-readiness.md
index 25667336..ffd6cc98 100644
--- a/docs/reference/code-agent-chat-readiness.md
+++ b/docs/reference/code-agent-chat-readiness.md
@@ -285,13 +285,20 @@ node scripts/dev-cloud-workbench-smoke.mjs --dom-only --url http://74.48.78.17:1
 授权凭证注入后的真实 DEV 复测：
 
 ```sh
-node scripts/code-agent-chat-smoke.mjs --live --url http://74.48.78.17:17666/
+node scripts/code-agent-chat-smoke.mjs --live
+node scripts/code-agent-chat-smoke.mjs --live --url http://74.48.78.17:17667/ --timeout-ms 45000
 ```
 
 `--live` 会向真实 DEV `/v1/agent/chat` 发送一条最小聊天请求。输出只包含
 readiness、provider/model/backend、assistant 回复是否非空和长度、错误分类等摘要；不打印
 assistant 回复正文，不读取或打印任何 Secret 值。
 
+默认 `--live` 应指向当前 G14 DEV API/edge 入口 `17667`，而不是历史 D601 端口。
+健康的 Codex stdio 冷启动首个 assistant token 可能需要数十秒；10 秒级 transport
+timeout 会把健康环境误报为 transport blocker。把 timeout 提高到 45 秒左右只是在真
+实 DEV 路由上减少误报，不能替代 `completed` + 非空 assistant reply 的最终判定标
+准。
+
 ## 复测结果解释
 
 - 若输出 `readiness.level: "BLOCKED/credential"`，后续动作是由授权路径注入
diff --git a/docs/reference/g14-gitops-cicd.md b/docs/reference/g14-gitops-cicd.md
index 35df2a58..146974b6 100644
--- a/docs/reference/g14-gitops-cicd.md
+++ b/docs/reference/g14-gitops-cicd.md
@@ -141,3 +141,75 @@ Argo CD 约定 repository Secret：`argocd/hwlab-git-ssh`，并带 label `argocd
 ## D601 边界
 
 G14 GitOps manifests 不包含 D601 kubeconfig、D601 node guard、D601 FRP 公网入口或 UniDesk Code Queue 调度入口。D601 仍由既有生产路径维护；G14 GitOps 的安装、PipelineRun、Argo sync 和 registry 操作都不能对 D601 执行 kubectl、docker 或流量切换动作。
+
+## 真相源与常见误判
+
+G14 PR、CI、CD 的判断应按以下顺序收敛真相，越靠前越接近最终运行面：
+
+1. live runtime：目标 namespace 的 Deployment/StatefulSet template、Pod ready、`describe`、容器日志和公网 health。
+2. Argo desired state：`hwlab-g14-dev` / `hwlab-g14-prod` 的 Application revision、sync、health 和实际 runtime path。
+3. Tekton 执行证据：branch-poller 日志、PipelineRun、TaskRun results、`gitops-promote` 终态。
+4. 干净 source workspace：`origin/G14` 当前内容，以及 `npm run g14:gitops:render`、`npm run g14:gitops:check` 和 planner 输出。
+5. 对照线索：旧 commit 记忆、坏 worktree、D601 legacy 路径、脚本旧默认值，只能当线索，不能当真相。
+
+常见误判与纠正：
+
+- 不要把 `/root/hwlab` 当前 checkout、任意 `/tmp` worktree 或带 conflict marker 的目录当 source truth；只有跟踪 `origin/G14` 的干净 worktree 才能作为当前发布依据。
+- 不要按“某个预期 commit 是否出现在 ancestry 中”判断功能是否已经合入；当前 `origin/G14` 实际内容比历史 commit 轨迹更重要。
+- 改了 source 但没先 render/check 时，generated mismatch 只说明 source 与 generated 没对齐，不等于 Tekton 或 Argo 本身坏掉。
+- 不要把 `build-*` TaskRun 名称直接当作镜像重建证据；reuse-only 变更也会扇出同名 TaskRun，必须看 Tekton result 的 `status=reused` 与 `build-backend=reused-catalog`。
+- 不要把 `G14-gitops` 分支已更新误判成 DEV 或 PROD 已滚动；只有 Argo Application revision、目标 workload ready 和 live manifest 生效，才算 CD 真实通过。
+- 不要把 health payload 中的镜像 commit 当成 runtime manifest commit；runtime-only 修复可能复用旧镜像，只改变 probe、env、annotation 或 sidecar 行为。
+- sidecar 监听 `127.0.0.1` 时，Pod-IP `httpGet` probe 失败不等于 sidecar 自身 crash；必须同时对照 sidecar listen 日志和 probe target 语义。
+- 真实 live smoke 超时要先排除脚本入口和 timeout 误报；健康的 Codex stdio 冷启动首 token 可能需要数十秒，10 秒级 transport timeout 不能直接判服务故障。
+
+## PR -> CI -> CD 最短零误判 SOP
+
+1. 工作区与路由预检
+
+```sh
+bun scripts/cli.ts ssh G14:/root/hwlab shell 'git status --short --branch && git remote -v | sed -n "1,4p"'
+```
+
+- 只有 `/root/hwlab` 已经是 `G14...origin/G14` 时才继续；否则先从 `origin/G14` 建干净临时 worktree，再开始本轮修改。
+- k3s 只走 `G14:k3s`；不要混用 D601 kubeconfig、master server 执行面或旧 SSH route 语法。
+
+2. Source / PR 预检
+
+```sh
+npm run g14:gitops:render
+npm run g14:gitops:check
+node scripts/g14-ci-plan.mjs --base-ref origin/G14 --target-ref HEAD --pretty
+```
+
+- 先看当前内容和长期参考，不按旧 commit 记忆判断“功能是否已合入”。
+- GitOps、manifest、poller/reconciler、provider profile 相关改动必须先跑 render/check；planner 用于判断本轮是 docs-only、reuse-only 还是需要真实构建。
+- provider/profile 变更在进入 PR 或 CI 之前，先按 `code-agent-chat-readiness.md` 做目标 Pod 最小闭环；不要把完整 CI/CD 当成 transport 试错工具。
+
+3. 合并或推送到 `G14`
+
+- `G14` 是 poller 的唯一 source branch。只有 source 侧检查通过后，才进入 merge 或 push。
+- push 被 fast-forward 拒绝时，先 `fetch` 和 `rebase` 到最新 `origin/G14`；不要为了抢跑 poller 强推覆盖别人的 GitOps promote 提交。
+
+4. 确认 CI 已接单
+
+- 先看最新 branch-poller job 或日志，确认它是否识别到新的 `G14` HEAD。
+- 再看 `hwlab-ci` 里的 PipelineRun 是否出现 `hwlab-g14-ci-poll-<short12>`。poller 还没创建 PipelineRun 时，不要先把问题归类为 Tekton 故障。
+- 如果本轮改的是 poller、Pipeline、RBAC、reconciler 或 render 模板，先确认 `hwlab-g14-control-plane-reconciler` 已经把新控制面 apply 进去，再用新 commit 验证。
+
+5. 确认 CI 真实通过
+
+- 最低通过条件是：`ci-json`、`plan-artifacts`、per-service fan-out、`collect-artifacts`、`gitops-promote` 全部成功。
+- `build-*` fan-out 要按 result 判断 reused 还是 rebuilt；不要只看 TaskRun 名称。
+- reuse-only 变更的目标是 `affectedServices=[]`、全部 service `status=reused`，且不触发无意义 rollout。
+
+6. 确认 CD 真实通过
+
+- 先确认 `G14-gitops` 头 revision 已更新，再看 Argo Application 当前 revision 是否追上该 GitOps revision。
+- 然后检查目标 namespace 的 Deployment、StatefulSet、ReplicaSet、Pod ready 和失败事件。
+- runtime-only 修复要直接检查 live Deployment template 是否带上新的 probe、env 或 annotation；不要只盯公网 health 里的镜像 commit。
+
+7. 做最终运行态验证
+
+- 先看公网 `/health/live`，再跑 focused live smoke；业务 smoke 必须在目标运行面已经 Healthy 后进行。
+- Code Agent 对话链路用 `node scripts/code-agent-chat-smoke.mjs --live` 或显式 `--url http://74.48.78.17:17667/ --timeout-ms 45000`；通过标准是“真实 DEV 路由 + `completed` + 非空 assistant reply”，不是单纯 HTTP 200、非 JSON chunk 或 10 秒内首包。