docs: require executable cicd debug steps

2026-07-04 04:18:46 +00:00
parent 7e5707e87d
commit b0d7691760
3 changed files with 3 additions and 2 deletions
@@ -44,6 +44,7 @@ bun scripts/cli.ts cicd branch-follower debug-step --follower web-probe-sentinel
 - 触发或验收 rollout 时必须绑定 lane、source commit、PipelineRun/GitOps revision、runtime ready 和 `/health` 端点验证结果；web-probe/Playwright 结果只能作为单独的 post-deploy 证据。
 - 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 联调。
 - 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 状态读写链路。
@@ -36,7 +36,7 @@ When a branch-follower issue remains ambiguous after a debug step or drill-down,

 For HWLAB native `control-plane-refresh`, the bounded evidence chain must preserve both the rendered Pipeline summary and the applied cluster object summary for the same source commit: rendered Pipeline name, bounded `runtime-ready` task/when summary, source commit/stage ref, applied Pipeline name, resourceVersion, and a short annotation/label subset proving which object was patched. If the Job TTL has already removed the original Job, status/events/logs must show `-` or a bounded missing reason from stored state instead of inferring the missing edge.

-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.
+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. "Single-step" means an independently triggerable and independently executable target-side CLI/debug-step/drill-down entry, not a passive observation extracted from one end-to-end follower run. Each gate must be runnable against a selected follower/source snapshot, must emit bounded evidence, and must be retryable/fixable without creating a new source PR or replaying the full follower loop. 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.

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