用途：这是一套“把升级依赖当作修 bug”的决策与执行方法论，用于缺陷根因可能位于上游第三方库/框架的场景。它可独立调用，也被 PDCA 类宿主在技术分析阶段引用，作为“无可行方案”分支的乐观对照。
主要能力：提供四步决策顺序——先归因缺陷更可能在上游还是自身代码；若疑似上游，则检索依赖的 Changelog、Release Notes、Issues 中与症状匹配的修复（如 composition、selection、Safari、iOS、widget、cursor 等关键词），确认修复版本及项目当前版本是否低于它；优先升级依赖（同主版本内 patch/minor 风险低）而非写本地补丁；仅当升级不可行（唯一修复版本含破坏性变更、项目被锁版本、上游未修复）才考虑临时方案，并标注触发条件与所跟踪的上游 issue。
使用方式：出现强信号时调用——缺陷涉及具名第三方库/框架/API 且与特定版本相关；症状具平台或库特异性；调用链完整、参数正确、日志有执行但行为错误；本地补丁已堆叠且各自只部分生效；CSS !important 在特定平台静默失效。若选择升级，需遵守升级工程规范：按项目实际跟踪的 lockfile 判断包管理器（git ls-files package-lock.json yarn.lock pnpm-lock.yaml），不混用；升级后执行类型检查、构建、完整单测与真机/目标环境验证；评估 semver 风险；用 npm ls <pkg> 或等价命令确认单一解析版本，避免多版本共存。
适用场景：第三方库相关缺陷、平台特异性渲染问题、静默失败、临时补丁堆积、CSS 覆盖失效等。
限制：本技能只含通用方法论，不含具体库的版本与 changelog 关键词，这类知识应放在各项目自身文档中；反模式包括未查 Changelog 就堆叠补丁、依赖 CSS !important 处理平台强制渲染、魔法数字计时补丁、以 UX 降级掩盖问题、未读破坏性变更说明就因“升级有风险”而回避升级。资料未提供具体安装命令、收费与平台信息。