nx_atomic_publish.nx

nx_atomic_publish.nx -- ALL-OR-NOTHING FILE PUBLISH WITH COMPARE-AND-SWAP, IN NISHILANG. WHY IT EXISTS. A multi-part source change applied as N sequential anchored edits is N chances to half-land. Measured twice on 2026-08-07: the MCP daemon wedged mid-sequence, edit 1 landed and edits 2-3 did not, leaving a live source with an UNCLOSED BRACE -- a broken file that blocks every build of that target, found only because the artefact was verified rather than the response believed. ★★★★★★A MULTI-PART EDIT OVER A FLAKY TRANSPORT IS AN ATOMICITY PROBLEM, NOT A RETRY PROBLEM: retrying makes a half-applied file MORE likely, not less. Stage the whole file, publish once. WHY IT IS AN ORGAN AND NOT A SHELL HELPER. The first version of this was a .ps1, and it JUDGED: it parsed a refusal to recover a token, classified transient-vs-deterministic, and decided refuse-vs-retry. That is judgement, and judgement belongs in NishiLang -- shell is the wire and nothing else. Here the only laptop-side act left is moving bytes to a scratch path; every decision happens on this side. usage: nx_atomic_publish <staged-src> <target> <expect> expect = "any" -- publish regardless (NAME IT OUT LOUD when you use it) | "absent" -- publish only if the target does not exist yet | <64-hex sha256> -- publish only if the target's CURRENT content hashes to exactly this nx_atomic_publish landed <writelist> -- the READ half: adjudicate ambiguous writes (ap_landed) CAS SEMANTICS, and the direction of failure is the point: on mismatch it REFUSES and PRINTS the live hash, so the caller can re-read, merge, and retry with the right token. It never re-resolves the token itself -- that would turn a concurrent writer's edit into a silent clobber, which is the exact defect compare-and-swap exists to prevent. ★A CAS THAT RESOLVES ITS OWN EXPECTED VALUE IS NOT A CAS, IT IS AN OVERWRITE WITH EXTRA STEPS. ATOMIC BY renameat, NOT BY WRITE ORDER: content goes to <target>.aptmp then renames over the target, so a reader never sees a half-written file and a crash mid-publish leaves the original intact. VERIFY AFTER: the published bytes are re-read and re-hashed before GREEN is printed. license_tier: ORIGINAL expect_exit: 0