docs: require cicd single-step validation loops

.agents/skills/unidesk-cicd/references/branch-follower.md

@@ -34,6 +34,8 @@ Do not debug the same state/read/write problem by repeatedly pushing empty or ti
 
 When a branch-follower issue remains ambiguous after a debug step or drill-down, split the CLI into a smaller single-step probe before any new end-to-end run. Add or use a focused `debug-step`, follower-scoped drill-down, or bounded target-side diagnostic for the exact missing edge, such as PipelineRun -> Pipeline spec, controller refresh apply object, state write, closeout re-read, or log/timing extraction. Do not use another source PR, merge, or full automatic follower loop as the next diagnostic action until the narrower step can show the needed evidence.
 
+CI/CD validation must be decomposable into ordered single-step gates before a full rollout observation is accepted: first validate the reuse plan, then CI parallelism/TaskRun plan, then CD rollout plan, then post-deploy monitoring/health evidence. Each gate must have a CLI/debug-step/drill-down entry that can be run and fixed independently on the target side. Do not use issue comments, repeated PR merges, or end-to-end follower loops as substitutes for a missing single-step validator; add the missing bounded CLI step first.
+
 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.

.agents/skills/unidesk-subagent/SKILL.md

@@ -15,6 +15,7 @@ description: UniDesk 主代理调度子代理的必读技能。用户提到子
 - 每个子代理 prompt 必须写清 repo、目标分支、独立 worktree、issue/PR、禁止触碰范围、验收命令、证据字段和是否允许部署；不要让多个子代理共享同一可写 worktree。
 - 用户指定模型（例如 `gpt-5.5`）时，主代理调度子代理必须在任务描述或调度参数中显式遵守。
 - 用户要求或授权“按任务难度分配模型”时，主代理必须按复杂度选择模型与 reasoning effort，并在 prompt 中写明选择理由；默认继承主模型，只有任务难度、风险或延迟收益明确时才显式覆盖。
+- 执行型子代理必须能在自己负责的边界内完成“单步验证 -> 定位 -> 最小修复 -> 复测 -> PR/issue 证据”的闭环；除非遇到架构边界、权限缺失或需要主代理合并/取舍，不要把每个单步验证都退回主代理通过 issue 大回环推进。
 - 子代理完成后必须留下可审查工件：PR、issue comment、commit、验证输出摘要、部署/observer/trace 证据或阻塞说明；主代理不能只凭口头结论合并。
 - 子代理完成任务后，主代理必须再给该子代理发送 post-task 收口要求；若主代理要求子代理纠偏或补验证，则等纠偏完成后再发 post-task。post-task 反馈由子代理按 `$post-task` 自行给出判断，主代理不负责反馈池去重；主代理只从子代理提好的反馈中挑选适合工程化的项转成正式 FEATURE/BUG issue，并优先派回提出该反馈的子代理执行。