nx_fence.nx

nx_fence.nx -- THE MONOTONIC FENCE TOKEN for the claims plane (hive mechanics, 2026-08-09). WHY THIS EXISTS -- measured, not assumed ---------------------------------------- 2026-08-08, corpus_complete=1 over 22,903 files: ONLY nx_claims and nx_seat reference knowledge/status/claims.jrnl. ZERO mutation paths consult it -- not nx_fs_write, not /api/promote, not /api/deploy, not any plane appender. The estate's own record agrees: "/api/deploy, /api/promote, /api/restart are NOT yet lease-gated -- two sessions can still race a DEPLOY." **** THE CLAIMS PLANE IS A WHITEBOARD, NOT A LOCK: IT CORRECTLY REFUSES A STALE *BEAT*, AND THEN NOTHING STOPS THE SAME STALE SEAT FROM WRITING STRAIGHT TO PRODUCTION. The 2026 distributed-systems answer is the FENCING TOKEN (Kleppmann; etcd's per-key creation revision; Raft terms): a monotonically increasing number issued at each acquisition, which the RESOURCE persists and uses to reject any operation carrying a lower one. The cardinal rule is **** NEVER TRUST A PROCESS TO KNOW THAT ITS OWN LOCK HAS EXPIRED -- so the check must live at the resource, never in the lock holder. nx_lease already carries a `nonce` and it is NOT a fence: a pid-derived tiebreaker (LS_NONCE_MOD 1000000) answering WHO WON A RACE, not WHO IS CURRENT. It has no ordering, so a resource cannot reject a lower one. **** A TIEBREAKER IS NOT A FENCE. THE TOKEN, derived never stored (the claims plane's cardinal law): fence(resource) = number of CLAIM frames for that resource in the append-only journal. Monotonic BY CONSTRUCTION (appends only), no new state, no daemon, and NO FRAME-FORMAT CHANGE (rule 19 additive) -- every existing reader is unaffected. HOLDERSHIP STAYS ONE COPY: state/holder come from FORKING `nx_claims state`, never re-derived here (the nx_seat precedent -- its derived-holdership parser stays THE one copy). This organ owns exactly one new thing: the count. !! FC_CLAIMS_ELF is a DEPLOYMENT ASSUMPTION (a path constant). Named out loud so it is findable: A PATH CONSTANT IS A DEPLOYMENT ASSUMPTION, and the estate has shipped silent ones before. nx_fence token <journal> <resource> -> fence=<N> + nx_claims state line; exit 0 nx_fence verify <journal> <resource> <actor> <fence> -> exit 0 ALLOW | 3 REFUSE reason=<R> nx_fence selftest [scratch-dir] -> gate teeth, verdict carried by exit code FAIL DIRECTION: verify REFUSES anything it cannot PROVE (unreadable journal, non-numeric fence, fork failure, missing holder field). **** A GUARD THAT GATES A DESTRUCTIVE ACTION MUST BE WRONG IN THE DIRECTION OF DOING NOTHING. It ships with a POSITIVE CONTROL because a guard that refuses everything passes every negative test -- four SSRF deny-tests once went green over a broken guard.