Future: Explore redstone module support for functional builds

[madawei2699]

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 Define Voxel Plan internal representation #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.

[madawei2699]

Design clarification: redstone should be module-verified, not browser-simulated

After reviewing the existing Minecraft redstone ecosystem and the likely product risks, this issue should stay focused on verified RedstoneModule support, not a general redstone simulator or arbitrary circuit synthesis system.

What exists in the ecosystem

• WorldEdit can copy/paste structures containing redstone, but it does not design or verify redstone behavior.
• CraftBook-like plugins abstract redstone/logic with server-side mechanics, but that changes the runtime model and is not the same as generating vanilla-compatible structures.
• Carpet-style tooling is useful for real Minecraft smoke tests and technical validation, but it is not a schema-driven generator.
• Tutorials and schematics provide fixed human-authored designs, but not parameterized, validated, explainable modules.

This leaves a useful gap for CraftDAG:

schema-driven vanilla redstone/automation modules
→ deterministic expansion
→ valid block states / block entities
→ schematic export
→ material/layer/tutorial/troubleshooting output
→ real Minecraft smoke-test evidence

Strategic non-goals

Do not make this issue about:

• A complete browser-based Minecraft redstone tick simulator.
• Arbitrary redstone circuit synthesis.
• A redstone IDE.
• A WorldEdit/CraftBook/Carpet replacement.
• LLM-generated raw redstone coordinates.
• Guaranteeing arbitrary redstone correctness without verified module fixtures.

Recommended implementation direction

Use a staged module approach:

Stage 1: redstone block-state support

Support export/validation for a small set of vanilla redstone blocks:

• redstone_wire
• redstone_torch
• repeater
• comparator
• lever
• button
• redstone_lamp
• piston / sticky_piston
• observer

The first goal is not behavior simulation; it is correct block-state placement, facing, materials, bounds, and schematic export.

Stage 2: simple verified modules

Add a small RedstoneModule authoring surface or equivalent module-expansion pattern for modules that do not require container NBT first:

• LeverLampToggle
• RepeaterClock
• PistonDoor2x2

Each module should have:

• version target, initially Java Edition only
• anchor and facing
• bounds
• emitted block states
• material list
• initialization instructions
• static validation rules
• fixture tests

Stage 3: block entity support for automation

Only after basic block-state modules are solid, add block entity/NBT support for automation modules:

• hopper inventory
• chest/barrel inventory
• dropper/dispenser inventory
• furnace inventory

Then add modules such as:

• ItemSorterSlice
• AutoSmelter
• DropperElevator
• StorageWall

Without block entity support, these should not be advertised as fully working automation modules.

Stage 4: real Minecraft smoke-test notes

For each verified module, record manual or automated Minecraft validation notes:

• Java version tested
• WorldEdit paste result
• initialization steps, such as toggling a lever once
• known limitations
• server/version caveats

Browser preview should show structure and explanation, but real Minecraft remains the source of truth for behavior.

Validation layers

Prefer three validation layers:

1. Static schema/block-state/bounds validation
2. Module-specific rule validation
3. Real Minecraft smoke-test evidence

A lightweight signal-flow preview may be useful later for education/debugging, but it should be clearly labeled as explanatory, not as a full Minecraft-equivalent simulator.

Product implication for MinePilot

MinePilot should eventually show:

• redstone/automation category
• 3D preview
• critical block highlights
• working principle
• initialization steps
• common mistakes
• Java version notes
• material list
• layer guide
• schematic export

This keeps the scope commercially useful without turning CraftDAG into a full redstone simulator.