acceptance-checklisted

# acceptance-check 按 [docs/claude/standards.md#验收文档应至少包含](../../../docs/claude/standards.md#验收文档应至少包含) 的字段结构，对一项任务或一组改动给出 QA 验收结论。 ## 用法 `/acceptance-check <验收对象>` 示例： - `/acceptance-check tasks-p5.md 中 T1-T7` - `/acceptance-check src/opc/agent.py 的工具循环上限` ## 字段要求 输出必须严格包含以下 5 个字段： 1. **验收对象** — 被验收的任务/改动/文件范围 2. **验收标准** — 来自任务条目的"完成标准"或 PRD/architecture 中的对应验收点，若任务要求可恢复性，还应包含 evidence / handoff / 前置读取要求 3. **检查方法** — 实际执行的命令、读取的文件、对比的基线，以及是否检查了可恢复性 4. **结果记录** — 每项标准的检查结果（含证据：文件路径+行号 / 命令输出关键片段） 5. **是否通过** — `通过` / `不通过` / `部分通过`，并列出未通过项 ## 执行规则 1. 先定位"验收标准"来源。优先级：tasks-pX.md 条目 > PRD > 架构文档 > 用户口述。来源不明时，要求用户提供。 2. 检查方法必须是可复现的（命令 / 文件路径），禁止"看起来 OK"这类模糊描述。 3. 结果记录中，每项检查必须给出可点击引用，例如 `[file.md:12](path/file.md#L12)`；长任务还必须标明 evidence / handoff / 前置读取是否齐全。 4. "部分通过"必须显式列出未通过项及阻塞原因，不得将其合并为"通过"。 5. 如果任务声称完成但缺少验证证据、交接信息或前置读取记录，不得直接判定为"通过"。 6. 如果任务不能在清空聊天上下文后由任务文件和产物恢复，应输出可恢复性风险或不通过结论。 7. 不擅自修复缺陷；发现问题时建议建立修复任务（可调用 `/task-spec` 配合）。 ## 输出骨架 ``` [示例：可清空上下文继续] [验收对象] ... [验收标准] - 标准 1: ... - 标准 2: ... [检查方法] - 命令 / 文件 / 对比项 [结果记录] - 标准 1 → 通过 / 不通过（证据：path:line） - 标准 2 → ... [可恢复性结论] 可清空上下文继续（证据：任务条目、evidence、handoff、前置读取记录齐全） [结论] 通过 / 不通过 / 部分通过 [未通过项 & 后续动作] （仅当非"通过"时） [示例：不可清空上下文继续] [验收对象] ... [验收标准] - 标准 1: ... [检查方法] - 命令 / 文件 / 对比项 [结果记录] - 标准 1 → 部分通过（证据：path:line） - evidence / handoff / 前置读取记录 → 不通过（缺少验证证据或交接信息） [可恢复性结论] 不可清空上下文继续 [结论] 部分通过 / 不通过 [未通过项 & 后续动作] - 补齐验证证据、交接信息或前置读取记录后重新验收 ``` ## 验收 - 输出包含全部 5 个字段 - 每条结果都有可定位的证据 - "通过"结论与逐项结果不矛盾