38 lines
3.1 KiB
Markdown
38 lines
3.1 KiB
Markdown
# 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.
|