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

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.

Treat this as future architecture guidance rather than an immediate implementation task. After ComponentPlan and MinePilot workflows stabilize, inspect the boundaries between the core compiler, VoxelPlan, and Minecraft exporters, then draft docs/DOMAIN_BOUNDARIES.md or an architecture note. Done means the note separates reusable compiler concepts from Minecraft adapters without changing the current Minecraft-first positioning or requiring a package split.