development-retrospective

name	development-retrospective
description	通用开发生命周期的「复盘与沉淀」阶段 owner；在任务终止前轻量判断经验是否值得持久化，重复、可复用或高影响问题才正式展开，不负责继续实现或默认新增规则。

Development Retrospective

目标

回答“这次工作是否产生了能让以后做得更好的经验”。每个开发任务结束前做一次轻量判断；没有信息增量时直接结束，不制造规则、测试和文档噪声。

轻量复盘

检查：

• 最初目标和成功条件是否准确；
• producer、owner、boundary、consumer 判断是否正确；
• 方案和实际交付是否一致；
• 是否发生返工、误判、无效调查、重复验证或错误路由；
• 下次能否用更短路径取得同等可信度；
• 当前任务是否其实尚未完成。

当前任务未完成时返回对应返工阶段，不用“后续优化”掩盖缺口。

正式沉淀门槛

同时判断：

1. 这是重复问题、系统性缺口或高影响单次事件吗？
2. 现有 owner 本应阻止它却没有阻止吗？
3. 改进能覆盖一类问题，而不只是当前文件或一句反馈吗？
4. 新机制的触发成本和误报是否低于问题损失？

任一答案不足时修正当前任务即可，明确“不新增规则”。

根因层次

• 表层症状：用户或系统看到了什么；
• 直接触发：哪一步判断或执行出错；
• 结构根因：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 当作内部复盘。