Future: Keep CraftDAG Minecraft-first but domain-shaped, not domain-locked

[madawei2699]

Context

CraftDAG is currently focused on MinePilot and Minecraft-oriented build planning. That should remain the short-term product and implementation focus.

However, the core architecture may generalize beyond Minecraft:

Intent
→ schema-constrained semantic plan
→ deterministic expansion
→ low-level graph IR
→ target-state representation
→ preview/export/execution

This issue records the long-term architectural boundary: CraftDAG should stay Minecraft-first, but the core compiler ideas should not become unnecessarily locked to Minecraft-specific exporters, block registries, or execution layers.

Principle

CraftDAG should be domain-shaped, not domain-locked.

That means:

• Shape the current product around Minecraft builds.
• Keep the core compiler pipeline clean enough that future bounded spatial construction domains could reuse parts of it.
• Do not prematurely turn CraftDAG into a generic spatial framework.

Short-term stance

Keep focusing on Minecraft:

• ComponentPlan for Minecraft-style builds
• CraftDAG primitive compilation
• VoxelPlan preview/material/layer outputs
• schematic export
• MinePilot integration

Do not rename the project or dilute the product positioning.

Boundary guidance

Prefer keeping these concerns in core:

• schema-constrained plans
• DAG dependency semantics
• component expansion
• deterministic compilation
• bounded spatial validation
• VoxelPlan target-state representation
• repairable errors
• material/layer metadata

Prefer keeping these Minecraft-specific concerns in adapters/exporters or clearly isolated modules:

• minecraft:* block-state validation
• schematic / litematic export
• Java Edition DataVersion
• WorldEdit compatibility
• Mineflayer / bot execution
• survival-friendly Minecraft palettes

Design rule of thumb

Core plans should prefer semantic material roles and bounded spatial primitives.

Minecraft block states should enter through palettes and Minecraft-specific exporters/adapters rather than leaking into every layer of the architecture.

Good:

{
  "palette": {
    "wall": "minecraft:oak_planks",
    "roof": "minecraft:spruce_planks"
  },
  "materials": {
    "wall": "wall"
  }
}

Less ideal:

{
  "block": "minecraft:oak_planks"
}

inside every high-level component.

Possible future domains

These are not roadmap commitments, just examples of domains that share bounded spatial construction properties:

• LEGO / brick building instructions
• voxel art
• simple block-based CAD-like structures
• game level blockouts
• robotics construction planning

The most plausible first non-Minecraft experiment would be LEGO-like brick instructions, because it shares discrete space, material/color constraints, layer guides, and preview needs.

Non-goals

• Do not make CraftDAG generic before MinePilot/Minecraft workflows are strong.
• Do not introduce abstract UniversalPlan naming now.
• Do not remove Minecraft-specific examples or schematic support.
• Do not split packages prematurely unless implementation pressure requires it.
• Do not block ComponentPlan, schematic export, or MinePilot work on this abstraction.

Acceptance criteria for future design work

If this evolves into docs or implementation later:

• A short docs/DOMAIN_BOUNDARIES.md or architecture note exists.
• It distinguishes core compiler concepts from Minecraft adapters/exporters.
• It documents where Minecraft block states are allowed to enter the pipeline.
• It does not change current Minecraft-first positioning.
• It does not require immediate package split.

Suggested timing

Revisit after:

1. ComponentPlan v0.1/v0.2 is stable.
2. MinePilot can generate, preview, verify, and export Minecraft builds reliably.
3. The codebase shows real pressure to separate core material roles from Minecraft target bindings.