closed-loop-deliverylisted

# 验收标准闭环交付 ## 何时使用 核心原则：**对照 DoD（Definition of Done）交付，而不是对照代码改动量交付。** 一个任务在验收标准被「证据」验证之前，都视为未完成——仅仅改了代码不算完成。 适用： - 用户给出编码/修复任务，并期望**端到端**完成（不只是改完代码就交差）。 - 任务跨越多个环节：代码 + 测试 + PR 评论 + dev 部署 + 运行时检查。 - 想避免「现在去测一下」「现在去部署」「现在再看下 PR」这类反复的人工催促。 不该用（负边界）： - 纯问答 / 纯解释类请求——没有要交付的可验证产物。 - 未经**明确人工批准**的生产（prod）/预发（staging）部署请求。 - 被缺失的密钥、账号权限阻塞、且无法合理推断的任务——先升级求助，不要硬闯。 ## 步骤 ### 0. 执行前先定义一次（Required Inputs） 执行前一次性确定：**任务目标**、**验收标准（DoD）**、**目标环境**（默认 `dev`）、**最大迭代轮数**（默认 `2`）。 - 若缺验收标准：**只追问一次**。用户仍不给，就提出一个具体默认标准并据此推进。 - 优先经过 issue 门禁（参见 `create-issue-gate` 思路）：issue 状态为 `ready`、执行门禁 `allowed` 才继续；状态为 `draft` 时**不要**进入实现/部署/评审循环；开工前要拿到用户提供的、**可测**的验收标准。 ### 1. 定义 DoD 把需求转成**可测**标准。示例：结账任务的 DoD =「在 dev 环境，结账接口返回一个有效、可打开的第三方支付 URL」。 ### 2. 最小化实现 scope 严格收紧到任务目标，不夹带无关改动。 ### 3. 本地验证 先跑**聚焦的测试**（与改动直接相关的用例），需要时再扩大到更广的检查。 ### 4. 评审回合（Review loop） - 拉取 PR 的评论 / review。 - 分类：**有效** vs **无法落地/非问题**。 - 修复有效项，重跑验证。 ### 5. dev 部署 + 运行时验证 当运行时行为重要时，部署到 `dev`。通过**真实 API / Lambda / 日志凭证**对照 DoD 验证。 ### 6. 凭证化完成判定 只有当**所有** DoD 检查通过时才报告「完成」；否则继续循环，直到通过或触发停止条件。 ## 指令 ### PR 评论轮询策略（避免噪声短轮询，用批量窗口） | 回合 | 等待 | 动作 | |---|---|---| | 第 1 轮 | `3m` | 收集增量评论 / review | | 第 2 轮 | `6m` | 再收集增量 | | 最终轮 | `10m` | ���集此刻所有可见评论 / review | 每一轮内**一次性批处���所有新评论**，不要每来一条就立刻重新轮询。`10m` 轮之后停止等待，按当时可见的全部评论推进。若 CI 仍在跑，把轮询对齐到 check 完成边界，而非固定快轮询。 ### 人工门禁（必须征求确认） 以下情形必须先拿到用户**明确确认**： - 超出约定范围的生产 / 预发部署； - 破坏性操作（改写历史、force push、毁数据操作）； - 影响计费 / 安全态势的动作； - 仓库 / 运行时中不存在的密钥值； - 会实质改变结果的歧义 DoD。 ### 迭代 /