Dependency Upgrade Risk Audit

Assess an upgrade by what the codebase actually uses, not by how long the changelog is.

PACKAGE: {name}
FROM VERSION: {x} TO VERSION: {y}
HOW WE USE IT: {paste the imports and the call sites, or the files that touch it}
CHANGELOG / RELEASE NOTES: {paste}

Return:

1. BREAKING CHANGES THAT TOUCH US — only the ones intersecting the call sites above. A long list of breaking changes in features we never import is not risk, and treating it as risk is why upgrades get postponed for years.

2. SILENT BEHAVIOUR CHANGES — the dangerous category: same signature, different result. Defaults that moved, sorting that became stable, timezone handling, rounding, error types that changed. These pass the type checker and fail in production.

3. EFFORT — a realistic estimate of the code that must change, expressed as call sites, not hours.

4. UPGRADE ORDER — if peers must move together, the order that keeps the project buildable between steps.

5. HOW TO VERIFY — the specific behaviour to test after upgrading, tied to the changes found in 1 and 2. "Run the test suite" is not an answer unless the suite covers those paths; say which ones it does not.

6. THE CASE FOR WAITING — state it honestly. If this version is days old, or the only gain is features we do not use, that is a real option.