Future: Define input adapter architecture

[madawei2699]

Context

Arnis is useful as an example of a clean data-to-world pipeline. The relevant lesson for CraftDAG is not to copy OSM generation, but to make input sources modular.

Idea

Define a future adapter architecture where different inputs can eventually produce CraftDAG documents or VoxelPlans:

Prompt / template config → CraftDAG
Existing .schem → VoxelPlan
Future sketch/image input → CraftDAG or VoxelPlan
Future structure library → CraftDAG templates

Design principle

CraftDAG core should remain deterministic and small. Input adapters should live around the core and should not pollute schema/compiler responsibilities.

Suggested design

Possible package boundaries:

• @craftdag/adapter-template
• @craftdag/adapter-schematic
• @craftdag/adapter-llm
• @craftdag/adapter-sketch later

Each adapter should expose a clear output contract:

• produce CraftDagDocument, or
• produce VoxelPlan directly when semantic recovery is unavailable

Non-goals

• Do not add OSM/geographic generation now.
• Do not make adapter architecture block the current MinePilot MVP.
• Do not let adapters bypass validation when producing CraftDAG.

Acceptance criteria for a design doc

• A short docs/ADAPTERS.md exists.
• It explains input adapter boundaries.
• It explains when an adapter should output CraftDAG vs VoxelPlan.
• It lists first candidate adapter: schematic-to-VoxelPlan.

[madawei2699]

Roadmap note after the schematic-preview MVP:

This issue is still useful, but it should probably follow the new component/LLM authoring track:

• Design architectural component primitives for LLM-authored builds #31 Design architectural component primitives for LLM-authored builds
• Implement component-plan expansion into CraftDAG #32 Implement component-plan expansion into CraftDAG
• Create LLM authoring contract for CraftDAG plans #33 Create LLM authoring contract for CraftDAG plans

The reason is that import/adapters are valuable, but the next core unlock is a safe intermediate component IR: more expressive than raw coordinate nodes, but still deterministic and expandable into validated CraftDAG. Once that layer exists, adapters can target either VoxelPlan or the component/CraftDAG layer depending on how much semantic structure they can recover.