nx_craft_erosion_shot.nx

nx_craft_erosion_shot.nx -- THE BEFORE/AFTER PICTURE OF EROSION, TAKEN FROM THE WASM A VISITOR LOADS. WHY THIS EXISTS (operator standing rule, 2026-08-25): "if it's not publishing on a live page then it's not truly deployed, as I can't validate." Talus erosion ships in /craft and is proven by NUMBERS -- nx_wasm_craft_vm_gate measures talus 154/256, 509 of 576 lattice heights moved, rugosity 88 -> 75 permil -- and not one of those is a PICTURE. A number the operator cannot see is a claim he has to take on trust, which is the one thing this estate exists to stop doing. * WHY NOT nx_world_snap, THE INCUMBENT CAPTURE INSTRUMENT. Two reasons, and either alone is decisive. (1) IT RENDERS NATIVELY: it imports nx_wasm_craft as a LIB and calls init_impl_v / render_impl in this process's own memory. That is precisely the "a gate that tests a different build than the one that ships is not testing the product" defect nx_wasm_craft_vm_gate exists to correct -- /craft shipped BLACK TWICE while the native gate read 59/59 GREEN both times, because the native build never meets the wasm memory bound at all. A before/after picture drawn by the native twin would prove the twin erodes, not the product. (2) IT CANNOT REACH THE COLUMN ANYWAY: its style poke is bounded 7..58 and its gen-row allowlist is 0..6, 59, 60, 61 -- so spec idx 64, THE EROSION BUDGET, is unreachable from nx_world_snap in BOTH of its lanes. Measured, not assumed. So this organ drives the emitted .wasm through the estate's own nx_wasm_vm, in a linear memory sized to exactly what the module declares -- the same subject, the same bound and the same VM the vm-gate uses. It opts in through the GENP block byte-for-byte the way craft.html's NXGP loop does, so the erosion it photographs arrives by the SHIPPED door and not through a private back channel. The PNG encoder is COMPOSED, never rewritten: nx_png_write_rgb is the estate's one encoder. usage: nx_craft_erosion_shot <outbase> <variant> <seed> [q] [budgetA] [budgetB] [flat] writes <outbase>_off.png (budgetA, default 0) and <outbase>_on.png (budgetB, default 1), same variant + same seed + same camera; the erosion budget is the only difference. q omitted or 0 -> DERIVED (see es_q_mem / es_q_rays). q given -> explicit, still refused if it breaks the module's declared memory. flat=1 -> ALSO zero P_TAMP1 and P_TAMP2 through the same GENP door, i.e. ask for a world with NO RELIEF. THIS IS THE CONTROL THAT MATTERS, and it was earned the hard way: the obvious control (render /beach, which never opts in) was run first and CAME BACK 680 PERMIL DIFFERENT -- so it proved nothing about the pipeline and could not be published. beach's sand is NEAR-flat (P_TAMP1=2, P_TAMP2=1), not flat, and on a two-block relief a one-block shed moves most columns. A flat world has no slope steeper than its own average at all, so the measured talus is zero and the operator turns itself off. Because budgetA and budgetB then describe the SAME world, one such run proves BOTH that the capture is deterministic AND that erosion does nothing without slopes: an image pipeline that painted noise, drifted with wall-clock time, or added an offset would fail it.