nx_npy_lib.nx

nx_npy_lib.nx -- THE .npy MEMBER PARSER. The first byte of the GNM / NishiGen lane (procgen PG38). WHY THIS AND NOTHING MORE. GNM Head ships its model as .npz, and .npz is a ZIP of .npy members. The ZIP half is ALREADY SHIPPED and is NOT rebuilt here: nx_zip_header.nx carries zip_find_eocd, zip_parse_eocd, zip_parse_lfh and zip_method_known, nx_zip.nx carries the central-directory field accessors and CRC32, and nx_safe_archive_ingest already composes them under a never-poison envelope. Measured 2026-09-03 before writing a line: the estate reads ZIP well enough that nx_varfacts measures 91 VirtaMate .var archives (which ARE zips) straight into the refcorpus journal. What was genuinely ABSENT -- confirmed, not assumed, after the two "NUMPY" hits in the tree turned out to be a benchmark constant NX_INCUMBENT_NUMPY=600 -- is the .npy header parser. So this file is the ONE missing layer, not a second archive reader. FORMAT (numpy NEP 1): magic 0x93 'N' 'U' 'M' 'P' 'Y', major, minor, then a header LENGTH (u16 little-endian for v1, u32 for v2 and v3), then that many bytes of a Python dict literal: {'descr': '<f4', 'fortran_order': False, 'shape': (5023, 3), } then the raw array bytes, C-contiguous unless fortran_order says otherwise. FAIL CLOSED ON THE THREE THINGS THAT CORRUPT SILENTLY, because each produces PLAUSIBLE NUMBERS: 1. fortran_order True -- the same bytes transposed. A reader that ignores it returns a matrix that is the WRONG SHAPE-ORDER while every length check still passes, so a vertex basis would come back scrambled and nothing would error. REFUSED by name; supporting it later is a rung, not a default. 2. an unknown dtype -- guessing an itemsize makes every downstream offset wrong by a factor. 3. a declared element count that does not match the bytes actually present. The partition data_off + count*itemsize == total MUST hold; it is arithmetic, so it is its own oracle. license_tier: ORIGINAL