Plate 编辑器行为法栈重整（Reconsolidate Law Stack）：文档治理命令的触发时机、执行流程与后续刷新链路
【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate
导读
在 Plate 的 editor-behavior 工作流中，"法栈"（law stack）是指决定编辑器行为的一整套权威文档集合。随着每次实现批次、分支合并与外部证据更新的落地，这些文档之间极易出现标准、规范、协议矩阵、奇偶校验矩阵与审计文档互相漂移的矛盾。本文基于 reconsolidate-law-stack.md 展开，完整介绍"法栈重整"这一文档治理命令的适用时机、调用方式、输入输出、刷新清单与后续命令路由，并结合仓库中的法栈本体、命令包 README 与配套治理机制，说明它如何在两大操作车道上扮演"文档真相对齐"的收口角色。读完本文，你将掌握在何种信号出现时运行该命令、如何执行、产出什么、以及如何依据结果分流到证据刷新、批次重规划或批次启动等下一步动作。
一、背景：什么是"法栈"，为什么要重整
editor-behavior 文档目录被明确定义为"编辑器行为标准与覆盖度的真相对源"（source of truth），回答三个问题：决策模型是什么、我们希望什么样的行为、当前实际覆盖了什么。详见 docs/editor-behavior/README.md。
围绕这三个问题，仓库把权威文档拆成职责互斥的若干文件，每个文件只负责一类真值。法栈（law stack）即其中五份核心治理文档的集合，对应关系如下：
| 法栈成员 | 文件路径 | 承担的职责 |
|---|---|---|
| 标准 | markdown-standards.md | 权威方法论、参考池、决策规则、锁等级、偏差政策 |
| 规范 | markdown-editing-spec.md | 可读的行为规范（不变量、所有权规则、规范示例、已锁定的策略决策） |
| 协议矩阵 | editor-protocol-matrix.md | 穷举式场景矩阵（行级场景、权威来源、证据映射） |
| 奇偶校验矩阵 | markdown-parity-matrix.md | 功能家族级别的发布门禁（哪些已覆盖、哪些被推迟、哪些阻塞发布） |
| 参考审计 | markdown-editing-reference-audit.md | 外部参考证据（Typora / Milkdown 首轮审计、Obsidian 新证据） |
从 master-roadmap.md 的"真值所有权"表可以看到更完整的划分：法（law）由规范、协议矩阵、标准三份文档共同持有；门禁（gate）由奇偶校验矩阵持有；证据（evidence）由参考审计与docs/research持有；实施顺序（sequence）由 roadmap 与 commands 目录持有；历史执行记录归 2026-04-02-editor-behavior-major-execution.md。
之所以需要"重整"这个动作，是因为上述文档各自独立演进，任何一方更新都可能让其它文档失去同步。README 给出了一条实用规则：当两份文档看似在说同一件事时，规范对"法"拥有最终解释权，协议矩阵对"穷举场景"拥有最终解释权，奇偶校验矩阵对"发布门禁"拥有最终解释权——但这份裁决规则本身也需要有人去执行对齐，这正是 reconsolidate-law-stack 命令的职责。
二、所属车道与触发时机
所属车道
该命令属于doc-governance（文档治理）车道，同时被明确标注为"在实现/运行时批次改变了已发布行为之后"也会使用。也就是说，它既是文档维护的常规治理工具，也是运行时工作落地后的回填工具。
命令包 README（docs/editor-behavior/commands/README.md）把整个操作面划分为两条车道：
- doc-governance：维护标准、规范、协议、奇偶校验、审计与证据的真值；
- implementation/runtime：从 roadmap 中选择、启动并关闭真实的代码/测试/产品批次。
reconsolidate-law-stack 位于 doc-governance 车道，负责在真值漂移时重新同步标准/规范/协议/奇偶校验/审计整套栈，包括运行时工作改变行为后的同步。
何时运行（When To Run）
原文档给出四个明确的触发条件，任何一条成立都应运行该命令：
- 任何改变了 editor-behavior 真值的批次之后——批次落地后，文档必须跟着对齐；
- 任何让标准、规范、协议、奇偶校验或审计相互漂移的 pass 之后——五份法栈文档之间出现矛盾；
- 任何让 roadmap 或门禁状态与法栈不一致的分支合并之后——实施路线与文档真值脱节；
- 运行时/代码工作落地、但法栈尚未更新以匹配之时——代码先行、文档后补的间隙期。
从命令包 README 的快速路由来看，触发信号的判断逻辑是："文档彼此意见不一致"，或"运行时批次改变了行为而法栈没有跟上"，此时应首先从 reconsolidate-law-stack 开始，而不是直接去规划下一个实现批次。这体现了"先对齐真值、再安排执行"的治理次序。
三、调用方式（Invocation）
该命令的调用入口是一个面向 agent/operator 的命令字符串：
$editor-spec docs/editor-behavior law-stack reconsolidation三个参数段分别指定：操作主体（editor-spec 技能/工具）、作用目录（docs/editor-behavior）、具体动作（law-stack reconsolidation）。命令包本身的建设目标（见 2026-04-08-editor-behavior-commands-pack.md）是打造一套可复用的操作命令包，并将其接入本地文档与editor-spec技能，使后续 editor-behavior 工作能够主动使用它，而无需从散落的 plans、spec 文档与.omx工件中重新摸索工作流。
与之同属一族的命令还有各自独立的调用形式，供对比理解该命令在整个命令包中的位置：
- 证据刷新：
research-maintain editor behavior references（升级版research-full editor behavior references）； - 批次重规划：
$ralplan --consensus --direct docs/editor-behavior/master-roadmap.md； - 批次启动：
$ralph "Execute /absolute/path/to/approved-editor-behavior-lane-plan.md"； - 权威缺口重访谈：
$deep-interview --quick editor-behavior remaining authority gaps after latest batch。
四、输入（Inputs）：重整时以什么为准
运行 reconsolidate-law-stack 时，必须以法栈本体为基准进行对齐，输入包括：
- 五份法栈文档：
docs/editor-behavior/README.md（入口地图）、markdown-standards.md、markdown-editing-spec.md、editor-protocol-matrix.md、markdown-parity-matrix.md、master-roadmap.md、markdown-editing-reference-audit.md； docs/plans/下处于活动状态的执行记录（如 2026-04-02-editor-behavior-major-execution.md）；- 当矛盾来自实现工作时，还需要对应变更的运行时/代码/文档表面（the relevant changed runtime/code/docs surface）。
这里的输入设计隐含一个原则：重整不是重新发明真值，而是让五份文档回到彼此一致。矛盾可能来自文档内部漂移（标准更新了、规范没跟上），也可能来自外部实现（代码改了行为、文档没记录）。因此输入里既包含法栈自身，也包含执行记录与变更表面。
五、预期产出（Expected Outputs）：重整完成的判定标准
命令执行完毕后，应当产出以下四类成果，缺一不可：
- 刷新后的法栈，且矛盾已被移除——五份文档之间不再互相冲突；
- 刷新后的胜者地图（winner map）——如果权威归属发生了移动（例如某个场景的参考权威从 Typora 换成了 Obsidian），需要更新记录；
- 刷新后的当前门禁措辞——如果奇偶校验状态发生了变化（如某家族从
partial提升为locked），门禁文档的措辞要同步； - 刷新后的协议矩阵行——当可读的法（readable law）改变时，协议矩阵中对应的场景行要同步更新。
配合这些产出，奇偶校验矩阵自身的状态语义（见 markdown-parity-matrix.md）可作为"刷新到什么程度"的参考刻度：locked（足以支撑构建、不阻塞 major）、partial（功能存在但契约或覆盖仍薄弱）、gap（规格不足、有损或覆盖弱）、profile-divergence（功能可用但在严格 markdown-first 档案之外，仍需显式行为策略）、deferred-minor（不属于本次 major）。重整的目标之一，就是让每个家族都能被诚实标注到上述某一档，而不是停留在模糊措辞上。
六、运行后刷新清单（Refresh Afterward）
重整不是终点，命令完成后必须回写以下文档，确保"刷新"闭环：
docs/editor-behavior/README.mddocs/editor-behavior/markdown-standards.mddocs/editor-behavior/markdown-editing-spec.mddocs/editor-behavior/editor-protocol-matrix.mddocs/editor-behavior/markdown-parity-matrix.mddocs/editor-behavior/master-roadmap.md——仅在矛盾改变了实现排期或车道分诊时才需要刷新（注意这个条件限定）docs/editor-behavior/markdown-editing-reference-audit.md
与兄弟命令对比可以看出"刷新范围"的差异是刻意的：refresh-evidence-ledger 刷新审计与证据类文档，replan-next-batch 刷新 roadmap 与执行记录，而 reconsolidate-law-stack 的刷新面覆盖整条法栈 + 条件性的 roadmap。这与法栈文档结构清理（2026-04-03-editor-behavior-doc-structure.md）确立的职责划分一致：执行历史归docs/plans/，法栈文档只保留各自职责范围内的真值，删除过期的草稿语言，规范示例保留在 spec 而非家族积压清单中。
七、常见下一步（Common Next Step）：重整后的命令路由
原文档给出了三种典型分流，其选择依据是"矛盾从何而来"以及"下一步是否已经明确"：
| 场景 | 下一步命令 | 判定理由 |
|---|---|---|
| 矛盾由证据漂移引起（如参考审计过时、外部证据更新） | refresh-evidence-ledger.md | 先补证据，再回法栈 |
| 法栈已重新自洽，但下一批次仍不明确 | replan-next-batch.md | 用对齐后的真值重新规划下一个运行时切片 |
| 法栈已重新自洽，且下一运行时批次已获批 | launch-next-ralph-batch.md | 直接启动获批批次 |
这套路由与命令包 README 的快速路由逻辑完全呼应：文档治理问题从 reconsolidate 或 refresh-evidence 开始；权威问题无法由法栈回答时先走 reinterview-open-authority-gaps.md；权威清晰后需要下一个可执行切片时走 replan-next-batch；门禁已闭合但还需剩余积压顺序时同样走 replan-next-batch；批次获批且具体时走 launch-next-ralph-batch；而运行时工作一旦暴露法栈漂移、证据欠账或未决权威，应弹回文档治理车道，而不是强行推进更多代码工作。
从 launch-next-ralph-batch.md 的视角看，reconsolidate 是整个执行循环的"收口站"：批次启动完成后，如果批次改变了法律真值则运行 reconsolidate；如果暴露了证据欠账则运行 refresh-evidence-ledger；如果暴露了未决权威则运行 reinterview-open-authority-gaps；如果改变了剩余工作则运行 replan-next-batch。也就是说，reconsolidate-law-stack 既是文档治理车道的入口，也是实现/运行时车道每次闭环后的回填出口。
八、配套治理机制：重整时赖以判定"谁赢"的底层规则
要让重整真正消除矛盾而非各说各话，法栈底层还有一套完整的判定机制（记录于 markdown-standards.md），理解它们有助于在重整时做出正确取舍：
- 权威顺序（Authority Order）：语法规范 → 显式表面定义与节点模型 → 带真实证据的最强表面特定 UX 权威 → 可检查的交叉验证与最强相邻先例 → 仅在前者沉默或不兼容时才使用显式回退。重整时判断"某个场景应该听谁的"，必须按此顺序，而不是按家族标签默认。
- 表面优先规则（Surface-first）：具体表面、家族拆分或协议行应各自选择它能真正证明的最强权威。不同 markdown 扩展行落在不同参考（Typora / Obsidian / Google Docs / GitHub）上是正常的，不应强行为整个家族强加单一所有者。
- 锁等级（Lock Levels）：
draft（引用前框架）→audit（参考研究进行中）→proposed（可能决策、未锁定）→locked（已接受的靶向行为）→deviation（有意与参考不同）。重整时可将proposed升级为locked，但必须遵循研究方法的顺序：先锁架构与标准文档、按场景审计、标记冲突、添加以 spec ID 为键的失败测试、重构行为接缝、最后升级锁等级。 - 偏差政策（Deviation Policy）：偏差允许，隐藏偏差不允许。与 Typora / Obsidian / Google Docs / Notion / Milkdown 不同时必须记录 spec ID、场景、参考行为、Plate 行为、理由；语法正确性、文档模型安全、更好的多块一致性、流式稳定性、档案可组合性等是正当理由，而"插件本来就如此""改起来麻烦""已有测试""旧默认值"是不正当理由。
- 稳定 spec ID 方案：
EDIT（编辑行为）、PARITY（解析/序列化/往返奇偶校验）、STREAM（流式或增量 markdown 行为）、DEV（有意偏差），如EDIT-LIST-BACKSPACE-START-002、PARITY-GFM-TASKLIST-001。spec ID 同时是测试命名的锚点，最终目标是"从这些文档驱动 TDD"。 - 门禁状态语义：如前文所述，奇偶校验矩阵的
locked / partial / gap / profile-divergence / deferred-minor五档，是重整后给每个功能家族打标签的刻度。
九、写在最后：何时不该先跑重整
文档治理的目的是防止两个常见失败模式：把"markdown 支持"只当作解析与序列化；把编辑器行为等同于当前插件实现碰巧做出的样子。reconsolidate-law-stack 正是这两类漂移的矫正工具，但它不是万能入口。
按照命令包 README 的明确指引：如果问题是审计或研究过时、实现车道被薄弱证据阻塞，应优先运行 refresh-evidence-ledger；如果问题是法栈无法回答"这里谁该赢""下一步是什么""优先级该上移还是下移"，应优先运行 reinterview-open-authority-gaps 再进入规划。而一旦法栈重新自洽，就应立即通过 replan-next-batch 或 launch-next-ralph-batch 把真值转回执行，避免陷入无止境的文档维护循环——这正是整个命令包"两条车道、快速路由"的设计意图。
【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
