nx_ctlbyte_repair.nx

nx_ctlbyte_repair.nx -- FIND AND REPAIR CONTROL-BYTE CORRUPTION IN NishiLang SOURCES. WHAT HAPPENED, MEASURED 2026-09-03. A whole-population compiler census (nx_langcensus) found 314 of the tree's 13,721 top-level programs refused with "a control byte (decimal 14) sits in the source here" -- the single largest refusal class in the estate, larger than the next nineteen combined. Every one carries ONE contiguous run of EXACTLY 119 bytes of 0x0E, and in every case that run sits inside an integer-print helper, between the digit loop and its `return 0`. The corruption is present on BOTH trees, so it cannot be recovered from a twin, and the run length is a fixed filler that does not equal the length of the text it replaced -- so it cannot be recovered from the pattern either. It CAN be recovered from the CONTRACT: the enclosing function has already handled zero and sign and has built the digits into d[0..k) in reverse, so the only thing the lost bytes can have done is reverse them and write them. ★★★★★★A LOST REGION IS RECOVERABLE WHEN THE CODE AROUND IT PINS ITS CONTRACT -- AND THE ONLY HONEST REPAIR IS THE ONE THE SURROUNDING CODE FORCES, NEVER THE ONE THAT MERELY LOOKS PLAUSIBLE. 13 of the affected sources are on the gate roster, so their binaries RUN while their sources cannot rebuild them: the AHEAD class, where the served artifact carries code no source can reproduce. TWO SHAPES, ONE DECIDABLE RULE. Between the digit loop and the corrupt run: - no `sys_write(` yet -> the reversal AND the write were destroyed -> INSERT the tail, drop the run. - a `sys_write(` already -> only trailing cleanup was destroyed -> DROP the run, insert nothing. Anything else -> UNKNOWN, and this organ REFUSES to touch it. ★A REPAIRER THAT GUESSES IS A CORRUPTER WITH GOOD INTENTIONS: the unknown shapes are NAMED for a human, never silently rewritten. Usage: nx_ctlbyte_repair [--apply] [root ...] Default is a DRY census: every file, its class, and the partition -- nothing is written. `--apply` performs only the repairs whose class is decided, and re-reads each file afterwards to prove the byte is gone. ROOTS ARE ARGUMENTS, AND THE ORGAN PRINTS THE ONES IT WALKED. Measured 2026-09-03: with the roots hard-coded as `runtime/`, running this on the NAS (CWD = the serving root, where `runtime/` holds 17 files) reported `files=17 ... verdict=CLEAN` over a tree whose sources live in `buildroot/runtime/`. ★★★★★A SCANNER POINTED AT THE WRONG ROOT PRODUCES A CONFIDENT, COMPLETE-LOOKING FALSE NEGATIVE -- and a bare relative path is not a tree name, it is an expression whose meaning is the caller's CWD. Defaults (runtime, runtime/_hdl_build) apply only when no root is named, and are printed either way. Exit: 0 CLEAN (no corruption found) - 1 CORRUPTION PRESENT (dry run, or unknown shapes remain) 2 usage - 3 UNPROVEN (a walk cap filled, or a write-back could not be verified). RESOURCE ENVELOPE: one read and at most one write per affected file, sequential; buffers sized from the file and reused; nothing outside the named source files is written. license_tier: ORIGINAL No hw writes (Rule 26).