mnote/design/01-tree-first-graph-kernel/reference/1-4-next-phase-execution-roadmap-v1.md

1-4 [reference] 下一阶段执行路线图 v1

创建时间：2026-05-19

当前状态：reference

归档说明（2026-07-19）：本文保留下一阶段路线推导；当前可执行入口已收敛到 design/10-review/process/21-mvp-post-architecture-closure-checklist-v1.md，不再从本文直接派发实现。

上位依据：

• /mnt/Data1T/mnote/design/01-tree-first-graph-kernel/done/1-3-current-priority-execution-checklist-v1.md
• /mnt/Data1T/mnote/design/05-editor-mainline/reference/5-14-zed-lapce-vscode-reference-adoption-matrix-v1.md
• /mnt/Data1T/mnote/ARCHITECTURE.md（CURRENT_ARCHITECTURE.md 为兼容指针）

目标：把当前已经推进到混合态的主线，收口成一条更清晰的下一阶段路线，避免“功能继续堆、底座继续散”的问题。

---

1. 结论

下一阶段不是全量重写，也不是继续优先补 UI 功能，而是：

以架构收口为主，带着产品化闭环往前推。

这里的“架构收口”指的是把当前已经存在但还没完全统一的底座收束到少数几条正式主链上：

• WorkspacePath / ProjectPath / ObjectIdentity
• BufferStore / fileVersion / dirty / external change
• Page Aggregate
• tree.* / tree.resource.*
• live cache 的 snapshot / delta / resync 主链
• agent 文件编辑权限与 allowed roots

这里的“产品化闭环”指的是在底座稳定后，继续做：

• 分享与同步
• simplemindmap / office 资源模型
• 旧 Convex 数据迁移

---

2. 为什么不是先做功能补全

1-3 里已经完成了比较多的可见功能：

• 管理员目录授权控制面。
• VSCode-like 冲突处理 UI。
• agent changed files / diff 审计。
• 本地搜索、反链、资源引用索引。

5-14 也说明了一个更底层的事实：

• Zed 更适合作为主架构参考。
• Lapce 更适合作为轻量实现参考。
• SideX 更适合作为 VS Code 行为迁移到 Rust 后端的桥接参考。
• 官方 VS Code 只适合作为行为规格参考。

这意味着当前真正缺的不是“再加一个功能”，而是：

把这些功能压在同一套身份、版本、命令、搜索和 watcher 主链上。

如果继续优先做功能补全，结果通常是：

• 新功能依赖旧兼容面。
• 新能力继续长在不同命令面上。
• UI 看起来越来越完整，但底层真相越来越散。

---

3. 下一阶段三段式推进

3.1 阶段 A：架构收口

这是当前最优先的阶段。

目标：

把 workspace identity、buffer/version、page aggregate、tree command、live cache 收成统一主链。

应优先推进的事：

• 统一 WorkspacePath / ProjectPath / ObjectIdentity。
• 统一 BufferStore / dirty / save / external change 模型。
• 继续瘦身 documents.*，新增只走 tree.* / tree.resource.*。
• 让 Page Aggregate 继续成为页面主投影唯一入口。
• 统一 Sidebar / filetree / page subtree / WS / SSE 到同一 live cache。
• 让 agent 文件编辑权限、allowed roots、symlink escape、文件版本仲裁保持一致。

不该做的事：

• 不重建通用 IDE 壳。
• 不优先做 terminal / debugger / extension host。
• 不继续扩展旧兼容命令面。

3.2 阶段 B：资源与共享产品化

架构收口后，第二阶段做产品化闭环。

目标：

把 simplemindmap / office / 分享 / AI 访问权限纳入同一套资源与权限模型。

应优先推进的事：

• share grant 与 local access grant 的关系。
• shared AI session 的权限边界。
• tree.resource.* 的资源创建 / 重命名 / 移动 / 删除 / 恢复。
• simplemindmap / office 的 ObjectIdentity 和 Resource Tree 映射。

3.3 阶段 C：迁移与运营闭环

最后做迁移和收尾。

目标：

把旧 Convex 资产迁移成本变成可视、可回滚、可验证的产品流程。

应优先推进的事：

• Convex workspace 导出到本地 root。
• dry run。
• 备份。
• 冲突报告。
• 回滚。

---

4. 和 1-3 / 5-14 的关系

4.1 1-3 负责告诉我们“当前还剩什么没收口”

1-3 已经把主线拆得很清楚：

• P0 到 P3 基本是已完成或接近完成的产品能力。
• P4 到 P7 仍然是后续主线。
• 其中 P7 明确指出：Page Aggregate / tree command / realtime 兼容链还要继续瘦身。

4.2 5-14 负责告诉我们“底座应该参考什么”

5-14 的作用不是多拉一个功能列表，而是告诉我们：

• workspace / project / buffer / search / agent 权限，主参考应是 Zed。
• RPC / proxy / config / keymap 的轻量 Rust 组织方式，可以参考 Lapce 和 SideX。
• VS Code 只用于行为规格校准。

4.3 合起来的结论

两份文档合起来，结论就是：

下一阶段的主线是“架构收口 + 产品化闭环”，不是“全量功能扩展”也不是“推倒重写”。

---

5. 明确优先级

P0

• WorkspacePath / ProjectPath / ObjectIdentity
• BufferStore / fileVersion / dirty / conflict
• Page Aggregate
• tree.* / tree.resource.*
• live cache 主链
• agent 文件编辑权限

P1

• 本地搜索与快速打开继续巩固
• File Tree / Page Tree / Resource Tree 命令上下文统一
• command context / context key 统一

P2

• share / sync
• simplemindmap / office 资源产品化
• 本地迁移与导出

P3

• terminal / PTY 边界
• MultiBuffer / excerpts
• review diff / streaming apply
• 插件运行时

---

6. 当前不做什么

• 不把 MNote 拉成通用 IDE。
• 不先做 extension host / debugger / terminal 优先级升级。
• 不让 documents.* 继续长成新主命令面。
• 不把 Tauri desktop shell 当成当前主壳方向。
• 不把 UI 功能增长误当成主线前进。

---

7. 下一步建议

接下来最合理的动作是：

1. 先按 1-4 这条路线图推进架构收口。
2. 在 1-3 里把 P7 拆成明确的收口子任务。
3. 等底座稳定后，再把 P4-P6 推成产品化闭环。

一句话结论：

先收口主链，再做产品化。