PLAT-2003/ci: add uv-lock pre-commit hook

[brtkwr]

Context

Nothing currently checks that uv.lock agrees with pyproject.toml in this repo.

The Dockerfile runs uv sync --frozen, which installs from the lock without verifying it matches pyproject. So a dependabot pip PR that edits pyproject.toml alone stays green — it tests the versions the lock already pins, never the ones it proposes — and the lock quietly goes stale. The mismatch then lands all at once whenever someone next regenerates the lock, far from the PR that caused it.

Worked example: PLAT-2000

That is not hypothetical. In ratatosk:

• 15 Jul — dependabot bumped pydantic to >=2.13.4 in pyproject only. Lock untouched, uv sync --frozen installed 2.12.5, deploy succeeded.
• 22 Jul — a merge-conflict resolution regenerated uv.lock, pulling in pydantic 2.13.4, which breaks pydantic-xml's computed_element on model inheritance. The module died at import.
• Staging was undeployable for a week, silently — a failed helm pre-upgrade hook aborts before the Deployment rolls, so the old pods kept serving 2/2 Ready and nothing alerted.
• Clearing that revealed a second latent failure behind it (a missing alembic migration), which had been invisible because the import error fired during pytest collection, before any DB fixture ran.

An org-wide audit found 25 of 40 repos with a uv.lock are missing this guard.

Changes

• Add the astral-sh/uv-pre-commit uv-lock hook at rev 0.10.0, matching the org's current standard (5 repos on 0.10.0, 4 on 0.9.7).

The hook regenerates uv.lock and fails if the file changes, so drift goes red on the PR that introduces it, on the day — via the pre-commit check this repo already runs.

Scope / Non-goals

• Config only. No dependency versions change.
• uv sync --frozen is deliberately left alone. All 24 repos with uv sync in a Dockerfile use --frozen; switching to --locked would work too but would make this repo the only one doing it, and catches the problem later (image build) than the hook does (commit).
• This repo's lock was verified in sync with its pyproject before the PR was opened, so the hook should pass first time. If pre-commit goes red here, it has found real pre-existing drift and the regenerated lock needs reviewing on its merits — that regeneration is exactly what detonated ratatosk, so it should not be rubber-stamped.

Validation

• Insertion validated as parseable YAML with exactly one repo entry added, across all 25 repos in the sweep.
• Placement matches checkout-api's, immediately before the two-inc/git-hooks entry.

Ticket

• https://linear.app/two-inc/issue/PLAT-2003

🤖 Generated with Claude Code

https://claude.ai/code/session_017VDJqb1XWoNNxZEfGQ8meH

[github-actions]

☂️ Code Coverage

current status: ✅

Overall Coverage

Statements	Covered	Coverage	Threshold	Status
253	244	96%	0%	🟢

New Files

No new covered files...

Modified Files

No covered modified files...

updated for commit: 5e4640f by action🐍

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5e4640f503

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Execute the lock hook in the PR workflow

When Dependabot opens the dependency-update PRs this change is intended to guard, no client-side pre-commit hook runs. The only workflow inspected, .github/workflows/deploy.yaml, runs uv sync --all-groups and pytest at lines 26–28 but never invokes pre-commit, so this new hook is not executed and a PR with an uncommitted lockfile update can still pass. Add a CI step that runs this hook (or an equivalent lock consistency check).

Useful? React with 👍 / 👎.

[Puvendhan]

Mechanical uv-lock pre-commit hook addition (PLAT-2003). Approving.