done

接收来自 /do 的清单路径，以及 Outcome、每项 Acceptance Criterion 和 Global Invariant 被判定为成立的依据，还有其范围明确的强制构建工作的处置情况。

用户的决策。 如果两位谨慎的人基于相同证据，可能会合理地作出不同决定，而且这种差异会影响用户，那么这就是用户的决策。请用这句话检验每项实质性决策；你自己的信心并不能决定结果。在属于用户的决策上，先遵循用户明确保留的决定或适用的委托；然后查看用户的 Taste 条目——即已加载记忆文件中 ## Taste 部分经确认的偏好。只有在条目明确适用于此处时才遵循：它既针对这类决策，也确实会改变选择。像减少工作量或降低成本这类几乎会影响所有决策的普遍倾向，本身并不适用。否则，根据证据作出决定。报告决策时，先列出本次运行重新审议的每项决策记录，并说明搁置该决定的理由及推翻它的代价；随后列出用户的决策，每项说明未选的替代方案，以及决定依据——遵循了哪条偏好，或没有适用的偏好。

用普通文本按以下顺序输出完成摘要。

开头用一行说明构建了什么，以及 Outcome 和每道门槛均已通过。

接着说明哪些事项需要当事人决定或接受。按照上文“用户的决策”中的要求，列出本次运行重新审议的每项决策记录，以及每项用户决策及其替代方案。如果 Manifest 的 ASM-* 条目记录了因项目原则而搁置的请求，请说明请求内容、相关原则、实际构建的替代方案，以及恢复原请求所需的一项改动。列出所有留待当事人决定而未接受的提议，例如更新 setup 项目或转交 ticket-up；无论是本次运行标记的，还是 Manifest 的 ASM-* 条目记录的，都要列出。列出所有由 Agent 担任决策者的决策记录。对于每项提议和记录，说明接受或审查它会带来什么变化。逐字保留 /do 提供的任何草拟 Taste 条目，并附上询问用户是否同意的问题。

然后说明其余内容。列出关键改动（文件及其行为影响，而不只是路径）、偏离的任何 Process Guidance、偏离 Initial Approach 或交付顺序的情况及原因，以及任何值得注意的工作完成情况。说明所有实质性的自主决策及其理由，包括实质性的工作主张或证据修订及其依据，以及 Appetite 的任何修订，并说明其收益为何足以抵消新增的复杂性和维护成本。准确说明 /do 提供的 Outcome 和每道门槛的依据。逐项列出 /do 移交的债务——仅包括本次运行无法修复的事项，并按原文提供；对用户希望处理的事项，提供 ticket-up 选项，并附上该界面保留的练习证据链接。不要列出低于门槛标准的发现，也不要列出本次运行顺手修复的既有问题。说明顺手修复的问题，以及因无用或近乎同义反复而移除的测试及其原因。若 /do 保留了执行日志，请说明其路径。

即使执行日志已记录以上内容，也要在摘要中全部列出；读者不应为了了解哪些建议性指导被搁置或计划如何调整而打开日志。根据任务复杂度调整细节——小型修复用几句话，多交付物重构用一到两段。对于多仓库清单，摘要应覆盖整个清单，并说明验证了哪些仓库的交付物。 仅当 Outcome、每项当前验收标准和全局不变量都已基于最新证据成立，且没有任何内容仍未验证、失败、过时、因可采取行动的原因而受阻或待升级，同时有界的强制构建工作已完成或按照 /do 的规则进行了有效路由时，方可完成。尚未解决的修订或必要证据缺失都会阻止完成。报告执行器支持的判定结果，不要额外增加评审者达成共识的条件。最后必须附上以下指令行——它是指令而非观察结果，因为完成后清单仍是事实来源：

如果下一条消息描述了变更或新要求（而非单纯提问），请调用 /define <this-manifest-path> 进行修订。单纯的问题直接在此处回答。