[lhoupert]

The action resolves its dependencies on every run (uv run --no-project --with), so the committed uv.lock was never installed by the action or by CI, whose self-audit already resolves fresh since #77; it only produced Dependabot alerts and PRs for versions nobody ran. This removes the lock and the root uv Dependabot entry, and makes the action's uv run skip releases younger than 7 days (--exclude-newer with an absolute cutoff): a hijacked PyPI release cannot reach users until it is a week old, while fixes still arrive without an action update. A new dependency_cooldown_days input (default 7, 0 turns it off) covers callers whose index publishes no upload times, where any cutoff resolves nothing. CI resolves with the same cooldown (UV_EXCLUDE_NEWER) and now also runs weekly, so tests and the self-audit follow what users get.

For reviewers: a dependency floor in pyproject.toml must not require a release younger than 7 days, or every run fails until that release ages. The cutoff is computed in bash because uv before 0.9.17 rejects "7 days" and setup-uv installs the uv a caller pins; it is a CLI flag rather than UV_EXCLUDE_NEWER, so it does not leak into the uv export that audits the caller's own lock.

How this was made

Claude Code drafted the change after @lhoupert chose a runtime cooldown over making the lock the action's runtime dependency set, to keep maintenance low. An independent Claude Code review agent then found that callers pinning uv older than 0.9.17, or using an index without upload times, would fail, and that the self-audit no longer ran without a push; all three are fixed in af44bab (its suggestion to add a cooldown for local development was left out). Checked locally: pytest (186 tests) with dependencies installed under the cooldown; a replay of the CI security job (pip-audit audited 44 packages resolved with the cooldown, no known vulnerabilities); the new audit step with cooldown 7, 0 and an invalid value, and under uv 0.9.16, which rejects the previous relative form; and that the flag does not reach the audited process's environment. The GNU date branch (Linux and Windows runners) only runs in CI. Pre-commit, including zizmor, passes.

— Claude Code, on behalf of @lhoupert

[github-actions]

✅ All test workflows behaved as expected

13 passed, 0 failed

Test	Name	Expected	Actual	Bandit	pip-audit	Result
01	requirements · flat · clean	success	success	—	—	✅
02	requirements · src/ · bandit HIGH	failure	failure	B105, B404, B602	—	✅
03	requirements · src/+scripts/ · bandit HIGH + pip-audit	failure	failure	B105, B404, B602	cryptography, idna, requests, urllib3	✅
04	uv · flat · clean	success	success	—	—	✅
05	uv · src/ · pip-audit vuln	failure	failure	—	certifi, idna, requests, urllib3	✅
06	uv · src/+scripts/ · bandit MEDIUM	failure	failure	B324, B506	—	✅
07	poetry · flat · clean	success	success	—	—	✅
08	poetry · src/ · bandit MEDIUM + pip-audit	failure	failure	B105, B324	certifi, cryptography, idna, requests, urllib3	✅
09	pipenv · flat · clean	success	success	—	—	✅
10	pipenv · src/+scripts/ · bandit HIGH	failure	failure	B404, B602	—	✅
11	requirements · flat · clean (root working dir)	success	success	—	—	✅
12	uv · flat · bandit-only (no pip-audit)	failure	failure	B404, B602	disabled	✅
14	uv · flat · low threshold (B101 assert)	failure	failure	B101	disabled	✅