企业官网建设流程全解析

Plate 编辑器行为 Command Pack 双车道模型：文档治理与实现/运行时批次的分流指南

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate

导读

本文围绕 Plate 仓库中docs/editor-behavior/commands/命令包的“双车道”（two-lane）重构展开：该命令包将原本只服务于规范文档维护的操作面，重塑为同时支撑**文档治理（doc-governance）与实现/运行时（implementation/runtime）**两条工作流的标准入口。读完本文，你将掌握五条操作命令的触发时机、调用语法、输入输出与后续流转，理解“法律栈（law stack）—路线图（roadmap）—证据层（evidence）—OMX 工件”之间的真值归属关系，并能直接复用这套模式来恢复或推进 Plate 编辑器行为车道。

一、背景：从“只维护文档”到“双车道操作面”

1.1 命令包为什么存在

docs/editor-behavior目录是 Plate 仓库中“编辑器行为标准与覆盖率”的真值来源（source of truth），用于回答三个问题：决策模型是什么、想要什么行为、当前实际覆盖了什么。当开发者在大量分散的计划、规范文档和.omx工件中迷失时，命令包就是“无需重新发现工作流”的恢复入口。

但正如 2026-04-10-editor-behavior-command-pack-two-lanes.md 所指出的，命令包在引入初期（见 2026-04-08-editor-behavior-commands-pack.md）存在严重倾斜：README.md、replan-next-batch.md、launch-next-ralph-batch.md仍偏向“文档导向”的表述，或仍路由到旧的 major-artifact 计划，读起来像“只为维护规范文档而存在”。

1.2 双车道模型的核心目标

重构后的期望结果是：命令包在以下两类工作之间干净地分流：

• 真值维护（truth maintenance）：跨 standards / spec / protocol / parity / audit 五层文档的一致性维护；
• 执行规划与运行时/代码批次：来自路线图车道的执行规划与真实代码/测试/产品批次推进。

关键判断依据来自三个“已知事实”：

1. 剩余的规范性工作车道集中在 master-roadmap.md（它是编辑器行为实现序列的规范路线图）；
2. README.md、replan-next-batch.md、launch-next-ralph-batch.md存在旧路由残留；
3. 命令包最初由 2026-04-08-editor-behavior-commands-pack.md 引入。

1.3 发现与计划编辑

重构前的排查发现：

• reconsolidate-law-stack.md与refresh-evidence-ledger.md已经读起来像文档治理命令；
• replan-next-batch.md应当成为“从文档真值到具体实现/运行时车道选择”的桥梁；
• launch-next-ralph-batch.md应当与车道无关（lane-agnostic），指向当前已批准的实现工件，而非旧的 major 计划。

据此安排了四项计划编辑：收紧命令包 README 明确双车道模型、重写replan-next-batch.md作为真值维护到实现车道的交接、重写launch-next-ralph-batch.md使其适配任意活跃实现车道、修补相邻命令文档中仍暗示“仅文档”面的路由表述。重构的最终验证方式为：回读已编辑的命令文档，并 grep 命令包中残留的单车道措辞。

二、命令包总览与双车道划分

commands/README.md 是命令包的操作面入口，明确声明两条车道：

两条车道共享同一批规范工件（canonical artifacts），但读取与更新的侧重点不同。

2.1 规范工件（Canonical Artifacts）

命令包 README 将工件分为四类：

• 法律栈（law stack）：
  • markdown-standards.md（权威方法论）
  • markdown-editing-spec.md（规范性行为规范）
  • editor-protocol-matrix.md（穷举场景矩阵）
  • markdown-parity-matrix.md（家族级覆盖门禁）
  • markdown-editing-reference-audit.md（参考证据审计）
• 活跃执行笔记：2026-04-02-editor-behavior-major-execution.md、2026-04-03-editor-protocol-matrix-completion.md
• 规范剩余实现路线图：master-roadmap.md
• 活跃支撑实现计划：2026-04-10-math-delimiter-trigger-implementation-plan.md、2026-04-10-autoformat-runtime-alignment-and-extension-plan.md、2026-04-09-date-media-expansion-consensus-plan.md

此外还保留了历史 OMX 工件（prd-editor-behavior-major.md、test-spec-editor-behavior-major.md、deep-interview-editor-behavior-major.md），它们仅作为历史上下文，不再承担活跃队列职责。

