用途：依赖升级本身容易，难在证明项目仍能自洽。该技能在版本选择完成后介入（通常对应 bun update -i -r 等交互式升级），验证实际落地内容：从 git 获取真实差异、peer 与 engine 完整性、跨过的每个版本的破坏性变更与迁移、值得采纳的新特性，以及实际运行项目而非只读文档的验证关卡。它也能回答反向问题：被暂缓的包能否升级、为何受阻，以及某个依赖为何存在于 package.json。
适用场景包括批量升级验证、暂缓包评估、依赖存在性追问、跨版本发行说明阅读、升级后类型/构建/测试失败的排查，以及升级前的成本侦察。
关键规则：先检测包管理器，只用其对应列（Bun、npm、pnpm、yarn 各自的原生命令），没有一个能力需要跨管理器调用；差异必须来自 git（lockfile diff 才包含传递依赖升级），而非提示词；outdated 只报告版本漂移，不代表兼容性；生态包的 peer 范围才是上限；peer-required 包即使零引用也必须声明；未经明确批准不得运行迁移或版本变更；跨界版本需逐个阅读说明；最终以类型检查、构建、测试为证据；未检查项须在报告中说明。
能力矩阵涵盖注册表元数据、为何安装、已安装树、peer 校验、安全公告、过期检查、范围内版本、lockfile 校验、读取 package.json 与运行工具等，每个包管理器均有原生命令，具体命令见技能文档中的逐管理器和逐阶段说明。
流程分为：阶段 0 建立差异（含 lockfile 二进制文件的处理与工作树校验）；阶段 1 静态完整性（peer 冲突、engines、弃用、重复主版本、安全状态、@types 对齐）；阶段 2 发行说明（按阶段 0 的风险预算，优先本地 CHANGELOG，其次 gh release view、仓库文档、文档站升级指南）；后续阶段用于运行项目验证与报告。
限制：使用的 jq 与 gh 需事先确认存在，gh 读取 release 还需认证；berry 与 yarn classic 命令不同，需先确认版本；Bun 的 outdated 无 JSON 输出；资料仅覆盖上述版本基线（bun 1.3.14、npm 11.19.0、pnpm 11.21.0、yarn 4.18.0、gh v2.102.0），其他版本行为暂未提供。