关于将此路线图转变为具体交付阶段的执行清单，请参阅 docs/mvp-todo-plan.md。关于面向客户端的运行时契约，请参阅 docs/contracts/README.md。
VoidCode 当前处于开发阶段。路线图从基础工作贯穿至 MVP 集成。仓库已经完成了初始环境/引导工作，现在还包括了一个稳定的 deterministic reference/debug engine、已落地的 provider-backed execution path，以及 runtime-owned delegated child execution 基线。同时，为工具、技能以及 LSP/ACP/MCP 的载体预留了初始扩展基础设施，而更广泛的 MVP 实现和 IDE 集成在当前阶段尚不在范围内。post-MVP 的明确方向之一是 multi-agent 支持，但这不会改变 runtime 作为系统控制面的边界。
- 用户可以提交开发任务
- 智能体可以阅读代码、搜索代码并调用工具
- 写入操作需要审批
- 会话可以恢复
- 确定性 execution engine 端到端运行
- 事件流可观测
- 为客户端渲染发出实时运行时事件
- 多角色 / multi-agent 执行拓扑（post-MVP 明确方向）
- 云端协作
- IDE 插件
- 插件市场支持
- workspace-scoped MCP、MCP 生态市场式语义或动态 agent marketplace
- peer-to-peer agent bus
- #285 context assembly / compaction 的完整产品化语义
- 高级 MCP 生态系统工作
- 复杂的视觉工作台
创建基准仓库和开发环境：Python 版本策略、uv、mise、仓库结构和 CI 基准。
当前状态： 基本完成。仓库现在拥有可用的开发者设置、CI、贡献者文档以及稳定的 deterministic reference/debug engine。扩展基础设施已通过统一的配置模式、工具提供商接口和初始技能发现机制建立。
定义图状态、节点、图编译以及中断/恢复，以便支撑 execution engine 的步骤推进。
当前状态： 完成。运行时现在实现了一个稳定的 deterministic reference/debug engine，支持轮次执行、工具解析和会话恢复。
构建自定义运行时外壳：会话管理器、运行时入口点、传输抽象以及运行时到图的集成。
当前状态： 完成。VoidCodeRuntime 边界已建立，支持 CLI 和 HTTP 传输，并具有统一的会话和事件处理。
将工具和扩展作为运行时的一等公民，包含元数据、注册、内置功能和统一的执行管线。此 Epic 还包括作为运行时管理接口的技能、语言服务器（LSP）和智能体通信协议（ACP）的基础设施。
当前状态： 部分完成。内置工具和技能发现已实现。skill_refs 已作为 manifest/catalog 默认选择进入 runtime skill application，force_load_skills 与 delegated load_skills 则只为目标 run / child session 注入完整 skill body。LSP 已具备 read-only runtime-managed 基线（manager、tool、事件与测试），并且仓库已经补齐了 lsp/、skills/、provider/、acp/、mcp/ 等能力层边界目录文档；独立的 LSP server preset/config 模块也已经落地，主流 workspace 的 implicit defaults 也已进入可用状态。MCP 已具备 runtime-managed lifecycle、tool discovery、tool call 集成 groundwork，支持 runtime scope 与 session scope 生命周期，但当前仍是 config-gated / opt-in 能力（#107 目标：稳定化当前边界，而非新增功能），不包含 workspace-scoped MCP 或 marketplace。ACP 已进入最小的 runtime-managed transport / lifecycle 路径，但仍未扩展为更宽的协作控制面或直接 agent-to-agent bus。
技术细节： ProviderSingleAgentGraph 代表当前已实现的 provider-backed execution path，直接调用 SingleAgentProvider.propose_turn()，不依赖 LangGraph；当前顶层兼容默认 execution engine 仍是 deterministic，用于无凭据本地演示、测试和参考/debug harness。产品化主路径应继续收敛到配置了 model/provider 的 provider-backed execution，因此仅 DeterministicReadOnlyGraph 使用 LangGraph StateGraph 这一事实不应被表述为“LangGraph 已退出主路径”。
通过 allow、deny 和 ask 实现受控执行，在写入和高风险 shell 操作之前需要审批。
当前状态： 完成。运行时支持受监管的执行，并在所有传输方式中具有审批-恢复连续性。
通过钩子注册、工具前后钩子、轮次钩子和钩子执行日志添加事件驱动的扩展性。这包括用于客户端观测和轮次重新编号的规范运行时事件模式。
当前状态： 完成。运行时事件模式已稳定，并为所有主要循环阶段发出事件。已实现轮次重新编号，以确保会话恢复时的序列一致性。最小 pre/post tool hooks 已在运行时执行。 richer hook phases 和更宽的 hook framework 仍不在当前 MVP 范围内。
在 SQLite 中持久化会话和执行状态，以便在重启后恢复中断的工作。
当前状态： 完成。完整的会话持久化（包括事件、输出和待审批项）已实现。
管理长期运行的上下文，并提供对轮次、工具、审批、钩子和错误的追踪友好可见性。
当前状态： 部分完成。通过事件流实现的轮次级可观测性已完成；provider fallback、step budget 与恢复关键配置的运行时治理已经落地。#70、#82、#83 与 #84 已经分别完成 waiting / terminal session resume checkpoint groundwork、retention / compaction / checkpoint invalidation 语义、corrupt / unreadable checkpoint fallback correctness，以及 cold-session archive / replay strategy。
通过具有流式输出、审批交互和会话恢复的可用入口点暴露运行时。
当前状态： 进行中。CLI 仍是最完整的客户端入口；TUI 保持初始实现状态，优先级已下调，暂不作为当前 MVP 完成的硬条件；Web 客户端已经接入极简的真实运行时路径，并承担当前 MVP 主路径的主要客户端验证工作。
将整个路径连接成一个可演示的产品循环，包括端到端测试、故障处理、演示脚本和用户文档。
- Wave 1: 基础、初始图工作和运行时骨架（已在仓库形式中部分完成）
- Wave 2: 工具执行、权限和钩子
- Wave 3: 存储、恢复、上下文和可观测性
- Wave 4: 入口点、集成和 MVP 演示就绪
当 VoidCode 能够可靠地演示一个受监管的开发任务执行流，并具备持久化、审批、可观测性，以及至少一个经过真实验证的客户端入口点时，即认为达到了 MVP 边界。
在最近几轮 runtime 配置、provider fallback、恢复语义、checkpoint groundwork 与 archive / replay 主线收口之后，当前 backlog 的优先级应以 GitHub issue 列表为准，而不再继续沿用 #83 / #84 作为“当前下一步”的描述。
接下来的工作不应再以能力面扩张为优先，而应以尽快做出一个真正可用的 agent coding 工具为目标。对当前仓库而言，这意味着：
- 优先提升真实任务成功率，而不是继续增加更多表面能力；
- 优先完善 CLI + Web 这条已经真实接入 runtime 的主路径，TUI 继续保持降权状态；
- 优先解决“为什么这台机器不能用”“为什么改完代码后不稳定”“为什么默认项目还需要大量手动配置”这类首轮体验问题；
- provider / multi-agent / ACP / MCP 等能力扩张，只有在不挤占主路径产品化时间的前提下才继续推进。
因此，后续 backlog 的判断标准应从“还能再做什么能力”转为“是否直接提高第一次真实改码任务的完成率”。
最近已经完成了 agent preset 的最小 runtime 接入、runtime-managed skill execution 的最小模型、Session Continuity Memory 第一切片，以及 delegated child execution 的 E2E 基线。因此“当前最直接的剩余主线”已经不再是 #152 / #153 这类最小接入问题，而是这些能力的深化与产品化收口：
- 更完整的 agent preset/runtime consumption 与验证闭环；
- 更真实的 skill context / capability binding / execution semantics；
- delegated child execution 的产品化打磨，但不扩大成任意拓扑 multi-agent 平台；
- continuity memory 在 provider-backed execution 中的后续 shape、reinjection 与验证；
- CLI + Web 主路径上的 first-task success rate 与默认可用性问题。
也就是说，当前 backlog 应围绕“把已落地的最小切片变成稳定可用的主路径能力”来重建，而不是继续把已完成 issue 作为当前下一步。
#130：add more llm api
这一层工作的目标不应再是补前一轮已经完成的 LSP 默认配置，而是继续提高真实任务完成率和 provider-backed 主路径的可用性。
#130 这类 provider 扩展工作仍应放在主路径稳定化之后，避免在核心任务链路尚未完全收口时继续扩大维护面。
#100：TUI parity 已完成一轮增强，但 TUI 后续 polish 仍不应与 CLI + Web 主路径并行争抢产品化时间；#126：fuzz test 继续有价值，但应服务于主路径稳定化，而不是替代产品化主线本身；#97：ACP contract extraction 仍应保持 boundary-first，不应抢占当前 MVP 主路径时间。
这些 issue 都应继续遵守当前边界：
- 通过 runtime 统一进入执行路径
- 保持 CLI / HTTP / Web 共享同一套 persistence / replay truth
- 不把 ACP / MCP 提前拉进当前 MVP 主路径
因此，ACP 与 MCP 当前仍应继续保持 boundary-first 的推进方式，而不是提前膨胀为当前 MVP 主路径。
multi-agent 支持已经是明确的 post-MVP 方向。当前推荐的进入方式不是让 runtime 失去控制面地位，而是在既有边界之上继续使用已经存在的 src/voidcode/agent/ 作为预定义 agent 的声明式配置边界，并在当前 delegated child execution 基线之上补齐真正的协作语义，例如：
- prompt / profile
- hook 绑定
- skill 绑定
- MCP server/profile 绑定
- tool allowlist / default tool set
- provider / model preference
在这一方向下：
runtime/继续拥有 session、approval、permission、persistence、event、transport 与 capability lifecycle truthgraph/继续拥有 loop / step orchestrationagent/负责预定义 agent profile 与组合层
这使得当前 MVP 主执行路径与未来 multi-agent 扩展可以沿着同一条 runtime-centric 架构演进，而不把治理语义下沉到 graph、prompt 或客户端侧。