verify-release

验证发布

在有人询问某个 OpenClaw 版本是否已完全发布、已公布、已升级、已完成冒烟测试或已通过线上验证时使用此工具。这是验证工具，而非发布工具；更改发布状态前，请使用 $release-openclaw-maintainer。

规则

• 将 .27 之类的短后缀解析为基于当前日期／上下文的具体 CalVer 版本，然后说明解析出的版本。
• 先确定发布渠道。两个渠道都使用共享的 GitHub Release 证据台账。常规 beta/stable 还会使用平台图谱；extended-stable 使用其规范分支、npm 选择器和 Gateway 界面。不要要求某个渠道提供另一渠道专属的原生或 ClawHub 工件。
• 验证线上状态。不要将本地检出状态、发布说明或过时记忆当作当前事实。
• 如果检出内容有未提交更改或与远程分歧，只将其用于脚本／参考。获取版本元数据时，请从 GitHub release/tag 获取，或在 /tmp 下解压标签 tarball。
• 绝不打印机密信息。
• 最终回复保持简短：yes/no、证据要点、注意事项、清理情况。

常规 beta/稳定版检查

仅对常规编排发布通道使用以下检查。

1. GitHub 发布：
   • gh release view v<VERSION> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
   • 确认稳定版发布不是草稿/预发布。
   • 确认发布说明在预期情况下包含 npm、CI、插件 npm、ClawHub、 mac/appcast 证据链接。
   • 确认稳定版 mac 发布所需资产已上传：zip、dmg、dSYM、 依赖项证据、不可变全量验证清单、发布后证据和稳定版主线收尾清单。
   • 下载每个不可变证据资产及其 .sha256 配套文件，然后 在信任发布记录前验证校验和。
2. 根 npm：
   • npm view openclaw@<VERSION> version dist-tags.latest dist.tarball dist.integrity time.<VERSION> --json
   • 对于稳定版，latest 必须等于 <VERSION>。
   • 记录 tarball、完整性值和发布时间。
   • 确认发布后证据记录了 npmRegistrySignaturesVerified: true 和 npmProvenanceAttestationMatched: true。
3. 插件发布集：
   • 从 GitHub 获取准确的标签元数据；本地检出有改动时不要使用本地数据： 下载 https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSION> 到 /tmp/openclaw-v<VERSION>-src。
   • 使用已记录发布的 Tooling SHA 对应的规范发布规划器/收集器， 根据准确标签的包元数据，派生该发布通道完整的预期 npm 和 ClawHub 包集。 不要根据原始发布标志进行计数：即使设置了发布标志， openclaw.build.bundledDist === true 也会明确推迟外部发布。 单独记录推迟发布的包名称及原因。
   • 使用不可变发布计划、注册表回读和工作流作业，核对原始发布、 之前发布的版本和所选恢复运行中的预期包身份、版本及数量。所选恢复子集 不得缩小完整的预期发布集： gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate。
   • 每个预期的 npm 插件都必须具有 <VERSION> 版本，且 dist-tags.latest === <VERSION>。
4. ClawHub：
   • 检查 Plugin ClawHub Release 工作流结论和发布作业数量。
   • 使用 OpenClaw 本身获取实时注册表证据： openclaw plugins search <known-plugin> --json。
   • 在隔离的 HOME 中，从 ClawHub 安装一个准确请求发布版本的官方插件： openclaw plugins install clawhub:@openclaw/matrix@<VERSION>。 优先使用 matrix，除非该插件不在预期集中。ClawHub 版本应写入规范； --pin 仅支持 npm 安装。
5. 发布工作流：
   • 验证发布说明证据链接对应工作流的结论： Full Release Validation、OpenClaw Release Checks、OpenClaw NPM Release、 Plugin NPM Release、Plugin ClawHub Release，以及需要稳定版 mac 资产时的 mac preflight/validation/publish。
   • 对于稳定版，验证 OpenClaw Stable Main Closeout 成功，并且其 清单记录了匹配的发布标签、当前回滚演练、稳定版浸泡测试和阻塞性性能证据。
   • 仅总结相关的成功/失败作业；除非发布说明明确承诺，否则忽略例行跳过的 可选通道。

