The declared floor, the local pin, the lockfile, the image, and CI had all
drifted apart: pyproject said >=3.10, .python-version said 3.11, uv.lock
resolved >=3.11, the Dockerfile ships 3.13, and unified-tests hardcoded 3.12.
Set the server's floor to 3.13 to match the only interpreter that actually
ships, and pin CI to the same version. Three workflows passed
python-version-file: pyproject.toml, which makes setup-python read
requires-python as a range and install the newest match -- run 33108027458
resolved to CPython 3.14.7, so CI tested a Python nobody deploys and the 3.10
floor was never exercised. Pointing them at .python-version installs an exact
version instead.
That promotion makes .python-version load-bearing for CI, so add it to the
path filters in unittest.yml and live-llm-tests.yml. Those keyed on
pyproject.toml for the interpreter before; without this, editing the pin alone
would change which Python CI runs on without retriggering the suites that run
on it. unified-tests.yml is left alone -- it filters on src/** and tests/**
and never keyed on pyproject.toml either.
Re-resolving the lockfile drops async-timeout, tomli, and overrides, which
were backport shims only needed below 3.13.
sdks/python (honcho-ai, >=3.8) and honcho-cli (>=3.11) are left alone; they
publish to PyPI, so those floors are consumer-facing.
Ruff's inferred target-version moves py310 -> py313, which surfaces ~200 new
findings tree-wide (mostly UP017, datetime.timezone.utc -> datetime.UTC).
Ruff runs only via pre-commit, not in any workflow, so CI is unaffected; the
sweep is left for a follow-up rather than adding unrelated churn here.
Fixes DEV-2415
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
83fc0d4260