chore: make uv.lock the real install path

[smaramwbc]

Replaces #517, which deleted the lockfile. That was the wrong fix, for a reason worth writing down.

What was actually wrong

uv.lock was installed by nothing. CI ran pip install -e ".[dev]", the Dockerfile ran pip install ".[llm]", and both re-resolved pyproject.toml on every build. A repo-wide grep finds no uv sync, uv run, uv pip or setup-uv anywhere. The lock had drifted far enough to pin eight direct dependencies below pyproject.toml's own lower bounds while CI stayed green, which is only possible if nothing reads it.

But it was not dead weight. GitHub's dependency graph is built from it. All 99 graphed PyPI packages come from uv.lock, and all 27 Dependabot alerts in this repo's history cite manifest=uv.lock — none has ever come from pyproject.toml. Static transitive analysis is unsupported for pip, so the lockfile is the only reason indirect dependencies are monitored at all.

That explains the three open alerts:

alert	lock pins	image actually installs	fix version
#25 fsspec, HIGH CVSS 8.8 (GHSA-27vj-qcqg-25rc)	2026.4.0	2026.9.0	2026.6.0
#26 multidict, MEDIUM	6.7.1	6.9.1	6.9.1
#27 Mako, MEDIUM	1.3.12	1.4.3	1.4.2

The detector was aimed at fiction. Nothing shipped was vulnerable, and equally, a CVE in the versions that do ship would have gone unreported. Deleting the file would have cleared the alerts by removing the only thing capable of raising them.

What this does instead

Makes the lockfile true, so the graph describes the artifact.

uv lock --upgrade, not a plain uv lock. This is the trap in the whole change. A plain relock treats existing pins as resolution preferences: it bumps only the 15 packages pyproject.toml's bounds force and leaves fsspec, Mako and multidict exactly where they are. Promoting that to the real install path would have converted three phantom alerts into three genuine ones and downgraded the image.

uv export + uv pip install --system, not uv sync. --system installs into the same interpreter pip used, so ruff, alembic, pytest and start.sh's bare python / alembic / uvicorn all keep resolving. uv sync would create a .venv nothing activates and would prune pip out of the image. Plain uv pip install is also deliberate over uv pip sync / --exact, which prune.

--locked everywhere, never --frozen. --frozen succeeds on a drifted lock and exports the stale pins — that is the #327 undeclared-runtime-dependency failure waiting to happen again, invisible to startup, pytest and docker-smoke because the imports are function-local. --locked fails instead. CI also runs uv lock --check as an explicit gate. It fails on real pyproject-vs-lock drift but not merely because a newer release exists upstream, since resolution prefers existing pins.

setup-uv is pinned by commit SHA. The action publishes no floating major past v7; @v8, @v9 and @v10 all return 404, so uses: astral-sh/setup-uv@v10 would fail at action-resolution time before any step ran.

Both Dockerfile install steps stay. The second one is still what puts server/ into site-packages; without it alembic upgrade head dies with ModuleNotFoundError: server and the container exits 1 while uvicorn alone still looks fine.

dependabot.yml replaces the pip entry with uv rather than adding one. The pip ecosystem cannot update uv.lock — it rewrites pyproject.toml alone — and uv.lock records each requirement's constraint string verbatim, so a pyproject-only edit invalidates the lock. Keeping both entries would fail uv lock --check on every weekly pip PR. dependency-type: all is required because every alert this repo has ever had was against an indirect pin, and the entry is grouped into one PR because it now covers ~95 packages.

bump_version.py writes uv.lock too. The lock records the project's own version, so a release bumping pyproject.toml alone would fail uv lock --check with a message that never mentions the version.

Verification

Checked against the shipped artifact, not on exit codes.

The rebuilt image installs the same dependency set it does today:

• boto3 / botocore are one patch newer (1.43.110 vs 1.43.109, released since this morning's build)
• packaging is now pinned explicitly at 26.3 — the exact version python:3.11-slim already provides, so no change in what is importable
• the five packages leaving the lock are typer's tree (typer, rich, markdown-it-py, mdurl, shellingham), dropped because huggingface-hub 1.33.0 no longer requires it. Absent from today's image and imported nowhere in the repo.

docker build plus the docker-smoke sequence pass locally against a pgvector/pgvector:pg16 service: migrations run through 0033, /healthz returns {"status":"ok"}, both scripts.bootstrap_* modules import from /app (they resolve as a namespace package from the working directory), site-packages/server is present and non-editable, and pip survives.

The CI install path was reproduced in an isolated venv: the hashed export installs under hash-checking mode, ruff 0.16.10 / alembic 1.20.0 / pytest 9.1.1 land on PATH, and server imports from any cwd.

The release path was exercised: bump_version.py 1.6.0 now updates uv.lock alongside pyproject, README, the three issue templates and the two Helm files, and both bump_version.py --check and uv lock --check stay green.

ruff clean. 1194 unit tests pass. 320 of 321 integration tests pass — test_distributed_rate_limit_blocks_after_limit fails identically on a baseline pyproject-resolved install, so it predates this change and is a local environment difference, not a regression.

Trade-off

The uv updater writes uv.lock only, so it will not raise pyproject.toml's lower bounds the way the pip entry did. Those floors matter to consumers of the published package, so bumping them becomes a deliberate step at release time rather than an automated PR.

Follow-ups

• chore(deps): bump mako from 1.3.12 to 1.4.2 #514, chore(deps): bump fsspec from 2026.4.0 to 2026.6.0 #515 and chore(deps): bump multidict from 6.7.1 to 6.9.1 #516 should resolve as superseded once this lands, since the lock will pin versions at or past every fix version. If Dependabot declines to close them (it refuses to close a PR for a dependency that is no longer vulnerable), they can be closed by hand.
• statewave-py carries the same dead uv.lock (49,741 bytes, 2 alerts off it, no uv references in the repo). Same treatment, separately.