nx_organkind.nx

nx_organkind.nx -- WHAT KIND OF THING IS THIS ORGAN? The classifier seq1492 says both ship verbs need. THE DEFECT IT FIXES: `/api/promote target=nx_torrent_get` -> 400 'daemon/oracle names are never promotable (use /api/deploy)'; `/api/deploy target=nx_torrent_get` -> 400 'unknown target'. Promote calls it a DAEMON, deploy has never heard of it, so a gate-proven binary (nx_poolgov_gate 21/21, deleting a hardcoded MAXP=32) cannot ship by ANY sanctioned route. Both verdicts come from matching NAMES -- a `torrent`/daemon-ish substring -- rather than from what the organ IS. LAW: TWO VERBS THAT DISAGREE ABOUT AN ARTEFACT'S KIND LEAVE IT UNSHIPPABLE -- the classifier, not the allowlist, is the defect. WHY A DECLARED KIND AND NOT A BETTER HEURISTIC: a smarter name rule is still a guess, and the cost of guessing is asymmetric -- misfiling a DAEMON as a one-shot lets promote swap a binary underneath a running process with no health check and no rollback (a rule-26 hazard), while misfiling a one-shot as a daemon merely makes it unshippable. So the kind must be DECLARED DATA (rule 11/17), and anything undeclared must be REFUSED BY BOTH VERBS rather than fall through to a name guess. THE ASYMMETRY IS THE WHOLE POLICY: deploy = for things with a HEALTH SURFACE (a port to probe, so never-brick rollback is meaningful). promote = for one-shots/oracles: atomic rename + .prev backup, no probe needed because nothing is holding the old binary open -- its 'health' is that the NEXT invocation succeeds. A one-shot handed to deploy would have a port-based health check run against a target with no port, making the never-brick verdict meaningless-or-wrong BY CONSTRUCTION. Lives in runtime/ (PRIMITIVE layer, seq1450) so BOTH mgmt handlers can reach it; imports nothing above. license_tier: ORIGINAL Pure + read-only. No hw writes (Rule 26).