nx_zimage_weights.nx

nx_zimage_weights.nx -- the LAYER-WEIGHT RESOLVER: (layer L, slot k) -> where that tensor lives. sd-server -> Nishi migration, the binding brick between the GGUF and the encoder. nx_zimage_layout DUMPS blk.0's offsets to a text file for a human to read; that is a diagnostic, not an API. The full-scale assembly needs to ask, 36 x 11 times, "where is layer L's slot k?" -- so that question becomes a function here instead of being inlined into whichever organ needs it next. SLOT ORDER IS THE ENCODER'S ARGUMENT ORDER, deliberately, so a binder can fill the per-layer pointer arrays of nx_f32_qwen_encoder_layers by looping slots with no mapping table: 0 attn_norm 1 attn_q 2 attn_k 3 attn_v 4 attn_output 5 ffn_norm 6 ffn_gate 7 ffn_up 8 ffn_down 9 attn_q_norm 10 attn_k_norm <- Qwen3 QK-norm, see below ***FINDING (2026-07-30, debt 1785449705): slots 9/10 EXIST IN ALL 36 LAYERS, and the sovereign nx_f32_qwen_layer DOES NOT CONSUME THEM.*** Their existence was not guessed -- it was FORCED by arithmetic: 36 x 9 = 324 but tensor_count = 398, and 36*11 + token_embd + output_norm = 398 EXACTLY. Running real weights through the 9-slot encoder therefore yields finite, plausible, WRONG numbers with nothing erroring. LAW: tensor_count is a checksum on your architecture understanding. FAIL-CLOSED: an unknown slot or a missing tensor returns -1 and writes NOTHING to the box. It never invents an offset -- a fabricated offset would read arbitrary bytes out of a 6.5GB file and the resulting garbage would look like a numerical bug thirty layers later. METADATA ONLY: resolves offsets/dims/types from the parsed header. No tensor is materialized, so this is cheap enough to call for every layer at startup. license_tier: ORIGINAL expect_exit: 0