3.1 KiB
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.