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

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.

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.

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`.

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.

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.