chore: enforce supply chain age gating

[Kevin-layerV]

Summary

• Adds a CI workflow (dependency-age-check.yml) that rejects dependencies published in the last 7 days
• Uses uv lock --exclude-newer <7-days-ago> as a standalone resolver to validate dependency ages
• The project's package manager remains pip/hatchling — uv is only used as a validation tool here

Why

Newly published or hijacked packages are typically detected and removed within days. A 7-day quarantine at the CI merge gate ensures compromised packages never enter our dependency tree.

Override for critical updates

# In the workflow, temporarily set CUTOFF to now:
uv lock --exclude-newer "$(date -u '+%Y-%m-%dT%H:%M:%SZ')"

Test plan

• Workflow triggers on PRs that modify pyproject.toml
• uv lock --exclude-newer <RFC3339 timestamp> resolves successfully for current deps
• Action pinned to commit SHA, permissions restricted to contents: read
• Manual: add a dependency published <7 days ago, verify CI blocks the PR

🤖 Generated with Claude Code

[claude]

PR Review: chore: enforce supply chain age gating

Summary: The intent - adding a quarantine window so newly published (or hijacked) packages cannot enter the dependency tree - is a solid supply chain security practice. However, the implementation has a critical issue that prevents it from working as described.

---

Critical Issue: Invalid exclude-newer value

The file sets exclude-newer to "7 days".

exclude-newer does not accept relative duration strings. It requires an absolute RFC 3339 timestamp (e.g., 2026-03-25T00:00:00Z) or a date string (e.g., 2026-03-25). The value "7 days" is not a valid format and will cause a parse error or be silently ignored depending on the uv version.

This means the PR does not achieve its stated goal - there is no rolling 7-day quarantine mechanism built into uv.

What exclude-newer is actually designed for: It pins dependency resolution to a fixed point in time for reproducibility - e.g., only consider packages that existed before this date. It is not a sliding window.

Recommendations:

1. If the goal is reproducible lockfiles pinned to a known-good date: set exclude-newer to a fixed date and update it periodically (manually or via CI), e.g. exclude-newer = "2026-04-01T00:00:00Z". This would need a process (e.g., a scheduled CI job) to bump the date forward.

2. If the goal is a rolling quarantine window: this cannot be achieved via static uv.toml config alone. You would need a CI step or pre-commit hook that computes the date dynamically and passes it via the CLI flag.

3. If the goal is broader supply chain protection: consider complementary measures like hash-checking (uv lock already generates hashes in uv.lock), pinning to exact versions, or using a private index/proxy with its own quarantine policy.

---

Other Notes:

• No test or CI changes needed for a config-only file, so the minimal diff is appropriate.
• The override instructions in the PR body are helpful - good practice for documenting escape hatches.
• The commit message format follows the project conventional commit convention.

---

Verdict: Request changes. The current value is invalid and will not provide the intended protection. Please update to a valid RFC 3339 timestamp and consider which approach (static pin vs. dynamic CI step) best fits the project workflow.

---

Reviewed by Claude

[claude]

PR Review: chore: enforce supply chain age gating

Overall Assessment

Looks good. This is a small, well-motivated supply chain security hardening change. A few points to consider before merging:

---

Code Quality & Best Practices

• Placement is correct — [tool.uv] in pyproject.toml is the right place (vs. a separate uv.toml), keeping all tool config co-located. The PR description mentions uv.toml but the actual change is in pyproject.toml, which is fine — just a minor description inconsistency.
• Commit message follows the chore: conventional commit format per project conventions.

Potential Issues

1. exclude-newer expects an RFC 3339 timestamp or a date, not a relative duration. According to the uv documentation, the value should be an RFC 3339 timestamp (e.g., "2006-12-02T02:07:43Z") or a date (e.g., "2006-12-02"). The value "7 days" is not a valid format and will likely be silently ignored or cause an error. This is the main blocker — please verify by running uv lock --dry-run and confirming it actually applies the constraint. If uv doesn't support relative durations, you'll need a different approach (e.g., a CI script that computes a date 7 days ago and passes --exclude-newer <date>).

