end-acceptance

完成验收测试

每个负责塑造、规划、构建或审查的技能都会先阅读 docs/acceptances/ATTENTION.md。只有当其中的内容都是真实模式，而且表述足够精准，能让处于相应阶段的 Agent 知道要检查什么时，它才有用。因此，验收过程中不会向其中写入任何内容：候选项先放在 docs/acceptances/ATTENTION.<feature>.md 中，并在此处逐项与用户敲定，包括具体措辞。

**由用户决定，也由用户措辞。**你可以提出建议，但绝不能擅自用自己的措辞提升候选项。如果用户中途离开，尚未决定的候选项会留在功能文件中，旁边附上你的提议，整个会话也就此停止。

找出待处理项

1. 列出 docs/acceptances/ATTENTION.*.md——所有待处理的候选项文件，或用户指定的文件。如果没有，说明情况并停止。
2. 对每个文件，说明对应的功能、候选项的写入时间，以及该功能的验收是否已完成：阅读 docs/<feature>/ACCEPTANCE.md 中检查项旁的结果。如果检查尚未运行，说明情况，并询问现在是否敲定候选项，还是将文件留待本次会话稍后处理。
3. 先完整阅读 ATTENTION.md，如果该文件存在。你需要将候选项与其中内容进行比对，新条目也必须沿用其分组方式和语气。如果文件尚不存在，就创建该文件，并添加两行文件头：说明它的用途，以及每个负责塑造、规划、构建和审查的技能都会阅读它。

完整运行测试一次

验收会话没有运行测试套件——运行时间太长，不能让用户等待——因此会话结束时的代码树未经验证。现在运行一次项目的完整测试套件、lint 和类型检查，然后再敲定任何事项。失败就是发现的问题：如果原因较小且明确，使用 fix-bug 修复；否则将其记录到问题日志，或留到 V2 修订中处理，并注明观察到的情况。报告必须说明运行了什么以及结果如何；如果测试未通过，就不能在报告未说明失败的情况下提升经验条目。

比对

提问前，逐一审视所有候选项，并从以下三种判断中为每项选择一种。用一张表格、每项一行，让用户在问题开始前了解本次会话的大致情况：

• 已涵盖——现有条目已经说明了这项内容。扩充该条目的 seen in；如果候选项能让条目措辞更明确，则将其作为提议。
• 新增——ATTENTION.md 中没有涵盖这项内容。说明它符合哪些系统性测试（以前发生过、出现在多个地方、属于一类情况而非单个实例、某个阶段漏掉了它），以及应该由哪个阶段发现。
• 在你看来不具系统性——这是一次事件，而非一种模式；说明原因。用户可以不同意。

称其为“新增”之前先搜索：同一条经验往往已经以不同措辞存在，而同一种模式写成两个条目，正是导致文件不再有人阅读的原因。

逐项提问

对于每个新增或不具系统性的候选项，以及每个你想修改措辞的已涵盖候选项，每次只问一个问题：

• 候选项的原始记录措辞，以及它所对应的检查 ID；
• 它看起来具有系统性的原因，或不具系统性的原因；
• 你的建议——先提出提升、扩展现有条目或舍弃；
• 将写入 ATTENTION.md 的确切措辞：它所属的阶段、概括该模式的标题、用一到两句话说明应采取什么做法，以及 seen in。

用户可以认可措辞，也可以修改。必须逐字写入最终敲定的内容，不能改述。每个问题只讨论一项决定；绝不能捆绑两个候选项，也绝不能在问题尚未解决时继续推进。扩充现有条目的 seen in、但不修改其正文措辞，无需提问；说明你已完成即可。

编写与清退

• 更新 ATTENTION.md：在对应阶段下添加新条目，在原处扩展现有条目。合并，绝不重复。如果本次会话表明某个条目已过时——它已成为原则、技能检查或测试，或者很长时间以来都未再造成问题——则单独提出清退该条目。
• 所有候选事项都已处理后，删除 ATTENTION.<feature>.md。Git 会保留它。已舍弃的候选事项无需转移到其他位置；检查项旁的结论已记录了它们。如果仍有候选事项尚未决定，则保留该文件，只留下这些事项，并为每项附上已提出的方案。
• 使用 commit-changes 提交：说明哪些内容已纳入、扩展、舍弃和清退，以及关闭了哪些功能文件。展示提交信息，获批后提交，绝不推送。
• 在一屏内报告：逐个功能文件列出候选事项及其处理结果，并说明 ATTENTION.md 新增了哪些内容。