nx_exclprobe.nx

nx_exclprobe.nx -- DOES O_CREAT|O_EXCL VIA __syscall ACTUALLY WORK HERE? (2026-08-07) WHY THIS EXISTS. The async job lane assigns ids by probing whether `_jobs/job_<id>.done` EXISTS, but a RUNNING job has no `.done`, so two tools/call in the same second get the IDENTICAL id and the loser's receipt is overwritten (observed live: two nx_debt add both returned id=1786110674). The correct fix is an ATOMIC reservation, and `dl_lock` in nx_dispatch_lease already does exactly that with __syscall(SYS_OPENAT, AT_FDCWD, path, 193, 420, 0, 0). But banked memory warns that LITERAL __syscall numbers are rv64->x86 TRANSLATED, which would make 257 mean something else entirely -- and I am not shipping that into the daemon that serves /mcp on a guess after two outages today. ★ VERIFY A PRIMITIVE IN A THROWAWAY BEFORE PUTTING IT IN THE THING EVERYTHING ELSE DEPENDS ON. This organ answers it decisively and touches nothing but /tmp. nx_exclprobe -> JSON {first_create, second_create, verdict} EXPECTED IF THE PRIMITIVE IS SOUND: first >= 0 (we created it), second < 0 (EEXIST refused us). If BOTH succeed, O_EXCL is not being honoured and the whole approach is unusable. If BOTH fail, the syscall number is being translated and 257 is not openat here. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0