nx_content_get_client_gate.nx

nx_content_get_client_gate.nx -- THE GATE FOR THE SOVEREIGN DOWNLOAD CLIENT, 2026-09-04. SUBJECT: the BUILT nx_content_get_client elf, forked in `dryrun` mode so the JSON-RPC envelope it would put on the wire becomes a deterministic artifact with no socket involved. WHY dryrun IS THE RIGHT SUBJECT, and it is the sibling's reasoning inherited rather than re-derived: a malformed envelope is rejected by the SERVER, and the server's refusal names neither the client nor the real fault -- it reports a schema or argument error about a request nobody can see. The upload client's first draft carried a DOUBLED params key with a four-brace tail that balanced against itself: syntactically valid JSON of entirely the wrong SHAPE, which no live run would have named. T2 is here because this client copies that constant's structure and could copy its defect. THE ASYMMETRY WORTH STATING: the upload gate carries an EXTERNAL SHA-256 KAT, because its client hashes the local file before begin and the digest it sends is checkable against the FIPS 180-2 published value for "abc". THIS CLIENT HASHES NOTHING AT BEGIN -- in a get the digest is DECLARED BY THE SERVER and the client's job is to verify its reassembly against it. So there is no KAT to run here, and inventing one would be a tooth that tests nothing. That absence is declared rather than quietly omitted, because a reader comparing the two gates should be able to see WHY they differ. T3 IS THE TOOTH THE UPLOAD GATE CANNOT HAVE, and it is the one that guards this client's whole premise. In a get the client knows NEITHER the total size NOR the whole-file digest -- both are the server's, read from its begin receipt. So the begin argv must contain EXACTLY TWO elements: the verb and the source path. If some future edit ever has this client compute a size or a digest and send it, the argv grows and this tooth fires. That is the "the chunk size is the server's, never computed here" rule made mechanical instead of merely written in a comment. T6/T7 ARE THE REFUSAL PAIR, on the sibling's precedent. T6 requires a source carrying a double-quote to be REFUSED rather than escaped, because a hand-rolled JSON escaper is wrong in exactly the cases nobody tests. On its own T6 would pass on a client that refused EVERYTHING, so T7 requires a safe source to be ACCEPTED. Neither is evidence without the other. Teeth, in order: T1 the envelope's braces and brackets balance. T2 "params" appears EXACTLY ONCE (the doubled-key defect that shipped in the sibling's first draft). T3 the begin argv carries EXACTLY TWO elements -- the client sends no size and no digest of its own. T4 the remote source appears verbatim in the envelope. T5 the capability token appears verbatim (a client that dropped it would 401 for the wrong reason). T6 NEG-CONTROL: a source containing a quote is REFUSED (exit 4), never escaped. T7 POSITIVE CONTROL: a safe source is ACCEPTED (exit 0), so T6 cannot pass on a refuse-everything client. T8 the argv array opens with the begin verb.