last-hearth/docs/m3-verification.md

M3 implementation and verification — The Last Hearth

Updated: 2026-11-02. Scope: the M3 home-building systems and automated evidence. This record does not claim a two-player acceptance playtest, a general physics simulation, production readiness, or completion of any launch checklist checkbox. See the roadmap, M2 evidence, architecture, and launch criteria.

M3 implementation present

Area	Behavior	Boundary
Room and shelter	Flood-fill from the player's head is limited to 7 × 7 × 5 cells (245 max), with a one-second, 256-entry cache. Building/room edits invalidate geometry. Closed doors block weather; open doors expose a side; roofs and structural openings change shelter. Unknown/unloaded probes fail exposed.	Approximate room model, not material-specific insulation, wind simulation, or persistent smoke diffusion. No exact guarantee on large spaces beyond the bounded region.
Ventilation and fire	A closed room is sheltered but unventilated; a roof vent or open door admits exhaust. An enclosed, unvented lit hearth reports smoke and applies the existing bounded damage rule.	No chimney path simulation or stored smoke concentration. The vent is the M3 exhaust control.
Building palette	Craftable stone foundation, timber frame, wall, roof, stairs, open/closed door, reed-lattice window, and roof vent. Doors are reversible; rotation is supported through native facedir metadata where applicable. Recipe index includes M3 items.	Window art is a procedural placeholder; no polished building textures or animation are claimed.
Support changes	Existing placement graph limits remain: two horizontal construction links and 16 vertical blocks. can_dig refuses removing a support if bounded connected construction would lose a valid support; unknown/unloaded dependency probes fail closed. Dependencies cannot cross household claim ownership.	Refusal instead of collapse. This is intentionally conservative, bounded support validation—not a general structural solver. If an engine/mod forcibly deletes nodes outside callbacks, no cascade guarantee is claimed.
Household roles	Versioned schema-1 access world record; missing record defaults empty. Owners may grant up to 16 named resident (build/dig/workstation use) or storekeeper (storage only) members using /claim share <player> <role>. /claim unshare, /claim list, and /claim remove manage grants. Invalid roles/usernames and ambiguous overlapping claims deny.	No new numeric schema version; this is an additive record kind. Member accounts are not authenticated/linked by this prototype.
Protected storage	Craftable 24-slot storage can be placed only within a claimed homestead. Every open and inventory put/take/move is authorized. Storekeeper is limited to storage; removal requires empty inventory and owner/resident authority. Existing container owner metadata prevents a later claim from adopting another household's contents.	Node inventories use engine metadata; no transactional guarantee beyond Luanti's normal persistence. No shared ownership transfer protocol.
Comfort	Craftable rain cloak toggles persisted player metadata; it slows wetting and adds modest warmth. A sheltered drying rack accelerates drying; hearth heat also dries.	Small prototype values, not balance acceptance; clothing wear, item durability, and broader clothing progression remain future work.
Claim visibility	/claim show reports coordinates and emits temporary player-local boundary markers.	Markers are a convenience, not a complete 3D boundary renderer or client-independent map overlay.

Automated verification on this Windows host

• Contract: Node.js 24.22.0, Luanti 5.18.0, game 0.4.0-m3, save schema 1.
• Real-engine integration: scripts/run.mjs test passed after M3 integration. The pinned engine compiled 43 Lua files, ran 19 isolated suites / 281 assertions, and passed native registry/craft/resource/enclosure and stationary actor smoke. The tests exercise role policy, claim commands, room/vent behavior, storage and removal denial; they do not emulate two real players or prove appeal/comfort.
• Node tooling/assets: node --test tests/tooling.test.mjs tests/assets.test.mjs passed 31/31 against the bumped release. It covers reproducible package and asset inventory/path protections. Optional full codec decoding was not run; Ogg framing/CRC/hash checks did run. Windows did not grant file-symlink privilege; directory-junction protections were tested.
• Diff hygiene: run the existing line-ending-aware git diff --check workflow.
• No separate Lua interpreter, clean-machine run, Linux/macOS native certification, browser client, sustained multiplayer load, or production run is claimed.

M3 two-player acceptance still required

1. In a disposable world, have two real clients create separated homesteads. Owner A builds a cabin with foundation, frame, wall, roof, door, window, vent and storage; owner B shares as resident, then as storekeeper in a separate check.
2. Verify resident can build/use and access household storage; storekeeper can use storage but cannot place/dig blocks or use other workstations. Revoke each role while clients remain online and verify access denies immediately. An outsider must not open, move, take, place, dig, or indirectly access either household's assets.
3. Check /claim show, release and restore a claim, reconnect, server restart, and a nonempty storage refusal. Verify old worlds with no access map load unchanged.
4. Build a lean-to and a small enclosed cabin. Compare displayed exposure, wetness, cloak and drying-rack outcomes. Test closed door, open door, vented hearth and unvented hearth; feedback must explain comfort/smoke differences.
5. Attempt to remove a foundation supporting a wall/roof; removal must be refused without changing nodes. Then remove an independent block; it should succeed. Test cross-claim supports, unloaded edges/restarts and ordinary natural terrain.
6. Record exact engine/game, save fixture, client count, actions and reproducible defects. Do not claim a human pass from engine harnesses or screenshots.

M1 voluntary repeat-play and performance/network acceptance, M2 unfamiliar-first-night acceptance, and operator approval of shared climate coordinates also remain separate open gates. M3 implementation supports beginning M4 engineering by explicit user direction, but M3 is not human-accepted until the two-player cabin and permission checks are observed and recorded.