nx_fetchclean.nx

nx_fetchclean.nx -- REMOVE OUR OWN FETCH LANE'S DIAGNOSTIC PREAMBLE FROM A DOWNLOADED ASSET. WHY (measured 2026-08-07, caught by nx_assetprobe on its first real binary): nx_https_get prints transport diagnostics (nishi-tcc / nishi-cert / nishi-xfer) on the captured stream, AHEAD of the entity body. A genuine PNG fetched through our lane therefore read: bytes=13933 magic=UNKNOWN ext_claim=PNG verdict=UNIDENTIFIED because a 38-byte preamble displaced the magic from offset 0. Two real BVH files landed at exactly +38 bytes over their upstream size for the same reason; they survived only because BVH is text and gets a bounded scan. EVERY binary asset -- PMX, VMD, PNG, ZIP, GLB -- is broken by this, and each would have failed later, inside a loader, as an unexplained corruption. *THE FIX BELONGS IN THE PIPE, NOT IN THE RULER. Widening the magic check to "somewhere in the first N bytes" would have hidden this and destroyed the guarantee that makes a magic a magic. CLOSED PREFIX SET, LEADING RUN ONLY. We strip a line only if it begins with one of the four KNOWN diagnostic prefixes, and we stop at the first line that does not. A generic "starts with nishi-" rule would eat a legitimate body, and a whole-file rule would eat a payload that merely mentions the string. Never silent: the stripped byte and line counts are always printed. usage: nx_fetchclean <in> <out> nx_fetchclean --kat selftest: 5 teeth, 3 of them anti-vacuity exit 0 ok | 2 unreadable | 3 usage | 9 write-failed | 1 KAT RED license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0