nx_srclint.nx

nx_srclint.nx -- LINT THE HAZARDS THAT HAVE ACTUALLY BITTEN, ESTATE-WIDE. RULE 1: CURSOR-SENTINEL. The idiom while p < n { if <done> { p = n + 9 } ... } if p > n { p = p - 9 } writes the loop's EXIT MARKER INTO THE VERY VARIABLE BEING SEARCHED FOR, and the restore lands on `n`, not on the position found. It does not crash and it does not fail to compile -- it silently returns the wrong index, so the caller reads the wrong byte and every downstream number is plausible and wrong. Measured cost on 2026-08-07 alone: FIVE defects. nx_memdemote -- the whole file parsed as ONE line nx_memnew -- file_path extraction returned nothing, the hook silently never fired nx_memnew -- the memfind output parsed as one line, zero results shown nx_unwired -- every identifier ran to end-of-file: 0 functions found across 7,113 sources nx_gatesubj -- the char after an identifier read from the wrong place: 0 of 157 end-to-end gates detected, in the organ built to measure exactly that The fourth and fifth happened INSIDE tools written to catch unverified work, hours after the primitive that fixes it (`gk_eol`) already existed. ★★★★★★ THE FIFTH TIME YOU FIX A BUG BY HAND IS PROOF THE FIX BELONGS IN A LINTER, NOT IN ANOTHER PATCH -- A HAZARD YOU CAN RECOGNISE ON SIGHT IS A HAZARD A MACHINE CAN RECOGNISE EVERY TIME. THE RULE IS THE PAIRING, NOT THE CONSTANT. `x = n + 9` alone is ordinary arithmetic; what makes it this defect is a matching `x - 9` restoring the same variable shortly after. Matching the pair keeps the rule precise -- a linter with false positives is worse than none, because it teaches everyone to ignore it. ★★★★★ A DETECTOR WITH FALSE POSITIVES IS WORSE THAN NONE. usage: nx_srclint [--dir D] [--quiet] [--accept] exit: 0 = no NEW hits since the baseline; 1 = a new hit (named, so it can be attributed) license_tier: ORIGINAL