nx_magic_lib.nx

nx_magic_lib.nx -- THE RULE-11 LITERAL SCANNER. Extracted out of nx_magic.nx on 2026-08-25 for two reasons, and the second is the one that mattered. (1) IT COULD NEVER BE MUTATION-PROVEN WHERE IT WAS. mg_scan lived inside a program with main(), so the only way to exercise it was to fork the deployed elf -- and every mutant of a fork/exec'd subject comes back NOT-REACHED. The estate's most widely-consumed text scanner (it decides what /api/build calls a rule-11 breach) had therefore never had a single tooth on it. In a lib it sits inside the gate's own build closure and nx_gate_bite can kill mutants in it. (2) IT WAS BLIND TO HEXADECIMAL, AND THE BLINDNESS WAS DECLARED RATHER THAN FIXED. nx_magic's header said "Decimal only -- hex is DECLARED out of envelope (nearly all hex here is < 1024)" and the map envelope printed decimal_only:1, hex_out_of_envelope:1 on every call. A declaration does not make a count mean what its name says. MEASURED 2026-08-25 on buildroot/runtime/_hdl_build/nx_activities_gate.nx at floor 2: 41 sites / 26 distinct, one of which is the decimal literal 420 -- while the FOUR `0x1ed` literals on lines 123/124/127/128 of the same file, which are THE SAME NUMBER, were not sites at all. The mechanism was mechanical and total: at `0x1ed` the scanner read the digit run `0`, saw that the next byte `x` is an identifier character, and discarded the whole token as identifier-digits. So the value it would have carried was not merely mis-scaled, it was 0. A file written entirely in 0x notation read as magic:0. The estate had ALREADY banked the law -- "THE SAME CONSTANT IN TWO BASES IS TWO CONSTANTS TO EVERY SCANNER", earned when a 39-site MODE_0644 sweep matched decimal 420 and missed a raw 0x1a4 -- and then never taught the ruler the second base. A LAW BANKED IN PROSE AND ABSENT FROM THE INSTRUMENT IS A LAW THE NEXT SWEEP WILL BREAK AGAIN. SCOPE OF THE FIX, STATED SO IT IS NOT OVERREAD: this closes the blind spot in nx_magic's scanner, which produces the WORKLIST and the FLOOR VIEW. It does NOT change the number nx_magicratchet gates builds on: that count comes from `nx_law_warden countfile` -> lw_line_lits, which is hex-blind by exactly the same mechanism and is deliberately left alone here, because raising a count that already has 911 stored baselines is the one edit that can refuse real builds estate-wide. Named, measured, not done blind. SKIPPED BY CONSTRUCTION (the false-positive controls, unchanged except where noted): whole-line comments, TRAILING comments after code, const/static DECLARATION lines, bytes inside string literals, digits that continue an identifier (x2048, and now also a hex body that runs into a letter), named-index table writes `a[NAME] = literal`, any value below the threshold, and NEW: a hex literal too wide to represent exactly (see MG_HEX_SAFE_DIGITS -- it is COUNTED and REPORTED, never silently dropped, and never recorded as a site because a site authorises `nx_magic apply` to REWRITE THAT TEXT and a wrong value there is source corruption). A HEURISTIC THAT GATES A DESTRUCTIVE ACTION MUST BE WRONG IN THE DIRECTION OF DOING NOTHING. 100% sovereign. No hardware writes (Rule 26). license_tier: ORIGINAL