deps-upgrade

Dependencies are inherited code. Upgrades are inherited risk. Patch in batch, minor in batch with a smoke test, major one-at-a-time with a CHANGELOG read. ## When to Apply / NOT Apply: CVE remediation; major upstream release; compatibility forcing function; quarterly hygiene cadence; pre-release lockfile audit; deprecation warnings accumulating. NOT apply: active feature branch with high churn; pre-release freeze window; mid-incident; API-break-driven refactor. ## Anti-patterns - **Skipping the lockfile**: floating ranges create non-reproducible builds. - **Suppressing deprecations**: `--warning-as-error=off` defers cost. - **Bypassing audit signals**: `npm audit fix --force` without reading. - **No smoke test on minor**: minor versions can introduce behavior shifts. - **Forgetting transitives**: surface deps look fine; transitive CVE remains. - **Mixing concerns in one commit**: upgrade + refactor + feature. Atomize per `<git>` policy. ## Workflow (language-neutral) 1. **Inventory**: enumerate manifests + lockfiles across ecosystems. Many canonical names are extensionless (`go.mod`, `Gemfile`, `pom.xml`); filtering by extension alone misses them. `fd` only takes one glob per call, so anchor on canonical filenames via a single regex: ```sh fd -t f '^(package(-lock)?\.json|pnpm-lock\.yaml|yarn\.lock|Cargo\.(toml|lock)|pyproject\.toml|poetry\.lock|requirements.*\.txt|Pipfile\.lock|go\.(mod|sum)|pom\.xml|build\.gradle(\.kts)?|settings\.gradle(\.kts)?|libs\.versions...