nx_adoptdelta_gate.nx

nx_adoptdelta_gate.nx -- THE REFEREE for nx_deltaclass `adoptdelta` (DM7, devmgmt rung). END-TO-END: forks the DEPLOYED nx_deltaclass elf, so it grades the artifact callers run. The accept rule this enforces, verbatim from devmgmt.plan: "two consecutive beats emit deltas whose arithmetic reconciles against the underlying logs, and any row whose reference is REF-FOSSIL is excluded from the promotable delta rather than counted in it." The fixture is built so that a WRONG emitter cannot pass by luck. It carries, in one log: * two PRODUCTION rows whose every class delta is a different number, so a transposed column shows; * a GATE-FIXTURE row (reg= names another registry) with wildly different values BETWEEN them -- an emitter that grades it as a beat gets visibly wrong deltas, which is the real hazard: the live log genuinely contains a `distinct=6` fixture census between two `distinct=963` sweeps; * a LEGACY row with no reg= at all -- UNKNOWN-PROVENANCE is its own bucket, and folding it into either side is the "unrecognised value falls into a known bucket" defect; * a PRODUCTION row whose own classes do not sum, which must be COUNTED as malformed rather than silently averaged in; * a `xstale=999` decoy immediately before the real ` stale=3`, because a key read by substring rather than at a token boundary reports a different column under the right name -- a confident wrong answer, the hardest kind to notice. Fixtures live under /tmp/nx_adoptdelta_gate/ and are rewritten O_TRUNC on every run (idempotent); a gate that shares scratch with a production path grades the fixture, not the code. license_tier: ORIGINAL Read-only outside /tmp. No hw writes (Rule 26).