Backend: regenerate uv.lock for requires-python >=3.14 #91

Merged

claude-bot merged 1 commit from fix/uv-lock-requires-python into main

2026-08-31 20:14:20 +00:00

claude-bot commented

2026-08-31 20:05:54 +00:00

Contributor

Fixes an inconsistency I introduced in bc2284d (#90).

What went wrong

#90 narrowed requires-python from ">=3.12" to ">=3.14" but committed only pyproject.toml. backend/uv.lock still declared ">=3.12", along with the cp312 wheels and python_full_version < '3.13' conditional dependencies that belong to it.

So main has been internally inconsistent since that merge.

Why CI didn't catch it

ci.yml runs uv sync --group dev without --frozen, so uv silently re-resolves and updates the lock inside the workspace. Every job passed on a lock it had quietly rewritten in memory — the committed one was never validated.

uv lock --check says so plainly:

The lockfile at `uv.lock` needs to be updated, but `--check` was provided.

The fix

Regenerated with uv lock. Both files now read ">=3.14", and --check passes. The diff is -287/+1: dropping the cp312 wheel set and the 3.12-conditional deps that >=3.14 makes unreachable.

Backend gate re-run against the refreshed lock: ruff clean, mypy clean across 61 files, 253 tests passing.

How I found it

Not by looking — by accident. A local git merge of the lockfile-maintenance branch refused to run because backend/uv.lock had uncommitted changes, which were uv regenerating it during my test runs. That's a poor way to catch a correctness bug on main.

Follow-up worth doing

Nothing in CI verifies the lock matches pyproject.toml. That's the actual gap — this class of drift can recur silently on any dependency change.

A uv lock --check step in the python jobs would close it, in exactly the same spirit as the existing alembic check that guards model/migration drift. I haven't added it here to keep this PR to the fix itself, but it's a small change and I'd recommend it.

Fixes an inconsistency I introduced in `bc2284d` (#90). ## What went wrong #90 narrowed `requires-python` from `">=3.12"` to `">=3.14"` but committed **only `pyproject.toml`**. `backend/uv.lock` still declared `">=3.12"`, along with the cp312 wheels and `python_full_version < '3.13'` conditional dependencies that belong to it. So `main` has been internally inconsistent since that merge. ## Why CI didn't catch it `ci.yml` runs `uv sync --group dev` **without `--frozen`**, so uv silently re-resolves and updates the lock inside the workspace. Every job passed on a lock it had quietly rewritten in memory — the committed one was never validated. `uv lock --check` says so plainly: ``` The lockfile at `uv.lock` needs to be updated, but `--check` was provided. ``` ## The fix Regenerated with `uv lock`. Both files now read `">=3.14"`, and `--check` passes. The diff is `-287/+1`: dropping the cp312 wheel set and the 3.12-conditional deps that `>=3.14` makes unreachable. Backend gate re-run against the refreshed lock: `ruff` clean, `mypy` clean across 61 files, **253 tests passing**. ## How I found it Not by looking — by accident. A local `git merge` of the lockfile-maintenance branch refused to run because `backend/uv.lock` had uncommitted changes, which were uv regenerating it during my test runs. That's a poor way to catch a correctness bug on `main`. ## Follow-up worth doing **Nothing in CI verifies the lock matches `pyproject.toml`.** That's the actual gap — this class of drift can recur silently on any dependency change. A `uv lock --check` step in the python jobs would close it, in exactly the same spirit as the existing `alembic check` that guards model/migration drift. I haven't added it here to keep this PR to the fix itself, but it's a small change and I'd recommend it.

claude-bot added 1 commit

2026-08-31 20:05:54 +00:00

Backend: regenerate uv.lock for requires-python >=3.14

CI / Alembic migration check (pull_request) Successful in 1m16s

Details

CI / Python lint & type-check (pull_request) Successful in 1m49s

Details

CI / Frontend lint, test & build (pull_request) Successful in 1m54s

Details

CI / Python tests (pull_request) Successful in 2m35s

Details

CI / Docker build, health smoke & E2E (pull_request) Successful in 2m47s

Details

ee32e2b60c

bc2284d narrowed requires-python from ">=3.12" to ">=3.14" but committed only
pyproject.toml. uv.lock still declared ">=3.12" and carried the cp312 wheels and
the python_full_version < '3.13' conditional dependencies that go with it, so
main was internally inconsistent.

CI did not catch it: ci.yml runs `uv sync --group dev` without --frozen, so uv
silently re-resolves and updates the lock in the workspace. The committed lock
is the reproducible pin, though, and `uv lock --check` failed on it:

  The lockfile at `uv.lock` needs to be updated, but `--check` was provided.

Regenerated with `uv lock`; both files now read ">=3.14" and --check passes.
Backend gate re-run against the refreshed lock: ruff clean, mypy clean across
61 files, 253 tests passing.

Worth a follow-up: nothing in CI verifies the lock matches pyproject, which is
why this slipped through. A `uv lock --check` step in the python jobs would
catch it, in the same spirit as the existing `alembic check` guarding model and
migration drift.

Refs #37.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

claude-bot merged commit 54e3d8bedd into main

2026-08-31 20:14:20 +00:00

claude-bot deleted branch fix/uv-lock-requires-python

2026-08-31 20:14:21 +00:00

claude-bot referenced this pull request

2026-08-31 20:15:49 +00:00

CI: fail when uv.lock drifts from pyproject.toml #92