2.2 真值归属（Truth Ownership）

master-roadmap.md 用一张真值归属表划清了每类信息的“所有权”：

同一份 README 还给出了“实践规则”判定冲突优先级：spec 赢法律、protocol matrix 赢穷举场景、parity matrix 赢发布门禁——这是文档治理车道仲裁真值矛盾的裁决基准。

三、文档治理车道（Doc-Governance Lane）

文档治理车道包含三条命令，解决“真值漂移”“证据陈旧”“权威悬而未决”三类问题。

3.1 reconsolidate-law-stack：重固法律栈

• 车道归属：doc-governance；实现/运行时批次改变了已交付行为后同样需要调用。
• 触发时机：任何改变编辑器行为真值的批次之后；standards / spec / protocol / parity / audit 之间出现漂移；分支合并导致路线图或门禁状态与法律栈不一致；运行时/代码工作落地而法律栈尚未跟进。
• 调用语法：

  $editor-spec docs/editor-behavior law-stack reconsolidation

• 输入：docs/editor-behavior/README.md、法律栈五件套（standards / spec / protocol / parity / audit）、master-roadmap.md、docs/plans/下的活跃执行笔记，以及引发矛盾的已变更运行时/代码/文档面。
• 期望输出：消除矛盾后的法律栈；权威（winner）变化时刷新 winner map；奇偶性（parity）变化时刷新当前门禁措辞；可读法律变化时刷新 protocol 行。
• 事后刷新：法律栈五件套 + master-roadmap（若矛盾改变了实现排序或车道分诊）+ audit。
• 常见下一步：若矛盾源于证据漂移 → 运行refresh-evidence-ledger；若法律栈已一致但下一批次仍不明确 → 运行replan-next-batch；若法律栈已一致且下一运行时批次已批准 → 运行launch-next-ralph-batch。

3.2 refresh-evidence-ledger：刷新证据账本

• 车道归属：doc-governance；当证据成为阻塞项时作为实现/运行时车道的支撑车道。
• 触发时机：audit 感觉陈旧；有新的外部参考（reference）通道落地；法律栈存在可能已被已编译研究回答的gap/partial/tension行；运行时批次暴露了薄弱权威、淡薄的产品压力或站不住脚的 winner 声明。
• 调用语法——默认（编译覆盖度足够时）：

  research-maintain editor behavior references

  升级（编译覆盖过薄或过旧时）：

  research-full editor behavior references

