用途：把仓库或 monorepo 中的 JavaScript/TypeScript 依赖向前升级，采用小批量、经过验证、可回滚的分组方式，使每次提交保持绿色通过，并让每一处破坏都能锁定唯一可疑来源。不要把重构、功能开发或 lint 规则清理混入升级提交，只修复升级本身造成的破坏。
核心规则：从干净 git 树和记录的基线开始；升级前已存在的失败不算升级失败。每个主版本（以及 0.x 包的每个次版本）都要读官方 changelog、发布说明或迁移指南，不得猜测破坏性变更。每组一个主版本，补丁和次版本可批量合并，耦合的包家族一起移动。安全修复单独成组并优先处理。只运行非交互式命令，不要用 bun update -i 或任何提示驱动的流程，按名称或模式选择包。遵守供应链门禁：优先选择已发布数天的版本，信任包前审查新维护者和安装脚本。锁文件随 package.json 改动一起提交，绝不手改 bun.lock。若某组失败且一次无法看清原因，停止、二分该组并推迟问题包，不要强行通过红色门禁。保留无关的用户改动，未经说明不要动用户有意排除或固定的包。
工作流：1）基线：git status 须干净，创建分支如 chore/upgrade-deps；记录 bun、Node、包管理器、TypeScript 版本；从 package.json 脚本、CI 配置及项目文档发现门禁（安装、类型检查、lint、格式检查、测试、构建、E2E）；在未动的树上各跑一次并保存结果作为既有失败。2）盘点：运行 bun outdated（工作区加 -r 或 --filter）、bun audit（可用 --json）；检查版本出现位置（dependencies、devDependencies、peerDependencies、catalog、overrides、patchedDependencies、trustedDependencies、engines、packageManager、CI 镜像标签、.nvmrc 等），区分固定与范围版本，找出废弃包。3）分类分组：安全组、运行时与工具链底线（Bun、Node、TypeScript、@types）、补丁+次版本批、耦合家族、其余每个主版本一组（风险低者先），最后清理 bun dedupe 与废弃 overrides、shim、polyfill。4）准备每个主版本：读官方文档并记录来源 URL，列出破坏性变更，grep 代码库确认影响，查找官方 codemod，检查插件与适配器的 peer 范围。5）应用：用最窄命令，优先 --dry-run，例如 bun update --dry-run、bun update zod '@types/*'、bun update --latest vite @vitejs/plugin-react、bun add -d typescript@<version>、bun audit fix --dry-run && bun audit fix；monorepo 中编辑共享 catalog 条目后 bun install。6）验证：每组后按基线顺序跑门禁，用 bun install 和 bun install --frozen-lockfile 证明锁文件一致，再类型检查、lint、测试、构建；影响运行时的组还要启动应用或跑 E2E 查看新废弃警告；检查 bun pm untrusted 和残留 peer 警告；若门禁回退，只修升级破坏之处，超过一次仍不清晰则二分并推迟。7）提交：每组一次提交，包含锁文件、catalog 和最小代码改动，信息写 from -> to 版本；除非被要求，不要推送或开 PR。8）报告：给出升级表、跳过与阻塞的包及原因、既有失败、待处理废弃与回滚路径。
限制：资料未提供具体支持的操作系统、包管理器最低版本、价格或授权信息；技能本身是流程与规则集合，依赖 Bun 命令与官方文档，且要求人工判断破坏性变更与 peer 兼容性。