Dependency Policy

---
name: dependency-policy
description: Audit declared dependencies, lockfiles, tool versions, compatibility, licenses, and upgrade evidence before implementation or release.
---

# Dependency policy

Use when a project adds, removes, upgrades, or relies on a package, SDK, compiler, runtime, service,
model, or third-party API. Also use during onboarding, architecture review, and release preparation.

## Procedure

1. Run `node "${CLAUDE_PLUGIN_ROOT}/scripts/dependency-check.mjs" <project-root>`.
2. Read the architecture and stack-defaults documents before choosing a version.
3. Confirm the declaration and lockfile changed together where the ecosystem uses a lockfile.
4. Record direct dependency, purpose, version constraint, transitive risk, license, minimum platform,
   deprecation status, and rollback/removal plan in the ticket evidence.
5. Use the project-pinned toolchain (`gradlew`, `Package.resolved`, lockfile, or equivalent). Never
   silently install a global version to make a check pass.
6. If a dependency is unapproved, unpinned, unlocked, incompatible, or unknown, block or escalate;
   do not “resolve” it by picking the newest version from memory.

## Policy

- Prefer platform-native libraries and the smallest dependency surface.
- A new dependency needs a written reason and an owner.
- A version claim must name its source and date; “latest” is not evidence.
- A failed or unavailable vulnerability/license lookup is `CANNOT EVALUATE`, not a clean result.
- Never update a lockfile without reviewing the resulting transitive diff.