nx_livecloexec_gate.nx

nx_livecloexec_gate.nx -- does any LIVE process hold a listening socket WITHOUT FD_CLOEXEC? WHY THIS EXISTS ALONGSIDE nx_cloexec_gate (debt 1785521781). That gate is excellent at what it does: it calls the SHIPPING nx_http_server_listen and proves the returned fd carries FD_CLOEXEC, with a control and a reader neg-control. But it measures THE PRIMITIVE, and a primitive is not a fleet: (a) a LIB fix reaches an organ only on ITS NEXT REBUILD -- a daemon deployed before the fix still runs the old code, and the gate is GREEN the whole time; (b) a daemon that binds by some OTHER path (raw sys_socket + bind + listen instead of the shared helper) is not covered by the primitive at all. So nx_cloexec_gate GREEN + a wedged port are perfectly consistent, which is exactly what happened 2026-07-31: the gate passed while :18098 was unreachable for every seat. THIS gate measures the OTHER side: it walks /proc/<pid>/fd, finds sockets, and reads the REAL FD_CLOEXEC bit out of /proc/<pid>/fdinfo/<fd> (`flags:` octal, 02000000 = O_CLOEXEC). It reports what is TRUE OF RUNNING PROCESSES RIGHT NOW, not what the library would do if called today. ★ A GREEN PRIMITIVE GATE IS NOT EVIDENCE ABOUT DEPLOYED BINARIES. ⚠ ADVISORY BY DESIGN, exit 0 unless the SCAN ITSELF fails. A non-CLOEXEC socket is not automatically a defect: most are ACCEPTED connections (short-lived, no port to hostage) and inherited-fd risk applies to LISTENERS. Distinguishing listener from accepted socket needs /proc/net/tcp inode correlation -- see nx_portdup for that lane. Reporting a count with an honest caveat beats a RED verdict this gate cannot justify. What it DOES prove non-vacuously: the scan reached real fds and read real flags. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0