start-acceptance

开始验收测试

用户现在要开始试用这项工作。你需要为他们做好两件事：一份供他们逐项测试的清单，以及一份能留存他们测试结果的记录。清单位于 docs/<feature>/ACCEPTANCE.md。记录有两个位置，采用两种不同的筛选方式：检查项旁的结论会保留所有内容；docs/acceptances/ATTENTION.<feature>.md 只保留可能具有系统性的问题。第二个文件是暂存区——其中的候选项会由 end-acceptance 在用户参与下，用用户自己的措辞，提升至 docs/acceptances/ATTENTION.md。这是整个项目的关注清单，所有塑造、规划、构建和审查技能都会读取。切勿在本次会话中写入 ATTENTION.md。

由用户决定。 验收者就是用户。用户提出修正意见，不是要争论谁对谁错，而是计划或构建情况的证据；你的任务是查明是哪一种。给出建议、记录下来，并由用户决定现在修复、暂时搁置还是放弃。

查找或编写清单

1. 确定功能。 根据参数、分支、最新的 EXECUTION.md 或规划目录中的计划文件夹判断（docs/<feature>/，除非项目使用其他位置）。如果无法明确判断，就询问——只问一个问题，并先说出你最有把握的猜测。
2. 如果存在 ACCEPTANCE.md， 读取并对照代码树检查：查看它编写之后的 git log。之后合入的工作可能尚未涵盖——说明受影响的检查项，并追加一个章节，不要重写用户可能已经测试过的内容。然后告诉用户从哪里开始，并按章节说明：每节需要多少时间。
3. 如果不存在，就编写一份， 使用 write-acceptance，依据实际变更编写：分支的 git log，以及它与主集成分支的差异（或者与用户指定的发布版本或提交之间的差异）、EXECUTION.md 和最终文档（如果存在）。开头说明你认为本次验收的范围是什么——用户现在能做哪些以前做不到的事，以及应如何测试；并在他们开始前，请用户确认范围。范围不对会浪费用户的时间。只要不影响准确性，就尽量保持简短。
4. 阅读 docs/acceptances/ATTENTION.md（如果存在），以及之前其他功能中仍未关闭的 ATTENTION.<other>.md。凡是适用于本功能的条目，如果清单中还没有对应检查项，就都要添加——验收过去发现的问题，是优先复查的内容。
5. 告诉用户你已准备就绪：他们可以随时发送备注、截图和修正意见；你会负责记录。

记录——紧邻检查项

将判定结果保存在 ACCEPTANCE.md 文件本身的带日期 ## Results 标题下（如果项目的检查清单有结果列，也可以记录在该列中），这样收尾技能就能在每项检查旁找到对应判定。对于用户发送的每一项内容：

• 将其对应到一项检查。 如果找不到对应项，这说明清单有问题——添加该检查，然后记录判定。
• 亲自查看截图。 对照预期的可观察结果，说明你看到了什么。绝不要让用户描述他们刚刚展示给你的内容。
• 对其分类，用一个便于记录排序的词：通过；缺陷（按计划构建，但无法正常工作）；遗漏需求（无人计划，但用户有所期待）；设计错误（按计划构建，但计划本身有误）；润色（措辞、间距、默认设置）；或问题（只有用户能定夺）。
• 记录下来：检查项 ID、判定结果、用户原话、你的解读、发现问题的平台或设备，以及你对此采取的措施。
• 采取行动。 原因明确的小缺陷：现在就用 fix-bug 修复，说明你已修复，并将提交哈希写入记录。任何属于产品决策或影响范围较大的事项：先询问，问一个问题，并先给出你的建议——绝不要在会话中自行决定。任何超出本次会话范围的事项：将其记入问题日志，或记入收尾技能所写的 V2 修订版，并提供足够的背景信息，方便他人之后接手。任何事项都不能只留在聊天中。
• 绝不要争辩着否定用户的纠正。 如果对用户来说不对，那就是不对。查明是结构、计划、构建还是审查环节放过了它——这正是候选文件需要记录的内容。
• 不要运行测试套件。 这太耗时，而且用户正坐在打开的应用旁。会话中做出的修复，只需针对所改动的内容运行一项测试（前提是能在几秒内跑完），其他测试一律不跑；完整测试套件、lint 和类型检查只在 end-acceptance 中运行一次。在记录中说明修复尚未经过其他验证，避免有人误以为它已测试。

候选项——docs/acceptances/ATTENTION.<feature>.md

每个小问题都应记录在对应检查项旁。此文件用于记录也可能影响下一个功能的内容：模式，而非个例。 一旦发现问题看起来属于模式，就立即写入候选项——不要等到会话结束，那时就想不起当时的推理了。符合以下任一条件时，问题就是候选项：

• 以前发生过——作出判断前，先搜索此功能及更早功能的记录。
• 在此功能的多个地方发生过。
• 它是一类问题，而非单个实例：“从未说明空状态”“从未测试第二台设备的情况”“快捷键只按 Windows 的习惯标注”——而不是“保存按钮是灰色的”。
• 问题之所以出现，是因为某个阶段跳过了某项工作：结构设计从未考虑失败情况，计划没有为此设置验收项，审查时也未检查。

不确定时，就将其写为候选项，并说明疑虑是什么。收尾验收删掉一项很容易，丢失一条经验却代价高昂。

每项候选内容都应简短：用一行标题概括该模式；用一句话说明它符合上述哪些测试；列出它所依据的检查项 ID 和日期；标明本应发现它的阶段（塑形、设计、规划、执行、审查、验收）；并初步写出应如何改进——说明哪项检查或问题可以发现它。十行已经算长。出现首项候选内容时就创建文件，并用一行说明这是此功能的候选项清单，且收尾验收会将其归档。

与现有 ATTENTION.md 条目相符的候选项仍应记录在此处，并注明“extends: ”，以便收尾验收扩充该条目的记录。

结束会话

当用户表示已完成或停止发送消息时：

• 用一屏报告：已通过、失败和未运行的检查；已提交的修复及其哈希；已移交的内容及其去向；已写入的候选项。
• 未运行的检查仍保留在列表中，并标明未运行。 close-plan 和 close-roadmap 会逐项检查并清除列表；不要在此处清除。
• 测试套件尚未运行。请说明这一点；由 end-acceptance 运行。
• 使用 commit-changes 提交记录和候选文件：展示提交信息，经批准后提交，绝不推送。
• 说明下一步是 end-acceptance，并询问用户现在是否有时间运行。完成这一步之前，候选项还不能算作经验教训。