← ClaudeAtlas

lockfile-probelisted

Check whether the dependency bound declared in pyproject.toml is also in force in the lockfile the deployment installs from. Reports LOCK_DRIFT with both diverging specifiers, LOCK_UNSATISFIED when the pinned version violates the declaration, LOCK_STALE from the resolver's own check. Read-only — `uv lock` is only ever run with `--check`. Deterministic; run it, do not reason about it.
malkreide/mcp-continuous-auditor · ★ 0 · AI & Automation · score 71
Install: claude install-skill malkreide/mcp-continuous-auditor
# Lockfile probe `pyproject.toml` states the bound. Does the lockfile — the file the deployment actually installs from — state it too? ```bash python scripts/lockfile_probe.py --target <path> python scripts/lockfile_probe.py --target <path> --format json python scripts/lockfile_probe.py --target <path> --no-tools # offline, files only ``` Exit `0` in sync, `2` **findings**, `3` no lockfile (NOT MEASURED — never read as a pass), `4` the checkout moved during the run, `127` the harness could not run. ## The incident The upper bounds from a portfolio PR were merged, reviewed and green — in `pyproject.toml`. `uv.lock` was not regenerated, so its recorded `requires-dist` still carried the uncapped range and its pins came from the pre-bound resolution. On `main` the fix was in the file everybody reads and absent from the file that installs. ## The findings | Code | Claim | |---|---| | `LOCK_DRIFT` | pyproject's specifier ≠ the one the lock recorded. Both printed. Where the difference is a missing cap, the detail says the bound is not in force where the install happens | | `LOCK_UNSATISFIED` | the pinned version is not admitted by pyproject's specifier — what installs violates what is declared | | `LOCK_STALE` | `uv lock --check` / `poetry check --lock` says the lock is out of date | | `LOCK_MISSING_DEP` | a declared dependency has no entry in the lock at all | Specifiers are compared as parsed clause sets: `>=2.0.0,<3` and `<3,>=2.0.0` are one requirement, `<3` and `<3.0`