delivery-acceptance (YANSHOU · 验收)

一句话：把“实施计划 + 已交付代码”当成不可信交付来独立验收，用计划对账、源码审查、真实测试和边界探针给出可合并判断。发现问题时，先按用户开局授权决定是否顺手修复；不要无条件制造待执行计划文件。

这个 skill 解决什么

Plan-driven 工作流常见盲区是：执行者说“做完了、测试全绿”，但没人独立对账。delivery-acceptance 的价值是用陌生视角核实：计划要求是否真落地，测试是否真跑过，边界是否有隐藏 bug，交付是否可合并。

验收不是单纯 code review，也不是机械地写更多文档。验收输出必须让用户一眼知道：现在能不能合并；如果不能，剩下什么可执行工作。

何时触发

用户表达以下意图时使用：

• “验收一下这次交付 / 帮我验收 docs/plans/xxx 这个计划”
• “程序员说做完了，你核实一下”
• “这个 plan 执行完了，做一次 acceptance / YANSHOU”
• “审查一下交付质量 / 这次改动有没有 bug”
• 计划驱动交付合并前的最后一道闸

输入

唯一必需输入：实施计划文件路径，例如 docs/superpowers/plans/2026-06-19-xxx.md。

• 如果用户没有给计划文件路径，立即停下问：“请给我需要验收的计划文件路径。”不要猜目录。
• 计划文件是 ground truth：从中抽取 Task、要求文件、关键函数、关键测试、提交信息和 Self-Review 声明。
• git 历史从 git log 自动取；如果用户明确给了 commit/hash，以用户给的为准。

开局强制决策

拿到计划路径后，先问用户，不要默认替用户决定。这是硬规则。

先做一次快速预判：读计划基线 + git diff --stat + 涉及文件量级，判断这批交付若发现问题，更倾向哪种处理方式（A 顺手修复 / B 写 fix 计划 / C 逐项确认）。预判只是为了把推荐讲清楚，不改变问问题这件事本身——问题照常问，A/B/C 文字一字不改，只在预判倾向的那个选项后面加“（推荐）”标记，并附一句理由。

必须问清楚：

1. 发现问题后怎么处理？
   • A. 小而明确的问题可在验收中顺手修复；修完只写验收报告，不再写待执行 MD 计划。
   • B. 先不修复；只写验收报告 + 可执行 fix plan。
   • C. 每个问题先停下问我，再决定修不修。
2. 是否允许提交？（仅当用户允许修复时 relevant）
   • 只改工作区，不 commit。
   • 修完可 commit，不合并。
   • 其他明确授权。
3. 验收深度？
   • 标准：计划对账 + 源码审查 + 真实测试 + 边界探针。
   • 快速：只读代码 + git log + 既有测试；报告必须标注“浅验”。
4. 是否追加补充维度？
   • 默认三维度：计划完成度 / 代码质量 / Bug 审计。
   • 可追加性能、安全、文档完整性、可访问性等。

如果当前平台没有多选提问工具，就用普通对话问完并等待用户回答。不要 auto-resolve；标了“（推荐）”只是表达倾向，仍必须等用户回答后再执行，不能“按推荐默认值继续”。

输出规则

• 验收报告落盘到：docs/superpowers/reports/<plan-slug>-acceptance-report.md
• 待执行修复计划落盘到：docs/superpowers/plans/<plan-slug>-fix-plan.md
• <plan-slug> 使用原计划文件名去掉 .md 后的名称。
• 如果项目没有 docs/superpowers/，就在计划文件所在目录向上寻找 docs/；仍找不到时，询问用户报告目录。
• 按状态输出的契约见 README「输出契约」一节。
• 报告是 report 不是 plan；修完的不补写事后 TDD 计划。

核心原则

1. 独立验收视角。 假设自己第一次看到这个交付，不因“我看着它写出来”而放水。
2. evidence before assertions。 任何“完成/通过/无 bug”都必须有命令、探针、diff 或 file:line 证据。
3. 真实测试 + 边界探针。 标准验收不能只读代码和 git log。边界探针是挖出隐藏 bug 的关键。
4. 报告和计划分离。 report 放结论；plan 只放未来要执行的工作。不要把验收结论放进 plans 目录。
5. 修复策略由用户开局决定。 未问清楚前，不得默认派子代理、默认修复、默认提交、默认只写计划。
6. 最小改动。 修 bug 优先局部最小修复，保护既有契约；若必须改契约，必须在报告中显式说明影响路径和复审重点。
7. 不写假闭环。 发现问题但未修就是未闭环；修了但没复验也不是闭环。

工作流

Step 1 · 建任务追踪

创建任务列表：抽取计划基线、计划完成度核查、代码质量审查、Bug 审计、报告落盘、必要时修复、最终复验。

