| name | development-retrospective |
| description | 通用开发生命周期的「复盘与沉淀」阶段 owner；在任务终止前轻量判断经验是否值得持久化，重复、可复用或高影响问题才正式展开，不负责继续实现或默认新增规则。 |
Development Retrospective
目标
回答“这次工作是否产生了能让以后做得更好的经验”。每个开发任务结束前做一次轻量判断；没有信息增量时直接结束，不制造规则、测试和文档噪声。
轻量复盘
检查：
- 最初目标和成功条件是否准确；
- producer、owner、boundary、consumer 判断是否正确；
- 方案和实际交付是否一致；
- 是否发生返工、误判、无效调查、重复验证或错误路由；
- 下次能否用更短路径取得同等可信度；
- 当前任务是否其实尚未完成。
当前任务未完成时返回对应返工阶段，不用“后续优化”掩盖缺口。
正式沉淀门槛
同时判断：
- 这是重复问题、系统性缺口或高影响单次事件吗？
- 现有 owner 本应阻止它却没有阻止吗？
- 改进能覆盖一类问题，而不只是当前文件或一句反馈吗？
- 新机制的触发成本和误报是否低于问题损失？
任一答案不足时修正当前任务即可，明确“不新增规则”。
根因层次
- 表层症状：用户或系统看到了什么；
- 直接触发：哪一步判断或执行出错；
- 结构根因：owner、路由、合同或验证为何允许它发生；
- 机制缺口：现有规则是缺失、重复、过宽、触发不到还是不可执行。
经验抽象层级校准
沉淀经验时从本次实例逐层上移，停在“最高但仍可执行”的层级：它应覆盖多个共享同一机制的相邻 case，同时能直接改变下一次设计、实现、验证或评审中的具体决策。
- 实例层只用于保存证据；若经验仍依赖本次功能名、文件名或偶然现象，继续寻找其共同机制。
- 模式层说明哪些相邻 case 因同一 owner、边界、不变量或失败条件而同类；这是形成通用经验的起点。
- 原则层必须能指出触发条件、要改变的决策、阻止的错误路径和不适用边界；满足这些条件时优先停在这一层。
- 口号层无法导出具体行动或反例边界；若只能表达“保持一致”“提高质量”等普遍正确结论，说明抽象过度，必须下沉。
正式落盘前用四个问题校准：它能否覆盖至少一类相邻场景；未来遇到什么信号会触发它；它会让执行者改变哪一个选择或检查；在哪些场景下不适用。缺少任一答案时，不把它当作长期经验。不要把单个实例改写成窄规则，也不要把多个实例稀释成无法执行的哲学命题。
持久化路由
- 产品想法、设计、计划、PRD、路线图和普通项目知识：
project-knowledge-governance；
- 重要交付、跨模块长链路、重大根因、红区或大型治理批次：
nextclaw-iteration-log-governance；
- 已确定需要修改 AGENTS、commands、skill、reference 或治理脚本：
nextclaw-agent-instructions-governance；
- 稳定行为回归风险：优先自动化测试；
- 高信号、低误报、可确定执行的问题：扩展已有通用 script；
- 没有复用价值的一次性经验：不落盘。
规则更新优先删除、合并、收窄或修正现有 owner；只有不存在稳定 owner 时才新增 skill。能由测试或 script 确定解决的问题，不重复追加自然语言。
输出
说明是否需要沉淀；命中时说明重复模式、证据、现有 owner 为什么失效、选择的单一落点和验证方式；未命中时明确不落盘。
本阶段不默认继续修改实现，不把每次任务摘要写进 docs/logs，也不把用户可见 release notes 当作内部复盘。
