Slate v2 后路线图阻塞批次执行计划从「1-6 完成」到可审计的发布闸门【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate导读本文档对应仓库中的 docs/plans/2026-04-08-slate-v2-post-roadmap-blocker-batches-plan.md讲解 plate 项目中slate-v2迁移程序在完成 1–6 号 tranche 路线图后如何把「路线图收尾」转化为「阻塞批次blocker batches」驱动的执行序列。你将看到一套可复制的工程治理方法批量拆解Batch 7/8/9、规划规则、进度同步与退出判读以及它们如何落到 master-roadmap.md 与 release-file-review-ledger.md 这两份「活文档」上。背景为什么路线图完成后还要再造一批「批次」slate-v2是 plate 仓库内将 Slate 编辑器运行时向全新架构迁移的长期程序其官方迁移顺序记录在 master-roadmap.md 中共 8 个 trancheTranche主题状态文档记录1Root、工具链、文档Bun/Turbo/Biome/ESLint已完成2React 19.2 与低风险兼容性已完成3slate读/写事务核心与公开 API 重置已完成4slate-history、slate-hyperscript无损收口已完成5slate-dom运行时收口已完成6slate-react运行时收口已完成7示例、基准、增值项进行中8RC 台账收口待办当 1–6 完成、路线图「现金化cashout」之后程序面临一个新的问题「完成」不等于「可发布」。仍有一批阻塞项散落在各文档中需要被重新整理成一个有所有权、有粒度、可执行的序列。这就是本文档的核心目标把已完成的 1–6 路线图阶梯转变为Target B的「阻塞批次」执行序列。规划规则四条不可妥协的纪律文档开篇即列出四条 Planning Rules它们是后续所有批次工作的「宪法」路线图唯一权威规范化的实时路线图始终维护在 master-roadmap.md任何批次的拆解都从该文件取源不得另起炉灶判读所有权归属现有文档实时判读verdict的所有权留在既有的 release/blocker 文档中避免判读被复制到多处而失同步粒度 diff 追踪显式化逐文件、逐行的 diff 追踪必须显式记录在 release-file-review-ledger.md不允许「模糊地知道改了什么」性能不得悄悄回流到常规发布闸门性能perf的结论必须冻结在「已测量车道」上禁止把性能当作例行发布门槛的隐形条件。第 4 条尤其关键它防止了「顺手把 perf 塞回发布流程」这种隐性范围蔓延与后续 Batch 9「perf 不作为独立 Target B 阻塞器」的决定一脉相承。四阶段流程从重读到架构评审批次计划本身也遵循一个固定流程Phases每次执行都按此推进重读剩余阻塞项并核对证明所有权re-read remaining blockers and proof ownership——先确认「还有哪些没做完、各自的 proof owner 是谁」定义下一个阻塞批次阶梯define the next blocker batch ladder——把剩余工作排成一个明确的批次序列同步路线图、命令与粒度台账语言sync roadmap, commands, and granular ledger language——让 master-roadmap.md、commands 与台账的措辞一致避免文档间概念漂移验证并做架构评审verify and architect-review the replan——对重排后的计划做架构级复核。这一流程在仓库中已被固化为可反复运行的命令文档replan-remaining-work.md其中明确给出了「何时运行」批次改变阻塞集、改变证明所有权、范围重审、或恢复的契约 owner 证明现有计划欠量/超量时以及四条 Hard Rules。批次阶梯Batch 7 / 8 / 9 的内容与退出判读本文档的 Progress 部分确认规范路线图已刷新为三个显式阻塞批次。以下分别结合各自的执行计划文档展开。Batch 7Claim Width And Oracle Deepening声明宽度与 Oracle 深化对应计划2026-04-08-slate-v2-batch7-claim-width-and-oracle-deepening.md。Batch 7 要解决的核心矛盾是公开声明claim比实际证明proof宽。其五阶段流程为识别下一批可支撑的 oracle 行 → 在slate-v2落地 oracle 深化 → 用具名原因分类剩余高信号跳过行 → 同步声明承载文档与粒度台账 → 验证与评审。文档记录的关键产出识别出delete删除是最高信号的即时 oracle 缝隙优先镜像了delete/selection/block-middle.tsx与delete/selection/block-across.tsx两个块级选择删除用例用失败的导入尝试来收窄公开声明——delete/path/text.tsx与delete/path/inline.tsx无法通过导入就如实收窄声明而不是「假装达成 parity」逐行分类剩余删除债记录在oracle-harvest-ledger.md收紧声明承载文档只宣称「精确的块路径删除 parity」不宣称「通用叶子路径删除 parity」也不宣称「自定义 setSelection(...) prop parity」。退出判读Batch 7 完成后snapshot-contract.ts镜像了 81 行 legacy oracle删除桶从「通配符迷雾」变成「具名剩余债」。Batch 8Family Depth And Granular Diff Closure家族深度与粒度 diff 收口对应计划2026-04-08-slate-v2-batch8-family-depth-and-granular-diff-closure.md。Batch 8 处理的是「功能家族family」层面的兼容性深度问题。其五阶段流程为对剩余薄家族缝隙排序 → 在真正能买来收口的地方深化当前兼容性证明 → 显式收窄仍仅限当前实现的家族契约 → 同步家族台账、维护者故事与粒度台账 → 验证与评审。文档记录的关键产出识别出四条「低成本深化路径」markdown、forced-layout、styling、hovering-toolbar 的当前兼容性行新增了markdown-preview、markdown-shortcuts、forced-layout、styling、hovering-toolbar的当前兼容性行更新家族台账使每个被拓宽的家族都有显式的证明姿态runtime-backed运行时背书、browser-backed浏览器背书、compat-backed兼容性背书仅在诚实处使用、intentionally narrow刻意收窄关键决定scroll-into-view保持显式仅限当前实现而不是发明一个虚假的 legacy 基线editable-voids、images、embeds、tables 则维持 compat-backed 姿态。退出判读家族故事更紧凑——不再假装每个家族都是 legacy 的「一揽子克隆」。Batch 9Perf Posture AndTarget BPromotion / Hold性能姿态与 Target B 升级/搁置对应计划2026-04-08-slate-v2-batch9-perf-posture-and-target-b-promotion-hold.md。Batch 9 是整个批次阶梯的「裁决批次」用最新证据刷新替换闸门冻结性能措辞然后决定Target B是升级promotion还是搁置hold。其五阶段流程为刷新完整替换闸门证据 → 冻结性能措辞到已测量车道 → 决定 Target B 升级或搁置 → 同步判读文档与台账 → 验证与评审。文档记录的关键产出确认替换闸门脚本是最终性能姿态的正确新鲜证据源并运行了完整闸门yarn test:replacement:gate:local用新的已测量车道结果刷新记分板把性能故事冻结到已测量车道裁决Target A GoTarget B No-Go保持显式搁置同时把 perf 从「独立的 Target B 阻塞器」中移除。退出判读剩余阻塞器只剩三类——公开声明宽度、oracle 深度、刻意收窄的家族契约性能姿态为「仅限车道级结论不是宣称『全面更快』的许可」。配套工具链命令文档与粒度台账如何支撑批次执行批次计划不是一次性文档而是与一套可执行的控制文档联动。以下是文档明确依赖的核心文件replan-remaining-work.md重排剩余工作的命令入口定义触发时机与 Hard Rules刷新后需同步路线图、发布就绪判读、文件评审台账、RC 证明台账与 PR 描述refresh-file-review-ledger.md刷新逐文件评审台账的命令launch-next-ralph-batch.md启动下一个 Ralph 批次的命令reconsolidate-roadmap.md重新整合路线图的命令。其中「粒度台账」release-file-review-ledger.md 是本文档反复强调的逐文件真相源。台账为每个文件定义了五种状态词ported原样移植、adapted适配改造、pending待处理、archived归档、post RCRC 后处理。例如在台账的「Tranche 1 包清单」部分packages/slate/package.json→adapted构建改走 tsdown发布 ESM-only 的dist/index.jsdist/index.d.tspnpm-workspace.yaml、pnpm-lock.yaml、yarn.lock、Rollup 配置 →archivedBun 锁文件与 ESM-only tsdown 构建取代了旧工具链。批次计划特别强调在台账中为 post-roadmap 阻塞面新增了显式「未勾选」的粒度评审行——即在批次执行前这些行保持未确认状态直到逐文件复核完成才勾选。仓库中的落点从计划到源码的真实映射虽然批次计划是「治理层」文档但它的每一条结论在仓库中都有可验证的落点以当前仓库实际状态为准tranche 阶梯与批次见 master-roadmap.md 的 Tranche Order 与 Package Orderslate→slate-history→slate-hyperscript→slate-dom→slate-react外加早期落地、处于 packages/slate-browser 的slate-browser契约证明文件snapshot-contract.ts81 行 oracle 镜像、query-contract.ts、operations-contract.ts、history-contract.ts、integrity-contract.ts等在 release-file-review-ledger.md 的「Current Recovery Rows」中逐条登记了 dispositionrestored/adapted/created/preserved与 proof owner核心 API 方向tranche 3 将editor.read/editor.update定为公开生命周期EditorCommit作为本地运行时真相而editor.children、editor.selection、editor.marks、editor.operations被明确归类为「非主读路径」性能命令如bench:react:rerender-breadth:local、bench:react:huge-document-overlays:localtranche 6 记录以及 Batch 9 用到的yarn test:replacement:gate:local。说明以上映射以当前仓库文档记录为准批次文档中的部分契约测试文件在本文写作时的仓库结构中位于迁移目标路径读者应以台账与路线图的当前状态为准继续追踪。总结这套计划的可复用价值slate-v2的后路线图阻塞批次计划提供的是一套通用的「收尾治理模板」完成 ≠ 可发布路线图完成后阻塞项必须被重新组织为有所有权、有顺序的批次声明必须被证明约束当证明不足时收窄声明Batch 7比伪造 parity 更诚实兼容性姿态必须分级runtime-backed / browser-backed / compat-backed / intentionally narrow 四种姿态让每个家族都有明确的证明义务Batch 8性能结论只属于已测量车道perf 可以参与裁决但不能悄悄变成例行门槛Batch 9一切同步到活文档路线图、命令、台账三者的语言必须一致逐文件状态必须显式登记。这套方法论不仅适用于大型编辑器内核迁移也适用于任何「功能已齐、发布未决」的软件项目收尾阶段。延伸阅读master-roadmap.md规范 tranche 顺序与执行纪律overview.mdslate-v2 迁移程序的入口与阅读顺序release-file-review-ledger.md逐文件迁移真相台账replan-remaining-work.md重排剩余工作的命令Batch 7 执行计划、Batch 8 执行计划、Batch 9 执行计划【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Slate v2 后路线图阻塞批次执行计划：从「1-6 完成」到可审计的发布闸门
Slate v2 后路线图阻塞批次执行计划从「1-6 完成」到可审计的发布闸门【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate导读本文档对应仓库中的 docs/plans/2026-04-08-slate-v2-post-roadmap-blocker-batches-plan.md讲解 plate 项目中slate-v2迁移程序在完成 1–6 号 tranche 路线图后如何把「路线图收尾」转化为「阻塞批次blocker batches」驱动的执行序列。你将看到一套可复制的工程治理方法批量拆解Batch 7/8/9、规划规则、进度同步与退出判读以及它们如何落到 master-roadmap.md 与 release-file-review-ledger.md 这两份「活文档」上。背景为什么路线图完成后还要再造一批「批次」slate-v2是 plate 仓库内将 Slate 编辑器运行时向全新架构迁移的长期程序其官方迁移顺序记录在 master-roadmap.md 中共 8 个 trancheTranche主题状态文档记录1Root、工具链、文档Bun/Turbo/Biome/ESLint已完成2React 19.2 与低风险兼容性已完成3slate读/写事务核心与公开 API 重置已完成4slate-history、slate-hyperscript无损收口已完成5slate-dom运行时收口已完成6slate-react运行时收口已完成7示例、基准、增值项进行中8RC 台账收口待办当 1–6 完成、路线图「现金化cashout」之后程序面临一个新的问题「完成」不等于「可发布」。仍有一批阻塞项散落在各文档中需要被重新整理成一个有所有权、有粒度、可执行的序列。这就是本文档的核心目标把已完成的 1–6 路线图阶梯转变为Target B的「阻塞批次」执行序列。规划规则四条不可妥协的纪律文档开篇即列出四条 Planning Rules它们是后续所有批次工作的「宪法」路线图唯一权威规范化的实时路线图始终维护在 master-roadmap.md任何批次的拆解都从该文件取源不得另起炉灶判读所有权归属现有文档实时判读verdict的所有权留在既有的 release/blocker 文档中避免判读被复制到多处而失同步粒度 diff 追踪显式化逐文件、逐行的 diff 追踪必须显式记录在 release-file-review-ledger.md不允许「模糊地知道改了什么」性能不得悄悄回流到常规发布闸门性能perf的结论必须冻结在「已测量车道」上禁止把性能当作例行发布门槛的隐形条件。第 4 条尤其关键它防止了「顺手把 perf 塞回发布流程」这种隐性范围蔓延与后续 Batch 9「perf 不作为独立 Target B 阻塞器」的决定一脉相承。四阶段流程从重读到架构评审批次计划本身也遵循一个固定流程Phases每次执行都按此推进重读剩余阻塞项并核对证明所有权re-read remaining blockers and proof ownership——先确认「还有哪些没做完、各自的 proof owner 是谁」定义下一个阻塞批次阶梯define the next blocker batch ladder——把剩余工作排成一个明确的批次序列同步路线图、命令与粒度台账语言sync roadmap, commands, and granular ledger language——让 master-roadmap.md、commands 与台账的措辞一致避免文档间概念漂移验证并做架构评审verify and architect-review the replan——对重排后的计划做架构级复核。这一流程在仓库中已被固化为可反复运行的命令文档replan-remaining-work.md其中明确给出了「何时运行」批次改变阻塞集、改变证明所有权、范围重审、或恢复的契约 owner 证明现有计划欠量/超量时以及四条 Hard Rules。批次阶梯Batch 7 / 8 / 9 的内容与退出判读本文档的 Progress 部分确认规范路线图已刷新为三个显式阻塞批次。以下分别结合各自的执行计划文档展开。Batch 7Claim Width And Oracle Deepening声明宽度与 Oracle 深化对应计划2026-04-08-slate-v2-batch7-claim-width-and-oracle-deepening.md。Batch 7 要解决的核心矛盾是公开声明claim比实际证明proof宽。其五阶段流程为识别下一批可支撑的 oracle 行 → 在slate-v2落地 oracle 深化 → 用具名原因分类剩余高信号跳过行 → 同步声明承载文档与粒度台账 → 验证与评审。文档记录的关键产出识别出delete删除是最高信号的即时 oracle 缝隙优先镜像了delete/selection/block-middle.tsx与delete/selection/block-across.tsx两个块级选择删除用例用失败的导入尝试来收窄公开声明——delete/path/text.tsx与delete/path/inline.tsx无法通过导入就如实收窄声明而不是「假装达成 parity」逐行分类剩余删除债记录在oracle-harvest-ledger.md收紧声明承载文档只宣称「精确的块路径删除 parity」不宣称「通用叶子路径删除 parity」也不宣称「自定义 setSelection(...) prop parity」。退出判读Batch 7 完成后snapshot-contract.ts镜像了 81 行 legacy oracle删除桶从「通配符迷雾」变成「具名剩余债」。Batch 8Family Depth And Granular Diff Closure家族深度与粒度 diff 收口对应计划2026-04-08-slate-v2-batch8-family-depth-and-granular-diff-closure.md。Batch 8 处理的是「功能家族family」层面的兼容性深度问题。其五阶段流程为对剩余薄家族缝隙排序 → 在真正能买来收口的地方深化当前兼容性证明 → 显式收窄仍仅限当前实现的家族契约 → 同步家族台账、维护者故事与粒度台账 → 验证与评审。文档记录的关键产出识别出四条「低成本深化路径」markdown、forced-layout、styling、hovering-toolbar 的当前兼容性行新增了markdown-preview、markdown-shortcuts、forced-layout、styling、hovering-toolbar的当前兼容性行更新家族台账使每个被拓宽的家族都有显式的证明姿态runtime-backed运行时背书、browser-backed浏览器背书、compat-backed兼容性背书仅在诚实处使用、intentionally narrow刻意收窄关键决定scroll-into-view保持显式仅限当前实现而不是发明一个虚假的 legacy 基线editable-voids、images、embeds、tables 则维持 compat-backed 姿态。退出判读家族故事更紧凑——不再假装每个家族都是 legacy 的「一揽子克隆」。Batch 9Perf Posture AndTarget BPromotion / Hold性能姿态与 Target B 升级/搁置对应计划2026-04-08-slate-v2-batch9-perf-posture-and-target-b-promotion-hold.md。Batch 9 是整个批次阶梯的「裁决批次」用最新证据刷新替换闸门冻结性能措辞然后决定Target B是升级promotion还是搁置hold。其五阶段流程为刷新完整替换闸门证据 → 冻结性能措辞到已测量车道 → 决定 Target B 升级或搁置 → 同步判读文档与台账 → 验证与评审。文档记录的关键产出确认替换闸门脚本是最终性能姿态的正确新鲜证据源并运行了完整闸门yarn test:replacement:gate:local用新的已测量车道结果刷新记分板把性能故事冻结到已测量车道裁决Target A GoTarget B No-Go保持显式搁置同时把 perf 从「独立的 Target B 阻塞器」中移除。退出判读剩余阻塞器只剩三类——公开声明宽度、oracle 深度、刻意收窄的家族契约性能姿态为「仅限车道级结论不是宣称『全面更快』的许可」。配套工具链命令文档与粒度台账如何支撑批次执行批次计划不是一次性文档而是与一套可执行的控制文档联动。以下是文档明确依赖的核心文件replan-remaining-work.md重排剩余工作的命令入口定义触发时机与 Hard Rules刷新后需同步路线图、发布就绪判读、文件评审台账、RC 证明台账与 PR 描述refresh-file-review-ledger.md刷新逐文件评审台账的命令launch-next-ralph-batch.md启动下一个 Ralph 批次的命令reconsolidate-roadmap.md重新整合路线图的命令。其中「粒度台账」release-file-review-ledger.md 是本文档反复强调的逐文件真相源。台账为每个文件定义了五种状态词ported原样移植、adapted适配改造、pending待处理、archived归档、post RCRC 后处理。例如在台账的「Tranche 1 包清单」部分packages/slate/package.json→adapted构建改走 tsdown发布 ESM-only 的dist/index.jsdist/index.d.tspnpm-workspace.yaml、pnpm-lock.yaml、yarn.lock、Rollup 配置 →archivedBun 锁文件与 ESM-only tsdown 构建取代了旧工具链。批次计划特别强调在台账中为 post-roadmap 阻塞面新增了显式「未勾选」的粒度评审行——即在批次执行前这些行保持未确认状态直到逐文件复核完成才勾选。仓库中的落点从计划到源码的真实映射虽然批次计划是「治理层」文档但它的每一条结论在仓库中都有可验证的落点以当前仓库实际状态为准tranche 阶梯与批次见 master-roadmap.md 的 Tranche Order 与 Package Orderslate→slate-history→slate-hyperscript→slate-dom→slate-react外加早期落地、处于 packages/slate-browser 的slate-browser契约证明文件snapshot-contract.ts81 行 oracle 镜像、query-contract.ts、operations-contract.ts、history-contract.ts、integrity-contract.ts等在 release-file-review-ledger.md 的「Current Recovery Rows」中逐条登记了 dispositionrestored/adapted/created/preserved与 proof owner核心 API 方向tranche 3 将editor.read/editor.update定为公开生命周期EditorCommit作为本地运行时真相而editor.children、editor.selection、editor.marks、editor.operations被明确归类为「非主读路径」性能命令如bench:react:rerender-breadth:local、bench:react:huge-document-overlays:localtranche 6 记录以及 Batch 9 用到的yarn test:replacement:gate:local。说明以上映射以当前仓库文档记录为准批次文档中的部分契约测试文件在本文写作时的仓库结构中位于迁移目标路径读者应以台账与路线图的当前状态为准继续追踪。总结这套计划的可复用价值slate-v2的后路线图阻塞批次计划提供的是一套通用的「收尾治理模板」完成 ≠ 可发布路线图完成后阻塞项必须被重新组织为有所有权、有顺序的批次声明必须被证明约束当证明不足时收窄声明Batch 7比伪造 parity 更诚实兼容性姿态必须分级runtime-backed / browser-backed / compat-backed / intentionally narrow 四种姿态让每个家族都有明确的证明义务Batch 8性能结论只属于已测量车道perf 可以参与裁决但不能悄悄变成例行门槛Batch 9一切同步到活文档路线图、命令、台账三者的语言必须一致逐文件状态必须显式登记。这套方法论不仅适用于大型编辑器内核迁移也适用于任何「功能已齐、发布未决」的软件项目收尾阶段。延伸阅读master-roadmap.md规范 tranche 顺序与执行纪律overview.mdslate-v2 迁移程序的入口与阅读顺序release-file-review-ledger.md逐文件迁移真相台账replan-remaining-work.md重排剩余工作的命令Batch 7 执行计划、Batch 8 执行计划、Batch 9 执行计划【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考