ONE FAMILY NAME, SEVERAL CONTRACTS
Read the prefix before deciding what the bytes mean
NCM: is not a serialized payload version. In the current avatar renderer it selects a small built-in alias table whose entries all resolve to the standard boy NCM2 bytes. NCM1: is the older palette-and-cuboid representation retained by the general source codec. NCM2: is the compact source-grid representation used by the current boy and girl fixtures. NCM4: is a separate self-contained animated character representation with bounded cuboids, bones, groups, actions, canonical Base64URL, and CRC32C.
NCM3: is a separate declarative building language. It stores canonical NiceChunk material IDs and ten bounded construction opcodes instead of character boxes or bones. It is not a backward-compatible NCM2 or NCM4 upgrade, and the building path never treats a character body as a building. NCF1. is separate again: it represents forged equipment and is independently decoded, meshed, cached, and currently attached through the established NCM2 avatar path.
The safest mental model is a router with explicit destinations. A family resemblance in the prefix does not imply the same byte layout, account, validator, trust level, scale, or renderer.
The alias itself contains no palette or cuboid payload.
The general source codec reads NCM1 and NCM2; the shared avatar renderer dispatches NCM2 or NCM4 after alias resolution.
They use different prefixes, bytes, validation boundaries, hashes, and runtime reconstruction paths.
RGB PALETTE AND BIT-PACKED CUBOIDS
NCM2 preserves occupied shape and color, not the authoring file
The VOX conversion path groups occupied voxels into greedy, non-overlapping cuboids of one color. NCM2 then writes the original grid dimensions, an integer scale, cuboid and palette counts, one RGB triplet per palette entry, and a bit-packed cuboid stream. Origins use enough bits for their axis; extents are stored as size minus one using the corresponding axis width.
That representation is exact for the occupied RGB voxels covered by its non-overlapping cuboids, but lossy relative to the authoring file. It does not preserve source material identifiers, object names, bones, textures, alpha, arbitrary rotations, or an editor hierarchy. Equal RGB values become one palette entry, and the runtime creates generated part names. A later consumer can reproduce the axis-aligned colored boxes, but it cannot recover authoring metadata that never entered the payload.
The checked-in 32 by 32 by 32 girl fixture uses scale 9, 70 cuboids, and 10 colors: 334 raw bytes become 451 NCM2 text characters, while the repository file is 452 bytes because it ends with a newline. The boy uses the same grid and scale with 56 cuboids and 8 colors: 261 raw bytes, 353 text characters, and a 354-byte file.
The unpadded NCM2 text is 451 characters before its file newline.
The unpadded NCM2 text is 353 characters before its file newline.
Dimensions and scale survive; authoring hierarchy and semantic bones do not.
CHUNK.JS AVATAR RUNTIME
NCM2 gains a heuristic rig, while NCM4 brings bones and explicit actions
After a built-in NCM: alias is resolved to the standard boy, the current shared avatar loader dispatches NCM4: to the strict animated-character codec and otherwise accepts NCM2: for the established static-villager path. Both branches center decoded cuboids above the ground and emit vertex and index buffers, but their rig and equipment capabilities differ.
NCM2 carries no skeleton. Chunk.js infers head, torso, left arm, right arm, and leg membership from generated geometry names and normalized spatial position, calculates pivots from the resulting bounds, and adds hand anchors for tools. Animation therefore belongs to the renderer's current rigging policy; it is not proof of a bone layout stored in the model code.
For NCM2, forged equipment is composed after the body has been decoded. A selected NCF1 payload is restored through the forge runtime cache, positioned at the inferred hand anchor, and appended to avatar draw data. NCM4 preserves its own twenty-bone skeleton and explicit actions, but current normal Play moving and mining state does not select those actions; its mesh currently reports equipment: [] and handAnchors: {}, so the established held-tool attachment path is not yet integrated.
NCM1 remains a general source-codec format rather than a current avatar-loader route.
NCM2 infers groups and pivots; NCM4 carries its bounded skeleton and actions.
The NCM4 branch currently returns empty equipment and hand-anchor fields.
PLAYERAPPEARANCE STORAGE
The player account proves who stored text, not that the text is a canonical model
PlayerAppearance reserves 2,048 bytes for UTF-8 model text. Its model-code validator rejects an empty value, an oversized value, invalid UTF-8, or text that does not begin with uppercase NCM. It does not parse NCM1, NCM2, NCM3, or NCM4; it does not decode Base64URL or verify CRC32C; and it does not inspect palette size, cuboid bounds, canonical encoding, geometry, bones, actions, or runtime cost.
modelKind is separately restricted to the male or female enum, but the validator never binds that enum to hair, proportions, colors, or any semantic feature in modelCode. A syntactically arbitrary string such as NCM followed by unrelated text can therefore satisfy this storage check even though no renderer can decode it.
The gameplay avatar session catches decode failures. If no working mesh exists it tries the built-in villager; otherwise it keeps the current mesh. This makes corrupt or unsupported appearance text survivable in the client, but fallback behavior is not retroactive on-chain model validation.
The fixed account layout zero-fills the unused remainder.
No colon, numeric version, payload canonicality, or geometry rule is required here.
The enum and model bytes are validated independently.
BUILDING PDA AND CANONICAL COMMANDS
NCM3 receives structural verification because shared buildings need stronger bounds
NCM3 starts with binary version 1, three dimensions, and a command count. Its ten opcodes cover BOX, REPEAT_BOX, X- and Z-oriented gable surface, trim, and fill variants, TREE, and FENCE. Every material operand must be one of the 81 current canonical IDs: 1 through 52, 55 through 77, or 96 through 101. The chain accepts at most 4,096 commands and 256 voxels on each declared axis.
The Building Program reads unsigned varints canonically, rejects overflow and redundant terminal zero groups, validates every origin and extent, checks repeat steps and procedural envelopes, rejects trailing bytes, and accumulates at most 262,144 conservative validation units. A zero-command payload is valid if the version and dimensions are valid and no trailing bytes remain. Later cuboids overwrite earlier voxels only when Chunk.js expands them; the chain applies the same deterministic command-cost formulas without allocating that voxel Map.
Production stores NCM3 metadata, payload length, and a SHA-256 commitment in one NCKBLD02 BuildingManifest. The raw NCM3 payload bytes live exclusively after the 64-byte headers of one to eight NCKBDT01 BuildingShard accounts; neither account type stores the NCM3: Base64URL string. Finalization recomputes SHA-256 over the ordered raw payload, parses the full command stream, rotates the declared footprint, and checks foundation fit and build height before activation. The NCBP decoder still present in the JavaScript codec is an early helper, not the deployed production account layout.
TREE is only a compact explicit building command. It does not invoke natural world generation, query a SurfaceDecorationTable PDA, or require tree-like material semantics: both supplied material IDs merely have to pass the canonical allowlist. The validator also permits empty or visually unhelpful structures. It proves bounded syntax and placement, not architectural quality.
IDs 1-52, 55-77, and 96-101 are accepted by both current JavaScript and Rust paths.
Ten declarative opcodes share one 262,144-unit conservative validation budget.
One manifest commits the ordered raw bytes held by at most eight data shards.
CLIENT RECONSTRUCTION AND COMPATIBILITY
Chunk.js builds the expensive products and currently applies one stricter memory guard
After the chain loader verifies ordered shards and the full SHA-256 digest, it restores the NCM3: text envelope for the codec. A dedicated building worker normally decodes commands, materializes deterministic local geometry, applies quarter-turn placement at one design voxel per world voxel, bakes light, builds terrain-compatible greedy meshes, separates visual materials, and emits compact collision masks. Transferable buffers return those products without copying their backing stores. The chain performs none of that rendering work.
The current JavaScript building path first applies the chain-equivalent 262,144-unit conservative command budget, then the voxelizer caps actual expanded cuboid writes at 262,144 and rejects more than 131,072 unique voxels. A single 256 by 3 by 256 BOX performs 196,608 writes and leaves 196,608 unique voxels. Its syntax, dimensions, allowed material, bounds, and command cost are acceptable to the NCM3 chain validator, yet the current client rejects it at the unique-voxel safety check. Until those ceilings are aligned, authors should stay at or below both limits to avoid this known incompatibility.
Overwrite-heavy designs expose the difference: every command retains its conservative validation-unit charge even if a later operation replaces its expanded voxels, while the client safety check measures the final Map size. The voxelizer separately caps actual expanded cuboid writes. Once accepted, placement and meshing can be reused through building caches, but the temporary voxel Map still determines peak reconstruction memory.
NCF1 does not close this NCM3 gap or provide an alternate building path. The forge runtime hashes raw NCF1 bytes with 32-bit FNV-1a, decodes component or baked-appearance geometry, builds a packed equipment mesh, and caches it separately. The backpack program derives forge requirements from the leading 108 header bits and computes the same design hash across the entire bounded 14- to 640-byte raw payload, including geometry, but that hash cannot reconstruct forge geometry and is unrelated to a BuildingManifest SHA-256 commitment.
Every command contributes its conservative formula cost; BOX and REPEAT_BOX equal attempted writes, while gable and TREE costs can overestimate.
This additional guard runs after the last-writer Map is materialized.
Structurally valid under the chain conservative validation-unit budget, but rejected by the current client Map limit.
PACKING, PLACEMENT, AND BOUNDED WORK
Five equations expose what is compact, what is authoritative, and what still costs memory
NCM2 saves repeated RGB and coordinate bits, NCM4 adds a separately bounded animated-character envelope, and NCM3 saves repeated construction intent. All defer visible meshes to Chunk.js. The equations below focus on the implemented NCM2 layout and transform plus the NCM3 overwrite rule, opcode budget, and production shard commitment.
NCM2 packed byte length
beta(n) = max(1, ceil(log2(n))) for n >= 1; b_cuboid = beta(P) + 2 * beta(Sx) + 2 * beta(Sy) + 2 * beta(Sz); B2 = V(Sx) + V(Sy) + V(Sz) + V(s) + V(C) + V(P) + 3P + ceil(C * b_cuboid / 8)The header uses unsigned varints for three source dimensions, integer scale, cuboid count, and palette count. Every palette entry costs three RGB bytes. The remaining cuboid fields are packed at widths derived from the palette and axis ranges; NCM2: plus unpadded Base64URL is the text envelope, not part of B2.
- V(n)
- Unsigned-varint byte length of nonnegative integer n.
- Sx, Sy, Sz
- Source voxel-grid dimensions.
- s, C, P
- Integer scale, cuboid count, and RGB palette count.
- b_cuboid
- Bits for one palette index, three origins, and three size-minus-one fields.
NCM2 cuboid-to-avatar coordinate transform
cx = x + (w - 1) / 2; cy = y + (d - 1) / 2; cz = z + (h - 1) / 2; p = (round((cx - (Sx - 1) / 2)s), round((cz + 1 / 2)s), round(((Sy - 1) / 2 - cy)s)); size = (ws, hs, ds)The converter centers source X, promotes source Z to avatar height, and reverses source Y into runtime depth. The half-voxel vertical offset and integer rounding reproduce the current Chunk.js avatar boxes exactly.
- x, y, z
- Minimum source-grid coordinate of one cuboid.
- w, h, d
- Source X width, source Z height, and source Y depth.
- p
- Integer avatar-box center after axis conversion and scale.
NCM3 deterministic overwrite rule
V(p) = m_j where j = max({ i | p in E(c_i) })E(c_i) is the set of voxel coordinates expanded by command or cuboid i. If several expansions cover p, the material from the latest one wins; if none covers p, the position is empty. The validator budget is separate: it charges each command conservative validation units even when its expanded voxels are later overwritten. BOX and REPEAT_BOX units equal attempted voxel writes, while gable and TREE families can overestimate them.
- V(p)
- Final canonical material stored at local voxel position p.
- E(c_i)
- Voxel positions expanded by the ith construction operation.
- m_j
- Material carried by the last covering operation.
NCM3 conservative validation-unit budget
o(BOX) = w*h*d; o(REPEAT_BOX) = n*w*h*d; Lx = ceil(w/2); Lz = ceil(d/2); o(GABLE_X, TRIM_X, FILL_X) = (2*Lx*d, 4*Lx, Lx*w*d); o(GABLE_Z, TRIM_Z, FILL_Z) = (2*Lz*w, 4*Lz, Lz*w*d); t = max(2, h-r); o(TREE) = 4*t + 8*r*(2*r+2) + 4; o(FENCE) = 2*len + 5*(ceil(len/spacing)+1); sum_i o(c_i) <= 262144; current client also requires |V| <= 131072These are the exact conservative command-cost formulas used by the JavaScript encoder and Rust validator for the ten opcodes. BOX and REPEAT_BOX equal their attempted voxel writes; gable and TREE formulas may overestimate the cuboid writes produced during expansion. The chain ceiling limits summed validation units. The additional Chunk.js ceiling limits final unique voxels, so overlap can reduce |V| without reducing the validation-unit total.
- Lx, Lz
- Number of roof layers across the selected gable axis.
- h, r, t
- TREE height, crown radius, and derived trunk height.
- |V|
- Number of unique voxels remaining in the current client Map after last-writer overwrite.
Production NCM3 shards and content commitment
S = ceil(B / 8192) <= 8 with 1 <= B <= 65535 for upload and B >= 5 for structurally valid NCM3 v1; W = sum_i ceil(B_i / 700); H = SHA256(P_0 || P_1 || ... || P_(S-1))B is the raw binary NCM3 payload length, not the NCM3: text length. The upload and storage envelope accepts 1 through 65,535 bytes, but even a zero-command structurally valid NCM3 v1 payload needs at least 5 bytes for its version, X, Y, Z, and command count. Each shard P_i is uploaded sequentially in writes of at most 700 bytes. Finalization hashes the ordered raw shard slices, while the client restores the NCM3: prefix only after loading and verifying those bytes.
- S
- Required BuildingShard count.
- W
- Minimum number of current payload-write instructions across all shards.
- H
- Authoritative 32-byte BuildingManifest content hash.
NCM2 writes a palette header and one compact bit stream
JavaScriptsrc/vox/ncm.jsexport function encodeNcmVox({ size, scale, cuboids }) {
const palette = [];
const paletteIndex = new Map();
for (const cuboid of cuboids) {
const color = normalizeColor(cuboid.color);
if (!paletteIndex.has(color)) {
paletteIndex.set(color, palette.length);
palette.push(color);
}
}
const bytes = [];
writeVar(bytes, size.x);
writeVar(bytes, size.y);
writeVar(bytes, size.z);
writeVar(bytes, scale);
writeVar(bytes, cuboids.length);
writeVar(bytes, palette.length);
for (const color of palette) writeRgb(bytes, color);
const bitWriter = createBitWriter();
const colorBits = bitWidth(Math.max(0, palette.length - 1));
const xBits = bitWidth(Math.max(0, size.x - 1));
const yBits = bitWidth(Math.max(0, size.y - 1));
const zBits = bitWidth(Math.max(0, size.z - 1));
for (const cuboid of cuboids) {
bitWriter.write(paletteIndex.get(normalizeColor(cuboid.color)) ?? 0, colorBits);
bitWriter.write(cuboid.x, xBits);
bitWriter.write(cuboid.y, yBits);
bitWriter.write(cuboid.z, zBits);
bitWriter.write(Math.max(0, cuboid.w - 1), xBits);
bitWriter.write(Math.max(0, cuboid.h - 1), zBits);
bitWriter.write(Math.max(0, cuboid.d - 1), yBits);
}
bytes.push(...bitWriter.finish());
return `NCM2:${base64UrlEncode(Uint8Array.from(bytes))}`;
}Palette insertion order is deterministic for the supplied cuboid order. Axis-specific bit widths make the compact stream much smaller than a JSON box list while retaining exact integer extents.
PlayerAppearance validates only a text envelope
Rustprograms/nicechunk_player/src/state.rspub fn validate_model_code(code: &[u8]) -> Result<&str, NicechunkPlayerError> {
if code.is_empty() || code.len() > APPEARANCE_MODEL_CODE_MAX_BYTES {
return Err(NicechunkPlayerError::InvalidCharacterCode);
}
let value =
core::str::from_utf8(code).map_err(|_| NicechunkPlayerError::InvalidCharacterCode)?;
if !value.starts_with("NCM") {
return Err(NicechunkPlayerError::InvalidCharacterCode);
}
Ok(value)
}This routine does not dispatch NCM versions, decode Base64URL, parse cuboids, test canonical bytes, or compare modelKind with model contents. The uppercase prefix check is intentionally much weaker than NCM3 building finalization.
NCM3 serializes bounded declarative commands
JavaScriptchunk.js/ncm/blueprint-codec.jsexport function encodeNcm3(blueprint) {
validateBlueprint(blueprint);
const bytes = [1];
writeVar(bytes, blueprint.size.x);
writeVar(bytes, blueprint.size.y);
writeVar(bytes, blueprint.size.z);
writeVar(bytes, blueprint.commands.length);
for (const command of blueprint.commands) {
bytes.push(command.op);
if (command.op === OPCODE.TREE) {
writeMaterial(bytes, command.trunkMaterial);
writeMaterial(bytes, command.leafMaterial);
[command.x, command.y, command.z, command.height, command.crownRadius].forEach((value) => writeVar(bytes, value));
continue;
}
writeMaterial(bytes, command.material);
if (command.op === OPCODE.BOX) {
[command.x, command.y, command.z, command.w - 1, command.h - 1, command.d - 1].forEach((value) => writeVar(bytes, value));
} else if (command.op === OPCODE.REPEAT_BOX) {
[command.x, command.y, command.z, command.w - 1, command.h - 1, command.d - 1, command.count - 1].forEach((value) => writeVar(bytes, value));
[command.dx, command.dy, command.dz].forEach((value) => writeSignedVar(bytes, value));
} else if (GABLE_OPS.has(command.op)) {
[command.x, command.y, command.z, command.width - 1, command.depth - 1].forEach((value) => writeVar(bytes, value));
} else if (command.op === OPCODE.FENCE) {
[command.x, command.y, command.z, command.length - 1, command.axis, command.spacing].forEach((value) => writeVar(bytes, value));
} else {
throw new Error(`Unsupported command opcode ${command.op}.`);
}
}
return `${NCM3_PREFIX}${base64UrlEncode(Uint8Array.from(bytes))}`;
}NCM3 writes a binary version, declared dimensions, command count, opcode, material IDs, and integer operands. The payload contains data only; it never evaluates imported JavaScript.
The Building Program parses dimensions, count, bounds, and BOX work
Rustprograms/nicechunk_building/src/building.rspub fn validate_ncm3_payload(slices: &[&[u8]]) -> Result<Ncm3Dimensions, NicechunkBuildingError> {
let mut reader = PayloadReader::new(slices);
if reader.read_byte()? != 1 {
return Err(NicechunkBuildingError::InvalidNcm3);
}
let dimensions = Ncm3Dimensions {
x: reader.read_var()?,
y: reader.read_var()?,
z: reader.read_var()?,
};
if !(1..=NCM3_MAX_DIMENSION).contains(&dimensions.x)
|| !(1..=NCM3_MAX_DIMENSION).contains(&dimensions.y)
|| !(1..=NCM3_MAX_DIMENSION).contains(&dimensions.z)
{
return Err(NicechunkBuildingError::InvalidNcm3);
}
let command_count = reader.read_var()?;
if command_count > NCM3_MAX_COMMANDS {
return Err(NicechunkBuildingError::InvalidNcm3);
}
let mut operation_budget = 0_u64;
for _ in 0..command_count {
let opcode = reader.read_byte()?;
match opcode {
1 => {
read_material(&mut reader)?;
let values = read_vars::<6>(&mut reader)?;
validate_origin(values[0], values[1], values[2], dimensions)?;
let w = plus_one_bounded(values[3], dimensions.x)?;
let h = plus_one_bounded(values[4], dimensions.y)?;
let d = plus_one_bounded(values[5], dimensions.z)?;
validate_cuboid_bounds(values[0], values[1], values[2], w, h, d, dimensions)?;
add_budget(
&mut operation_budget,
u64::from(w) * u64::from(h) * u64::from(d),
)?;
}The complete function continues with every other opcode, the shared conservative validation budget, material validation, canonical varints, repeat and procedural bounds, and a trailing-byte rejection. It returns the declared envelope for final footprint and height checks; it does not return a mesh.
Chunk.js materializes the last-writer map and enforces its extra ceiling
JavaScriptchunk.js/ncm/blueprint-codec.js/** Later commands overwrite earlier commands, matching a deterministic paint stack. */
export function voxelize(blueprintOrCuboids, sizeOverride) {
const blueprint = Array.isArray(blueprintOrCuboids) ? null : blueprintOrCuboids;
const cuboids = blueprint ? expandBlueprint(blueprint) : blueprintOrCuboids;
const size = blueprint ? blueprint.size : normalizeSize(sizeOverride);
const voxels = new Map();
let operationBudget = 0;
for (const cuboid of cuboids) {
validateCuboid(cuboid, size);
operationBudget += cuboid.w * cuboid.h * cuboid.d;
if (operationBudget > 262144) throw new Error("Expanded voxel operation budget exceeded.");
for (let y = cuboid.y; y < cuboid.y + cuboid.h; y++) {
for (let z = cuboid.z; z < cuboid.z + cuboid.d; z++) {
for (let x = cuboid.x; x < cuboid.x + cuboid.w; x++) {
voxels.set(`${x},${y},${z}`, { x, y, z, material: cuboid.material });
}
}
}
}
if (voxels.size > 131072) throw new Error("Expanded voxel safety limit exceeded.");
return voxels;
}Map.set implements deterministic replacement. This loop's first ceiling counts actual expanded cuboid writes; blueprint validation separately applies the chain-equivalent conservative command budget before expansion. The final check is a stricter current-client memory guard over unique positions.
IMPLEMENTATION EVIDENCE
Where these claims come from
Each claim is intentionally scoped to a concrete implementation path. These references are for verification, not decoration.
src/vox/ncm.js
Defines NCM1 and NCM2 encoding and decoding, greedy same-color cuboid conversion, axis mapping, palette packing, and generated runtime box fields.
scripts/validate-ncm-fixtures.mjs
Exercises both checked-in villager fixtures through the general source codec; its truncated-payload rejection does not describe the looser avatar NCM2 bit reader.
public/media/vox/chr_peasant_girl_orangehair.ncm
Provides the canonical 451-character girl NCM2 fixture used for the reported 70-cuboid, 10-color, 334-raw-byte measurement.
public/media/vox/chr_peasant_guy_blackhair.ncm
Provides the canonical 353-character boy NCM2 fixture used for the reported 56-cuboid, 8-color, 261-raw-byte measurement.
chunk.js/renderer/avatar-mesh.js
Resolves boy-only aliases, dispatches NCM2 or NCM4, maps cuboids into runtime coordinates, applies the NCM2 heuristic rig and equipment path, and currently returns empty NCM4 equipment and hand anchors.
chunk.js/ncm/character-codec.js
Defines NCM4's canonical Base64URL and CRC32C envelope, bounded cuboids, twenty fixed bones, actions, and 1,532-byte raw payload ceiling.
chunk.js/renderer/avatar-action.js
Samples explicitly selected NCM4 actions, rotations, and visible groups independently of normal Play moving and mining state.
play/player-motion-controller.js
Supplies normal moving and mining animation inputs without selecting an NCM4 action or clip.
chunk.js/tests/smoke.test.mjs
Covers default and symbolic NCM avatar decoding, stable animated vertex buffers, and built-in and forged equipment composition.
play/play-avatar-session.js
Implements local avatar decode failure handling by falling back to the default model or retaining the current valid mesh.
programs/nicechunk_player/src/state.rs
Defines the fixed 2,048-byte PlayerAppearance model-code field, independent modelKind validation, prefix-only model text validation, and account packing tests.
chunk.js/ncm/blueprint-codec.js
Defines NCM3 command encoding, canonical material IDs, deterministic expansion, overwrite semantics, operation bounds, unique-voxel safety, and the non-production NCBP helper.
chunk.js/tests/ncm-blueprint.test.mjs
Covers canonical NCM3 round trips, allowed and rejected materials, command geometry, negative repeats, procedural bounds, and operation-budget rejection.
programs/nicechunk_building/src/building.rs
Defines NCKBLD02 metadata and NCKBDT01 payload storage, shard and write limits, raw payload hashing, canonical varints, material and opcode validation, dimensions, command limits, and the shared conservative validation formulas.
programs/nicechunk_building/src/lib.rs
Finalizes only complete ordered shard sets whose raw SHA-256 hash, parsed NCM3 envelope, rotated footprint, offsets, and build height pass.
src/chain/nicechunkChain.js
Loads production NCKBLD02 manifests and NCKBDT01 shards, reassembles raw bytes, verifies SHA-256 and Guardian hash prefix, and restores the NCM3: client envelope.
chunk.js/construction/building-mesh-worker.js
Runs parsing, exact-scale placement, meshing, lighting, and collision-mask production off the main thread and transfers packed buffers back to the renderer.
chunk.js/construction/building-parser.js
Separates local stable code IDs and canonical-text hashing from production raw-byte identity while implementing exact-scale quarter-turn placement.
chunk.js/tests/building-parser.test.mjs
Covers one-to-one scale, rotation, offsets, foundation fit, cross-Chunk face culling, canonical material layers, and opaque-versus-glass mesh separation.
chunk.js/tests/building-mesh-client.test.mjs
Covers one-active-job worker scheduling, priority queue order, queued cancellation, and active stale-work abortion followed by clean work on a fresh worker.
chunk.js/forge/forge-runtime-cache.js
Restores canonical NCF1 independently, checks the raw FNV-1a design hash, builds packed forge geometry once, and evicts by entry and byte budgets.
chunk.js/tests/forge-runtime-cache.test.mjs
Covers canonical NCF1 restore, cache reuse, hash mismatch rejection, mesh attachment to the avatar, collision parts, and hidden-equipment cost removal.
programs/nicechunk_backpack/src/state.rs
Derives NCF1 material requirements from the leading 108 bits, hashes the entire raw payload with 32-bit FNV-1a, verifies selected backpack material capacity, and tests equal-or-greater material acceptance without reconstructing forge meshes.