# Roadmap and Scope


> **Documentation baseline:** VoxelCore `main` at `452b569` · 14 September 2026.  
> **Repository:** [https://github.com/VoxelHorizons/VoxelCore](https://github.com/VoxelHorizons/VoxelCore)


This page separates what the wider VoxelCore rebuild **plans** to become from what the current item/content MVP already supports.

## Current completed foundation

The present implementation has realised several early roadmap principles:

- deterministic content discovery and bounded YAML parsing;
- explicit single-parent inheritance with cycle/missing-parent validation;
- immutable compiled definitions;
- atomic runtime snapshot publication and failed-reload preservation;
- stable ContentID separate from rendering identifiers;
- shared persistent render-allocation authority;
- deterministic Java resource-pack compilation;
- explicit version adapters and exact pack profiles;
- real-server CI behaviour checks instead of enable-line-only CI;
- non-destructive config schema migration.

## Next system classes

The broader migration roadmap still calls for systems beyond this MVP. Current README/source explicitly leaves these outside the supported item milestone:

- placed custom blocks;
- furniture, seats, storage, light and display-entity lifecycle;
- vehicles/input/simulation;
- crops and bounded growth scheduling;
- GUI/menu framework and session lifecycle;
- Bedrock/Geyser frontend mappings and presentation;
- richer version-aware item metadata;
- legacy HavenCore import/compatibility paths.

## Architectural direction from the migration roadmap

The planning document recommends maintaining a distinction between:

- immutable **content definitions**;
- individual **item instance state**;
- persistent **world placement state**;
- replaceable **render handles**.

It also proposes keeping gameplay addons dependent on stable services/API contracts rather than importing one another's mutable registries, and treating the pack builder as a deterministic compiler rather than a ZIP utility.

These are planning constraints and design direction, not a claim that all proposed modules/services already exist in `main`.

## Compatibility policy

The roadmap's most important rule is already visible in implementation: compatibility must be explicit. 1.21.4 no longer claims unvalidated future versions, and Minecraft/Paper 26.2 received a dedicated adapter, Java target, pack profile and smoke row. Future releases should follow that pattern.

## Documentation rule for future milestones

When a roadmap item is merged, move its behavioural contract into dedicated reference pages and remove it from the “not implemented” list. Do not make this roadmap page the only documentation for a completed subsystem.