Future: Define input adapter architecture

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.

Start by reviewing the issue's proposed adapter boundaries and the repository's CraftDAG and VoxelPlan pipeline. Create docs/ADAPTERS.md covering adapter boundaries, when to output CraftDAG versus VoxelPlan, and the schematic-to-VoxelPlan adapter as the first candidate. Done means all three topics are documented without adding OSM generation or blocking the MinePilot MVP.