Roadmap

​

1. Motivation

HeavenBase moves quickly, so the roadmap separates shipped architecture from genuine gaps. Use this page to understand direction; use release notes and the source repository for exact delivery status.

​

2. Current Baseline

The 0.1.2.1 line completed the Registry and module convergence work.

• One Context owns one standard-library Registry kernel, configuration authority, module resolver, and live workspace state.
• Built-in and external modules use the same import-free meta.yaml folder protocol and ModuleService lifecycle.
• Catalog and MetaSchema are fixed workspace foundations; Capsule is required; Toolkit and Prompt are packaged defaults.
• Agent, Memory, and Database remain optional extension roots.
• Concrete Toolkits and their referenced Capsules persist in an explicit application workspace.
• Immutable queries route through registered Backend and handler records, and explain() reports native, adapter, scan, fallback, or unsupported execution honestly.
• Workspace manifest version 2 captures construction, requested roots, and schemas without claiming to export rows.

​

3. Near-Term Focus

• Make provider-native execution broader only where capability evidence remains exact.
• Improve portable query performance and cross-Backend diagnostics without hiding scan or fallback work.
• Keep module artifacts reproducible while defining remote acquisition, signatures, and ecosystem trust policy.
• Keep public docs, Chinese translations, and engineering references synchronized with shipped behavior.

​

4. Known Gaps

• Remote module acquisition and signature policy are not product surfaces yet; local path modules are captured as verified content-addressed artifacts.
• Descriptor inheritance and composition are not implemented.
• Workspace manifests reconstruct shells, not stored rows or physical Backend data.
• Independently routed Backends do not form a distributed transaction boundary.
• LLM session persistence remains deferred; runtime sessions and optional Agent rows are separate contracts.
• Multi-agent orchestration, lineage, automation, and federation are not implemented HeavenBase products.

These are boundaries, not secret menu items. Design against what HeavenBase can prove today.

​

5. Longer-Term Directions

• Trustworthy remote module distribution with explicit provenance.
• Better provider-native text, aggregate, and graph execution where semantics can be proven.
• A concrete portable-data bundle only when a real restore use case establishes the contract.
• Capsule-backed callable persistence where it can replace, rather than duplicate, existing callable authorities.
• LLM persistence only after memory ownership, replay, and privacy boundaries are explicit.

​

6. Non-Goals

• No second Registry, planner, or descriptor format.
• No universal extension unload abstraction without domain-owned cleanup semantics.
• No tag-derived execution proof or provider behavior hidden in central branches.
• No speculative orchestration platform before concrete product demand establishes its contract.

​

Summary

• The Registry-first, one-folder module architecture is the shipped baseline.
• Current work should deepen providers and trust without reopening converged ownership.
• Gaps stay explicit so applications can choose safe boundaries.

​

Further Exploration