dependency-policylisted

# 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.