[github-actions]

hack/bump-convert-pins moved these pins in console/convert-pins.json:

torch 2.14.1 -> 2.15.0
torchvision 0.29.1 -> 0.29.2

tests/console_test.sh and tests/model_opt_test.sh passed in the workflow
run that opened this PR.

[88plug]

Checked this bump before merge. It is good to merge; one behaviour change is noted at the end.

Versions. torch 2.15.0 and torchvision 0.29.2 are the newest stable releases on PyPI (both uploaded 2026-10-28). torchvision 0.29.2 declares torch>=2.14.0 and ships Python-agnostic py3-none wheels; the PyTorch CPU index carries both (2.15.0+cpu, 0.29.2+cpu). The other seven pins are unchanged and still the newest that optimum-intel 2.2.0 allows (huggingface-hub<1.22, transformers<5.6, optimum~=2.3.0; nncf, openvino and openvino-tokenizers are at their latest). hack/bump-convert-pins --dry-run run on main's pins reproduces exactly these two moves, and run on this branch it moves nothing.

Install and run. The full pin set installs into a Python 3.12 venv, and uv pip check is clean. torchvision's native ops (nms, roi_align, the JPEG round trip, v2.Resize) run under torch 2.15.0. As a control, I built a tiny random Gemma4ForConditionalGeneration with the structure of the 26B-A4B QAT config (MoE block, the sliding/full layer pattern, attention_k_eq_v, the vision tower). I exported it with conversion_job's flags (--task image-text-to-text --weight-format int4 --sym --group-size 32 --ratio 1.0 --backup-precision none), once under main's pins and once under this branch's. All four .bin files are byte-identical. The XML files differ only in auto-generated tensor names and the recorded pytorch_version.

Ledger. No running or pending row's arm reads console/convert-pins.json. H54q's OVQ was built by bench/h54/convert.sh from bench/h54/ov-export-venv.txt (torch 2.14.1+cpu, with its sha256s recorded in EXPERIMENTS.md). The H50/H51 exports use bench/eatflow/crescent/ov-export-venv.txt. Neither file changes here, and nothing in EXPERIMENTS.md or console/ledger-rules.json names qat-convert or these pins, so no amendment is needed.

Rebased onto main at f53eac1 so CI runs against the current tree (the earlier runs were action_required on an old base). Locally, these all pass on the rebased tree: console_test, audit_test, console_mcp_test, model_opt_test, gate_merge_test, claims_check, ledger_drift_check and pe_premise_check. CI run 40945202504 on 1bf784c is green (75 checks pass, 1 skipped).

Behaviour change: Python 3.10 drops out. torch 2.15.0 publishes no cp310 wheels (requires_python >=3.11). So the printed conversion commands (python3 -m venv ... && pip install <pins>) no longer install on a host whose python3 is 3.10, which is Ubuntu 22.04's default. Main's pins resolve on 3.10. This branch's pins resolve on 3.11, 3.12 and 3.14, but not on 3.10. The pin policy follows optimum-intel's own requirements, and those do not cap torch, so this follows from the policy rather than from a bump error.

[88plug]

Independent review of 1bf784c: approve, no defects found.

• Versions. torch 2.15.0 and torchvision 0.29.2 are the newest stable releases on PyPI. torchvision v0.29.2's release notes say it is compatible with PyTorch 2.14 and later (ABI stable since 0.29.0; 0.29.1 relaxed the pin to torch>=2.14), so the pair is supported upstream, not only allowed by metadata. optimum-intel 2.2.0 allows both (torch>=2.1, torchvision). hack/bump-convert-pins --dry-run (packaging 26.3) on this branch moves nothing.
• Resolution. uv pip compile of the pin set for x86_64 manylinux resolves on Python 3.11, 3.12, 3.13 and 3.14. It does not resolve on 3.10, because torch 2.15.0 requires Python >= 3.11. The README's supported hosts are Ubuntu 24.04 (3.12) and 26.04 (3.14.3), Fedora, Arch and Manjaro, so no supported host is affected. torchvision's !=3.14.1 exclusion is unchanged from 0.29.1.
• Conversion control. I built a tiny random Gemma4ForConditionalGeneration from the QAT checkpoint's own config.json (rev f1e06dc5), with the MoE block, attention_k_eq_v, the sliding/full layer pattern and the vision tower kept, and exported it with conversion_job's flags under main's pins and under this branch's pins (CPU torch, Python 3.14). All six .bin files are byte-identical. With tensor names stripped, the XML files differ only in the recorded pytorch_version.
• Ledger. No row reads console/convert-pins.json: H54q's OVQ comes from bench/h54/ov-export-venv.txt, and the crescent exports come from bench/eatflow/crescent/ov-export-venv.txt. Neither file changes here, and EXPERIMENTS.md does not change. No amendment is needed.
• Suites on this head pass: console_test (61/0), audit_test (49/0), console_mcp_test, model_opt_test (37/0), gate_merge_test (31/0), claims_check_test (81/0), claims_check, ledger_drift_check_test and ledger_drift_check (41 files, 81 rows). The PR body's test claim matches run 40873203081: console 61/0 and model_opt 37/0.
• Main has since moved to d997ea8 (EXPERIMENTS.md and bench/flashnext/h60.sh). The branch still merges cleanly, and the merge gate will re-sync it before CI.

[88plug]

Closing as superseded by #238. #238 (merged 2026-10-29 22:10Z as 012b4e9) moved console/convert-pins.json to the same pins this PR carries: torch 2.15.0 and torchvision 0.29.2. Merging this branch into main (74ff63e) gives main's tree exactly, so a squash here would put an empty commit on main. Both pins are still the newest releases on PyPI as of 2026-10-30 00:05Z. The bump job skips the PR step when nothing moved, so it would not close this PR by itself. The next nightly that finds a newer release opens a fresh one.