[BobClawblaw]

tf-cuda-test kernel-contract-limits on fatbins built by nvcc 13.3 (zig build fatbins kernel-contract-fatbins -Dsm=80,86,89,120,121,
CUDA 13.3.73 on Linux) reported 559 problems on main at 31a864f (563 at 40c6406, with #1284's window_pages launches): 539 stale records (204 launches, 206 at 40c6406, whose 13.3
register counts, and in a few cases static shared bytes, differ from the 13.2 or 13.0 records they were checked
against), the 10 awaiting launches of cuda_lane_pending.zig that fail closed by design, and the 10 planted controls.

What changes

• core/contract/nvcc_133_records.zig: a 13.3 set of the 206 launches, appended to cuda_sets' 13.3 entry beside the
  flashnext and GLM sets, with the tool's own RECORD lines as the overrides. Families in it: deepseek-v4.1 (dsv41_*),
  qwen35 (and kv8, keep, draft, bf16_rows), GLM mm, flashnext, nemotron (mamba, router, moe, experts), tree, window,
  act_rows, affine4, dense, lane_gemv, qmmf, w4a8_prefill, window_pages and the others the log names.
• tests/cuda/contract_limits.zig: a RECORD line always carries five entries. An SM a launch does not apply to (a
  cluster kernel below sm_90, a GB10-only family's image) keeps the record the compiler is checked against, so the line
  pastes straight into an Override (before, such a line held one or two entries and did not compile as one).
• core/contract/measurements/pending_133.zig: 13.3 receipts for the 50 pending launches (base record none or
  later_pending, which usageFor returns early for), read by pending_132.zig's 13.3 lookup beside the qwen lanes'.
  pending_132_test.zig: the w4a8 and BF16-rows tests now expect the 13.3 receipt (13.2 and 14.0 still none), and a
  loop over the receipts checks each names a registered launch, keeps 13.0's record there and is 13.3's.

Checked on five-SM fatbins of the rebased tree (40c6406 plus this change) with the new runner: 0 stale records (was 539, 543 with window_pages); the 20 remaining lines are the 10 awaiting launches (FAIL by design) and the 10 planted RED controls. zig build test-kernel-contract: passes.
zig build kernel-contract -Dsm=120 on an RTX 5090 (CUDA 13.3, driver 615), the rebased tree: 344 kernels pass gates 1-4, 96 controls red as planted, 5 known findings (as on main), and 42 limit problems. Main at 31a864f had 161 on the same card (340 kernels then; main at 40c6406 was not rerun). The 42 are main's own: the 8 awaiting launches times 5 SMs ("no compiled usage recorded") and the live launches of tf_q35_attn_partial/partial8 at 1024 threads where the driver allows 128. Main's other 119 problems at 31a864f were live launches whose 13.3 register counts differed from the 13.2 record (e.g. tf_wrows_part_512: 122 registers, recorded 125); the 13.3 set clears them.

Not changed: the 10 awaiting launches (tf_q35_attn_partial* at 1024 threads, .usage = none) still fail closed, as
cuda_lane_pending.zig's test wants.
Rebased onto d0948b6 before the push; the required checks were run again there and pass. The fatbins, limits tool and GPU contract above ran on the tree at 40c6406; the commits since touch no kernel or contract file.

[BobClawblaw]

Checked on an RTX 4090 (sm_89) under Windows, nvcc 13.3.73 with an MSVC 19.50 host, driver 616.56, at 1a2db8900:

• zig build kernel-contract -Dsm=89: SUMMARY 330 kernels: 330 pass gates 1-4, 0 fail, 5 known findings; 90 controls: 90 red as planted, 0 missed; 43 limit problems. The 43: your 40 (the 8 awaiting launches on five SMs) and three live ones, tf_q35_attn_partial and tf_q35_attn_partial8 (the awaiting registrations at 1024 threads) and tf_experts3_widen, where Windows' nvcc gives 12 registers against the recorded 34. The same check on qwen CUDA: paged KV streams take the tensor-core attention, so a paged batch's replies equal a whole window's #1373's branch, which lacks these records, has 120 here.
• tf-cuda-test kernel-contract-limits on five-SM fatbins built here: 3,034 lines pass; the 10 FAIL lines are tf_q35_attn_partial and tf_q35_attn_partial8, the awaiting launches. 10 lines still read "record stale": tf_exl3_grouped_0 (sm_120, sm_121), tf_experts3_widen (all five SMs) and tf_experts3_planes (sm_80, sm_120, sm_121); Windows' nvcc 13.3 gives them other register counts than your Linux 13.3 records, all within their limits.
• The limits runner then stops with SymbolNotInImage at dsv41_x3ld: its records name the Linux mangling (PKl, long) and the Windows build's symbol is PKx (long long, LLP64), so the lines after it are not checked here. Not this change's doing, but it keeps the offline limits from finishing on Windows.
• zig build test-kernel-contract test-golden passes; zig fmt --check build.zig zig passes; lean against d0948b64b: 442 problems, 442 on the base, 0 new.

[ashhart]

Landed on main as 0293760, and it will ship in 1.1.7. On a GB10 the kernel contract passes all 344 kernels, and all 96 planted controls fail as they should. The author address on the commit is your ID noreply. Thank you!