nx_tcratchet_lib.nx

nx_tcratchet_lib.nx -- TOOLCHAIN RATCHET: refuse a toolchain artifact that SHRANK against its banked size. WHY (the incident this exists for, measured 2026-07-30, debt 1785440455): buildroot/_offc/nx_cc_sovereign.elf was found LIVE at 520,103 bytes when the known-good build is 543,126 -- a compiler whose optimiser was 11,712 SOURCE-bytes short. **THE HUB WAS COMPILING EVERY ORGAN WITH A REGRESSED COMPILER**, which is why its .s output came out 16,430 bytes larger than the laptop's from identical sources. Nobody knowingly promoted it. WHY THE EXISTING CANARY DID NOT CATCH IT, stated in that debt: nx_tc_canary proves a compiler is CORRECT (8 checks that must RUN), NOT that it optimises well. **A WORSE-BUT-CORRECT COMPILER PASSES IT BY DESIGN.** Correctness and quality are different axes and a gate on one says nothing about the other. THE RULE: a toolchain artifact that SHRINKS is REFUSED until a human re-banks deliberately. This is the ecosystem's own banked law -- 'a byte-count DECREASE after an addition is a REVERT' -- mechanised at the one place where being wrong corrupts every binary the ecosystem produces. ⚠IT WITHHOLDS, IT DOES NOT DIAGNOSE. A legitimate shrinking refactor lands here too (nx_capaxes went 20177->16243 when its selftest moved out, correctly). That is why the verdict is REFUSE-PENDING-REBANK and not 'corrupt': the remedy is an explicit re-bank, so an intentional shrink costs one deliberate act and an accidental one cannot pass silently. Same stance nx_stale_check takes on DEPLOYED-AHEAD. FAIL-CLOSED: an UNBANKED artifact returns its own verdict, never OK. A ratchet that cannot compare must refuse to bless -- a guard that waves through what it cannot measure is not a guard. license_tier: ORIGINAL No hw writes (Rule 26).