扩展稳定版与仅变更日志验证

Extended-stable 验证¶

Extended-stable 验证使用相同的受检辅助程序，并带有不可变的受信任 main 工具链 SHA。请将精确候选、工具链 SHA、规范上下文和工作流传输方式分开保存：

VALIDATION_SHA="<exact-candidate-sha>"
TOOLING_SHA="<recorded-full-main-ancestor-sha>"
CONTEXT_REF="extended-stable/YYYY.M.33"
pnpm ci:full-release \
  --sha "$VALIDATION_SHA" \
  --target-ref "$CONTEXT_REF" \
  --workflow-sha "$TOOLING_SHA" \
  -f validation_purpose=publish \
  -f publication_selection_json='{"route":"extended-stable","npmDistTag":"extended-stable","publishOpenclawNpm":true,"pluginPublishScope":"all-publishable","plugins":[]}' \
  -f release_profile=stable \
  -f run_release_soak=true \
  -f fail_fast=false \
  -f rerun_group=all \
  -f reuse_evidence=false \
  -f dispatch_release_evidence=false

该辅助程序会在工具链 SHA 处创建 release-ci/<tooling-prefix>-<unique-id>，从该命名分支发起调度，提供受信任 main 身份，并将精确验证 SHA 同时用于 ref 和 expected_sha，同时在 target_context_ref 中使用规范分支。GitHub 工作流调度的 --ref 接受分支或标签，而不接受原始 SHA。在 extended-stable 验证之外，仅当规范分支的头部同时也是受信任的工作流实现时，直接对该分支进行调度才有效。当前的 extended-stable 验证使用不同的受信任 main 工具链，因此需要不可变的辅助程序。