如果用户开局选择”先不修复”，任务里加入”写 fix plan”；否则不要预设 fix plan 任务。

Step 1.5 · 复述理解

读完计划后，先用大白话复述三件事给用户，等用户确认或纠正再进 Step 2：

1. 验收什么：计划标题 + 涉及哪些文件/模块
2. 关键约束：计划里强调的原则、Self-Review 声明的”本期不做”
3. 怎么验：三维度顺序、是否要写探针、要不要跑额外命令

不复述直接进 Step 2 = 默认”我已经理解”，违背硬规则。如果用户纠正了，回到 Step 1 调整任务列表。

Step 2 · 抽取计划基线

读计划文件，建立验收对照表：每个 Task 对应要求文件、函数、测试、提交信息。核实 Self-Review 中“本期不做”的声明是否与实现一致。

Step 3 · 三维度验收

参考 references/acceptance-dimensions.md。

• 计划完成度：逐 Task 对照计划核实，检查 git log、文件、函数、测试是否真存在。
• 代码质量：读核心新文件和 diff，评估分层、命名、错误处理、误报防护、冗余。
• Bug 审计：运行真实测试拿基线，再写探针验证边界。区分确认 bug 与疑似风险。

Step 4 · 按用户策略处理问题

先判定"顺手可修"边界——全满足才动手，任一不满足 → 停下问用户：

• 改动 ≤ 30 行（不含测试）
• 不改公共 API / 导出签名
• 不新增第三方依赖
• 不改既有测试的语义（可新增测试，不可改）
• 修复后能跑一条针对性测试或探针复验

满足后按用户开局策略处理：

• 无问题：直接写验收报告。
• 有问题 + 用户允许顺手修复：按 TDD 修复小而明确的问题，复验后写报告；不要写 fix plan。
• 有问题 + 用户要求先不修复：不要改代码；写报告 + fix plan。
• 有问题 + 用户要求逐项确认：停下给出问题、影响、建议，让用户决定。
• 问题高风险或会大改架构：无论开局策略是什么，都停下确认。

Step 5 · 写验收报告

使用 references/report-template.md。报告必须包含：

• 验收对象和方式
• base/head commit 或工作区状态
• 三维度结论和证据
• Bug / 风险清单
• 如果已修复：修复摘要、变更文件、复验结果
• 如果未修复：fix plan 路径和未闭环状态
• 可合并判定

Step 6 · 仅在“未修复”时写 fix plan

只有当用户明确选择“先不修复”或验收决定留下未来可执行工作时，才使用 references/polish-plan-format.md 写 fix-plan.md。

fix plan 必须是未来可执行的 TDD 计划：每个 Fix 有失败测试、跑红方式、实现方向、跑绿命令。不要把已经完成的修复写成计划。

Step 7 · 最终复验

若本轮做了修复，必须复验：

• 对每个修复点写或运行针对性探针/测试。
• 跑项目对应全量测试。
• 必要时跑 build/lint/source gate。
• 检查 diff 只包含相关改动。

复验结果写进报告。

Step 7.5 · diff 范围核查

防"顺手改进"型无关改动。修复前存基线，修复后对比。

• 修复前：git diff --stat <base_sha> > .gstack/.acceptance/<plan-slug>/diff-before.stat
• 修复后：git diff --stat <base_sha> > .gstack/.acceptance/<plan-slug>/diff-after.stat 对比
• 多出的文件必须显式说明理由，写到报告
• 改动范围超出授权 → 停下问用户

反例黑名单：不要顺手格式化无关文件、不要改 lockfile、不要加无关注释——这些不算 surgical change。

强制停手点

以下情况必须停下问用户：

1. 未完成开局决策。
2. 修复会大幅改变交付语义、架构或公共契约。
3. 涉及合并默认分支、打 tag、部署、force push、删除大量文件等高风险动作。
4. 发现严重数据损坏、安全漏洞或需要人工业务判断的问题。
5. 用户开局选择“逐项确认”。

反例黑名单

• 不要没问用户就默认“推荐策略”。
• 不要把 acceptance report 写进 plans/。
• 不要在已顺手修复后再补写 polish.md / fix-plan.md。
• 不要把“修复记录”伪装成“待执行计划”。
• 不要只读代码 + git log 就声称标准验收完成。
• 不要把交付者的“测试全绿”当证据，必须自己跑。
• 不要把私有路径、API key、个人配置写进报告或计划。
• 不要用 git reset --hard 当默认回退。

进阶参考

• references/acceptance-dimensions.md — 三维度检查清单与探针套路。
• references/report-template.md — 验收报告结构。
• references/polish-plan-format.md — 仅用于未修复工作的 TDD fix plan 模板。
• references/dispatch-fix-subagent.md — 当用户明确要求派子代理修复时使用。
• scripts/probe-template.mjs — 边界探针脚本起手模板。