2. CI/developer friction — If this setting works as intended, it will block resolution of any dependency published in the last 7 days. This could slow down adopting security patches for actual vulnerabilities (e.g., a critical httpx fix). The override instructions in the PR description are helpful, but consider documenting the override in a comment in pyproject.toml itself so developers don't need to go hunting through PR history.

Security

• The intent is sound — age-gating is a reasonable supply chain defense. The 7-day window is a practical choice.
• This does not replace other supply chain protections (lockfile pinning, hash verification, Dependabot/Renovate). Make sure those are also in place for defense in depth.

Performance

• No performance impact — this only affects dependency resolution time.

Test Coverage

• No code changes requiring tests. The test plan in the PR description is appropriate.
• Recommend actually running the test plan items before merging, especially given the format concern above.

---

Summary

The idea is solid, but please verify that "7 days" is a valid value for exclude-newer — the uv docs indicate it expects an RFC 3339 timestamp or date string, not a relative duration. If it isn't valid, the setting may be silently ignored, giving a false sense of security.

🤖 Generated with Claude Code

[claude]

PR Review: chore: enforce supply chain age gating

Overall Assessment

Approve. The third commit fixes the critical issue flagged in previous reviews (invalid relative duration "7 days" replaced with a valid RFC 3339 timestamp). The change is minimal, well-commented, and achieves its stated goal.

---

Code Quality & Best Practices

• Good placement — [tool.uv] in pyproject.toml is consistent with how ruff, mypy, and pytest are configured in the same file. The second commit consolidating from a standalone uv.toml was the right call.
• Helpful inline comments — The override instruction (uv lock --exclude-newer "2099-01-01T00:00:00Z") is documented right where a developer will see it, not just in PR history. Good practice.
• Commit messages follow the chore:/fix: conventional commit format per project conventions.

Potential Issues

1. Date will become stale quickly. The pinned date 2026-04-03 is already 7 days behind today (2026-04-10). Once merged, uv lock will not resolve any package version published after April 3rd. There is no automated process to bump this date — CI uses pip install, not uv, so the setting currently only affects local developer workflows. Consider one of:

   • A scheduled CI workflow (e.g., weekly) that bumps the date and opens a PR.
   • A Makefile / script target that sets the date to $(date -d '7 days ago' -u +%Y-%m-%dT00:00:00Z) before running uv lock.
   • Documenting the expected manual cadence in CONTRIBUTING.md or similar.

2. CI doesn't use uv today. The CI workflow (ci.yml) installs dependencies via pip install -e ".[dev,langchain]", so exclude-newer has no effect in CI. This means the protection only applies to developers who use uv lock locally. If supply chain hardening is the goal, consider migrating CI to uv as well, or at minimum noting this limitation.

3. Minor: PR description inconsistency. The summary bullet still says "Adds uv.toml with exclude-newer = "7 days"" — this was true for commit 1 but no longer reflects the final state. Worth editing the description so future readers aren't confused.

Security

• The intent is sound — age-gating is a reasonable layer of supply chain defense.
• This is not a substitute for lockfile pinning, hash verification, or Dependabot/Renovate. It's complementary. No uv.lock file exists in the repo today, so the full benefit of uv's supply chain features (hash checking, locked installs) isn't realized yet.

Performance

• No performance impact. This only constrains dependency resolution.

Test Coverage

• Config-only change — no code tests needed. The test plan items in the PR description are appropriate.

---

Summary

The fix in the third commit resolves the original blocker. The main remaining concern is operational: without a process to periodically advance the date, it will drift and eventually block legitimate dependency updates. Consider adding automation or at least documenting the expected cadence before merging.

🤖 Generated with Claude Code

[claude]

Code Review — PR #10: Supply Chain Age Gating

Good idea overall — a 7-day quarantine on new packages is a practical supply chain defense, and the evolution from a static config to a dynamic CI check was the right call. A few issues worth addressing before merging:

