Future: Explore redstone module support for functional builds

Context

CraftDAG currently focuses on architectural Minecraft builds: rooms, roofs, openings, platforms, bridges, small shrines, towers, and similar bounded structures.

This is useful, but the long-term product value may be stronger when MinePilot can help players build functional mechanisms that are harder for ordinary players to design by hand.

Redstone is a natural candidate:

simple architecture = many players can hand-build it
redstone automation = many players need planning, tutorials, validation, and reusable modules

This issue records the future direction. It should not replace the current ComponentPlan/MinePilot model-assisted generation work.

Value thesis

MinePilot becomes more valuable if it can generate and explain functional Minecraft builds, not only static structures.

Examples:

• hidden piston doors
• automatic farms
• item sorters
• auto-smelters
• dropper elevators
• storage systems
• redstone lamps and triggers
• basic clocks and signal lines

These are harder for casual players to reason about than cottages or towers because they involve spatial layout, signal direction, tick delay, block orientation, and version-specific behavior.

Design principle

Do not start with arbitrary redstone circuit synthesis.

Start with known, bounded, reusable redstone modules.

Good first direction:
RedstoneModule library
→ static validation
→ deterministic expansion
→ CraftDAG / VoxelPlan
→ preview / materials / layer guide / schematic

Bad first direction:
User asks for any circuit
→ model invents arbitrary redstone layout
→ no validation
→ likely broken in-game

Possible future model

A future ComponentPlan may include architectural and functional components:

ComponentPlan
├── Architectural components
│   ├── RoomShell
│   ├── Platform
│   └── Roof
└── Functional / Redstone components
    ├── RedstoneClock
    ├── SignalLine
    ├── PistonDoor2x2
    ├── ItemSorterSlice
    └── AutoSmelterModule

Each redstone module should still expand into ordinary CraftDAG/VoxelPlan outputs. Redstone should not bypass the compiler pipeline.

Candidate module stages

Stage 1: Simple interaction modules

• LeverInput
• ButtonInput
• PressurePlateInput
• RedstoneLampLine
• DoorTrigger
• SimpleSignalLine

Stage 2: Small redstone mechanisms

• RedstoneClock
• RepeaterDelay
• DispenserTrap
• PistonDoor2x2
• HiddenLightSwitch

Stage 3: Automation cells

• SugarCaneFarmCell
• BambooFarmCell
• AutoSmelterModule
• DropperElevatorSlice
• HopperLine
• ItemSorterSlice

Stage 4: Modular arrays

• ItemSorterArray
• FarmCellArray
• MultiFloorItemElevator
• StorageWall

Stage 5: Complex systems

• Automated storage room
• Multi-module farm hub
• Factory-like automation base

Stage 6: Advanced circuit synthesis

• logic gates
• adders
• memory cells
• programmable circuits

Stage 6 is explicitly out of scope until earlier module systems are reliable.

Validation requirements

Redstone modules need stronger validation than ordinary architecture.

Potential checks:

• required bounding box and clearance
• orientation and facing direction
• signal input/output locations
• required air gaps
• piston push constraints
• hopper/comparator/repeater orientation
• clock period/tick delay constraints
• module material requirements
• Java Edition version assumptions

The first version does not need a full Minecraft tick simulator, but it should validate module invariants statically.

Agent authoring guidance

Agents should select and configure known modules, not invent arbitrary redstone wiring.

Good:

{
  "id": "sorter_row",
  "type": "ItemSorterArray",
  "params": {
    "anchor": [2, 1, 2],
    "slots": 8,
    "direction": "east"
  }
}

Bad:

{
  "id": "custom_circuit",
  "type": "RawBlocks",
  "params": {
    "description": "a complicated redstone computer"
  }
}

Non-goals

• Do not add this before MinePilot model-assisted ComponentPlan generation is useful.
• Do not support arbitrary redstone circuit synthesis initially.
• Do not let models emit raw redstone block coordinates as the primary interface.
• Do not add live Minecraft bot execution here.
• Do not promise correctness without validation.
• Do not support every Minecraft Java version at once.

Acceptance criteria for future design work

When this becomes active, start with a design doc such as:

docs/REDSTONE_MODULES.md

The doc should define:

• module boundary and naming
• module input/output semantics
• orientation model
• validation rules
• expansion into CraftDAG/VoxelPlan
• first 3-5 candidate modules
• non-goals around arbitrary circuit synthesis

Suggested timing

Revisit after:

1. MinePilot #15 model-assisted ComponentPlan generation is working.
2. The ComponentPlan validation/repair loop is mature enough to handle module-specific errors.
3. CraftDAG has stable material/orientation conventions.

Related product direction

This may be more valuable than plain decorative building generation because many Minecraft players can hand-build simple houses, but fewer can design correct redstone automation systems.

When this direction becomes active, start with docs/REDSTONE_MODULES.md and review the ComponentPlan validation/repair loop, CraftDAG material and orientation conventions, and MinePilot #15. The design is done when it defines module boundaries, input/output semantics, orientation, validation, CraftDAG/VoxelPlan expansion, initial modules, and non-goals for arbitrary circuit synthesis.