共享发布器要求使用这一规范的 release-ci/* 生产者，并将其受信任的工作流 SHA 与精确候选 SHA 分开绑定。其受保护的 release-publish/* 引用不能替代规范候选分支。保留完整的 rerun_group=all 清单、精确运行 ID 和成功尝试；拒绝直接规范分支/main 生产者、窄范围运行、过期尝试和不匹配的目标。如果经审查的工具链修复更改了发布 SHA，验证工具链必须仍可从当前 main 访问，并且所有候选和证据身份仍必须匹配。

产品故障修复应向后移植；对冻结目标工具链进行最小且保持行为的修复；provider、approval 或 runner 失败可在不更改源代码的情况下重试。任何分支更改都需要一次完整的新运行。不要因为目标较旧而省略必需的包、安装程序、更新、渠道或 live 行为。

如果常规发布的合格代码 SHA 已包含最终说明，请将该提交用作发布 SHA。保留其成功的完整验证父工作流以及精确准备的发布工件；无需仅为了区分这些角色而额外提交或运行验证。

如果说明在资格认定后发生变化，请将选定的发布条目及其允许的记录/索引更新提交为新的发布 SHA，并针对该提交运行相同的辅助程序。产品证据复用是可选的，并且需要 GitHub 证明发布 SHA 是绿色代码 SHA 的后代。完整的变更路径集合必须包含 CHANGELOG/YYYY.M.PATCH.md；此外，只允许包含 CHANGELOG.md 和 CHANGELOG/records/YYYY.M.PATCH.md。允许新增或修改条目/记录；根索引只能被修改。重命名、删除、其他发布文件以及文档源编辑不符合条件。该路径记录 split-changelog-release-v1；历史上仅变更根文件的收据保留其 changelog-only-release-v1 契约。复用仍然使更改后的包和镜像字节符合资格。任何其他源代码更改都会回到完整代码验证。发布顺序请参阅 Releasing。

概念阶段映射到当前输入：

beta-publish：release_profile=beta，run_release_soak=false
postpublish-confidence：validation_purpose=postpublish-confidence，不选择发布项，使用精确的已发布包，并设置 run_release_soak=true 或显式聚焦组
stable-publish：release_profile=stable

对于匹配的规范发布分支或 beta 标签上的实际 beta 包，使用 release_profile=beta 且不进行 soak 的 all 会记录 coveragePolicy=npm-beta-v1。它保留 Linux、macOS 和 Windows 的 Node 检查、Control UI、插件、包完整性、安装/更新验收、Linux/Windows/macOS 跨操作系统包检查、QA 对等性、核心运行时配对/重启证明以及运行时工具覆盖。原生应用资格认定、产品性能和已发布包的 Telegram 置信度被延后。广泛的 live/E2E 和 QA-live 也仍不在此有界门禁之内。

针对精确已发布的 beta 包运行延后的置信度检查：使用 run_release_soak=true，或显式选择 ci、performance、npm-telegram、package 或相关的 QA/live 组。选中的子项仍必须完成并通过其现有策略；延后的检查不会运行，也永远不会通过。Stable、完整、启用 soak 的验证以及聚焦验证保留其现有的置信度覆盖。main 和非 beta 目标不符合 npm-beta-v1 的条件。

对于匹配发布分支或标签上的常规最终包，使用 release_profile=stable 的 all 会记录 coveragePolicy=npm-stable-v1，并使用 CI 的 npm-stable 范围。数字更正符合条件，包括基础标签解析到相同源 SHA 的未更改基础包。此策略仅延后 macOS Swift/OpenClawKit、iOS/Watch、Android 和原生 i18n。Linux、macOS 和 Windows 的 Node 覆盖、Control UI、插件、包和安装程序验收、QA、稳定 soak 和阻塞性产品性能仍为必需。Extended-stable、没有发布上下文的 main、full 以及显式 ci 运行保留完整 CI。证据复用要求相同的覆盖策略、精确包版本、目标上下文和有效输入；beta 或历史完整收据不能静默替代 stable npm 资格认定。

原生发布负责被延后的资格认定。对于 npm-stable 发布，OpenClaw Release Publish 在核心发布的同时启动一次启用 Android 的精确源完整 CI 运行。只有原生资格认定和核心发布均成功，才允许独立的 Android 作业签发 v3 批准收据，并调度标签所属的 APK 发布器。该收据绑定精确的原生 CI 运行、尝试和工具链引用。发布器在写入批准之前、紧接调度之前、APK 证明之前以及每次资产上传之前，都会重新检查该证明。缺少 v3 消费方的冻结标签（包括 v2026.8.2 及其同源更正）必须使用 release_profile=full；发布会在启动核心发布之前，拒绝针对这些目标的仅 npm 证据。它们的历史完整验证路径保留 v2 批准契约。原生失败会被记录并阻止 Android 批准，而核心 npm 发布和 GitHub release 定稿保持独立。核心发布完成后，父工作流可继续处于活动状态以处理原生工作。macOS 保留其单独的原生验证、签名、公证和晋升门禁。Stable npm 发布仍然拒绝没有 soak 和阻塞性产品性能的证据。

macOS 应用签名、公证、appcast 发布以及 Windows Hub 资产提升与 npm 发布并行或在 npm 发布之后运行，且永远不会延迟 npm。它们自身的制品验证和提升门禁仍然适用；在常规 GitHub 发布离开草稿状态之前，Windows Hub 资产仍然是必需的。

Package Acceptance 通常从已解析的 ref 构建候选 tarball，包括通过 pnpm ci:full-release 派发的完整 SHA 运行。在 beta 发布之后，传入 release_package_spec=openclaw@YYYY.M.PATCH-beta.N，以在发布检查、Package Acceptance、跨操作系统、发布路径 Docker 以及 package Telegram 中复用已发布的 npm 包。仅当 Package Acceptance 需要有意证明另一个包时，才使用 package_acceptance_package_spec。Codex 插件实时包通道遵循相同状态：已发布的 release_package_spec 值会派生 codex_plugin_spec=npm:@openclaw/codex@<version>；SHA/制品运行会从所选 ref 打包 extensions/codex；操作员可以直接为 npm:、npm-pack: 或 git: 插件源设置 codex_plugin_spec。该通道会授予该插件所需的显式 Codex CLI 安装批准，然后运行 Codex CLI 预检和同一会话中的 OpenAI 智能体轮次。其最终的零重试、中等思考轮次会发送可见进度，并省略 Codex final，读取随机化的工作区输入，写入其精确制品，并发送显式完成。这可以捕获 v2026.7.1 中的回归问题，即普通进度发送会终止该轮次。

所选 source Telegram QA 和独立 npm Telegram 测试必须在常规发布验证通过之前通过。所选 Package Acceptance Telegram 也必须在每个 profile 中通过。缺少凭据、池耗尽以及失败尝试均不计为成功证明。精确候选身份、凭据隔离和租约清理仍然是必需的。

对于每个未启用 soak 的 beta-profile all 运行，包括 main 的 beta-profile 检查，Package Acceptance Telegram E2E 会自动延迟。生效的 skip_package_telegram_e2e=true 会在输入和摘要中记录为 未运行。启用 soak 的运行以及显式 rerun_group=package 默认保持选中 Telegram。现有的 -f skip_package_telegram_e2e=true 输入仍可用于显式 beta 延迟；对于 stable 和 full 会被拒绝，并且不会禁用聚焦的 rerun_group=npm-telegram 工作流。

所选测试要求与显式省略相互独立。已审查的例外为 -f telegram_waiver=2026.8.1-owner-approved 和 -f telegram_waiver=2026.9.1-owner-approved。任何未来例外都需要经过审查的代码变更；仅有一个匹配的 <target-version>-owner-approved 字符串并不构成授权。该值必须指明已验证目标的实际 package.json 版本，密封候选版本必须匹配，并且 profile 必须是 stable 或 full。Beta、预发布和未列出的目标会被拒绝。包规范覆盖必须恰好为 openclaw@<target-version>；空白规范会选择密封候选。它会省略 source Telegram QA、Package Acceptance Telegram E2E 以及已发布包 Telegram E2E；其证据状态为 已豁免 / 未运行，绝不会是通过。Telegram 单元测试以及所有其他所选门禁保持激活，包括 stable soak 和性能检查。显式 Telegram 重跑或套件过滤器，包括选择 Telegram 的聚合项（例如 qa-live 或 qa-live-non-slack），会与豁免冲突并被拒绝。声明和目标版本会绑定不可变的执行计划、manifest 和复用身份；发布者会将豁免带入发布验证说明。上述仅限 beta 的包延迟保持不变。

Source Telegram QA 使用发布检查的共享上下文检查：精确候选 SHA 必须仍然是其规范分支的祖先，或者等于其发布标签。构建准入和执行准入都会独立重复该检查，并保留候选版本、签名/合并归属以及实时维护者检查。推进发布分支不会选择新的候选，也不会使旧候选失效。

本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 cl/openclaw