diff --git a/docs/reference/g14-gitops-cicd.md b/docs/reference/g14-gitops-cicd.md
index 146974b6..bd893778 100644
--- a/docs/reference/g14-gitops-cicd.md
+++ b/docs/reference/g14-gitops-cicd.md
@@ -38,6 +38,25 @@ npm run g14:gitops:render -- --source-revision <sourceCommit>
 npm run g14:gitops:check
 ```
 
+## 原生 k8s Tekton + Argo 配置面 vs CI.json runner 执行面
+
+这两条路线不是平行替代关系，而是当前 G14 CI/CD 的分层：Tekton + Argo 是发布控制面，`CI.json` runner 是 source-local 执行面。当前标准发布路径仍然是 `G14` source branch -> Tekton -> `G14-gitops` -> Argo CD；`ci-json` 只负责在 Tekton 的 `ci-json` step 内执行 repo-owned 命令清单，不能替代 GitOps desired state、Argo rollout 或 live runtime 验收。
+
+| 维度 | 原生 k8s Tekton + Argo 配置面 | `CI.json` runner 执行面 |
+| --- | --- | --- |
+| 权威职责 | 构建、发布、GitOps promotion、Argo sync、runtime rollout | repo-local 静态合同、schema、focused smoke、预检命令 |
+| 真相来源 | PipelineRun、TaskRun result、`G14-gitops` revision、Argo Application、live workload | 仓库内 `CI.json` 命令、runner 镜像、单个 `ci-json` TaskRun 日志 |
+| 优点 | 控制面声明式、k8s 可观测、并行 fan-out、TaskRun result 可复用、CD 与 runtime 验收边界清楚 | 改 repo 内检查成本低、命令贴近源码、适合 source-only 合同和 focused preflight、无需每加一条检查就手写一套新 Tekton Task |
+| 缺点 | render/generated/cluster 模板三层更复杂，控制面改动要等 reconciler apply 后才能验证，source 与 generated 漂移会制造噪声 | shell 包装、命令链和日志语义更脆弱；多个检查挤在一个 step 内时失败隔离差，天然不提供 GitOps desired state、Argo rollout 或 live runtime 证据 |
+| 适用场景 | 需要发布真相、并发构建、artifact identity、GitOps promotion、CD rollout、live runtime 判定 | 需要 repo-local 源码检查、静态合同、快速 smoke、focused preflight，但不需要声明 runtime 期望状态 |
+| 不该承担的职责 | 不应回退成 D601 legacy JS CD 或 target-side build | 不应被提升为独立 CD 路线，也不应用来替代 Argo sync、live workload ready 或公网 health |
+
+选择规则：
+
+- 只要问题涉及 release truth、rollout、runtime desired state、namespace workload 健康、public health 或 artifact provenance，就必须回到 Tekton + Argo 配置面。
+- 只要问题仍停留在 repo-local 命令、静态合同、source-only smoke 或 focused preflight，可以先在 `CI.json` runner 执行面收敛，但收敛后的结论仍需通过 Tekton + Argo 标准路径固化。
+- `CI.json` runner 的价值是降低“增加一条检查”的成本，不是提供第二套发布控制面；如果一项检查开始依赖 rollout 顺序、TaskRun results、GitOps branch、Argo revision 或 live runtime，它就应该升级为 Tekton/Argo 路径的一部分，而不是继续挤在 `ci-json` 里。
+
 ## Monorepo 组件计划与兼容 render
 
 HWLAB 是 monorepo，G14 CI/CD 加速必须按组件输入判断构建和滚动，但不能破坏当前 `CI.json`、`deploy/deploy.json` 与全量 source commit render 合同。
@@ -163,6 +182,8 @@ G14 PR、CI、CD 的判断应按以下顺序收敛真相，越靠前越接近最
 - sidecar 监听 `127.0.0.1` 时，Pod-IP `httpGet` probe 失败不等于 sidecar 自身 crash；必须同时对照 sidecar listen 日志和 probe target 语义。
 - 真实 live smoke 超时要先排除脚本入口和 timeout 误报；健康的 Codex stdio 冷启动首 token 可能需要数十秒，10 秒级 transport timeout 不能直接判服务故障。
 
+- 不要把顶层 `set -e` 当成 `ci-json` 命令失败传播的充分保证；`CI.json` 里的 `a && b && c` 若直接内联到顶层 shell，会出现前半失败但 `ci-json` TaskRun 继续成功的假绿。生成器必须把每条 `CI.json` 命令包进独立子 shell 或等价 simple command，让非零退出码真正传播到 TaskRun。
+
 ## PR -> CI -> CD 最短零误判 SOP
 
 1. 工作区与路由预检