完成（或失败/令人失望的）一轮构建、QA、演示…

当一个产出物已完成、失败、令人失望或目标模糊，下一轮最需要的不是它的代码而是这一轮的教训时，用它做一轮无辩护的复盘沉淀。

适用场景

解决思路

1. 先读取原始目标、最终产出物、QA 证据、用户投诉以及本地规划笔记，作为本轮的全部输入材料。
2. 把可复用资产与误导性进展分开：contracts、schemas、tests、services、术语、示例中哪些真正值得复用，对比 UI、面板、脚手架、抽象中哪些只是看起来有产出。
3. 记录前先泛化：当反馈是一大堆具体投诉时，先向上聚类成共同模式再落笔——针对多个条目的多个具体问题通常共享同一个根因缺口；把根因及其模式族写成经验，具体条目只作为其下的证据，而不是经验本身。
4. 把每个失败命名为反模式（anti-pattern），而不是描述成情绪或心情。
5. 把重复出现或高影响的失败转化为下一轮的质量门（quality gate）。
6. 把含糊的用户方向转化为一个新 agent 能直接使用的架构词汇（vocabulary）。
7. 为本轮写下或刷新本地文档：一份 re0-memo 记录经验，一份 plan 记录下一轮的 contracts、gates 与 vocabulary。
8. 写完后验证：一个从零开始的 agent 仅凭这些文档就能避免同样的失败。
9. 不要为产出物辩护：如果它偏离了产品目标，就直接说清楚哪里偏了。
10. 不要写 changelog：文件清单和工时总结不是经验。
11. 不要把某条具体投诉原样抄成经验；只修被报告案例的经验会让人始终留在回路里，同一类失败会在没人指出处再次出现——要把每个具体问题升级到能覆盖整个类别的模式，报告者的原话只是证据，不是门禁。
12. 保留负面语料（negative corpus）：失败的路径也是训练数据。
13. 优先使用硬性 gate，而不是建议（advice）。
14. 引用本轮证据：目标、文件事实、QA 输出、截图、transcript、diff 或用户反馈。
15. 自检：如果下一个 agent 无法据此行动，它就还不是一条经验。
16. 把 provenance 保留在本地；交付出去的 artifact 不应叙述自己的伤疤。
17. 收尾前检查：每条经验都能追溯到本轮观察到的证据。
18. 收尾前检查：每个反模式都指出具体的失败模式以及能捕获它的 gate。
19. 收尾前检查：没有一条经验是伪装的单个报告案例——每条覆盖一个类别，引发它的具体条目作为证据挂在下面。
20. 收尾前检查：一个新 agent 无需读完整个旧会话，就能判断该保留什么、丢弃什么、先测什么。

适用边界 · 注意事项

• 本轮尚未结束、仍需继续推进 momentum 时——此时要的是继续做而不是复盘。
• 目标只是产出变更日志、进度汇报或情绪复盘时——这些不是经验沉淀。
• 缺少可引用的本轮证据（QA 输出、diff、截图、用户反馈等）时——写不出可行动的经验。