[docxology]

What changed

The quality job verified a committed requirements.lock against a fresh uv export --locked and failed on any difference. That file is derived from uv.lock, so the only thing that can make it differ is someone else writing the lock — which is precisely what a lock-only dependency update does. Dependabot's uv updater writes uv.lock and nothing else, so every Dependabot PR in this repository failed that diff before installing anything; all five that are open today (#16, #17, #18, #19, #20) are blocked by it, and none of them is wrong.

The export is now derived at run time and used, rather than compared against a committed copy:

• uv lock --check stays — it is the real check that the lock matches the manifests.
• the export is written to $RUNNER_TEMP/requirements.lock and the clean-environment step installs from that path, so the derived export is still exercised end to end.
• the committed requirements.lock is removed, and README.md / CONTRIBUTING.md now point at uv.lock, with the export shown as a scratch command rather than a file to keep.
• .gitignore ignores requirements.lock so an export cannot be committed again.

Scope: no other CI changes, no lockfile edits.

Why the committed file was wrong

It was a second source of truth for the lock, and the gate that validated it could not be satisfied by the only tool that updates the lock. A derived artifact cannot be the thing that validates its own regeneration: the check either passes because no lock-privileged change happened, or fails because one did. The lock itself is the provenance, uv lock --check is the assertion, and the export is reproducible from both.

Verification

• uv lock --check passes on this branch.
• The run-time export is byte-identical to the removed committed copy (diff empty, 964 lines), so the set of installed packages does not change.
• The workflow YAML parses and the quality job keeps its 12 steps; the clean-environment requirement path is the only install-path change.