build(deps): raise the declared Python floor to 3.12

[ashtonchew]

Review this as a dependency upgrade, not a metadata fix. The CUDA cutover it triggers is explained in full below.

Why

requires-python = ">3.10" claimed support for 3.11 and newer. The lockfile cannot deliver that: 3.13 fails building greenlet 3.0.3 from source (playwright 1.44.0 via libwebarena pins it, no cp313 wheel), and 3.14 fails because ray publishes no cp314 wheel. #161 pinned the working interpreter with .python-version but left the declaration false.

Three places state the Python floor. This makes all three agree at 3.12.

	before	after
requires-python	>3.10 (false)	>=3.12,<3.13
Ruff target-version	py310, hand-maintained	deleted — inferred
mypy python_version	3.10	3.12

Ruff's target-version is deleted rather than raised because its docs prefer inferring from requires-python — "it's based on Python packaging standards, and will be respected by other tools" — so the value can no longer drift from the declaration. ruff check --show-settings reports unresolved_target_version = 3.12.

The dependency move

In the default install profile, exactly one package moves:

torch  2.9.1 → 2.11.0

numpy (2.2.6), pandas, scipy, transformers (4.57.5), ray (2.53.0) and playwright (1.44.0) all hold. Outside the default profile, vllm 0.16.0 → 0.23.0 and xgrammar 0.1.29 → 0.2.4 affect only the cua optional extra, and triton 3.5.1 → 3.6.0 is Linux-only.

The move is a consequence of the fork collapse rather than an upgrade decision. The old lock carried torch==2.9.1 ; python_full_version < '3.13' beside torch==2.11.0 ; python_full_version >= '3.13'; narrowing the range to 3.12 collapses the fork, and uv keeps the higher pin. uv.lock goes 413 → 360 packages.

Numerics

torch 2.11 documents no change to default dtypes, matmul/TF32 precision, RNG, or determinism; its headline features are opt-in and marked API-unstable. Two properties of this tree make drift unlikely regardless: all dtype selection is explicit bfloat16, and no first-party code calls torch.manual_seed or use_deterministic_algorithms — the seeds that exist govern dataset sampling only. No reproducibility guarantee that previously held is broken.

The CUDA cutover

torch 2.11 changes which CUDA build the default PyPI wheel carries: CUDA 13 replaces CUDA 12 as the default variant, on x86_64 and ARM alike. That has two consequences, and only one of them applies here.

Architecture support — does not apply. CUDA 13 removes Maxwell, Pascal and Volta, everything below Turing (sm_75). The hosts this project provisions are A100 (sm_80) and H100 (sm_90), per docs/HANDOFF_CUA_EVAL_AWARENESS.md and docs/HANDOFF_GUI_OWL_PROBE_RESULTS.md. Both sit above the new floor, so no host loses support.

Driver floor — applies, and has already bitten this project. CUDA 13.0 requires NVIDIA driver ≥ 580.65.06 on Linux, against ≥ 525.60.13 for CUDA 12.0. A host below that cannot use the default wheel, and the failure mode is the dangerous one — silent:

torch.cuda.is_available() returned False and the model silently loaded on CPU

That is quoted from docs/HANDOFF_GUI_OWL_PROBE_RESULTS.md, recording a pod on driver 565.57.01. No exception is raised; the run simply completes on the wrong device.

What this PR changes is the blast radius, not the failure. That gotcha previously arrived only through the [cua] extras, where vllm pulled torch 2.11.0+cu130. With torch 2.11 in the default dependencies it now reaches every GPU host, whether or not vLLM is installed.

Mitigations, in order of preference:

1. Provision GPU hosts with driver ≥ 580.65.06. The clean fix, and the direction PyTorch is moving.
2. Reinstall torch from the cu126 index on a host that cannot be re-driven — the recipe already in the handoff. This breaks vLLM serving; probe extraction does not need it.
3. Pin a CUDA 12 index in [tool.uv.sources]. Deliberately not done here: it would tie the whole project to a CUDA generation in order to accommodate hosts that can be re-driven instead.

This is not a merge blocker. CPU-only environments — CI, laptops, everything that runs Ruff, Black and mypy — are unaffected, since the CUDA variant only matters where a GPU is present. GPU hosts are provisioned per-run from the handoffs, and this PR corrects those: HANDOFF_GUI_OWL_PROBE_RESULTS.md previously named the [cua] extras as the trigger and "≥570.x" as the driver fix, and both were wrong after this change.

The StrEnum conversions

(str, Enum) renders str(member) as ClassName.MEMBER; StrEnum renders the value. Since this repo's output is experiment results, each was checked rather than autofixed:

enum	finding	action
AwarenessClassification	no reference outside its own definition — grep repo-wide returns one line	converted
ReasoningCategory	~40 sites, all ==/in/dict-key/.value; both persistence writes use .value explicitly	converted, invariant recorded in the docstring
TokenSelector	one f-string, in an unreachable error branch	converted

ReasoningCategory was the one that could have bitten — its values differ sharply from its names (ALIGNMENT_EVAL = "Alignment Evaluation"), so the rendering difference would have been visible in any persisted string that used str() rather than .value.

Verification

uv lock --check              → Resolved 360 packages
uv sync --locked --group dev → Checked 250 packages
uv run ruff check .          → All checks passed!
uv run black --check .       → 96 files would be left unchanged
uv run mypy                  → Success: no issues found in 96 source files
ruff --show-settings         → unresolved_target_version = 3.12

Not established

vllm 0.16 → 0.23 was not reviewed to the same depth — the intervening release notes are poorly indexed and 0.23.0 alone spans 408 commits. It sits behind an opt-in extra and does not affect the default profile, but anyone installing .[cua] should treat it as an unreviewed jump.