reconcile

整合

你是整合后事实的唯一明确写入者——audit → reconcile → close 衔接中的写入环节。Audit 会识别变更并整理整合简报；你接收简报、写入变更，并记录完成的事项。Close 会在终止转换前确认结果。

你通过不同机制写入两个界面：

界面	机制
每个切片的制品（design.md、slice-NNN.md）	经用户同意后直接编辑
治理／规范事实（ADR、规范、需求、政策、标准）	REV 类型（doctrine revision）——使用类型化的 [[change]] 行、审批检查点和应用路径

.doctrine/ 之外的项目本地文档不是 Doctrine 功能类别——像任何项目文件一样直接编辑，和每个切片的制品相同。

一次整合过程可以同时使用这两个界面——例如，直接更新 design.md，并且为 ADR 修订编写 REV。每项变更应写入哪里，由整合简报决定，而不是靠猜测。

简报条目可能指定你无法写入的界面。 plan.toml 条件（EN-/EX-/VT-、PHASE-NN）为只追加且不可变（启动规则）——不是整合界面。如果简报条目要求你编辑计划条件，请不要这样做；将其退回 /audit 或 /consult，作为设计／计划升级处理。符合性／“虚假未交付”条目则应通过选择器注册表（doctrine slice selector rm/add）修复——这是起决定作用的操作——而不是只编辑 design.md §6 文本（§6 只是镜像；slice conformance 会读取 slice-NNN.toml 中的注册表）。只编辑文本，符合性仍会显示为未通过。

没有 CLI 动词界面。 doctrine slice reconcile 尚未实现（已延期）。你需要将现有动词（doctrine revision *、直接编辑文件）作为手动规范来执行——与当前 /audit 的做法相同。

检查，不要重新审计。 你要检查目标制品，以验证适用性、定位编辑点并发现自 audit 以来的偏移——但不要进行新的问题发现。如果发现简报中没有的新缺口，不要在此处新建发现项；将其退回 /audit 或提交给 /consult。衔接保持完整：audit 负责发现，你负责写入。

输入：

• RV 台账——review-NNN.toml（发现项状态）+ review-NNN.md（审查 Markdown 文件，包含整合简报）

• review-NNN.md 中的 ## Reconciliation Brief 部分——来自 audit 的结构化交接。它将发现项映射到目标制品，并分为每个切片（直接编辑）和治理／规范（REV）条目。其结构如下：

  ## Reconciliation Brief
  
  ### Per-slice (direct edit)
  - design.md §3: the eviction model changed … update prose
  
  ### Governance/spec (REV)
  - ADR-NNN: branch-point staleness description is wrong → REV modify
  - REQ-NNN: cordage scale target verified at 50k nodes → REV status active
  

简报位于专门的部分中，与 ## Synthesis（audit 的收尾说明）分开。

面向用户的整合说明

对于影响重大的拟议变更，在请求现有确认或 REV 审批之前，应清楚说明当前内容、拟议内容以及对后续工作的影响。提供足够的背景信息，以便判断这项变更；对于影响重大的 Doctrine 来源，还要提供确切的 doctrine <kind> show <ID> 命令。如果有帮助，可以提出用 /walkthrough 逐段讲解内容及其影响；关于剩余风险或意图的回答可能会改进提案，因此应将其纳入写入内容。这与下方的确认流程配合使用：不要增加第二个接受环节，也不要要求用户证明自己理解了变更。遵循项目默认的沟通方式，并尊重用户口头提出的修改。

流程

1. 读取输入

阅读 review-NNN.md 中的 ## Reconciliation Brief 部分。使用 doctrine review show RV-NNN --open 查看发现项状态——确认每项发现都已终结（verified / withdrawn；索引显示 findings: 0 of N），且审查轮次已结束（doctrine review status RV-NNN 显示 done · await=none）。如果仍有发现项处于 open / answered / contested 状态，或审查轮次尚未结束，则审计未完成——停止并交回 /audit。

发现项保持为 verified——由你单独记录修复情况，绝不通过修改发现项处置状态来记录。记录 RV id 和你将处理的简报条目。

2. 无操作关卡

如果协调简报为空——所有发现项都已撤回或容忍，且无需写入任何内容——在 review-NNN.md 中追加一个 ## Reconciliation Outcome 部分，确认无需操作，然后移交给 /close：

## Reconciliation Outcome

All findings were withdrawn or tolerated with rationale. No writes needed.
Reconcile pass complete — handoff to /close.

3. 按切片编辑

对于简报中的每个直接编辑项：

• 向用户展示拟议的编辑。展示确切位置、旧文本和新文本。获得确认后再写入。
• 写入 design.md 和/或 slice-NNN.md（如果实现过程中范围发生变化）。
• 记录编辑内容及促成该编辑的发现项，并持续更新协调结果。你将在第 6 步将其追加到 RV Markdown 文件中。

