# Decisions and boundaries

## D001. Independent Rust workspace

The core is a library. The server, MCP, and converter are separate executable components. The shared registry, coordinates, and operations are available through a public API. The server does not load graphics or external services.

## D002. Storage and end-to-end verification first

Start with memory architecture and durability; connect the client before completing the full catalog. A small working milestone does not change the final requirements. Unfinished items remain in the plan.

## D003. The first test client runs in the browser

The first verification client uses a custom WebGL2 renderer without an existing game engine. This makes it quicker to test two connections and MCP on a local machine. The core and server remain in Rust. This client does not count as an implemented native Rust client; a standalone native release and Launcher integration require a separate step. The client must not dictate the server's storage format.

## D004. The server cannot trust the client's claims about its own integrity

Manifests and hashes verify compatibility and downloaded files. The server validates game actions and sends only the necessary data. A self-check protocol cannot guarantee a complete ban on modified clients running on devices controlled by players. Distribution signing and launcher integration are separate tasks.

## D005. Minecraft compatibility is an adapter

The native world format is not a copy of Anvil. Converter and export profile versions are explicit. Unsupported data must not be silently replaced with air. A catalog of names is not equivalent to implementing shapes, collisions, behavior, and round-trip preservation.

## D006. Safe local defaults

The server listens on localhost. The control API requires a separate token that the ordinary game client never receives. All queues and request sizes have limits. Test data directories are separate from real worlds.

## D007. Versions and contracts are provisional

`CONTRACT.md` is an initial specification for parallel development, not a promise of a stable public API. Changes are agreed before dependent implementation and reflected in the documentation. Edit atomicity, pinned templates, registry limits, and network synchronization limits require particular attention.

## D008. Durable storage with SQLite/WAL

The first implementation uses SQLite with transactions, WAL, `synchronous=FULL`, a bounded page cache, and a lock that prevents a second writer. Sections remain custom compact binary data; SQLite stores references, metadata, and history. This lets us verify the game format without also inventing a reliable transaction mechanism. File size, WAL size, and SQLite's own memory are accounted for separately.

## D009. Conservative undo in the first milestone

Undo is allowed only at the latest revision created by the target edit. Any subsequent operation, including returning a block to its previous value, prevents that undo. This is stricter than future selective undo, but prevents the loss of later changes. The API states this limitation explicitly; resetting an arena is also a history boundary.