nx_gatesubj.nx

nx_gatesubj.nx -- RESOLVE EVERY GATE'S SUBJECT FROM THE GATE'S OWN SOURCE. THE PROBLEM THIS SIZES ---------------------- Non-vacuity (can this gate ever fail?) is measured by nx_gate_bite, driven in bulk by nx_bite_sweep over rows declared in `knowledge/compare/*.gates`. Measured 2026-08-07: 2,316 `*_gate.nx` in the tree 19 declared in the registry = 8 permil coverage 855 resolvable by NAME convention = 369 permil (nx_X_gate.nx -> nx_X.nx) So 99.2% of the estate's gates have never been asked whether they can fail, and the obvious convention reaches only a third of them. nx_bite_sweep's header is right to refuse NAME guessing -- "a guessed path that fails to open produces 'no mutant killed', which reads identically to a vacuous gate" -- but it drew the wrong conclusion from it, that the subject must be hand-declared. ★★★★★★ THE GATE ALREADY NAMES ITS SUBJECT -- IN THE PATH IT EXECUTES OR THE MODULE IT IMPORTS. DERIVING FROM THE FILENAME IS GUESSING WHILE THE ANSWER IS SITTING IN THE FILE. An END-TO-END gate contains the literal `_offc/<organ>.elf` it fork/execs. An IN-PROCESS gate contains `import "<organ>.nx"`. Neither is a heuristic: both are the gate's own statement of what it tests, and both are exact. A gate with neither is honestly reported UNRESOLVED rather than guessed. ★ REPORTING "I COULD NOT DETERMINE THIS" IS A RESULT; GUESSING AND BEING WRONG IS A FALSE ACCUSATION AGAINST A WORKING GATE. usage: nx_gatesubj [--dir D] [--rows] --rows emits `gate|subject.nx|target|mode` for a sweep license_tier: ORIGINAL