version-bump leaves uv.lock's self-version stale, so every checkout shows a spurious uv.lock diff

[vitali87]

What

version-bump.yml updates pyproject.toml and server.json when it bumps the version, but never updates uv.lock, which carries its own copy of the project version:

[[package]]
name = "code-graph-rag"
version = "0.0.747"      # <- stale on main while pyproject.toml says 0.0.750
source = { editable = "." }

The workflow only ever runs uv sync --frozen (line 229), which by definition will not rewrite the lock. The sed steps that follow touch pyproject.toml (line 236) and server.json — not uv.lock.

Effect

Any uv command that resolves the workspace regenerates that one line, so the file shows as modified in a clean checkout:

$ git status --short
 M uv.lock
$ git diff --numstat uv.lock
1	1	uv.lock

It is only ever the self-version line, so nothing breaks. The costs are that it is noise in every git status, it invites accidental inclusion in unrelated commits, and — the reason I noticed — it gets misattributed. Another agent session inspecting my checkout today read that diff as "someone's release work" in progress. It is not anyone's work; it is the repo self-healing a stale line.

The drift also self-corrects invisibly: whenever a PR happens to run uv lock for an unrelated reason, the current version rides along in that PR's diff. uv.lock's last three commits are 0996806b (a Markdown feature), 051d0302 (an SQL grammar pin), 09be0c10 (a Jedi frontend fix) — none of which are release commits. So the lock is version-bumped by whichever feature PR happens to touch it next, which is arbitrary.

Suggested fix

In the same block that seds pyproject.toml, update the lock's self-version. Either targeted:

uv lock --offline    # rewrites the self-version without re-resolving deps

or, if avoiding a uv invocation there is preferable, the same sed treatment scoped to the [[package]] name = "code-graph-rag" stanza — though uv lock is safer since it cannot corrupt the TOML structure.

Worth confirming it stays inside the existing "revert if it fails" guard so a lock failure cannot half-commit a release.

Not urgent

Cosmetic. Filing because it is a small, contained fix and because the misattribution risk is real when several agent sessions inspect each other's checkouts.

[vitali87]

Stronger evidence than the original framing: this is not cosmetic, it is a broken invariant on committed main.

On a clean checkout with no local edits:

$ git status --short
(clean)
$ uv lock --check
Resolved 250 packages in 95ms
The lockfile at `uv.lock` needs to be updated, but `--locked` was provided. To update the lockfile, run `uv lock`.

So uv.lock and pyproject.toml disagree in the repository itself, independent of anything any contributor ran locally. Confirmed independently on a second clone, where the drift is far wider — uv.lock at 0.0.728 against pyproject.toml at 0.0.746, eighteen versions apart. The gap is unbounded and grows until some unrelated PR happens to run uv lock and sweeps the current version into its diff.

Two consequences beyond the noise:

1. Every clone carries a permanently dirty file. Contributors must remember to discard it before staging; anyone who stages broadly lands a spurious version change in an unrelated PR. It is only harmless because people habitually work around it.
2. The workaround hides the cause. A second agent session had this recorded as "make readme touches uv.lock as a side effect" and had been discarding the file before every commit all day. make readme is innocent — any uv invocation that resolves rewrites the stale line. The workaround was cheap enough that the wrong explanation never got tested.

Root cause confirmed in version-bump.yml: the sed steps update pyproject.toml and server.json, and the commit stages pyproject.toml server.json NEWS.md README.md. uv.lock is neither regenerated nor staged, so its self-version has been frozen since it was last updated by an unrelated PR.

Fix should include a CI uv lock --check, not just a one-time re-lock — without it the same drift restarts on the next bump. Taking this one.