nx_jobfollow_parse_gate.nx

nx_jobfollow_parse_gate.nx -- THE GATE FOR THE JOB-POINTER PARSE, 2026-09-04. SUBJECT: jf_job_id / jf_artifact_ready / jf_json_safe, in-process, pure. THE DEFECT THIS EXISTS TO MAKE IMPOSSIBLE COST ELEVEN DAYS AND WAS INVISIBLE TO EVERY OTHER TEST. The tools edge may answer any call with `JOB-STARTED id=<n>` instead of the organ's receipt. A client scanning for a bare `id=` reads the JOB id as the ORGAN's id and reports a receipt that never existed. MEASURED: nx_content_put_client printed `CP-BEGIN id=1788537161 chunk_raw= nchunks=` while the real receipt in the job artifact was `CP-BEGIN id=1788537161795845 ... chunk_raw=48402 nchunks=1`. Both ids are epoch-derived, so the wrong one is a plausible PREFIX of the right one -- which is exactly why it was printed as a fact rather than questioned. The organ had never completed a single transfer. THE LOAD-BEARING TOOTH IS THE NEGATIVE ONE. Any implementation returns the right answer on a real job pointer; the defect lives entirely in what happens to a receipt that merely CONTAINS an id. So the tooth that matters asserts jf_job_id REFUSES a bare `id=`, and a gate without it would go green on the very code that shipped broken. PURE BY CONSTRUCTION, WHICH IS WHY THE PARSE WAS SPLIT OUT AT ALL. nx_jobfollow_parse imports only nx_syscalls, so this gate opens no socket -- on the nx_https_post_lib_gate precedent, a gate that needs the network goes RED for someone else's outage and its RED then indicts this code. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0