Build on NoderaMC

The wire protocol, the engine SDK, what a mod has to do to be compatible, and where the work is going.

The four normative documents

Everything else under this section is mirrored from the repository rather than rewritten for the site, because these are documents that already have to be correct and a second copy would start being wrong immediately.

Document	Answers
Wire protocol	The frame, its message families, and how two builds from different releases negotiate what they can say to each other. Read it before you put bytes on a socket.
Engine SDK	The deterministic region engine's public surface, and the rules a caller keeps to in order to stay deterministic.
Mod compatibility	What another mod may and may not do inside a validated region. Written for mod and modpack authors: it is the answer to "will my pack work".
Roadmap	Every task in every category, its status and what it depends on.

Determinism is the project's central bet, which is why the SDK is a normative document and not a convenience: if two honest peers cannot reproduce the same result from the same inputs, nothing downstream of that works.

Where the code is

One tree, four toolchains. Nothing may hardcode a directory: the root layout.properties is the one table, every build and script reads it, and LayoutManifestTest fails the build when the file and the tree disagree. A relocation is an edit there plus a git mv.

Directory	What it is
`library/java/core`	Pure Java, Minecraft-free, depends on nothing but the JDK.
`library/java/engine`	The deterministic engine and the validation API.
`library/java/transport`	The wire protocol and its transports.
`library/java/storage`	Event-sourced and on-disk world storage.
`library/java/endpoint`	What a Minecraft-hosting process needs in order to be a node, with no Minecraft in it.
`library/java/testing`	The shared test library and the live harness.
`peer`	The peer API, and the always-on headless node (`nodera-headless`) the companion app supervises.
`endpoints/neoforge-mod`	The only place Minecraft types may appear.
`endpoints/paper-plugin`	The Paper/Folia endpoint plugin.
`library/rust/nodera-{codec,core,service}`	The shared Rust crates: wire codec, app core, service runtime.
`tracker`, `rendezvous`, `telemetry`	The three services.
`app`, `app/ui`, `library/ts/nodera-ui`	The Tauri companion, its interface, and the kit both frontends share.
`web`	This site.

The gate

A change lands green or it does not land.

./gradlew check          # compile + every Java unit test
cargo test               # the Rust workspace: unit + cross-language conformance
cd app && cargo test     # the companion is a SEPARATE cargo workspace, held to the same standard
cargo fmt --check && cargo clippy --all-targets -- -D warnings
scripts/build-site.sh    # this website, including its own suite

The rule that surprises people

The interfaces may not claim a capability the system does not have, and that is enforced by tests rather than by review. It applies to this website too: every capability claim on the landing page and in these docs has a row naming the repository file that backs it and the string that must be found there, and the build fails when either side moves.

The practical consequence for a contributor is that softening a statement is a code change, and so is strengthening one. If a page says a thing works, something in the tree has to say so too.