diff --git a/.agents/skills/unidesk-cicd/SKILL.md b/.agents/skills/unidesk-cicd/SKILL.md
index 6f39dec0..55a3edc3 100644
--- a/.agents/skills/unidesk-cicd/SKILL.md
+++ b/.agents/skills/unidesk-cicd/SKILL.md
@@ -45,6 +45,7 @@ bun scripts/cli.ts cicd branch-follower debug-step --follower web-probe-sentinel
 - CI/CD 状态、日志和事件查询必须减少 trans/SSH 传输：能在目标 NODE/k8s 内解析、聚合、裁剪的内容，必须在目标侧计算成短 JSON/table 摘要后再回传；禁止为了本地解析而把完整 ConfigMap、大对象、长日志或原始 API payload 透传回来。
 - branch-follower 排障必须优先使用 `debug-step` 做单步调试：`state-read`、`status-read`、`decide`、`state-write` 分别定位状态读取、K8s native status、决策和 ConfigMap patch，不要通过反复推小提交触发整条自动跟随大回环来定位同一问题。
 - branch-follower 的“单步”不是端到端流水线里的被动观察点；reuse plan、CI 并行/TaskRun plan、CD rollout plan、post-deploy health/monitoring 每个 gate 都必须有可独立触发、独立执行、独立复测的目标侧 CLI/debug-step/drill-down 入口。没有这个入口时先补入口，再做 `run-once`、自动 loop 或小 PR 联调。
+- branch-follower 单步测不通时应继续在该单步边界内定位和修复，直到目标侧复测通过；不要把普通 gate 失败包装成阻塞结论。只有权限缺失、外部依赖不可达、架构取舍或明确超出当前授权范围时，才写 issue 阻塞和下一步最小范围。
 - CI/CD 排障中再次踩到已经暴露过的运行面坑、工具误用、镜像假设或状态可见性缺口时，必须先把长期规则写入本 skill/reference，再继续单步调试；branch-follower 必须先让相关 `debug-step` 单步全部通过，再做 `run-once`、自动 loop 或小 PR/小提交联调。
 - CI/CD 验证、测试和性能度量必须在目标 NODE/k8s 内执行，尤其是 branch-follower、Tekton/Argo、runtime reuse/env reuse、git mirror 和 runtime-ready 相关改动；不要在 master/local host 跑 test 或用本地验证结果替代目标运行面证据。本机只用于源码阅读、编辑和必要静态语法检查，正式收敛结论必须来自目标 NODE 计算出的短摘要。
 - in-cluster/controller/native helper 不能假设镜像内存在 `kubectl` binary。目标 Pod/Job 内读取或写入 Kubernetes 对象必须走 serviceaccount token + Kubernetes HTTPS API 或已封装的 native helper；`kubectl` 只允许在 operator 侧受控 CLI/trans 边界作为 transport/debug 包装，不得进入正式 controller 状态读写链路。
diff --git a/.agents/skills/unidesk-cicd/references/branch-follower.md b/.agents/skills/unidesk-cicd/references/branch-follower.md
index 0ca275df..717f1330 100644
--- a/.agents/skills/unidesk-cicd/references/branch-follower.md
+++ b/.agents/skills/unidesk-cicd/references/branch-follower.md
@@ -40,6 +40,8 @@ CI/CD validation must be decomposable into ordered single-step gates before a fu
 
 PRs that change branch-follower convergence, reuse, Tekton/Argo closeout, runtime readiness or gate visibility must be submitted only after the author has run the affected independently triggerable single-step gates on the target NODE/k8s and captured bounded pass evidence. If a required gate cannot be triggered independently or does not pass, do not open the PR as a validation vehicle; leave a short issue comment with the missing gate, target object names and next minimal fix scope, then fix the gate first.
 
+An independently triggered single-step failure is an actionable defect inside that gate until proven otherwise. The owner must narrow the failing gate, patch the relevant CLI/helper/controller logic, rerun the same target-side step, and iterate until it passes before submitting a PR. Issue-only blockers are reserved for permission gaps, external service outages, architecture decisions, or work that is explicitly outside the assigned runtime/repo boundary; ordinary failing step evidence is not a blocker.
+
 When a repeated runtime pitfall or visibility defect is found during branch-follower work, update this reference or the skill entry first, then continue with the narrow debug step. Do not proceed to `run-once`, controller loop observation, automatic follower validation, or source-commit-driven integration until the relevant `state-read`, `status-read`, `decide`, and `state-write` debug steps pass for the affected follower.
 
 Stage and end-to-end timing budgets are observability and guidance signals, not hard failure gates. When a stage or total wall-clock exceeds its YAML budget, the CLI/controller should record `overBudget`, emit a warning/hint, keep exposing state and continue toward native completion when the underlying Tekton/Argo/runtime operation is still making progress. Do not fail, kill, or permanently block a follower solely because the timing budget elapsed; otherwise the timeout checker itself can become the source of hung or failed delivery. Real failures must come from native objects such as Job/TaskRun/PipelineRun/Argo/runtime conditions, explicit command failures, missing required source/config, or operator cancellation.
diff --git a/.agents/skills/unidesk-subagent/SKILL.md b/.agents/skills/unidesk-subagent/SKILL.md
index ca5ba944..87b44072 100644
--- a/.agents/skills/unidesk-subagent/SKILL.md
+++ b/.agents/skills/unidesk-subagent/SKILL.md
@@ -16,7 +16,7 @@ description: UniDesk 主代理调度子代理的必读技能。用户提到子
 - 用户指定模型（例如 `gpt-5.5`）时，主代理调度子代理必须在任务描述或调度参数中显式遵守。
 - 用户要求或授权“按任务难度分配模型”时，主代理必须按复杂度选择模型与 reasoning effort，并在 prompt 中写明选择理由；默认继承主模型，只有任务难度、风险或延迟收益明确时才显式覆盖。
 - 执行型子代理必须能在自己负责的边界内完成“单步验证 -> 定位 -> 最小修复 -> 复测 -> PR/issue 证据”的闭环；这里的“单步验证”必须是可独立触发、独立执行、独立复测的入口，不是在端到端大循环中被动观察某个阶段。除非遇到架构边界、权限缺失或需要主代理合并/取舍，不要把每个单步验证都退回主代理通过 issue 大回环推进。
-- 需要提交 PR 的子代理必须在 PR 前自行用相关独立单步跑通目标运行面验证并保存 bounded 证据；测不通或缺入口时只写 issue 阻塞/缺口和下一步最小修复范围，不得先提交 PR 让主代理或自动 follower 替自己联调。
+- 需要提交 PR 的子代理必须在 PR 前自行用相关独立单步跑通目标运行面验证并保存 bounded 证据；测不通就继续定位和修改，直到该单步在目标侧通过。只有权限、外部依赖、架构取舍或明确越界时才写 issue 阻塞/缺口，不得先提交 PR 让主代理或自动 follower 替自己联调。
 - 子代理完成后必须留下可审查工件：PR、issue comment、commit、验证输出摘要、部署/observer/trace 证据或阻塞说明；主代理不能只凭口头结论合并。
 - 子代理完成任务后，主代理必须再给该子代理发送 post-task 收口要求；若主代理要求子代理纠偏或补验证，则等纠偏完成后再发 post-task。post-task 反馈由子代理按 `$post-task` 自行给出判断，主代理不负责反馈池去重；主代理只从子代理提好的反馈中挑选适合工程化的项转成正式 FEATURE/BUG issue，并优先派回提出该反馈的子代理执行。