用途：在版本发布、组件迁移或弃用完成后，对照原计划复盘实际执行情况，补齐治理闭环，沉淀可复用的经验，避免团队更替后重复同类错误。强调这是学习性产物而非追责。
主要能力：围绕五个维度逐项对比计划与现实——影响范围（受影响团队与实例数）、沟通（渠道与实际触达证据）、迁移路径（codemod 与手工步骤）、时间线（里程碑日期）、支持负担（问题模式分类）。每处偏差标注为可预见（分析不完整）、不可预见（重组、平台变更、安全事件等新情况）或流程（分析正确但执行走样）。输出结构化复盘报告，含摘要、计划与现实对照表、做得好与不好的地方、带负责人和期限的改进建议、决策记录更新，以及范围说明。
使用方式：先收集原始计划文档与执行数据；在仓库可达时先用 git 与搜索测量，例如用 git tag --list --format='%(refname:short) %(creatordate:short)' 获取实际发布时间，用 rg 搜索旧组件、token 或 prop 统计仍在使用旧 API 的引用数，并与计划基线提交对比得出迁移完成情况，用 git log --since=<announcement> --oneline -- <consumer paths> 查看各消费方迁移时间。随后按维度填写模板并撰写报告。
限制：所有数字必须来自计划、工具结果或用户，缺失维度写“not measured”，不得估算触达率或完成百分比；不得凭记忆重建计划；支持负担等仓库无法体现的数据需用户提供。若引用文件缺失（如安装器丢弃了 knowledge-notes/ 目录），应停止并提示按 1-INSTALL.md 重装并运行 verify-install.sh，除非用户明确同意在无参考资料下继续。小型发布可压缩为一页。