nx_cron_reconcile_gate.nx

nx_cron_reconcile_gate.nx -- THE REFEREE nx_cron_reconcile NEVER HAD, WHICH IS WHY IT SURVIVED. WHAT IT EXISTS TO CATCH. For at least two weeks this organ applied a PREFIX of its own SSOT and reported it as the whole: cr_read did ONE sys_read of CR_REGCAP-1 = 16383 bytes with no truncation check while cron.reg had grown to 24356, so 11 declared rows were silently inert -- including the estate's only compensating control over a fail-open authentication path. Nothing caught it because nx_catalog nx_cron_reconcile_gate read ABSENT: there was no gate at all. **** THE DECISIVE TOOTH IS T1: A REGISTRY BIGGER THAN THE OLD CAP, EVERY ROW APPLIED. **** THE PRE-FIX BINARY IS THE FREE MUTANT. Point argv[1] at it and T1/T2/T9 must go RED; point argv[1] at the fixed binary and they must go GREEN. A gate whose decisive tooth has only ever seen the fixed binary has not been shown to fire. ⚠TRUNCATION HAS TWO MANIFESTATIONS AND ONLY ONE OF THEM IS THE PRODUCTION ONE. MEASURED HERE 2026-08-20 while building this gate: where the 16383-byte cut lands INSIDE a row decides which. Cut EARLY in a row and the surviving fragment has lost "/nishihost/", so R3 fires and the organ REFUSES exit 5 -- loud, safe, and NOT what happened in production. Cut LATE in a row and the fragment still carries the mark, so the organ counts it, writes a crontab missing every later row, and reports CHANGED with exit 0. THAT is the production shape: a success message over a prefix. The first draft of this fixture hit the refusal by luck and its decisive tooth went RED for the WRONG REASON -- a red that would have read as proof while measuring something else entirely. **** A TOOTH THAT FAILS FOR A DIFFERENT REASON THAN THE ONE IT NAMES IS NOT EVIDENCE. **** So the header pad is now SOLVED FOR, not chosen: rows are uniform length and the comment header is sized by modular arithmetic so the old cut lands CRG_CUT_MARGIN bytes before a row end. T0 asserts that condition arithmetically before any outcome is asserted, and T1 requires exit 0 AND the last row present -- so the broken binary cannot pass by refusing either. THE VACUITY GUARD COMES FIRST AND IT IS NOT DECORATION. A fixture registry that does not actually EXCEED the old 16384-byte cap makes T1 pass against the BROKEN binary too, and the gate would then certify the defect. So T0 asserts the fixture reached the condition -- total bytes over the cap AND the last declared row STARTING past it -- before any outcome is asserted. The estate has shipped four vacuous fixtures in one day before (a 900 B trigger with an 836 B fixture); this is that lesson. SCRATCH IS /tmp/nx_cron_reconcile_gate/ AND THE SUBJECT NEVER SEES A REAL CRONTAB. The organ's own usage line already says "gate runs it on COPIES; prod = /etc/crontab". The fixture rows name nx_gatefixture_*.sh, which does not exist and is never installed anywhere -- they live and die in /tmp. Setup creates and clears; there is no teardown, because a teardown does not run when a run crashes. ⚠ONE HONEST SIDE EFFECT, NAMED RATHER THAN HIDDEN: on a CHANGED result the subject walks /proc and SIGHUPs every `crond`. Running this gate on the NAS therefore reloads the real crond. That reload is of an UNCHANGED /etc/crontab and is the same standard, non-destructive signal the organ already sends