update-deps

更新依赖项

审查过时的软件包，验证供应链完整性，安全的就升级，需要审查的暂缓，并记录所有操作。

此流程分为三个阶段：发现、完整性审计和执行。完整性审计最重要——每个软件包在写入锁文件前都要经过检查。

阶段 1：发现

运行 bun outdated，获取所有有可用更新的软件包列表。

bun outdated

将输出解析为结构化列表。对于每个软件包，记录：

• 软件包名称
• 当前版本
• 可用更新版本
• 是否受最低发布时限限制（输出中以 * 标示——脚注“The * indicates that version isn't true latest due to minimum release age”对此进行了说明）
• 它是运行时依赖、开发依赖还是对等依赖

另外，检查是否有软件包完全被最低发布时限限制（例如 @pierre/diffs，其最低 semver 范围无法解析）。单独标记这些软件包——可能需要在 bunfig.toml 中设置 minimumReleaseAgeExcludes。

阶段 2：完整性审计

这是整个流程的核心。为每个软件包启动一个 Sonnet 子 Agent，并行执行完整性检查。这里使用 Sonnet，是因为这些都是相互独立、结构化的验证任务，不需要更强的推理能力。

每个子 Agent 会收到软件包名称、当前版本和目标版本，并执行以下检查：

子 Agent 提示词模板

对于每个过时的软件包，启动一个 Sonnet Agent，执行以下任务：

You are auditing the npm package "{package}" for a version bump from {current} to {target}.

Run these checks and report back with a JSON object:

1. **Maintainer verification**: Check if maintainers changed between versions.
   npm view {package}@{current} maintainers --json
   npm view {package}@{target} maintainers --json
   Compare the two lists. Flag any additions or removals.

2. **Publish date and age**: Get the publish timestamp.
   npm view {package} time --json
   Extract the date for version {target}. Calculate days since publication.
   Flag if younger than 7 days.

3. **Provenance**: Check if the package has registry signatures or attestations.
   npm audit signatures (if not already run this session)
   Note whether the package has provenance attestations.

4. **Tarball diff**: Show what actually changed in the published package.
   npm diff --diff={package}@{current} --diff={package}@{target}
   Summarize the changes:
   - How many files changed
   - Are changes limited to version bumps, deps, and rebuilt dist? Or are there meaningful source changes?
   - Any new runtime dependencies added?
   - Any suspicious patterns (obfuscated code, eval(), network calls in unexpected places)

5. **Release notes**: Try to find what changed.
   Check the package's repository for release notes or changelog:
   npm view {package}@{target} repository.url
   gh release view v{target} --repo <owner/repo> (try with and without v prefix)
   Summarize the changelog if found.

Report your findings as JSON:

{{
  "package": "{package}",
  "from": "{current}",
  "to": "{target}",
  "age_days": <number>,
  "maintainers_changed": <boolean>,
  "maintainers_added": [],
  "maintainers_removed": [],
  "provenance": <boolean>,
  "new_runtime_deps": [],
  "files_changed": <number>,
  "has_source_changes": <boolean>,
  "changelog_summary": "<brief summary>",
  "suspicious_patterns": [],
  "verdict": "safe" | "review" | "defer",
  "verdict_reason": "<one sentence explanation>"
}}

Verdict guidelines:
- "safe": Same maintainers, no new runtime deps, changes match what changelog describes, no suspicious patterns
- "review": Minor concerns (e.g., new maintainer who is clearly from the same org, small new dep from known publisher)
- "defer": Maintainer changes from unknown accounts, new runtime deps with unclear purpose, suspicious code patterns, substantive API changes that need integration testing

收集结果

随着子 Agent 完成任务，收集其 JSON 报告。如果子 Agent 失败或超时，将该软件包标记为“暂缓”，原因设为“审计失败”。

等级分类

收集完所有结果后，将软件包分为不同等级，帮助用户快速了解风险概况：

等级	说明	典型操作
运行时、高影响面	代码会直接调用的库（解析器、差异引擎、UI 库）	检查来源、审查差异、运行测试
SDK/API 依赖	第三方服务 SDK（Agent SDK、平台集成）	阅读更新日志以了解 API 变更，测试集成
仅开发依赖	类型定义、构建工具、测试框架	可放心更新——这些不会随产品发布
构建工具链	Bun 本身、编译器、打包器	最谨慎处理——问题会影响所有构建产物

阶段 3：执行

升级安全的软件包

对于所有判定为“安全”的软件包：

bun update pkg1@version1 pkg2@version2 ...

如果更新因最低发布时限冲突而失败（软件包的最低 semver 版本无法解析），请将其添加到 bunfig.toml 的 minimumReleaseAgeExcludes 中，并记录原因。

记录供应链备注

将完整审计结果写入 ~/.supply-chain/notes/<YYYY-MM-DD>.json：

{
  "date": "YYYY-MM-DD",
  "project": "plannotator",
  "bumped": [
    {
      "package": "...",
      "from": "...",
      "to": "...",
      "age_days": 0,
      "maintainers_changed": false,
      "provenance": false,
      "notes": "..."
    }
  ],
  "deferred": [
    {
      "package": "...",
      "current": "...",
      "available": "...",
      "age_days": 0,
      "maintainers_changed": false,
      "reason": "...",
      "review_by": "YYYY-MM-DD"
    }
  ],
  "excluded_from_age_gate": [
    {
      "package": "...",
      "reason": "..."
    }
  ]
}

对于暂缓的软件包，将 review_by 设为距今天 7 天后的日期。

检查先前暂缓的软件包

读取 ~/.supply-chain/notes/ 中的所有文件，找出先前审计中暂缓、且当前锁文件中的版本仍未变化的软件包。这些软件包之前已被暂缓，至今仍未更新。

检查方法：对于每个先前暂缓的条目，查看当前安装版本是否与暂缓备注中的 current 字段相同。如果相同，该软件包仍处于暂缓状态。

阶段 4：总结

向用户清晰地总结：

已更新

列出每个已升级的软件包、版本变更，以及说明其为何安全的一句话理由。

已暂缓

列出每个暂缓的软件包、版本变更和暂缓原因。

仍在暂缓（来自先前审计）

列出先前审计中暂缓、至今仍未升级的软件包。注明最初的暂缓日期和原因。这一部分用于提醒“你一直在拖延处理”，避免暂缓的软件包被遗忘。

如果没有仍在暂缓的软件包，请明确说明——这是个好迹象。

最低发布时限排除项

如果有软件包被添加到 minimumReleaseAgeExcludes，请注明这些软件包及原因。