• 输入：docs/research/README.md、docs/research/commands/maintain.md、docs/research/commands/full-pipeline.md、docs/research/sources/**、docs/research/entities/**、docs/research/systems/**，以及 markdown-editing-reference-audit.md。
• 期望输出：安全范围内刷新已编译研究；刷新审计历史与缺口笔记；明确记录证据变化而不是伪造确定性；给出法律文档是否需要重固化的明确信号。
• 事后刷新：audit；若权威移动则刷新 standards；若可读法律移动则刷新 spec；若场景行移动则刷新 protocol matrix；若门禁状态移动则刷新 parity matrix；若证据变化改变实现优先级或车道分诊则刷新 master-roadmap。
• 常见下一步：研究弥合了缺口 →reconsolidate-law-stack；研究仍无法回答开放问题 →reinterview-open-authority-gaps；研究厘清了实现优先级或解除了真实运行时切片的阻塞 →replan-next-batch。

3.3 reinterview-open-authority-gaps：重访开放权威缺口

• 车道归属：桥接车道（bridge lane），位于文档治理与实现/运行时之间。
• 触发时机：法律栈仍无法干净回答 winner 问题；parity 显示locked但审计证据仍显牵强；车道不再能不靠猜测回答“这里应该谁赢？”“下一步是什么？”“什么应该升/降优先级？”；路线图或优先级重估被未决权威/范围问题阻塞；实现/运行时规划因法律栈过于含糊而无法诚实选批次。
• 调用语法：

  $deep-interview --quick editor-behavior remaining authority gaps after latest batch

• 输入：法律栈五件套 + master-roadmap + audit、最新批次发现与浏览器证明、来自真实代码/产品面的当前实现/运行时车道阻塞项。
• 期望输出：刷新后的权威边界；明确的剩余非目标（non-goals）与未决缺口；模糊是阻塞时刷新路线图/优先级指引；访谈改变车道顺序、切片顺序或升降序时给出明确的 master-roadmap 分诊；给出进入法律重固化或批次重规划的清晰交接。
• 事后刷新：.omx/specs/下最新的访谈/spec 工件；winners 变化则刷新 standards；spec；protocol matrix；门禁语言移动则刷新 parity matrix；访谈改变实现优先级、车道排序或切片分诊则刷新 master-roadmap。
• 常见下一步：访谈改变了权威或法律 →reconsolidate-law-stack；访谈主要改变路线图顺序或优先级 →replan-next-batch；访谈把阻塞收敛为一个具体已批准的运行时批次 → 通过launch-next-ralph-batch启动。

四、实现/运行时车道（Implementation / Runtime Lane）

实现/运行时车道包含两条命令，负责把文档真值转化为可执行的代码/测试/产品批次。

4.1 replan-next-batch：重规划下一批次（文档→实现交接桥）

• 车道归属：implementation/runtime；当权威或门禁真值变化时由 doc-governance 输出喂养。
• 触发时机：权威或门禁发生实质性变化且需要选择下一运行时切片；运行时批次改变了实际剩余工作；重访了开放范围或权威缺口之后；文档治理工作改变了当前“安全/值得实现”的集合。
• 调用语法——默认（直接基于路线图）：

  $ralplan --consensus --direct docs/editor-behavior/master-roadmap.md

  当某个车道已有书面支撑计划时：

  $ralplan --consensus --direct docs/plans/<active-lane-plan>.md

• 输入：markdown-parity-matrix.md、master-roadmap.md、2026-04-02-editor-behavior-major-execution.md、docs/plans/下任何活跃支撑车道计划、.omx/plans/下任何活跃车道专属规划工件。
• 期望输出：刷新后的完整剩余积压顺序或更窄的下一切片；现实变化时刷新 master-roadmap 的车道/切片分诊；现实变化时刷新支撑车道计划与执行笔记；显式交接进一个下一实现/运行时车道；显式注明启动前是否必须配对一次文档治理通道。
• 事后刷新：master-roadmap、2026-04-02 执行笔记、活跃门禁措辞变化时刷新 parity matrix、docs/plans/下相关支撑计划、.omx/plans/下相关 OMX 规划工件。
• 常见下一步：下一批次已批准且具体 → 运行launch-next-ralph-batch；重规划表明真值仍不稳定而非可实施 → 返回reconsolidate-law-stack/refresh-evidence-ledger/reinterview-open-authority-gaps。

4.2 launch-next-ralph-batch：启动下一批次（执行收尾）

• 车道归属：implementation/runtime；由replan-next-batch的已批准输出喂养。
• 触发时机：下一编辑器行为批次已确定；法律栈足够一致、可以直接执行而无需再访谈；剩余工作属于代码/测试/文档而不是又一轮权威通道；活跃车道是真实的实现/运行时批次而非文档维护。
• 调用语法：

  $ralph "Execute /absolute/path/to/approved-editor-behavior-lane-plan.md"

• 输入：docs/plans/或.omx/plans/下的活跃已批准车道计划、master-roadmap.md、2026-04-02-editor-behavior-major-execution.md、docs/editor-behavior/下的当前法律栈、活跃车道拥有的实际包/应用/文档面。
• 期望输出：一个运行时批次完成或实质性推进；同轮验证证据（same-turn verification evidence）；活跃车道的代码/测试/文档更新；批次改变真值时更新法律栈、路线图与支撑计划。
• 事后刷新：批次改变车道状态/切片状态/剩余内容时刷新 master-roadmap；2026-04-02 执行笔记；docs/plans/或.omx/plans/下的活跃支撑车道计划；法律变化时刷新 markdown-editing-spec.md；场景行变化时刷新 editor-protocol-matrix.md；门禁状态变化时刷新 markdown-parity-matrix.md；证据变化时刷新 markdown-editing-reference-audit.md；运行时车道改变了已交付表面时刷新公开包/应用文档。
• 常见下一步（闭环回到治理车道）：批次改变了法律真值 →reconsolidate-law-stack；批次暴露了证据债 →refresh-evidence-ledger；批次暴露的是未决权威而非普通实现债 →reinterview-open-authority-gaps；批次改变了剩余内容 →replan-next-batch。

五、快速路由：五分钟定位该跑哪条命令

命令包 README 提供了面向问题的快速路由，是实际操作中最常用的决策表。

5.1 处于文档治理问题时的路由

• 文档之间互相矛盾，或运行时批次改变了行为而法律栈未跟上 → 从reconsolidate-law-stack开始；
• audit 或研究感觉陈旧，或实现车道被弱证据阻塞 → 从refresh-evidence-ledger开始；
• 车道无法回答“这里应该谁赢？”“下一步是什么？”“什么应该升降优先级？” → 在规划前先运行reinterview-open-authority-gaps。

5.2 处于实现/运行时问题时的路由

• 权威已明确、需要下一个可执行运行时切片 → 运行replan-next-batch；
• 门禁已关闭但仍需要剩余积压顺序或更窄的下一切片 → 运行replan-next-batch；
• 下一运行时批次已批准且具体 → 运行launch-next-ralph-batch；
• 运行时工作暴露了法律漂移、证据债或未决权威 → 弹回文档治理车道，而不是强行推进更多代码工作。

5.3 命令总览表

六、双车道模型的工程要点与实践建议

6.1 三条设计原则

从本次重构可以提炼出可复用的工程模式：

1. 命令文档即操作契约：每条命令统一采用“车道（Lane）—触发时机（When To Run）—调用语法（Invocation）—输入（Inputs）—期望输出（Expected Outputs）—事后刷新（Refresh Afterward）—常见下一步（Common Next Step）”七段式结构，让 Agent 与人类操作者都能零上下文恢复工作流。
2. 真值单一归属，命令只做仲裁：法律、门禁、证据、序列、历史、支撑计划各有唯一所有者文档；命令不发明真值，只在所有者之间搬运与刷新，冲突时按“spec > protocol matrix > parity matrix”的裁决规则处理。
3. 闭环而非线性：治理车道与实现车道互为输入输出——实现批次落地后必须回流治理车道刷新真值；治理车道收敛后才允许启动新的实现批次。launch-next-ralph-batch的“Common Next Step”显式列出了四种回流路径，就是这一闭环的落地体现。

6.2 与仓库实际状态的对应

• 当前剩余实现序列由 master-roadmap.md 拥有，它明确区分了closed major（旧有特性大闸已不再是活跃执行队列）、lane（尚宽于单个批次的实现项目）、slice（车道内的具体执行块）、feature-gap follow-up（法律已写之后的真实实现工作）、todo（活跃已批准队列项）与backlog（需用户批准才能重新进入活跃队列的延期项）等词汇，这正是“重规划/启动批次”命令读取的路线图词汇表。
• 历史执行真值保留在 2026-04-02-editor-behavior-major-execution.md 与 2026-04-03-editor-protocol-matrix-completion.md，它们只作批次历史参考，不是当前门禁来源；当前门禁真值属于 parity matrix，当前实现路线图真值属于 master-roadmap。
• 外部参考证据的编译层位于 docs/research，覆盖 Typora、Obsidian、Milkdown 等来源的摘要、概念、决策与系统映射，是refresh-evidence-ledger命令的数据底座。

6.3 给操作者的最小启动步骤

若你要恢复或推进编辑器行为车道，推荐的最小路径为：

1. 阅读 commands/README.md 确认当前处于哪条车道；
2. 处于治理问题 → 按 5.1 路由执行对应治理命令；处于实现问题 → 按 5.2 路由执行replan-next-batch或launch-next-ralph-batch；
3. 任何命令执行后，严格按该命令的“Refresh Afterward”清单回写真值文档，避免产生新的漂移；
4. 用“grep 命令包中残留的单车道措辞”这类验证手段确认双车道模型没有被新批次重新打破。

结语

2026-04-10-editor-behavior-command-pack-two-lanes.md 记录了一次小规模但高杠杆的文档工程重构：它把docs/editor-behavior/commands/从“规范文档维护工具”升级为“文档治理 + 实现/运行时”双车道操作面。对于维护大型编辑器行为的团队而言，这套模式的价值在于：真值有唯一归属、操作有统一契约、治理与实现互相喂养且闭环回流——这正是让一个长期演进的编辑器行为规范体系免于漂移、可持续推进的组织方式。

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate