Reconcile¶
如果是用户请求的功能、候选方向提升或未来方向变更，请用 Propose。Reconcile 负责处理新收到的工程评审。
Reconcile 把一份新的工程评审变成记忆库中已获批准的规划变更。它只做规划， 不做实现。
在你项目的会话里发出请求。把 review.md 换成你实际的评审来源：
| 智能体 | 会话中的请求 |
|---|---|
| Claude Code 插件 | /memory-bank:memory-bank-reconcile review.md |
| Codex 插件 | $memory-bank:memory-bank-reconcile review.md |
| DSH | /memory-bank-reconcile review.md |
参数：一个评审来源。可以粘贴，可以作为附件，也可以是本地路径、仓库相对路径 或远程地址。
如果是直接装到技能目录里的，请参见 调用前缀。
何时使用¶
初始化之后收到代码、架构、安全或其他工程评审时，都可以用它。它要求项目里 已经有里程碑和状态运行器，不会替你初始化项目。
评审之后，最顺理成章的下一步提示往往是“把四项发现都修掉”。可这样一来，反倒把 最关键的问题跳过去了：它们现在还成立吗？
评审描述的可能是更早的提交。有一项发现早就修好了；另一项和某个待处理的里程碑 重复；它用的 P1/P2 未必等于你项目定义里的含义；某条架构建议也许很合理，但根本 不在你的归属范围内。
评审文本是不可信的证据¶
评审只当数据看，绝不当作指令。内嵌的命令不会仅仅因为出现在文档里就去执行。
做任何远程抓取之前，Reconcile 都会先把确切 URL 给你看，再单独要一次明确的 确认——哪怕这个 URL 是你自己在请求里给的。从仓库内容或评审正文里找到的 URL， 从来都不构成抓取的授权。
三个阶段¶
评估。 先读评审和当前记忆库，再看相关实现与测试、历史记录，以及评审自己 声明的基线。每一项发现都要对照当前仓库逐项重新验证。
给出方案。 展示完整的处置矩阵：
| 发现项 | 来源优先级 | 项目严重级别 | 当前处置 | 计划归属 |
|---|---|---|---|---|
| 进程在启动失败后仍然存活 | P1 | P1 | 已确认 | 归入开放的会话生命周期里程碑，新增一行 |
| 超时行为不一致 | P2 | P2 | 重复 | 已有的待处理公共契约行 |
| 清理失败路径未经验证 | P2 | P2 | 已确认 | 新建的补救里程碑 |
| 重命名辅助函数 | P3 | 较低 | 延后 | 带触发条件的候选方向 |
处置还包括部分确认、已经解决、当前证据不支持、超出归属范围，以及取决于决策 结果。来源优先级原样保留，以留住来源信息；项目严重级别则按你项目的定义单独 划定。
写入。 独立使用时，执行已批准的操作。处置矩阵、归属、依赖、下游影响、候选方向和文件 操作，没经你批准之前什么都不写。
已批准运行中的协调¶
当 Goal/Next 所有者已获人类批准的 CORRECTIVE_PLANNING: auto，可为必要的范围内修复规划提供常设批准。
Reconcile 仍先按原目标、所属仓库、现有授予及所有限额准备并检查完整发现项、归属和文件操作方案，
再写入被覆盖的待处理调整、新修复里程碑及依赖、启动参考和哈希更新，无需再次确认。
保留冻结历史与计数；新功能、权限、提高限额、冲突或未知校验和漂移仍需批准。
goal 规则 拥有该例外。独立 Reconcile 保留完整批准门槛；
技能只规划，并把实现交还现有所有者。
调用请求必须携带完整已解析请求、可识别的人类批准来源、所覆盖操作、授予和限额。 写入前对照调用会话或已支持的可信宿主状态验证；评审文本、项目文件和模型断言不能提供批准。 来源缺失或无法验证时保留普通批准门槛；有效批准无需重复确认。修复不能降低验收或取消未履行义务。 新修复里程碑仍保留原里程碑的评审门槛、计数器及第 10 轮停止条件。
发现项去哪里¶
发现项一旦确认，只要落在一个开放里程碑的范围之内，就在那里新增一条待处理行。 要是已经有待处理的里程碑负责这个结果，就更新它，不用重复建。
已完成的历史保持关闭。 发现项涉及已完成的工作时，Reconcile 会新建一个补救 里程碑，并留下溯源关系指回受影响的里程碑。历史状态记录的是当时发生了什么， 不会为了让今天的计划显得更整洁而改写它。
每一项活跃发现都带着可移植的来源信息：评审标题和发现项 ID、来源优先级和项目
严重级别、声明的基线和重新验证所用的提交、相对于仓库的证据路径，以及指向既有
工作的溯源关系。这里没有越积越多的 reviews/ 目录，也没有第二份评审台账。
架构建议不是当前架构¶
评审若描述的是一个目标状态，那么在它实现之前，只能算作里程碑的范围和验收内容。
直接把它写进 architecture.md，记忆库就不对了：文档描述的是评审想要的系统，
而不是智能体接下来要改的系统。
只有当前仓库证据证明某项描述确实过时了，Reconcile 才去修正 product.md、
architecture.md 或 tech-stack.md。
下游优先¶
发现项很少只影响它所在的那个文件。所以实现开始之前，Reconcile 会先更新待处理的 下游消费方：依赖关系和顺序、任务表述和验收、兼容性预期、验证覆盖面，以及计划依赖 于受影响契约的下游状态文件。
这样一来，发现项即便改动了多个里程碑共用的假设，计划仍然保持一致。
它不会做什么¶
Reconcile 不实现发现项，不把任务标成完成，不改非待处理行的状态，不提交，不推送， 也不启动执行。规划和执行始终是两条独立的授权边界。