nx_undopath_gate.nx

nx_undopath_gate.nx -- proves nx_undopath_lib, and CENSUSES every deploy row's reverse gear. THE THIRD QUESTION IN THE DEPLOY FAMILY. nx_deploycover_gate asks "is there a row at all"; nx_deploy_listen_gate asks "did the post-deploy check verify the INCOMING listener". This asks: WHEN THE ROW'S REVERSE GEAR FIRES, DOES IT REVERSE THIS TARGET -- OR SOMEBODY ELSE'S? It exists because on 2026-09-03 the answer was "somebody else's" for 16 of 31 rows: they declared `rollback`, and cmd_rollback() takes no target argument -- it renames sites.elf.prev over sites.elf and kills sites.elf. /api/deploy's health watchdog invokes that field, so a failed deploy of any of those daemons would AUTOMATICALLY have reverted the public front door and left the bad daemon live. ADVISORY ON THE CENSUS, HARD ON THE RULER. The pure classifier and the ratchet are teeth: they fail the gate. The live census RATCHETS -- wrong-subject may only fall -- because a permanently-red detector is one everybody learns to ignore, and because the honest remedy for a wrong row is a source change in the control plane, not a blocked build. A RISE is RED and the baseline is NOT rewritten. WHY IT COMPOSES md_resolve_target INSTEAD OF PARSING THE CONF ITSELF: that function IS the resolution /api/deploy performs -- primary knowledge/hosting path, cwd fallback, and the compiled-in builtin rows. A hand-rolled parser would measure a DIFFERENT SUBJECT than the deploy plane actually reads, which is the exact wrong-subject error this gate exists to catch. The row NAMES are enumerated from the conf (that is a list, not a resolution); every rb verb comes from the shipping resolver. license_tier: ORIGINAL Read-only. No hw writes (Rule 26). expect_exit: 0