shacraft-core/docs/VERIFICATION.md

Local MVP verification

Date: 2026-09-14. Test environment: Linux x86_64, AMD Ryzen 7 1700, Rust/Cargo 1.96.0, Node.js 22.22.3, Python 3.14.4. Exact versions are recorded in environment.json. Each release archive records its source revision in RELEASE.json. The verified implementation is b6ba064; the subsequent English documentation update does not alter runtime files. Raw machine reports and historical command output are preserved as recorded.

Automated checks

bash scripts/verify.sh
cargo build --release --workspace --locked
node scripts/check_server.mjs --binary target/release/shacraft-server --output artifacts/server-e2e-release.json
node scripts/check_mcp.mjs --binary target/release/shacraft-server --output artifacts/mcp-sdk.json
node scripts/benchmark_server.mjs --binary target/release/shacraft-server --output artifacts/server-benchmark-final.json

verify.sh exited with code 0: formatting, Clippy with -D warnings, 84 Rust tests (core 30, content 11, compat 17, MCP 8, server/WASM 18), 6 JavaScript tests, a separate storage crash check, and debug HTTP/WebSocket scenarios. Full log.

The release run passed 14 scenario groups, covering resource/authentication checks, an incompatible manifest, two clients, authoritative movement, unreachable edits, real break/place actions, sequential revisions, late join, immutable templates/isolation, chat, entity events, reconnection, complete Spleef and reset, disconnected-player cleanup, and SIGKILL followed by recovery of blocks, entity properties, and settings. Report.

The independent MCP SDK 1.30.0 passed initialize/notification/ping, 17 tool schemas, 4 resources, the prompt, durable edit/replay/conflict/undo, plan/commit/retry, PNG image content, entity CRUD, settings, metrics, and reset. SDK report. Install the independent client to reproduce this check:

npm install --prefix artifacts/mcp-sdk --no-package-lock @modelcontextprotocol/sdk@1.30.0
SHACRAFT_MCP_SDK="$PWD/artifacts/mcp-sdk/node_modules/@modelcontextprotocol/sdk" node scripts/check_mcp.mjs --binary target/release/shacraft-server --output artifacts/mcp-sdk.json

The game client does not depend on Node.js or the MCP SDK; they are verification dependencies. The initial published implementation also passed GitHub Actions.

Catalog and interoperability

The catalog is compared with an independent projection of the official reports across every canonical state, property/default, and entity type. Geometry, slab/stair/door orientations, contextual cases, and entity dimensions are checked separately. Repeating the full report/API extraction and original asset generation reproduced the files byte for byte: reproducibility report.

The 17 converter tests cover typed NBT, compression modes/external chunks, palettes, negative coordinates, unknown data, offsets/3D biomes, removal of stale chest data, original checksums, no-overwrite behavior, invalid input, entity creation/movement/deletion, and a separate entity fingerprint.

The official Java 26.2 codecs read the exact export (1 chunk, 3 blocks, 1 entity), edited export (2 chunks, 3 blocks, 1 entity), and new export (2 chunks, 2 blocks). nbtlib 2.0.4 checked Sponge tags and their numeric types. Machine-readable results, commands and limits. These checks invoked public codecs without launching the Minecraft game/server; they were not gameplay tests.

Memory and tick work

Budgets were recorded in the script before the run: 256 MiB for the server process with 10 clients, and sampled tick-work p95 ≤50 ms. The full catalog was enabled. One server contained 5 built-in/demo worlds and 1, 10, then 100 additional immutable lobby forks. Active phases ran 10 clients in one shared-world region and in separate worlds, with movement/jump input at 20 Hz for 15 seconds each; metrics were sampled every 100 ms. All clients then disconnected. Linux VmHWM also captured the process peak, including intervals between samples.

Final run:

• 1 / 10 / 100 idle forks: maximum RSS 50.28 / 50.35 / 50.50 MiB.
• 10 clients in one shared world: RSS/VmHWM 57.00 MiB, tick-work p95 9.54 ms.
• 10 clients in 10 worlds: RSS/VmHWM 59.65 MiB, p95 7.33 ms.
• After disconnect: 0 players and 0 active worlds; RSS remained 59.65 MiB because of retained cache/allocator memory. Zero active worlds does not mean zero RSS.
• The cache limit was respected in every sample; outgoing queues and active worlds were measured. Both budgets set before the run passed.

Full phases and raw samples. The p95 is calculated from samples of the last tick's work, not network latency or the complete continuous sequence of ticks. This is a short local movement test; vanilla simulation workloads, thousands of players, and unbounded user worlds are not included. No comparison with Paper/NeoForge was performed.

The separate stage-one storage benchmark is preserved in storage-benchmark.json: 256 unique sections, a cache of 8, 100 forks, traversal beyond cache capacity, and independent edit/reset operations. The immutable blob count remained 256 after fork creation. This is a synthetic core profile with two block states, separate from the full server benchmark.

Browser and distribution

The browser verification record describes real screenshots/DOM inspection, the catalog, partial shapes, entities, a fresh connection without the full registry, the gallery, reconnection, and the verified resource cache. This setup showed 144 FPS; that number should not be extrapolated to other devices.

python3 scripts/make_release.py and its --binaries variant create an archive from a clean Git commit, add RELEASE.json with each file's SHA-256, and verify every file by rereading the archive. An adjacent .sha256 file checks the entire archive. The b6ba064 source and Linux binary archives were extracted again, every manifest entry was verified, an offline Cargo source check passed with cached dependencies, and the extracted Linux server started successfully using resources from its archive. Its health endpoint, default worlds, client page, and public resource hashes were verified. The packaging and extraction verification reports are stored alongside the local archives under artifacts/.

Acceptance boundaries

The primary A-CORE/SERVER/CLIENT/MCP/SPLEEF milestones are supported by the tests and browser inspection listed above. B-CONTENT, B-PACKAGES, B-INTEROP, and B-PERSISTENCE are implemented within the documented profile. B-MEMORY is supported by the specified workload, not arbitrary scale. The broader items in the original ACCEPTANCE document (a long soak, all Minecraft gameplay contexts, all external-world variants, and a real Minecraft playtest) are not claimed as passed. There is no claim of complete vanilla simulation, hardware fault tolerance, or memory savings relative to Paper.