依赖升级评估
交付有来源的升级建议：当前版本、最新稳定版、新特性、破坏性变更、项目影响与验证方案。默认先完成只读评估，再让用户决定是否升级；用户已明确授权的具体升级方案继续有效。
1. 确认当前基线
定位目标项目，读取适用的工程规则，核对分支和未提交改动。根据依赖声明、锁文件或依赖解析结果确认：
- 精确身份：NPM 包名、Maven
groupId:artifactId，或插件标识及其官方仓库。 - 当前实际解析版本与版本控制位置：直接声明、父 POM、BOM、属性、锁文件或插件管理配置。
- 项目使用位置及相关运行时、框架版本约束。
区分声明范围与实际版本；同一依赖存在多个解析版本时注明受影响模块。只在目标或基线无法从项目确定时询问用户。
完成条件：明确比较起点、依赖身份和改动入口；无法确认的部分列为证据缺口。
2. 在线核实目标版本
按生态选择适用来源，结合官方仓库或文档交叉核实，不要求一个依赖同时存在于所有平台：
| 来源 | 查询重点 |
|---|---|
| NPM | 查询项目所用 registry 的包元数据、dist-tags、已发布版本及发布时间；如 npm view <package> dist-tags versions time --json。 |
| Maven | 查询该坐标在 Maven Central 或项目配置仓库中的版本元数据，确认目标制品实际发布；同时核对官方发布说明。 |
| GitHub Releases / 官方发布页 | 核实官方仓库、版本标签、发布日期、预发布标记及发布说明，确认标签与目标包对应。 |
默认目标为最新稳定发布，排除 alpha、beta、RC、SNAPSHOT 等预发布版本。区分“最新稳定版”“当前大版本的最新维护版”和“项目当前约束下可用版本”；存在差异时分别报告。用户指定版本时以该版本作为评估目标，同时告知最新稳定版。
latest 标签、GitHub 标签和制品仓库结果可能不同，按项目发布策略解释差异。GitHub 已发布但制品尚不可获取时，不将其作为可立即安装的版本。
完成条件：记录查询日期、版本、发布日期及来源链接；来源冲突或访问失败时明确保留不确定性。
3. 比较整个升级区间
阅读官方 Release Notes、CHANGELOG、迁移指南和兼容性说明，覆盖 当前版本之后至目标版本（含） 的变更，尤其是每次跨大版本迁移。多页发布记录需要继续翻页；仅阅读目标版本说明不足以完成比较。
整理与项目有关的：
- 新特性、重要修复和已公布的安全修复，以及是否需要主动启用。
- API 删除或签名变化、配置项与默认值变化、行为变化和弃用项。
- 最低 Java / Node 等运行时版本、框架兼容矩阵、peer dependencies、传递依赖及构建工具要求。
- 涉及时的数据格式、协议、数据库迁移及回退限制。
将每个相关破坏性变更映射到实际代码、配置或依赖关系，标为“受影响”“未使用该能力”或“待确认”，附项目路径与官方证据。弃用与已删除分别表述；版本号大小不能代替兼容性证据。
发布说明缺失时，可用官方标签间 diff 和源码补充，并区分官方声明与分析推断。将“未发现已知不兼容”与“已验证兼容”分开；查询或静态检查不能证明运行兼容。
完成条件：升级区间已覆盖，每项相关破坏性变更都有项目影响结论；缺失的版本记录或迁移证据显式列出。
4. 提交升级建议，交由用户决定
用简体中文给出紧凑报告：
- 版本结论：依赖、当前版本、最新稳定版、建议目标及查询日期。
- 收益与风险：按“变更 / 项目影响 / 必要调整 / 来源”组织，突出破坏性变更。
- 实施范围与验证：列明需修改的依赖声明、锁文件、调用点和配套依赖，以及适用的现有检查；区分已执行检查与计划执行检查。
- 建议：升级、选择兼容维护版或暂缓，并解释依据及尚缺证据。
评估阶段不修改依赖、锁文件或业务代码。报告完成后，询问用户是否按所列目标与范围升级；说明这是本技能“先评估、再由用户决定”的步骤并链接当前 SKILL.md。若已有明确覆盖该目标与范围的授权，直接执行，避免重复确认。发现必须超出授权范围的配套迁移时，先更新方案再请用户决定。
用户确认后按项目规则完成最小范围修改与相关验证，保留已有改动。在 Git 仓库检查最终 diff 和 git diff --check，报告实际版本、适配改动、验证结果及剩余风险。构建、部署和发布遵循项目规则与用户授权。