nx_content_get_client.nx

nx_content_get_client.nx -- THE SOVEREIGN NAS->laptop DOWNLOAD CLIENT. Retires nx_content_get_client.py. WHY THIS EXISTS (operator standing order, restated 2026-09-04: "we shouldnt be using ps1 or py or anything else in our build path only as external tooling being liar killers and validators etc"). nx_content_get has been the sovereign SOURCE since 2026-09-03 and its only driver was a Python script written on 2026-09-04 that shells out to a Python MCP wire. A SHIPPER IS THE BUILD PATH BY DEFINITION, so it can never be one of the external oracles that order permits. This is the NishiLang driver. Its outbound sibling nx_content_put_client.nx made exactly this move for the write direction and its own first line says so; this file is the half that was missing. nx_content_get_client [dryrun] <remote_src> <local_dest> <capfile> <url> MEASURED COST OF THE GAP IT CLOSES (hostops debt 1788534921, 2026-09-04): with the NAS array degraded and every NAS build refused, the laptop farm could compile and SHIP but could not BITE, because its nx_gate_bite.nx was 39,842 bytes against the NAS 98,879 and nothing could refresh it without a human copy or retyping bytes through an agent transcript. An outbound-only lane is a fallback that works only until the thing you need is on the other side. THE PROTOCOL IS THE SERVER OWN AND IT IS STATELESS, WHICH CHANGES THIS CLIENT SHAPE: begin <src> -> CG-BEGIN src= total_bytes= sha256= chunk_raw= nchunks= chunk <src> <index> -> CG-CHUNK OK ... chunk_sha256= b64=<data> There is no transfer id and no commit: in a get the bytes accumulate on the CLIENT, so there is no server-side state to open, resume or close. The put client id-threading and commit-unknown handling are therefore ABSENT rather than mirrored -- carrying them would be machinery with no invariant to protect, which the server own header names as the asymmetry a symmetric copy gets wrong. NOTHING IS WRITTEN TO <local_dest> UNTIL THE WHOLE-FILE DIGEST MATCHES. The server header states the exposure precisely: the SOURCE can change under a multi-call read, so chunks reassembled from two generations give a franken-file that is byte-valid and semantically nonsense. The per-chunk digest catches a CORRUPTED chunk and CANNOT catch a consistent read of a CHANGED file; only the whole-file sha256 declared by begin can. So this client assembles in memory, verifies, then writes ONCE. A partial or franken download must never be able to masquerade as a refreshed source -- and a size check would not do, because a same-size rewrite passes it. THE CHUNK SIZE IS READ FROM THE SERVER RECEIPT, NEVER COMPUTED HERE. nx_content_get derives it from the RESPONSE capture cap (163,840) rather than the request cap, which is the one term a symmetric copy of the upload client would get wrong. Recomputing it here would install a second ruler that drifts the moment the server reserve changes, and the drift would surface as truncated downloads. A SERVER DECISION IS NEVER RETRIED, AND IT HAS TWO VOCABULARIES.