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](roadmap.md), [M2 evidence](m2-verification.md),
[architecture](architecture.md), and [launch criteria](launch-features.md).

## 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.