nx_craft_erosion_shot_gate.nx

nx_craft_erosion_shot_gate.nx -- IS THE PUBLISHED BEFORE/AFTER PAIR ACTUALLY A PAIR? (2026-08-25) THE SUBJECT IS THE PUBLISHED PIXELS, AND THAT IS DELIBERATE. The operator validates by LOOKING, so the thing that must be true is a property of the four PNGs sitting in the docroot: they decode, they are pictures of the shipped module's own frame, the craft pair DIFFER, both sides are VARIED, and the control world -- one asked for with no relief at all -- produces two PIXEL-IDENTICAL frames. This gate decodes the exact bytes a browser will decode, with the estate's own decoder, and asserts those five things. * WHY IT DOES NOT RE-RENDER, STATED PLAINLY RATHER THAN LEFT AS A GAP. Re-deriving the pair means worldgen, and worldgen through the wasm INTERPRETER was MEASURED at init_ms=119382 for ONE scenario (nx_craft_erosion_shot, 2026-08-25, plus 4.84 ms per ray of render on top). Four scenarios is roughly 10 minutes at the coarsest resolution the module offers. No roster deadline in this estate admits that -- the slow roster's own beat allows 60000 ms -- so a re-rendering gate could not be run by anything, and a gate nobody runs is a comment. The heavy live proof already EXISTS and is not duplicated here: nx_wasm_craft_vm_gate runs the shipped wasm and measures that the ground itself moves (talus 154/256, 509 of 576 lattice heights moved, rugosity 88 -> 75 permil) and that the renderer paints a varied frame. This gate owns the layer that one cannot see: whether the pictures on the page are real, different, and honestly captioned. * AND THE PAIRING IS A FREE CROSS-CHECK, NOT A DUPLICATE RULER. The producer counts differing pixels in the wasm FRAMEBUFFER; this gate counts them in the DECODED PNG. They are two instruments over one claim with the encoder in between, so a disagreement between the two numbers locates a defect in the encode/publish path that neither could find alone. Both numbers are printed so the comparison is available to a reader without re-running anything. license_tier: ORIGINAL expect_exit: 0