chore(python): uv.lock still resolved 1.0.0, and nothing could see it

The 1.0.1 cut bumped `server/python/pyproject.toml` but not `uv.lock`, which went
on stating `version = "1.0.0"` for the project itself. Found by running the
python lane locally and getting a dirty tree afterwards.

It stayed invisible because no lane runs `uv` with `--locked` or `--frozen`:
plain `uv run` REWRITES a disagreeing lockfile in place, so every lane passes,
the committed file keeps saying something untrue, and the only symptom is a
surprise modified file for whoever next runs the suite. It also is not the
first time — the 1.0.0 cut needed its own follow-up commit
(`e5f39e302 chore(release): uv.lock resolves metaobjects at 1.0.0`), which is
what a step that is easy to skip and impossible to detect looks like on its
second occurrence.

Regenerates the lock and adds `scripts/check-uv-lock-version.sh` to the gates
lane beside the pom and bun version-parity guards, so the third occurrence
fails instead of drifting. Toolchain-free (awk + grep, no uv) so it runs in
`gates` rather than needing the python lane, and the package entry is matched
inside its own `[[package]]` block so a similarly-named dependency cannot be
read instead. Verified by restoring the stale lock: exit 1, naming both
versions and the `uv lock` command that fixes it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NTcEKXTQMYt84fAjuw5A2M

Author: dmealing

scripts/check-uv-lock-version.sh

@@ -0,0 +1,71 @@
+#!/usr/bin/env bash
+#
+# Guard: server/python/uv.lock's own `metaobjects` entry must carry the SAME version
+# as server/python/pyproject.toml.
+#
+# Why this exists: nothing in this repo runs `uv` with `--locked` or `--frozen` — every
+# lane uses plain `uv run`, which silently REWRITES the lockfile in place when it
+# disagrees with the project. So a release that bumps pyproject.toml and forgets the
+# lock leaves a committed file stating the previous version, every lane stays green,
+# and the drift is invisible until someone happens to run the suite and notices a dirty
+# tree. That is not hypothetical and it is not once: the 1.0.0 cut needed a dedicated
+# follow-up commit (`chore(release): uv.lock resolves metaobjects at 1.0.0`), and the
+# 1.0.1 cut skipped the step again — pyproject at 1.0.1, lock still saying 1.0.0.
+#
+# It matters beyond tidiness because the lock is what a `--locked` install would
+# resolve: the moment any consumer or CI adds that flag, a stale lock fails the install
+# rather than quietly self-healing.
+#
+# Toolchain-free on purpose (grep + sed, no uv), so it runs in the `gates` lane beside
+# the pom and bun version-parity guards rather than needing the python lane.
+#
+# Usage:  scripts/check-uv-lock-version.sh      # exit 1 + diagnostic on drift
+#
+set -uo pipefail
+
+ROOT="$(cd "$(dirname "$0")/.." && pwd)"
+PYPROJECT="$ROOT/server/python/pyproject.toml"
+LOCK="$ROOT/server/python/uv.lock"
+
+for f in "$PYPROJECT" "$LOCK"; do
+  [ -f "$f" ] || { echo "check-uv-lock-version: missing $f" >&2; exit 1; }
+done
+
+# `version = "..."` under [project]; the first such line in the file is the project's.
+project_version="$(grep -m1 -oE '^version[[:space:]]*=[[:space:]]*"[^"]+"' "$PYPROJECT" \
+                   | sed -E 's/.*"([^"]+)".*/\1/')"
+if [ -z "$project_version" ]; then
+  echo "check-uv-lock-version: could not read the version from $PYPROJECT" >&2
+  exit 1
+fi
+
+# The lock's own entry for this project — `name = "metaobjects"` followed by its
+# version. Anchored to the package block so a DEPENDENCY that happens to be named
+# similarly cannot be read instead.
+lock_version="$(awk '
+  /^name = "metaobjects"$/ { inpkg = 1; next }
+  inpkg && /^version = / { gsub(/^version = "|"$/, ""); print; exit }
+  inpkg && /^\[\[package\]\]$/ { inpkg = 0 }
+' "$LOCK")"
+if [ -z "$lock_version" ]; then
+  echo "check-uv-lock-version: could not find the metaobjects package entry in $LOCK" >&2
+  exit 1
+fi
+
+if [ "$project_version" != "$lock_version" ]; then
+  cat >&2 <<MSG
+check-uv-lock-version: server/python/uv.lock is STALE.
+
+  pyproject.toml : $project_version
+  uv.lock        : $lock_version
+
+The lock still resolves the previous version. Nothing runs uv with --locked, so every
+lane will keep passing while the committed lock says something untrue — and a plain
+\`uv run\` rewrites it, so whoever next runs the suite gets a surprise dirty tree.
+
+Fix:  (cd server/python && uv lock)   then commit server/python/uv.lock
+MSG
+  exit 1
+fi
+
+echo "check-uv-lock-version: uv.lock agrees with pyproject.toml ($project_version)"

scripts/ci-local.sh

@@ -173,6 +173,12 @@ gate_publish_set() { node scripts/publish-set.mjs --check && node scripts/test-p
 # checks names. Offline; one manifest.
 gate_script_name_hooks() { node scripts/check-script-name-hooks.mjs; }
 
+# ── release hygiene: uv.lock must agree with pyproject.toml ──────────────────
+# Every lane runs plain `uv run`, which REWRITES a disagreeing lockfile in place, so a
+# release that bumps pyproject and forgets the lock stays green forever. Twice now: the
+# 1.0.0 cut needed a follow-up commit, and 1.0.1 skipped the step again.
+gate_uv_lock_version() { scripts/check-uv-lock-version.sh; }
+
 # ── the lane selector decides what CI runs, so nothing may run it untested ────
 # Both selector tests existed-but-unwired at some point: test-ci-affected-ports.sh was
 # referenced by no lane at all, so the mapping that decides which ports get tested was
@@ -709,6 +715,7 @@ fi
 if want gates; then step    "leak-scan (security)"             gate_leak_scan;             fi
 if want gates; then step    "pom-version parity"               gate_pom_versions;           fi
 if want gates; then step    "bun-version parity"               gate_bun_version;            fi
+if want gates; then step    "uv.lock version parity"           gate_uv_lock_version;        fi
 if want gates; then step    "publish-intent parity"            gate_publish_intent;         fi
 if want gates; then step    "publish-set parity"               gate_publish_set;            fi
 if want gates; then step    "no committed pre-release version" gate_no_prerelease_versions; fi