nx_nxwreap_lib.nx

nx_nxwreap_lib.nx -- THE CLASSIFIER for LEAKED WRITE-GUARD SCRATCH FILES, and the ONE place the decision to remove one is taken. No `main`: the CLI (nx_nxwreap) and the gate (nx_nxwreap_gate) both import THIS, so the reaper and its proof cannot disagree about what a scratch file is. --------------------------------------------------------------------------------------------- THE DEFECT, MEASURED 2026-08-25. nx_fs_write lands every atomic write through a temp named <path>.nxw<pid> and renames it away on success (nx_fsops_lib.fsx_write). BOTH of its failure paths -- a short write and a failed rename -- ALREADY unlink that temp, so an ordinary FAILED write leaves nothing behind. What is left is the single case in which no code of ours runs at all: a writer KILLED between the open and the rename. Eleven agents were killed mid-write on this estate today by spend/session/weekly limits, and `nx_shelltool glob \"*.nxw*\" buildroot/runtime` returned matches=192 corpus_complete=1. THE INFLOW FOR *FAILED* WRITES IS ALREADY CLOSED. THIS ORGAN EXISTS FOR THE *KILLED* WRITER, WHICH NO amount OF CLEANUP CODE IN THE WRITER CAN EVER REACH. THE HARM IS NOT THE DISK, IT IS THE CENSUS. A scratch file is a FULL COPY OF A SOURCE FILE lying beside that source file, so `nx_shelltool find <name> buildroot/runtime` returns the fossils -- `find nx_organ_ship` returned 9 rows of which 5 were .nxw* -- and any name or content scan that does not filter by extension can read PRESENT off a fossil after the real file was already fixed. A STALE FULL COPY BESIDE THE FILE IT COPIES IS A FALSE-NEGATIVE-ON-ABSENCE GENERATOR. BOUNDED HONESTLY, because the scope of a claim is part of the claim: the EXT-FILTERED path is NOT affected. `nx_absent <pattern> <dir> nx` cannot match `....nxw12848`, since that name does not end in `.nx`. The blast radius is every UNFILTERED name/content scan, and only those. --------------------------------------------------------------------------------------------- FAIL-SAFE BY CONSTRUCTION, INHERITED RATHER THAN RE-STATED. The predicate is nx_lock_reap_core.lr_should_reap -- reap iff the file EXISTS AND its owner is NOT alive AND it is older than the threshold; everything else is 0. It is NOT re-implemented here. This organ contributes exactly one thing the lock reaper cannot: the OWNER IS IN THE FILENAME. WHY /proc/<pid> AND NOT lr_owner_alive's CMDLINE NEEDLE. The lock reaper identifies an owner by scanning every /proc/<pid>/cmdline for a substring, because a lock file does not say who holds it. A write-guard scratch file DOES say: the pid is its own suffix. Testing /proc/<pid> directly is one stat instead of a whole-/proc walk, and it is exact rather than a substring guess. PID REUSE IS REAL, AND IT IS RESOLVED IN THE SAFE DIRECTION. A dead writer's pid can be recycled by an unrelated process, and nothing in the filename can distinguish that from the original writer still running. So: IF /proc/<pid> EXISTS WE DO NOT REAP, even though the true owner may be long dead. That leaves some litter -- the HARMLESS failure. The other direction unlinks the in-flight temp of a LIVE writer, destroying a write that was about to succeed -- the HARMFUL one.