---

🔴 Security: setup-uv action not pinned to a commit hash

actions/checkout is correctly pinned to a full SHA — but astral-sh/setup-uv@v6 is only pinned to a mutable major-version tag. A compromised or hijacked tag could inject arbitrary code into this workflow. This is especially ironic in a supply chain hardening PR.

Recommendation: Pin to a specific commit hash, same as actions/checkout:

- uses: astral-sh/setup-uv@<full-sha> # v6.x.x

---

🟡 Scope: check only triggers on pyproject.toml changes

The paths filter means this workflow only runs when pyproject.toml is modified. This leaves gaps:

• If the project adopts uv.lock in the future, lockfile-only updates (e.g., via Dependabot/Renovate) would bypass the check.
• Transitive dependency changes that don't touch pyproject.toml aren't caught.

This is acceptable as a first iteration, but worth documenting as a known limitation — or broadening the trigger to also include uv.lock and/or requirements*.txt if those exist.

---

🟡 Workflow hardening: missing permissions block

The workflow doesn't declare permissions. Best practice for a read-only CI check is to restrict to the minimum:

permissions:
  contents: read

This limits blast radius if the workflow or an action is ever compromised.

---

🟢 Nit: unnecessary macOS date fallback

CUTOFF=$(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ' 2>/dev/null \
      || date -u -v-7d '+%Y-%m-%dT%H:%M:%SZ')

The fallback (date -v-7d) is the BSD/macOS date syntax, but this runs exclusively on ubuntu-latest (GNU coreutils). The fallback is harmless but unnecessary — removing it would reduce confusion about supported runners.

---

🟢 Nit: spurious blank line in pyproject.toml

The diff introduces an extra blank line between [tool.mypy] and [tool.pytest.ini_options] (residual from removing the [tool.uv] section in an earlier commit). Minor, but worth cleaning up.

---

Design consideration: what uv lock --exclude-newer actually validates

Worth noting for the team: uv lock --exclude-newer <cutoff> resolves the entire dependency tree using only packages published before the cutoff. If a constraint like httpx>=0.27,<1 can be satisfied by an older version (e.g., 0.27.2 from 6 months ago), the check succeeds even if a brand-new 0.28.0 was published yesterday. The check is effective at catching:

• Newly added dependencies with no version older than 7 days
• Version pin bumps that require a too-new release

It does not verify that the versions pip install or uv sync would actually select are older than 7 days. This is a reasonable trade-off for a first pass, but the team should understand the boundary.

---

Summary

Finding	Severity	Actionable?
setup-uv not pinned to SHA	High	Yes — pin it
Missing permissions block	Medium	Yes — add contents: read
Narrow paths trigger	Low	Document or widen later
macOS date fallback	Nit	Optional cleanup
Extra blank line in pyproject.toml	Nit	Optional cleanup

CI is green. The concept is sound — the main action item is pinning the setup-uv action to a commit hash for consistency with the rest of the repo's supply chain posture.

[claude]

Code Review — PR #10: chore: enforce supply chain age gating

Good initiative — supply chain age gating is a sound defensive measure. Pinned action SHAs, minimal contents: read permissions, and clear inline comments are all solid. A few items to address:

---

1. PR description / actual change mismatch

The PR body says "Adds uv.toml with exclude-newer = "7 days"" but the actual change is a GitHub Actions workflow file (.github/workflows/dependency-age-check.yml). No uv.toml is added. Please update the PR description to accurately reflect what's being introduced — this matters for anyone reading the git history later.

2. Project doesn't use uv — is this intentional?

The existing CI (ci.yml) uses pip install -e ".[dev,langchain]" with hatchling as the build backend. There is no uv.lock in the repository. Using uv lock --exclude-newer as a standalone validation tool is a creative approach, but it should be called out explicitly:

• Developers unfamiliar with this pattern may be confused about why uv appears in CI when the project uses pip/hatchling.
• A brief comment in the workflow (e.g., # uv is used here only as a resolver to validate dependency ages, not as the project's package manager) would help.

3. Trigger path uv.lock will never match today

The workflow triggers on changes to pyproject.toml or uv.lock, but uv.lock doesn't exist in the repo. The pyproject.toml trigger is sufficient for now. If uv.lock is aspirational (planning to adopt uv), that's fine — otherwise it's dead config that could confuse readers.

4. Missing timeout-minutes on the job

The existing ci.yml doesn't set one either, but uv lock performs network resolution against PyPI. If PyPI is slow or the resolver hits a pathological case, this job could hang for the default 6-hour timeout. Adding timeout-minutes: 5 (similar to the notify job) would be a cheap safeguard.

5. Test plan references behavior not in the diff

The test plan says "uv lock --dry-run shows P7D exclude-newer span in output" — but the workflow doesn't use --dry-run, and P7D is ISO 8601 duration syntax which isn't what the script computes (it computes an RFC 3339 timestamp via date). The test plan should reflect the actual implementation: verify that uv lock --exclude-newer <RFC3339 timestamp> resolves successfully.

6. Consider --frozen or --locked for a stricter check (minor)

Currently uv lock --exclude-newer re-resolves from scratch and writes a new lockfile. Since the lockfile is ephemeral in CI this is harmless, but if the project ever adopts uv.lock as a committed artifact, you'd want to compare against it (e.g., uv lock --check --exclude-newer). Something to keep in mind for the future.

7. date -d is GNU-specific (non-issue for now)

date -u -d '7 days ago' is GNU coreutils syntax. This works fine on ubuntu-latest but won't work on macOS runners. Just noting for awareness if the workflow ever needs to run on macos-latest.

---

Summary

The security rationale is solid and the implementation is clean. The main action items are:

1. Fix the PR description to match what was actually added (workflow, not uv.toml).
2. Add a clarifying comment that uv is used only as a resolver here, not as the project's package manager.
3. Add timeout-minutes to the job.
4. Update the test plan to reflect the actual implementation.

Items 1 and 4 are documentation fixes; items 2 and 3 are one-line additions. Nice contribution overall.

[claude]

Code Review — PR #10: chore: enforce supply chain age gating (final state)

Previous reviews drove meaningful improvements — the PR has evolved from an invalid static config to a well-structured dynamic CI check. Reviewing the final state of the single added file (.github/workflows/dependency-age-check.yml).

---

What's Good

• SHA-pinned actions — Both actions/checkout and astral-sh/setup-uv are pinned to full commit hashes. Consistent and appropriate for a supply chain hardening PR.
• Minimal permissions — contents: read restricts blast radius.
• Timeout — timeout-minutes: 5 prevents hangs on slow PyPI resolution.
• Dynamic cutoff — Computing 7 days ago at runtime avoids the stale-date problem that plagued the earlier static approach.
• Clear inline comments — The "uv is only a resolver" comment and the quarantine rationale are exactly where a future maintainer needs them.
• Clean diff — 33 lines, single new file, no churn in unrelated files.

---

Remaining Issues

1. uv lock failure message will confuse developers (Low)

When a too-new dependency triggers a resolution failure, uv lock will produce a generic "no matching version" error. A developer unfamiliar with this workflow will have no idea why their dependency update is failing.

Suggestion: Add a diagnostic message on failure:

- name: Check dependency age (7-day quarantine)
  run: |
    CUTOFF=$(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ')
    echo "Resolving dependencies with exclude-newer=$CUTOFF"
    if ! uv lock --exclude-newer "$CUTOFF"; then
      echo "::error::Dependency age check failed. A dependency was published less than 7 days ago."
      echo "::error::If this is an urgent update, see the override instructions in this workflow file."
      exit 1
    fi
    echo "All dependencies passed 7-day age gate"

2. No override mechanism documented in the workflow file (Low)

The PR description documents overrides, but PR descriptions aren't where developers look when CI is red. The inline comments explain what the check does, but not how to bypass it for emergencies. A one-line comment like # Override: re-run with CUTOFF set to now — see PR #10 for details would help.

3. uv lock writes an ephemeral lockfile — acceptable but worth noting (Informational)

uv lock resolves and writes a uv.lock to the workspace. Since the workspace is ephemeral in CI, this is harmless. However, if the project ever commits a uv.lock, this step would silently overwrite it. At that point, switch to uv lock --check --exclude-newer "$CUTOFF" to compare against the committed lockfile instead of regenerating.

4. Test plan has an unchecked item (Informational)

[ ] Manual: add a dependency published <7 days ago, verify CI blocks the PR

This is the most important test plan item — it validates the core purpose of this workflow. Recommend completing it before merge, or at minimum confirming uv lock --exclude-newer <cutoff> fails as expected locally with a synthetic too-new dependency.

5. exclude-newer validates resolvability, not installed versions (Informational)

uv lock --exclude-newer checks that a valid resolution exists using only packages published before the cutoff. If httpx>=0.27,<1 can be satisfied by 0.27.2 from 6 months ago, the check passes even if pip install would select a brand-new 0.28.0. This is a known trade-off and is fine for a first iteration — just worth documenting for the team so expectations are calibrated.

---

Summary

Finding	Severity	Status
SHA-pinned actions	—	Done
Minimal permissions	—	Done
Timeout	—	Done
Dynamic cutoff	—	Done
Failure message UX	Low	Suggested improvement
In-file override docs	Low	Suggested improvement
Ephemeral lockfile	Info	Note for future
Unchecked test plan item	Info	Recommend completing
Resolution vs. install gap	Info	Documenting for team

Verdict: Approve with minor suggestions. The implementation is solid and addresses all previously raised concerns. The two low-severity items (failure message UX, in-file override docs) are nice-to-haves that would improve developer experience but aren't blockers. Good supply chain hardening contribution.

🤖 Generated with Claude Code

[justin-layerv]

CR feedback addressed

Fixed

• Failure message UX — Wrapped uv lock in if ! block with ::error:: annotations explaining the failure and pointing to override instructions
• In-file override docs — Added inline comment with the override command so it's visible when CI is red

Deferred

• Ephemeral lockfile note — informational, no uv.lock committed
• Manual test — author's responsibility
• Resolution vs install gap — known trade-off, documented in PR description

Also rebased onto current main.

[claude]

Code Review: PR #10 — chore: enforce supply chain age gating

Overall Assessment

Solid supply chain security addition. The approach of using uv purely as a validation resolver (not replacing pip/hatchling) is well-designed and the 7-day quarantine is a sensible default. The workflow follows security best practices already established in this repo. A few items worth addressing below.

---

Positive Highlights

• SHA-pinned actions with version comments — consistent with the existing ci.yml style and prevents tag-repointing attacks.
• Minimal permissions (contents: read) — good least-privilege practice.
• timeout-minutes: 5 — prevents hung resolvers from burning CI minutes.
• Path-scoped trigger — only runs when dependency definitions actually change, avoiding unnecessary CI load.
• Clear override instructions — the emergency escape hatch is documented both in the workflow comments and the PR body.

---

Issues & Suggestions

1. Spurious uv.lock path trigger (low severity)

on:
  pull_request:
    paths:
      - "pyproject.toml"
      - "uv.lock"   # <-- this project doesn't use uv.lock

The project uses pip/hatchling — there is no uv.lock in the repo, and no workflow produces one that gets committed. This trigger path will never fire and may confuse future contributors into thinking the project uses uv for dependency management.

Suggestion: Remove the uv.lock trigger, or add a comment explaining it's defensive. Also consider adding uv.lock to .gitignore so the resolver artifact from this CI step (or from someone running uv lock locally) never accidentally gets committed.

2. Consider adding workflow_dispatch trigger (suggestion)

on:
  pull_request:
    paths:
      - "pyproject.toml"
  workflow_dispatch:  # allows manual re-runs for auditing

This would allow maintainers to manually re-run the age check on demand — useful for periodic audits or after a supply chain incident, without needing to touch pyproject.toml.

3. Missing concurrency group (minor)

Unlike a build/test job, this is a lightweight check, so it's not critical. But if PRs are frequently rebased, adding a concurrency group avoids redundant resolver runs:

concurrency:
  group: dep-age-${{ github.head_ref }}
  cancel-in-progress: true

4. Resolver scope includes optional deps — confirm this is intentional (question)

uv lock will resolve all dependency groups in pyproject.toml, including [dev] and [langchain] optional extras. This is likely the right behavior (you want to age-gate dev/test tooling too), but worth confirming it's intentional. If a new ruff or pytest release is less than 7 days old, this check would block unrelated PRs that touch pyproject.toml.

If that becomes noisy in practice, you could scope resolution to only production deps or handle optional groups differently.

5. Verify action SHAs match claimed versions (due diligence)

I was unable to verify the following SHAs against their claimed tags due to network restrictions in this review environment:

• actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd → claimed v6.0.2
• astral-sh/setup-uv@d0d8abe699bfb85fec6de9f7adb5ae17292296ff → claimed v6

The checkout SHA matches the one in ci.yml, which is a good consistency signal. Please verify both SHAs match the expected tags before merging:

git ls-remote https://github.com/actions/checkout.git 'refs/tags/v6.0.2^{}'
git ls-remote https://github.com/astral-sh/setup-uv.git 'refs/tags/v6^{}'

---

Security Considerations

• No secrets used — good; this job only needs read access to resolve deps.
• No artifact uploads or caching — no risk of cache poisoning.
• date -u -d '7 days ago' — GNU coreutils syntax, which is fine since the runner is ubuntu-latest. Just noting this would fail on macOS runners if the workflow ever gets a matrix.

Test Coverage

The PR description includes a test plan with manual verification. Since this is a CI workflow (not application code), unit tests aren't applicable. The one unchecked item — "add a dependency published <7 days ago, verify CI blocks the PR" — would be good to complete before merging to confirm the failure path works as expected.

---

Summary

This is a well-crafted supply chain security measure. The main actionable items are:

1. Remove or explain the uv.lock path trigger
2. Consider adding workflow_dispatch for manual runs
3. Verify pinned SHAs match their claimed tags

None of these are blockers — the workflow is safe to merge as-is and can be refined iteratively.

[justin-layerv]

CR feedback addressed

Fixed

• Removed uv.lock path trigger — project uses pip/hatchling, not uv. The trigger would never fire.
• Added workflow_dispatch — enables manual audit runs without touching pyproject.toml.

Deferred

• Concurrency group — lightweight check, not worth the noise
• Optional deps scope — intentional, age-gates dev tooling too
• Verify action SHAs — already verified across all repos

[claude]

Code Review: PR #10 — chore: enforce supply chain age gating

Overall

Good supply-chain hardening. The approach of using uv purely as a resolver/validator (without adopting it as the project's package manager) is pragmatic and well-documented. A few observations below.

---

Positives

• SHA-pinned actions — Both actions/checkout and astral-sh/setup-uv are pinned to commit SHAs with version comments. This is consistent with ci.yml and prevents tag-hijack attacks on the CI itself.
• Minimal permissions — contents: read at the workflow level; no write scopes. Good.
• Scoped trigger — Only fires on pyproject.toml changes, so it won't slow down unrelated PRs.
• Timeout — timeout-minutes: 5 prevents runaway jobs.
• Clear comments — The inline explanation of why uv is used here (resolver only, not the project's package manager) heads off the most obvious question a future contributor would have.

---

Issues & Suggestions

1. Resolution gap between uv and pip (low severity)

uv lock --exclude-newer validates that dependencies can be satisfied with pre-cutoff versions, but pip (the actual installer) will resolve independently and may pick a newer version. For example, if a developer adds new-lib>=1.0 and version 1.0 was published 3 days ago while 0.9 exists from months ago, uv resolves to 0.9 (check passes), but pip install resolves to 1.0.

This is an inherent limitation of the approach and probably acceptable for the stated threat model (catching entirely-new or no-history packages). Worth noting in a comment in the workflow so future maintainers understand the boundary.

2. Missing trigger on push to main (low severity)

The workflow only runs on pull_request. If branch protection were ever loosened (or a PR were merged via the API bypassing checks), there's no post-merge validation. Consider adding:

on:
  pull_request:
    paths:
      - "pyproject.toml"
  push:
    branches: [main]
    paths:
      - "pyproject.toml"
  workflow_dispatch:

This would catch anything that slipped through and is consistent with how ci.yml triggers on both push and pull_request.

3. Optional dependencies are resolved too — verify this is intended (nit)

uv lock resolves all dependency groups including [project.optional-dependencies] (dev, langchain). This means the age gate also covers pytest, ruff, mypy, langchain-core, etc. This is probably desirable (supply chain attacks target dev dependencies too — see the event-stream incident), but it does mean a new release of ruff or pytest could block unrelated PRs that happen to touch pyproject.toml. Worth a note in the workflow comments.

4. date -d is GNU-specific (non-issue for CI, but worth a comment)

date -u -d '7 days ago' is GNU coreutils syntax. This is fine on ubuntu-latest but would break on macOS runners. Since this repo only uses ubuntu runners, this is a non-issue — but a brief comment (# GNU date syntax; ubuntu-latest only) would prevent a copy-paste mishap if someone reuses this pattern.

5. Consider adding a concurrency group (nit)

If a developer pushes multiple commits rapidly to a PR that modifies pyproject.toml, multiple age-check runs will queue up. A concurrency group would cancel superseded runs:

concurrency:
  group: dep-age-${{ github.head_ref || github.ref }}
  cancel-in-progress: true

---

Security

The threat model is sound: quarantining recently-published packages is a well-known defense against supply-chain attacks (typosquatting, account takeover, malicious new packages). The 7-day window is a reasonable default used by several organizations.

The override path (editing the workflow) requires commit access, which is appropriate — it can't be bypassed via environment variables or PR labels.

No secrets are used or exposed.

---

Summary

This is a solid, low-risk addition. The suggestions above are mostly about hardening edge cases and improving documentation for future maintainers. None are blockers.

Verdict: Approve with minor suggestions.

[justin-layerv]

CR feedback addressed (round 2)

Fixed

• Added push to main trigger — matches ci.yml pattern, catches dependency changes that bypass PR checks

Deferred

• Resolution gap comment — documented in PR description
• Optional deps scope — intentional, already confirmed
• GNU date comment — cosmetic, ubuntu-latest only
• Concurrency group — lightweight check

[claude]

Code Review: chore: enforce supply chain age gating

Overall: This is a solid supply chain security measure. The approach of using uv lock --exclude-newer as a standalone validation tool (without adopting uv as the project's package manager) is pragmatic and well-documented. A few observations below.

Positives

• SHA-pinned actions with version comments — consistent with the existing ci.yml style
• Minimal permissions (contents: read) — principle of least privilege
• Good documentation — inline comments explain the "why," and the override mechanism is clearly documented in both the workflow and PR description
• Path-scoped triggers — only runs when pyproject.toml changes, avoiding unnecessary CI cycles
• timeout-minutes: 5 — prevents runaway jobs

Suggestions

1. uv.lock side effect: uv lock writes a uv.lock file to the working directory. No impact in CI (ephemeral workspace), but if a developer runs this command locally for debugging, it would create an untracked file. Consider adding uv.lock to .gitignore in this PR or a follow-up to prevent accidental commits.

2. push trigger on main provides visibility, not gating: Since the project enforces "never push directly to main" (PRs only), the push: branches: [main] trigger fires after a PR is merged. At that point the code is already on main. This is still useful for visibility (you'd see a failing check on the commit), but it can't block the merge. If the intent is purely gating, the push trigger could be removed to reduce noise. If it's intentional as a post-merge audit, it's fine as-is — just worth clarifying intent.

3. Consider pinning the uv version: setup-uv without a version: input installs the latest uv release. Since uv is under active development and --exclude-newer behavior could change, consider pinning to a known-good version:

   - uses: astral-sh/setup-uv@d0d8abe699bfb85fec6de9f7adb5ae17292296ff # v6
     with:
       version: "0.7.x"  # or whatever current stable is

   This prevents a future uv release from subtly changing resolution behavior and breaking CI.

4. Optional dependencies: uv lock resolves all dependency groups by default, including [project.optional-dependencies]. This means the age gate covers dev and langchain extras too — which is likely desirable for supply chain security. Just flagging that this is the implicit behavior so it's understood.

Security

No concerns — this workflow is well-scoped. It reads the repo, runs a resolver, and exits. No secrets, no write permissions, no artifacts. The 7-day quarantine is a reasonable heuristic for catching typosquatting and hijacked packages.

Verdict

Looks good. The suggestions above are minor improvements, none are blockers. Nice addition to the project's security posture.

---

Reviewed with Claude Code

[claude]

PR Review: chore: enforce supply chain age gating

Overall Assessment

This is a well-executed supply chain hardening measure. The approach — using uv purely as a resolver to enforce a 7-day dependency quarantine at the CI merge gate — is sound and avoids polluting the project's local dev workflow. The commit history shows thorough iteration through code review. A few observations below.

---

Positives

• SHA-pinned actions for both actions/checkout and astral-sh/setup-uv — important given this is literally a supply chain security PR
• Minimal permissions (contents: read) — principle of least privilege applied correctly
• Good triggers: pull_request (gate), push to main (catch bypasses), and workflow_dispatch (manual audits)
• Clear error messages with ::error:: annotations and inline override instructions visible where CI fails
• timeout-minutes: 5 prevents runaway jobs
• .gitignore addition for uv.lock is appropriate since uv is only a CI validation tool here

---

Suggestions & Considerations

1. Squash merge recommended

The branch has 10 commits, several using fix: as the type. Since this is a CI-only change with no library code modifications, those fix: commits would incorrectly signal patch releases to Release Please if merged individually. Squash-merging with the PR title (chore: ...) will avoid unwanted version bumps — just confirming this is the plan.

2. Optional/dev dependency coverage

uv lock resolves all dependency groups by default, which means langchain-core, pytest, ruff, etc. from [project.optional-dependencies] are also age-gated. This is the right behavior but worth being aware of — a new ruff release could block an unrelated pyproject.toml change. The workflow_dispatch override covers this, but it's worth noting in team documentation.

3. Path filter gap for requirements*.txt or future lock files

The paths trigger only watches pyproject.toml. If the project ever adds a requirements.txt, constraints.txt, or similar, the workflow won't catch changes there. This is fine for now — just something to revisit if the dependency management approach evolves.

4. Minor: # v6 comment on setup-uv SHA

- uses: astral-sh/setup-uv@d0d8abe699bfb85fec6de9f7adb5ae17292296ff # v6

The # v6 annotation is helpful but will go stale when the SHA is bumped. Consider using a tool like pin-github-action or Dependabot's GitHub Actions updates to keep SHA + comment in sync automatically.

5. Consider --no-cache for reproducibility

uv lock uses a local cache by default. In CI, this shouldn't matter (fresh runner each time), but adding --no-cache would make the intent explicit and guard against self-hosted runner cache pollution:

uv lock --exclude-newer "$CUTOFF" --no-cache

---

Security Review

• No secrets exposed or required
• No write permissions requested
• Override mechanism requires editing the workflow file (not exploitable via PR body/title injection)
• The 7-day quarantine is a pragmatic defense-in-depth measure — not bulletproof but raises the bar meaningfully against typosquatting and package hijacking

---

Verdict

Approve. This is a clean, well-scoped CI addition. The suggestions above are minor improvements, none blocking. Recommend squash-merging to keep the main history clean and avoid accidental fix: version bumps.