第 4 课

决策并修订

受支持的修订器，把一个发现项跟一种确定的修改连起来。它能创建提议，但提议只是一份只读说明——精确的编辑动作和对应的回退动作，仅此而已。

学完这一课

你要搞懂：提议还不是真正的修改、批准和拒绝各有各的价值、已批准的修订版怎么跟当初的证据保持关联。

诊断说：有个固定规则命中了。受支持的修订器说：项目知道一种有边界、结果确定的办法来处理它。但它不要求你非改不可。

比如 D009 映射到 R001——归一化受支持的行尾字符和水平空白。这个映射很具体，不给你开放式编辑器，也不让程序自己去发明改法。

text

发现项 -> 受支持的修订器 -> 提议 -> 明确的决策
                                  -> 批准 -> 已准备修订版
                                  -> 拒绝 -> 只留证据

提议把可能的修改摆在你面前，但还没真正发布。先看改动前后的对比。空白字符方面，工作台会把不可见字符渲染成可见的，这样空格、制表符、行尾符不会看起来一样。提议里可能不止一处编辑，用位置控件逐个检查，同时别忘了它们来自同一个发现项、同一个修订器。

工作台和命令行都一样，只给两个互斥的选项：

持久化的修订决策，是唯一的结构化决策权威。页面状态、提议状态、 HTTP 响应、转换状态——这些都不算数。

批准不是"程序干了什么我就认什么"。是你审完一个有边界的提议之后，明确做出的选择。拒绝也不是失败——它记录了"考虑了，但不改"，原始文档和证据都保留着。

已批准的修订版，记录父版本、精确应用的编辑、改前改后的哈希、正向推导和可逆证据。它是个后继版本，不是覆盖。之后你还可以拿它再跑一轮诊断。

工作台在修订版阶段把它展示成一段简短历史，而不是"旧文档没了"。选历史准备轮次时，它依然是只读、可查的。只有最新批准的修订版，才能开始新一轮的诊断-修订-修订版循环。

从 whitespace-cleanup.md 的 D009 继续。看一眼受支持的修订器，点创建提议，读完整个可见空白字符对比。主面板现在显示的是提议 ——文档还没真改。

选批准或拒绝，然后点记录决定。

不管选哪条，都用检查器对比一下：现在已发布的内容，跟你做决定之前临时看到的东西，有什么不同。

常见误解

别去编辑提议文件。生成修订记录前，系统会验证精确的规范提议和绑定的标识，对不上就不通过。

记住

发现项指出问题。提议把受支持的改法亮出来。只有明确的已记录决策才能产生修订版，而且只有批准才会产生。