bump-deps

升级依赖

使用 Taze 制定一个结构化更新计划，应用兼容的范围更新，并批量决定是否升级到主版本。

工作流

1. 解析技能目录，并从目标仓库保存辅助计划：

   bash <skill-dir>/scripts/run-taze.sh --plan [--include package-a,package-b] > <taze-plan.json>
   

   JSON 计划会将发现的每项更新归类为 apply、review-major、review 或 skip-fixed。辅助工具 会检测 monorepo，在扫描时纳入锁定版本，并镜像 Bun 的最低发布等待时间设置。如果仓库使用包管理器 的发布等待门控或 Bun catalogs，仅针对当前生效的分支阅读 references/conditional-workflows.md。

2. 如果请求了 --dry-run，展示计划和计数，然后停止，不更改清单或锁文件。

3. 选择所有标记为 apply 的范围内次版本/补丁版本更新。绝不按包名自动批准主版本更新。将所有 review-major 和未知更新汇总为一批供用户决策，并提供当前版本、目标版本、可查明时的包角色以及 相关迁移/发布说明。只应用用户选定的主版本更新。

4. 如果没有选中任何更新，报告无需操作并停止。如果根清单使用 Bun catalogs，则根据已接受的计划预览 精确的已选 catalog 变更：

   uv run <skill-dir>/scripts/update-bun-catalogs.py \
     --root <repo> --plan <taze-plan.json> --include package-a,package-b
   

   预览为只读操作。缺少 catalog 条目、计划行冲突、不支持的版本，或 catalog 值与计划不再匹配， 都会在写入前导致失败。辅助工具不会选择升级。

5. 首次写入清单或锁文件之前，先发现并运行仓库针对现有依赖状态的标准验证套件。优先使用仓库公布的 汇总检查；否则，运行所有已提供的依赖解析、构建、测试、类型检查、lint、格式检查、代码生成检查和 仓库不变量检查命令。尽可能使用冻结或非写入模式，并记录升级后重跑时要执行的准确命令。命令失败、 依赖或 peer 解析冲突，以及表明存在不兼容或不安全行为的可执行警告，都会阻止升级；无法避免的弃用等 信息性通知除外。如果基线存在任何阻断问题，则停止，并显示 ### ⛔ Dependency bump blocked — baseline failed， 列出准确命令和诊断信息，并要求用户解决已有问题。不要修改清单、锁文件、源代码或配置。

6. 使用一条命令写入所有选定的 Taze 更新：

   bash <skill-dir>/scripts/run-taze.sh --write --include package-a,package-b
   

7. 对于 Bun catalogs，使用相同的计划和包含集重新运行 update-bun-catalogs.py，并附加 --write。 它会以原子方式更新每个匹配的默认/命名 catalog 条目，并保留现有的 ^、~ 或空前缀。然后运行 ni， 让仓库的包管理器更新锁文件。

8. 检查清单和锁文件的差异。重新运行准确的基线命令，并运行能验证已更新依赖项和任何必需迁移的最小范围 检查。除非有证据表明与此次升级无关，否则应将所有新引入的错误、类型问题、检查失败（包括测试、构建、 lint、格式、代码生成和仓库不变量）、依赖或 peer 解析冲突，以及可执行的兼容性或安全警告，均视为此次 升级导致的问题。

9. 修复此次升级导致的所有问题，包括必需的源代码或配置迁移，同时保留预期行为。不要屏蔽诊断、降低验证 严格度，也不要仅为通过检查而改变预期行为。每次修复后，重新运行受影响的检查，然后重跑记录的完整套件， 直至全部通过。如果在任务授权范围内没有明确且安全的修复方案，则停止，并显示 ### ⚠️ Dependency regression decision required。将所有此类问题汇总到一个表格中，列出证据、受影响位置、 修复和回退选项及可能影响。只有用户作出选择、修复已应用或问题更新已回退、锁文件已重新生成且完整套件 全部通过后，才能报告完成。

面向用户的输出

将计划呈现为 ### 📦 Dependency plan，包含数量和简洁的表格：

ID	计划值	决策	软件包	当前 → 目标	类型	备注

将计划中精确的 apply、review-major、review 和 skip-fixed 值与通俗易懂的决策说明一同列出。 为需要用户选择的行分配稳定 ID，以便用户一次性作答。预览使用 ### 🔎 Dry run — no files written， 无操作时使用 ### ✅ No selected updates。

应用更新后，以 ### 🏁 Dependencies updated 收尾，并列出已更改清单文件／锁文件的树状结构，以及 ### 🧪 Verification。仅在存在非阻塞的说明事项时使用 ### ⚠️ Remaining review，绝不能用于 由升级导致的未解决问题。辅助 JSON、软件包／版本字符串、命令和诊断信息必须保持原样，不得添加修饰。

不变量

• 除非用户明确另有要求，否则固定版本和非 semver 协议保持不变。
• 软件包参数同时限定扫描和写入阶段。
• 扫描和写入使用相同的成熟期策略。
• Bun catalog 预览和写入使用相同的已接受 Taze 计划和选定的软件包集；过期计划绝不写入。
• 如果仓库证据、对等依赖范围或发行说明表明情况并非如此，不得仅根据 SemVer 推断兼容性。

完成工作必须满足：写入前基线干净、计划已审核、所选更新已保留、锁文件已重新生成、记录的测试套件和依赖项专项检查重新运行并通过，且不存在由升级导致的未解决问题。 Dry-run 完成必须提供结构化计划，并且写入次数为零。