Dependency Upgrade

A version string is a claim, not a fact — verify it before you pin it. Isolate majors so a bad one is a one-line revert. Read the changelog before the diff, not after something breaks.

A brand-new dependency's registry-existence check is builder's Hallucination Defense step, not this skill's — this protocol begins once the dependency is already in the manifest and due for a version change.

Order of Operations

Work the queue in this order, not commit-arrival order:

1. Security advisories first. A CVE fix jumps ahead of routine bumps already in flight — patch, then resume the queue.
2. Dev-dependencies before runtime dependencies. Lower blast radius, cheaper to revert, and they exercise the upgrade workflow before it touches anything user-facing.
3. Minors: batch per ecosystem. One commit per ecosystem's batch of minor/patch bumps — they're supposed to be backward compatible.
4. Majors: ONE AT A TIME. Each major version bump gets its own commit and its own full gate run. Never combine two majors in one change — if the gate fails, you won't know which one broke it.

Per-Upgrade Protocol

Run every step, in order, for every upgrade. Urgency (CVE) changes queue position, never skips a step.