Blockworld

In plain words: App: Blockworld (Minecraft missions)

Partial 3 min read 1 glossary terms 17 connected pages
The short version written for the Snayu team

An app that lets the Assistant act in a Minecraft-style world for one finite mission, such as building a reviewed blueprint on a private plot, with receipts for every placed block and recovery after interruption.

Why read it: Read this before any Minecraft or game-world work, to understand the mission contract and what is and is not wired up.
  1. 1A mission is bound to a specific bot, world, plot lease, blueprint, tools and budgets; no public autonomy, admin commands or cross-plot power.
  2. 2The game server stays the truth for blocks and inventory; Blockworld keeps mission, lease, action and receipt records.
  3. 3Today only an inactive one-block test workflow exists; it is not registered at boot and does not connect to Minecraft.

Partial Inactive one-block test workflow only; no live server or bot deployment.

Words on this page, decoded click one for its card

In this section 6 pages

Companion lab Blockworld: Companion lab An experimental Minecraft profile where you speak or type a short instruction (Slovak, Czech or English) to a controlled wolf NPC, see it queued, and get a result tied to what the server actually did. open → Horizon assist Blockworld: Horizon assist An experimental profile where the operator speaks a short instruction while playing and a separately controlled Horizon game client performs one bounded action (follow, build a few cells, look) and reports what it observed. open → Playing with a companion Blockworld: Playing with a companion User stories and acceptance trials for playing Minecraft with a companion: prepare, speak, observe, follow, build a few blocks and leave, with clear feedback and a quiet idle state. open → Mission Blockworld: Mission How one Minecraft mission is admitted (exact bot, world, plot, blueprint, deadline and budgets) and how a single block placement is prepared, frozen and reviewed before it can run. open → Sentinel Blockworld: Sentinel (action guard) The guard between the Assistant's proposed action and the game server: it checks each read or effect against the mission, and only issues a receipt when the server's own evidence confirms the result. open → Continuity Blockworld: Recovery after interruption Where each kind of truth lives (world, app records, mission/action records, volatile adapter state) and how Blockworld reconciles an uncertain action after a crash or restore before continuing. open →
The original text Underlined words open their plain-English card.

The inhabitant wakes for one mission. When its Mind goes quiet, the wall it placed may remain. Blockworld keeps the purpose, lease, placements, and receipts beside that consequence so the next awakening can begin from reconciled world truth.

A reviewed blueprint on a private plot is the first journey: establish the finite mission and its memory, have Sentinel guard each crossing into the server, then reconcile world truth after interruption or restoration.

Contract

blockworld.inhabitant revision 2 publishes blockworld.bounded_mission@2. Admission binds a finite mission, server mode, authenticated bot, exact world epoch and capabilities, plot lease, blueprint, tools, and budgets. Its return is verified action receipts, a durable mission cursor, and completion or exact non-completion. Public autonomy, unrestricted exploration, administrator commands, remote shell, and cross-plot power remain outside the mission.

Revision 1 and blockworld.bounded_mission@1 remain historical design contracts, retired in favour of revision 2. Their mission authority, five reads and five effects, verified receipts, and refusal to repeat an uncertain placement remain unchanged. Revision 2 adds required preparation, exact command/review binding, and native action continuity for the bounded placement operation. These requirements do not reinterpret revision 1 or establish parked-state compatibility. This design retirement defines no executable migration; State of Work owns registration and delivery.

The bounded-mission code slice is an inactive, one-block test workflow assembled explicitly with inert effects. It is not registered at normal boot and does not connect to Minecraft. The separate Horizon-assist profile supplies an experimental attached-client passage. State of Work keeps their evidence and remaining game checks distinct.

Blockworld records why the inhabitant acts and what it can account for: inhabitant, mission, world-local relationship, project, memory-candidate, lease, action, and receipt records. The server remains authoritative for blocks, entities, inventory, and game time. An Avatar may project the LichAssistant through the inhabitant, but gains no mission, inventory, lease, or world effect.

Your Minecraft client

Prism Launcher manages your Minecraft client instances, including the game version and modloader. In this design, you join the world through that human client; the inhabitant connects separately through an admitted bot identity and client adapter. The server owns the world, and Sentinel guards admitted effects.

A singleplayer world opened to LAN, or an existing external server, can be considered for attached mode only when its endpoint is reachable and bot access is explicitly authorized. Admission remains limited to the capabilities the server actually offers; client observation cannot supply missing server proof. The first managed fixture below remains the proving target.

A Prism Launcher client on macOS is separate from LychD's Linux host requirement. LychD Prism is a different component: its designed block-export path supplies blueprints for separate mission admission. An existing launcher instance does not establish game/modpack compatibility or provide Blockworld integration; State of Work records delivery.

Server

Choose one closed mode before admission:

[blockworld.server]
mode = "managed" # managed | attached
Mode Admitted control Limit
managed Rootless server Quadlet, declared world volume, configuration, exact mod/plug-in set, lifecycle and recovery receipts. Server or modpack changes require a separately admitted deployment and operator approval. The bot receives no administrator power.
attached Bot identity, endpoint, credentials and client adapter. No server files, console, lifecycle, snapshot, plug-in or mod authority. Admit only capabilities the external server offers.

The first proving fixture uses managed mode: a private, allowlisted, online-mode server and a dedicated non-operator bot. An attached server may offer weaker observation or verification. Before the bot wakes in either mode, pin mode, server identity, protocol, capability/modpack revision, and Sentinel availability. A mode change must drain missions and create a new server generation and world epoch.

Enter by question

Companion lab develops a separate opt-in Fabric NPC actuator with native command admission, a finite operator queue and CPU-ready speech. Its actor and experimental delivery boundary do not replace the authenticated-player bounded mission.

Horizon assist defines the separate experimental attached-client passage for bounded spoken or typed actions. It does not weaken the managed mission's receipt contract. Playing with a companion gives user stories, acceptance trials and the order of preparation for multilingual voice, following and shared building.

Mission defines the work the inhabitant may attempt. Sentinel guards each crossing into the server. After interruption or restoration, Continuity reconciles what remains before another awakening begins.

Workflow · Containers · Security · Composition Portfolio