nx_kinddedupe.nx

nx_kinddedupe.nx -- keep-first prune of AGREEING duplicate data rows in organ_kind.conf (2026-08-29). license_tier: ORIGINAL No hw writes (Rule 26). nx_kinddedupe plan [conf] -> measure only: prints every would-drop row, the partition, verdict nx_kinddedupe apply [conf] -> temp+rename rewrite dropping ONLY later exact same-name-same-kind data rows; comments, blanks, order and first occurrences untouched EXIT: 0 CLEAN-OR-PRUNED | 1 CONFLICT-REFUSED | 2 usage | 3 UNOBSERVABLE (unreadable conf, failed write) WHY A CONFLICT REFUSES INSTEAD OF RESOLVING: the reader is first-match-wins (nx_organkind ok_kind_of returns on the first whole-field name match), so a name carrying two DIFFERENT kinds is decided by LINE ORDER -- nx_organkind_gate neg-control-T20 proves the order IS the answer. A pruner that picked a winner would silently adjudicate a question that needs evidence. It refuses and names both rows. WHY AN ORGAN AND NOT A CLIENT EDIT: the SSOT carries law in its UTF-8 comments; a client-side rewrite republishes a transport RENDERING of those bytes (the transcription hazard, measured 2026-08-28 on the CLAUDE.md recovery). This organ reads the real bytes and DELETES WHOLE LINES ONLY -- it never rewrites a byte it keeps. Referee = nx_organkind_gate before/after: T22 agreeing_dups -> 0 with rows falling by exactly the drop count, CONFLICTING_NAMES stays 0, T23 whole-file, T24 headroom grows by the pruned bytes. The partition (bytes_kept + bytes_dropped == bytes_in) is asserted IN the organ, not beside it.