dependency-upgradelisted

# Dependency Upgrade Goal: the version number is the last thing that changes — after you know what changed between the versions and proved your code survives it. ## Steps 1. **State why.** Security fix, needed feature, or staying current — say which. One dependency (or one coherent group, e.g. a framework and its satellites) per task. Bulk-upgrading everything at once is banned: when something breaks, you won't know what broke it. 2. **Read before bumping.** Fetch the release notes / changelog for EVERY version between current and target — GitHub Releases page, CHANGELOG.md in the repo, the package registry's release feed, or the project's migration guide. You are hunting for: breaking changes, deprecations, changed defaults, behavior changes, security notes. No changelog anywhere? Evidence hierarchy applies — diff the library's source between the two tags. 3. **Map the impact to YOUR code, as a step list.** For each change found in step 2, search the codebase for the affected APIs. Turn the result into an explicit, ordered upgrade plan: "1) bump X 4.2→5.0 2) rename Foo→Bar at 3 call sites 3) new default for `timeout` — pin the old value 4) run full suite". That step list IS your Plan message — the user should see exactly what will happen and why. 4. **Classify the risk.** - Patch/minor of a leaf dependency → L1. - Major version, or a core dependency (framework, ORM, auth/crypto, serialization) → **L2 minimum**