用途
Brownfield Retrospective 用于对一个在未采用 ECC 流程的情况下构建的项目，追溯性地运行 ECC 工程流程。它选取现有代码库的任意一个切片，审计现状，重建其形成过程中的决策，提炼出四轴差距登记表，然后通过标准 ECC 流水线向前执行修复。
该工作流以切片为先：在发挥作用前无需先完成整个仓库的入门梳理，且每个阶段都可以从磁盘上的持久产物重新进入。可以从中间开始，向后推进，再向前推进。
主要能力
- 现状审计：对切片进行勘察（manifest 与框架指纹、入口点、测试布局、CI 检查），并行运行与栈匹配的审查器，每项发现都携带 file:line 指针；快照测试数量与覆盖率、lint/CI 状态、TODO/FIXME/HACK 清单。
- 向后重建：运行 spec-miner 挖掘行为规格（WHEN → THEN 与不变量），对边界范围做 git 考古，盘点固化在代码中的重大决策。
- 四轴差距分析：思考（决定过但未记录的内容）、编码实践、缺失功能、技术选型四类差距，各自转换为登记表行。
- 重新设计：对 P0 与 P1 行运行 architect 或 code-architect 产出目标设计，回填重构 ADR，将每行归类为就地修复、重写或保留并记录。
- 前向执行：按标准 ECC 流水线逐行推进，登记表状态是持久状态而非对话。
- 闭环与重审：全部完成后重新运行第 1 阶段审计并比对基线，记录增量。
工作方式（阶段）
阶段 0 — 选择入口点：从用户当下关心的事开始，不先梳理整个仓库。切片可以是目录/模块/服务、功能或用户流程、bug 或事故、依赖或技术选择；若用户未指定，则提出 2-3 条变更最频繁的热路径供其选择。在任何事之前先把边界记录在 gap-register.md 顶部：范围内的路径、入口点、调用方、影响半径。建议将切片控制在约 15 个文件或 2,000 行以内，超出则切分为命名的子切片。在边界旁保留 Current phase: 标记并在每阶段完成时推进。
阶段 1 — 现状审计：确立当前存在的内容并附证据，此阶段不做修复。运行与栈匹配的审查器（如各语言审查器、security-reviewer、silent-failure-hunter、type-design-analyzer，仅当切片处于热路径时才用 performance-optimizer）。将所有内容写入 baseline-audit.md。
阶段 2 — 向后重建：从当前状态反向推导产生它的决策。用 spec-miner 挖掘行为规格形成 reconstructed-spec.md；对边界做 git 考古（目录历史、体量最大与回滚最多的提交、变更热点、死胡同分支）；盘点固化在代码中的重大决策并与 docs/adr/、README 及注释核对。行为不透明处使用 code-explorer 追踪执行路径。
阶段 3 — 差距分析（四轴）：将审计与重建转换为登记表行，每行需要证据指针。登记表格式为：ID、Axis、Gap、Evidence、Forward fix、Severity、Effort、Status。严重度：P0 安全暴露或数据丢失，P1 正确性，P2 实践与可观测性，P3 选型与清理。工作量：S 一个会话内，M 数个会话，L 需要自己的计划。状态：open、in-progress、done、wont-fix。
阶段 4 — 重新设计：将登记表变成有序计划。遵循项目现有的任务与审批权限，登记表保持为审计证据，不创建竞争性的规范任务状态。在重写、替换技术、迁移或其他实质变更前，确认范围并获得项目要求的批准。对 P0 与 P1 行产出 target-design.md，回填重构 ADR（标记为 proposed (reconstructed)，注明原始决策早于记录，区分观察到的历史与推断的意图，经项目所有者确认后方可标为 accepted，绝不将回填 ADR 呈现为决策当时所写）。将每行分类为 fix-forward、rewrite 或 leave-documented，wont-fix 必须记录原因。
阶段 5 — 前向执行：按标准 ECC 流水线推进：planner（界定该行范围）→ tdd-guide（先写失败测试）→ 实现 → code-reviewer → security-reviewer（如触及输入、认证或数据）→ doc-updater + ADR（如决策变更）→ 约定式提交 → 标记该行完成。
阶段 6 — 闭环与重审：当所有行完成或 wont-fix 后，对同一范围重跑阶段 1 审计，与 baseline-audit.md 比对并用 verification-loop 验证，将增量记录在 gap-register.md 底部；重新出现的项成为新行。
使用方式
当在已存在且已成形的仓库中采用 ECC 时激活。用户要求“审计我的现有项目”“复盘这个代码库”或“我们漏掉了什么”，接手、继承或长期未接触后回归某代码库，询问“为什么是这样”继而问“应该保持这样吗”，某模块/功能/服务需在下个功能叠加前重新思考，或需判断某遗留区域应当就地修复、重写还是保留并记录时适用。
产物写入被审计项目 docs/retro/<slice>/ 下：gap-register.md（阶段 0-6，唯一恢复所需文件）、baseline-audit.md（阶段 1）、reconstructed-spec.md（阶段 2）、target-design.md（阶段 4）。回填决策写入 docs/adr/。若项目使用 OpenSpec，reconstructed-spec.md 可能改为 spec-miner 产出的 openspec/specs/<capability>/spec.md。
中途恢复：先读 docs/retro/<slice>/gap-register.md。存在登记表且有行 in-progress → 阶段 5；存在且所有行已关闭 → 阶段 6；存在、行开放且无进行中 → 从 Current phase: 标记恢复；无登记表但有 baseline-audit.md → 阶段 2；无任何产物 → 与用户一起进入阶段 0。
适用场景
- 在既有仓库中引入 ECC 工程流程。
- 接手、继承或长期后回归代码库。
- 在既有模块上叠加新功能前的重新思考。
- 判断遗留区域应就地修复、重写还是保留并记录。
限制
不适用于：无既有代码的全新项目（直接用 planner 与 tdd-workflow）；仅需规格驱动开发入门而不含重新设计循环（spec-miner 独立完成）；上线 go/no-go 的生产就绪检查（用 production-audit）；仅安全扫描（用 security-review）；团队流程复盘（冲刺仪式）——它审计代码库，而非人。
反模式：在任何切片前审计整个仓库；在阶段 1-3 期间修改代码（会破坏基线）；无证据指针的登记表行；无记录原因的 wont-fix；将回填 ADR 呈现为同期记录；跳过阶段 6 重审。
相关技能：codebase-onboarding（阶段 1 勘察基线）、architecture-decision-records（阶段 4 回填重构 ADR）、tdd-workflow（阶段 5 执行纪律）、verification-loop（阶段 6 闭环）、production-audit（上线就绪视角，后续补充）、security-review（仅安全请求）。