update-v8-version

更新 V8 版本

核心工作流

1. 阅读 third_party/v8/README.md，并遵循其中的版本升级步骤。将该文档视为发布流程的权威依据。

2. 检查并更新包含版本固定信息的具体仓库文件：

   • codex-rs/Cargo.toml
   • codex-rs/Cargo.lock
   • MODULE.bazel
   • third_party/v8/BUILD.bazel
   • third_party/v8/README.md
   • 当其余预构建输入发生变化时，更新相应的 third_party/v8/rusty_v8_<version>.sha256 清单

3. 在流程中继续使用现有的校验和辅助工具：

   python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
   python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
   python3 -m unittest discover -s .github/scripts -p test_rusty_v8_bazel.py
   

4. 在扩大工作范围之前，先验证候选版本路径：

   • 如果存在候选分支或 PR 的 v8-canary CI 结果，优先使用 GitHub 检查工具或 gh 等工具进行核查。
   • 如果 CI 不可用，或用户要求仅在本地检查，则运行针对变更内容可行的最接近的本地验证，并明确说明这是本地替代方案，而不是完整的托管 canary。

5. 如果 canary 路径通过，到此为止。总结结果，并鼓励用户提交候选变更，或继续执行其要求的发布流程。除非用户要求，否则不要发布标签、版本或推送。

失败路径

仅当 canary 或本地构建路径失败时，才进入此路径。

1. 记录失败的目标、工作流任务和第一个可采取行动的错误。
2. 对比当前固定的版本与相关上游标签或 SHA 中的目标版本。检查以下两项：
   • denoland/rusty_v8
   • 目标 Bazel 固定版本对应的上游 V8 源码
3. 追踪与构建相关的差异，而不是广泛的源码变更：
   • 生成的绑定布局变更
   • 归档文件或资源的命名变更
   • GN/Bazel 目标变更
   • 自定义 libc++ / libc++abi / llvm-libc 输入
   • 沙箱或指针压缩的功能关联
   • patches/ 中不再适用或不再与上游匹配的补丁片段
4. 将每项失败差异追溯到 Codex 的构建图中：
   • MODULE.bazel
   • third_party/v8/BUILD.bazel
   • .github/scripts/rusty_v8_bazel.py
   • .github/workflows/v8-canary.yml
   • .github/workflows/rusty-v8-release.yml
5. 仅更新恢复目标版本构建和制品约定所需的部分。补丁说明和文档变更应紧贴受影响的文件。
6. 重新运行针对性验证。如果验证通过，返回正常工作流并停止，同时提供简要总结和剩余的发布步骤。

报告

• 说明验证来自托管的 v8-canary，还是本地替代方案。
• 区分“版本升级完成”和“发布已发布”。
• 如果遇到阻碍，报告相关的上游差异、受影响的 Codex 文件，以及下一步可尝试的具体修复。