nx_deploycover_gate.nx

nx_deploycover_gate.nx -- WHAT FRACTION OF THE RUNNING FLEET CAN ACTUALLY BE DEPLOYED? THE QUESTION NOTHING ELSE ASKS. The ecosystem has gates for whether an organ WORKS, and a control plane for BUILDING and DEPLOYING one. Nothing measures whether the deploy plane COVERS the fleet -- so a service can run for months with no sanctioned way to update it, and nothing says a word. MEASURED 2026-07-31 on this host: 15 services running, 9 rows in deploy_targets.conf. A fix to one of the uncovered 6+ CANNOT BE LANDED over the API at all. That is the structural root of the recurring SOURCE-EDITED-BUT-NOT-DEPLOYED state seen across three lanes today: not discipline, COVERAGE. Worse, /api/inventory ADVERTISES nx_hub_gw.elf and nx_torrent_gw.elf as managed deployables while deploy_targets.conf -- the allowlist /api/deploy actually reads -- contains neither. The declared coverage and the real coverage disagree, and only the smaller one is true. BOTH DIRECTIONS, deliberately (this is the fleet-drift discipline: manifest-to-reality AND reality-to-manifest): RUNNING-NOT-DEPLOYABLE -- a live service with no sanctioned update path. The dangerous direction: its fixes must go around the health-checked, auto-rollback deploy path. DEPLOYABLE-NOT-RUNNING -- an allowlist row for something not up. Usually benign (oneshots, toolchain), but a row pointing at nothing is also how an allowlist rots. ADVISORY BY DESIGN (exit 0 unless the SCAN fails). A low coverage number is a backlog, not a reason to fail every build. What DOES fail: reading zero rows or zero services, because an instrument that measured nothing must never render as a clean fleet. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0