4. 编写 REV

对于简报中的每个治理/规范项，编写一项 REV 变更。默认情况下，每个切片中的多个治理项可以合并到同一个 REV 中（一项 reconcile SL-NNN REV，包含多行 [[change]]），如果各项需要单独讨论，也可以拆分为多个 REV（参见下方拆分规则）。

4a. 查找或创建 REV

如果简报记录了 REV id，则使用它：

doctrine revision show REV-N

否则，按惯例创建：

doctrine revision new "reconcile SL-NNN" --slug reconcile-sl-NNN

REV 初始状态为 proposed，且不含任何变更行。添加行之前，将其转换为 started：

doctrine revision status REV-N started

4b. 冲突防护

如果 reconcile-sl-NNN slug 已存在，先检查再复用：

doctrine revision show REV-N

• 如果相关（同一切片、同类变更）→ 复用它；追加新的 [[change]] 行。
• 如果无关（不同切片，或意图不同但 slug 冲突）→ 创建不同的 slug，或询问用户如何决定。不要悄悄将无关变更混入同一个 REV。

4c. 添加 [[change]] 行

对于每个治理/规范项，追加一行带类型的记录：

doctrine revision change add REV-N --action <action> [--target <T>] [--to-status <S>] [--new-label <L> --member-of <SPEC>] [--primary]

--action 的取值及其标志请参阅 doctrine revision change add --help。

哪些 --action 的取值会自动落地、哪些会转为手动落地，请参阅 doctrine revision apply --help。

4d. 记录协调说明

将协调理由写入 revision-NNN.md——说明变更内容、原因，以及指向促成该变更的 RV 发现项的链接。示例：

## Reconcile narrative

- [RV-NNN finding F-3]: the branch-point staleness description was wrong.
  Updated to match the CAS row semantics from the coordination slice.
- [RV-NNN finding F-5]: the scale requirement verified at 50k nodes. Status moved to `active`.

4e. 拆分规则

如果已知某行需要单独讨论，或不会在本轮落地，则必须在批准/应用之前将其拆分到单独的 REV 中。不要创建半应用的综合 REV，以免某一行受阻而导致无法关闭。REV 在所有行都落地之前会一直保持 started 状态——综合 REV 中受阻的一行会阻塞整个切片。

5. 批准并应用

写入所有 [[change]] 行并完成说明后：

doctrine revision approve REV-N
doctrine revision apply REV-N

• approve 记录独立批准——没有它，apply 会拒绝执行 （不区分调用者：独立开发者会自行批准）。
• apply 会自动落地 status 行，并将 modify / create / introduce / move / retire / prose 行转为手动落地。预检中的 from-guard 如果发现自拟定变更以来任何目标都已变动，则会中止整个 apply——如果触发此情况，请重新检查受影响的目标并重试。
• 记录哪些行已自动落地，哪些行已转为手动落地。

6. 手动落地文字内容

对于标记为需手动处理的行，请按照尊重作者真实意图的模型手动进行编辑。REV 会告诉你要改什么；你需要实际编辑文件。

所有标记的行都已落地后：

doctrine revision status REV-N done

然后在 RV 中记录对账结果。在 review-NNN.md 中追加一个 ## Reconciliation Outcome 章节：

## Reconciliation Outcome

### Direct edits applied
- design.md §3: updated eviction model prose → matches implementation (finding F-2)

### REVs completed
- REV-NNN (`reconcile-<slug>`): done — the staleness description amended, REQ-NNN → active
  (covers findings F-3, F-5). Rationale in revision-nnn.md.

### Withdrawn / tolerated
- Finding F-4: tolerated — drift in error message wording; rationale in finding disposition.

7. 升级门槛

如果在对账过程中发现模型本身并不完善——不是单纯的实例偏差，而是存在设计缺陷，导致无法通过此次更改表达所需内容——请升级回设计阶段：

doctrine slice status <id> design

这是设计回边：reconcile → design。在备注中（使用 --note 标志）说明模型的不足，以及设计需要解决的问题。不要擅自提出治理设计不支持的修复方案。

所有事项解决且结果已记录后，移交给 /close。

结果

• 对账说明中的每个治理／规范事项均已解决：由标记为 done 的 REV 覆盖、在 RV 中说明理由后撤回、在 RV 中说明理由后接受，或升级至设计阶段。
• 每个切片的直接编辑事项均已应用到目标文件。
• RV 包含 ## Reconciliation Outcome 章节，记录已完成的工作及其原因。
• 每个 REV 都在其 revision-NNN.md 中包含对账说明。
• 切片已准备好进入 /close：所有事项均已解决；没有尚未完全应用的 REV 阻碍关闭门槛。