Extended-stable 检查

Extended-stable 有 GitHub Release 和共享的发布证据，但没有原生或 ClawHub 产物。请将其与实时标签、工作流、注册表、来源证明和镜像状态一并验证。

1. **身份：**要求最终版本为 v<VERSION>，补丁号至少为 33，且没有后缀，并包含在 extended-stable/YYYY.M.33 中。只有处于活动状态的候选版本才必须与当前最新提交一致。根目录和每个可发布的官方插件都必须声明 <VERSION>。要求存在 Git 标签，以及公开、非预发布的 GitHub Release，且其标题和规范正文与标签一致。要求 isLatest=false，并提供依赖项证据、不可变的 Full Release Validation 清单、发布后证据及其校验和。要求没有原生产物或 ClawHub 资源。
2. **工作流链：**找到成功的父级发布运行，以及其预检、完整验证、插件 npm 和核心发布子运行。要求父级运行受保护，且名称符合 release-publish/*；验证生成器必须是规范的 release-ci/*，并具有经过验证的工作流 SHA 来源证明。验证必须使用 rerun_group=all、release_profile=stable、阻塞式 soak/performance 检查，以及保存的尝试记录。核心发布必须引用全部三个运行 ID，并将其清单、工作流引用和 tarball 摘要绑定到发布 SHA。
3. **注册表：**要求根目录、所有预检 corePackageTarballs 条目，以及根据标签推导出的每个 publishToNpm === true 官方插件，其精确选择器和 extended-stable 选择器都返回 <VERSION>。对比插件计划、作业和完整回读结果；绝不可根据差异推断清单。
4. **来源证明：**使用可信的当前工具运行 node --import tsx scripts/openclaw-npm-postpublish-verify.ts <VERSION>。要求签名、规范分支来源证明，以及发布和预检摘要与发布 SHA 的绑定。保留输出和工作流 URL。
5. **Docker：**在两个注册表中验证精确的默认、slim、browser 和架构镜像及其证明。只有三个 extended-stable* 别名可以解析到这些摘要。要求成功的 OpenClaw Release Publish 父级运行及其已完成的 Docker 验证。正常流程随后完成最终发布；明确请求的快速流程可以先激活 GitHub。通过当前主分支上的 Docker Channel Promotion，针对精确标签修复别名，不要重新构建。
6. **恢复：**绝不重新发布。根选择器（无后缀的最终补丁号至少为 33）使用 openclaw/releases dist-tag 工作流中的 promote_extended_stable；其他选择器使用经批准且凭据隔离的工具，然后重复完整回读。无需要求 ClawHub、原生/移动应用、网站、私有 dist-tag 或常规 latest。要求共享的发布证据，但不要求常规原生或 ClawHub 产物。

已发布软件包冒烟测试

通过特定发布渠道的检查后，使用一次性安装/缓存，并隔离 OpenClaw 状态：

• npm exec --yes --package openclaw@<VERSION> -- openclaw --version。
• 至少运行一条无害命令，触及已发布 CLI 的功能，例如 plugins --help 或 gateway --help。

不要额外启动本地 Gateway，也不要将临时实时模型调用作为初步发布检查。请使用上述规范的发布验证工作流和发布证据；这不会免除任何必需的检查阶段。仅在明确要求时运行额外的手动实时检查。

需报告的注意事项

• Dist-tag 注意事项：稳定版的发布依据是 latest；如果可选的 beta 仍指向 beta 版本，应将其报告为注意事项，而不是稳定版发布阻塞项，除非用户要求验证 beta 推广。
• 发布渠道注意事项：说明发布渠道及有意不包含的功能面。不要将缺少常规发布产物称为 extended-stable 发布失败。
• 检出版本不一致注意事项：如果本地源代码 SHA 与发布标签或 origin 不同，请说明这一点，以及改用哪些实时来源。