kscz0000 闭环交付
概述
将每个任务视为未完成，直到验收标准在证据中得到验证，而不仅仅是代码被修改。
核心规则：按照 DoD（完成定义）交付，而非按照代码差异大小交付。
使用时机
当以下情况时使用此技能：
- 用户给出编码/修复任务，期望端到端完成
- 任务跨越代码 + 测试 + PR 评论 + 开发部署 + 运行时检查
- 希望避免重复手动提示如"现在测试"、"现在部署"、"现在重新检查 PR"
以下情况不使用此技能：
- 纯问答/解释
- 没有明确人工批准的生产部署请求
- 因缺少密钥/账户访问权限而被阻塞且无法推断的任务
必需输入
执行前，定义一次以下内容：
- 任务目标
- 验收标准（DoD）
- 目标环境（默认为
dev） - 最大迭代轮数（默认为
2）
如果缺少验收标准，请求一次。如果用户未提供，提出一个具体的默认值并继续。
Issue 门禁依赖
执行前，优先使用 create-issue-gate。
- 如果 issue 状态为
ready且执行门禁为allowed，继续。 - 如果 issue 状态为
draft，不执行实现/部署/审查循环。 - 在开始执行前需要用户提供可测试的验收标准。
默认工作流
定义 DoD
- 将请求转换为可测试的标准。
- 示例：结账任务 DoD = "结账端点在 dev 环境返回一个有效的、可打开的第三方支付 URL"。
实现最小变更
- 将范围严格控制在任务目标内。
本地验证
- 先运行针对性测试，必要时再运行更广泛的检查。
审查循环
- 获取 PR 评论/审查。
- 分类有效项与不可操作项。
- 修复有效项，重新运行验证。
开发部署 + 运行时验证
- 当运行时行为重要时部署到
dev。 - 通过真实 API/Lambda/日志证据对照 DoD 进行验证。
- 当运行时行为重要时部署到
完成决策
- 仅当所有 DoD 检查通过时报告"完成"。
- 否则继续循环直到通过或达到停止条件。
PR 评论轮询策略
默认避免频繁的短轮询。使用批量窗口：
- 第 1 轮： 等待
3m，收集增量评论/审查 - 第 2 轮： 等待
6m，再次收集增量 - 最后一轮： 等待
10m，收集所有剩余可见评论/审查
每轮：
- 批量处理所有新评论
- 避免在每个单独评论后立即重新轮询
- 在
10m轮后，停止等待并处理当时可见的所有评论
如果 CI 仍在运行，将轮询对齐到检查完成边界而非固定快速轮询。
人工门禁规则（必须询问）
以下情况需要明确的用户确认：
- 超出约定范围的生产/预发布部署
- 破坏性操作（历史重写、强制推送、数据破坏性操作）
- 涉及计费/安全态势变更的操作
- 仓库/运行时中不可用的密钥值
- 会实质性改变结果的模糊 DoD
迭代/停止条件
当以下情况时停止并上报简洁的阻塞报告：
- DoD 在最大轮数（默认
2）后仍然失败 - 外部依赖阻塞进度（提供商故障、缺少凭证、账户权限）
- 冲突的审查指令无法同时满足
上报报告必须包含：
- 通过了什么
- 失败了什么
- 证据（命令/日志/API 结果）
- 需要用户做出的最小决策
输出契约
声称完成时，始终包含：
- 验收标准检查清单及通过/失败状态
- 运行的命令/测试
- 运行时证据（端点/Lambda/日志关键行）
- PR 状态（新可操作评论数量）
没有证据不得声称成功。
局限性
- 仅当任务明确符合上述描述范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少必需输入、权限、安全边界或成功标准，停止并请求澄清。