路线图应该是指南针，而不是把旧承诺换上新日期的博物馆。
1. 动机
HeavenBase 迭代很快，因此路线图会把已交付架构与真实缺口分开。 用本页理解方向；用发布说明与源码仓库确认精确交付状态。2. 当前基线
0.1.2.1 系列完成了 Registry 与模块收敛工作。
- 一个 Context 拥有一个仅依赖标准库的 Registry 内核、配置权威、模块解析器与实时工作区状态。
- 内置模块与外部模块使用同一套无需导入的
meta.yaml文件夹协议和ModuleService生命周期。 - Catalog 与 MetaSchema 是固定工作区基础；Capsule 是必需项；Toolkit 与 Prompt 是打包默认项。
- Agent、Memory 与 Database 仍是可选扩展根。
- 具体 Toolkit 及其引用的 Capsule 持久化在一个显式应用工作区中。
- 不可变 Query 通过注册的 Backend 与 handler 记录路由，而
explain()会诚实报告 native、adapter、scan、fallback 或 unsupported 执行。 - 工作区清单版本 2 捕获构造、请求的根与 schema，但不会声称已导出行。
3. 近期重点
- 仅在能力证据保持精确时拓展 Provider 原生执行。
- 改进可移植 Query 性能与跨 Backend 诊断，同时不隐藏 scan 或 fallback 工作。
- 在定义远程获取、签名与生态信任策略的同时，保持模块制品可复现。
- 让公开文档、中文翻译与工程参考持续同步已交付行为。
4. 已知缺口
- 远程模块获取与签名策略尚不是产品表面；本地路径模块会被捕获为经过验证的内容寻址制品。
- 尚未实现描述符继承与组合。
- 工作区清单重建外壳，而非已存储的行或物理 Backend 数据。
- 独立路由的 Backend 不构成分布式事务边界。
- LLM 会话持久化仍处于推迟状态；运行时会话与可选 Agent 行是两份独立契约。
- 多智能体编排、血缘、自动化与联邦尚不是已实现的 HeavenBase 产品。
5. 长期方向
- 带显式来源证明的可信远程模块分发。
- 在语义可证明之处提供更好的 Provider 原生文本、聚合与图执行。
- 仅在真实恢复用例确立契约后提供具体的可移植数据包。
- 让 Capsule 支撑 callable 持久化，但前提是它能替代而非复制现有 callable 权威。
- 仅在内存所有权、重放与隐私边界明确后推进 LLM 持久化。
6. 非目标
- 不引入第二套 Registry、planner 或描述符格式。
- 不在缺少领域自有清理语义时提供通用扩展卸载抽象。
- 不用标签推导执行证明，也不把 Provider 行为藏进中央分支。
- 不在具体产品需求确立契约前构建推测性的编排平台。
总结
- Registry-first、单文件夹模块架构是已交付基线。
- 当前工作应深化 Provider 与信任能力，而不是重新打开已收敛的所有权。
- 缺口保持显式，让应用能够选择安全边界。