扩展稳定和仅更改日志验证

扩展稳定验证

扩展稳定验证使用相同的候选者拥有的助手：确切的源候选者 C 也拥有资格 Q=C。独立信任的 P 承认并验证该请求。将这些角色和选定的发布上下文分开；在冻结之前故意向后移植缺失的资格合同 C。

VALIDATION_SHA="<exact-candidate-sha>"PUBLISHER_SHA="<recorded-full-trusted-main-ancestor-sha>"CONTEXT_REF="extended-stable/YYYY.M.33"pnpm ci:full-release \  --sha "$VALIDATION_SHA" \  --target-ref "$CONTEXT_REF" \  --admission-workflow-sha "$PUBLISHER_SHA" \  --admission-workflow-ref main \  -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

独立接纳后，帮助程序在 Q=C 处创建 release-ci/<Q-prefix>-<unique-id> 并从该不可变的命名分支进行调度。它传递的确切候选值为 ref 和 expected_sha，发布分支位于 target_context_ref。 GitHub 工作流调度 --ref 接受分支或标签，而不是原始 SHA。发布分支提供上下文，而不是资格权限。切勿手动创建传输参考或替换移动主harness。

共享发布者需要承认的候选人拥有的证据、完整的 rerun_group=all 覆盖范围以及确切的成功尝试。其受保护的 release-publish/* 参考选择 P，而不是 Q。发布工具更新不会更改冻结的候选人或资格身份。保留的历史交叉修订请求保留其原始恢复合同；新的显式 main/protected 诊断运行不能替代 Q=C 发布证明。

产品或资格harness维修更改 C/Q 并需要新的资格。提供者、批准或运行者恢复保留原始身份和输入。不要因为目标较旧而省略所需的包、安装程序、更新、频道或实时行为。

对于合格代码 SHA 已包含最终注释的常规版本，请使用与 Release SHA 相同的提交。保留其成功的完整验证母体和精确准备的发布工件；仅需要分离这些角色就不需要额外的提交或验证运行。

如果注释在限定后发生更改，请将选定的版本条目及其允许的 record/index 更新提交为新版本 SHA 并为该提交运行相同的帮助程序。产品证据重用是可选的，需要 GitHub 来证明版本 SHA 源自绿色代码 SHA。完整的更改路径集必须包括 CHANGELOG/YYYY.M.PATCH.md，也可能仅包括 CHANGELOG.md 和 CHANGELOG/records/YYYY.M.PATCH.md。 Entry/record 允许添加或修改；只能修改根索引。重命名、删除、其他发布文件和文档源编辑不符合资格。该路径记录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 包，all 带有 release_profile=beta 并且没有浸泡记录 coveragePolicy=npm-beta-v1。它保留了 Linux、macOS 和 Windows、Node 检查、Control UI、插件、包完整性、install/update 验收、Linux/Windows/macOS 交叉 OS 包检查、 QA 奇偶校验、核心运行时-pair/restart 证明以及运行时工具覆盖范围。本机应用程序资格、产品性能和已发布包 Telegram 置信度均被推迟。 Broad live/E2E 和 QA-live 也保留在该有界门之外。

使用 run_release_soak=true 针对确切发布的 Beta 运行延迟置信度，或显式选择 ci、performance、npm-telegram、package 或相关 QA/live 组。被选中的孩子仍必须完成并通过现有政策；延迟检查是未运行，从未通过。稳定、完整、可浸泡且有针对性的验证保留了现有的置信覆盖范围。 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、稳定的浸泡和阻塞产品性能。扩展稳定、无发布上下文的 main、full 和显式 ci 运行保留完整的 CI。证据重用需要相同的覆盖政策、准确的包版本、目标上下文和有效的输入；测试版或历史完整收据不能默默取代稳定的 npm 资格。

本土出版物拥有延期资格。对于 npm- 稳定版本，OpenClaw Release Publish 启动精确源完整 CI 运行，并与核心发布并行启用 Android。只有成功的本地资格和核心发布才允许单独的 Android 作业发出 v3 批准收据并分派标签拥有的 APK 发布者。该收据绑定了确切的本机 CI 运行、尝试和工具参考。发布者在撰写批准之前、在发送之前、在 APK 证明之前以及每次资产上传之前重新检查该证明。没有v3消费者的冻结标签，包括v2026.8.2及其同源更正，必须使用release_profile=full；在开始核心出版物之前，出版物仅拒绝 npm- 这些目标的证据。他们历史上的全面验证路线保留了 v2 批准合同。记录本机故障并阻止 Android 批准，而核心 npm 发布和 GitHub 发布最终确定保持独立。核心发布完成后，家长可以继续积极参与本地工作。 macOS 保留其单独的本机验证、签名、公证和升级门。稳定的npm出版物仍然拒绝证据，没有浸泡和阻碍产品性能。

macOS 应用程序签名、公证、appcast 发布和 Windows Hub 资产推广与 npm 发布并行或在发布之后运行，并且绝不延迟 npm。他们自己的工件验证和升级门仍然适用；在常规 GitHub 版本离开草案之前，仍然需要 Windows 集线器资产。

包验收通常从已解析的 ref 构建候选 tarball，包括随 pnpm ci:full-release 调度的完整 SHA 运行。 Beta 版发布后，传递 [email protected] 以在发布检查、包验收、跨 OS、发布路径 Docker 和包 Telegram 中重复使用已发货的 npm 包。仅当包裹验收应有意证明不同的包裹时才使用 package_acceptance_package_spec。 Codex插件实时包通道遵循相同的状态：发布的release_package_spec值派生codex_plugin_spec=npm:@openclaw/codex@<version>； SHA/artifact 运行所选参考中的包 extensions/codex；操作员可以直接为 npm:、npm-pack: 或 git: 插件源设置 codex_plugin_spec。该通道授予该插件所需的显式 Codex CLI 安装批准，然后运行 ​​Codex CLI 预检和同一会话 OpenAI 代理轮流。它最后的零重试、中等思维转向发送可见的进度，省略 Codex final，读取随机工作区输入，写入其确切的工件，并发送显式完成。这捕获了 v2026.7.1 回归，其中普通进度发送终止了回合。

选定源 Telegram QA 和独立 npm Telegram 测试必须先通过，然后才能通过正常发布验证。选定的包验收 Telegram 也必须在每个配置文件中传递。缺少凭证、耗尽池和失败的尝试不算作成功的证明。仍然需要准确的候选人身份、凭证隔离和租约清理。

包验收 Telegram E2E 对于每个在不浸泡的情况下运行的 beta 配置文件 all 都会自动推迟，包括 main 的 beta 配置文件检查。有效的 skip_package_telegram_e2e=true 在输入和摘要中捕获为 not run。默认情况下，启用浸泡的运行和显式 rerun_group=package 会保持选中 Telegram。现有的 -f skip_package_telegram_e2e=true 输入仍然可用于显式 Beta 延迟；它被 stable 和 full 拒绝，并且不会禁用重点 rerun_group=npm-telegram 工作流程。

选定的测试要求与明确的遗漏是分开的。经审核的 Telegram- 仅有 2026.8.1-owner-approved 和 2026.9.1-owner-approved 例外。已审查的 Telegram 和 Matrix QA-live 例外是 2026.9.5-owner-approved、2026.9.7-owner-approved、2026.9.8-owner-approved 和 2026.9.9-owner-approved。使用 -f telegram_waiver=<value> 传递所选值。任何未来的异常都需要经过审查的代码更改；单独匹配的 <target-version>-owner-approved 字符串不是授权。该值必须命名已验证目标的实际 package.json 版本，密封的候选版本必须匹配，并且配置文件必须是 stable 或 full。 Beta、预发布和未列出的目标将被拒绝。包规格覆盖必须完全是 openclaw@<target-version>；空白规格选择密封候选。它省略了源 Telegram QA、包验收 Telegram E2E 和已发布的包 Telegram E2E；他们的证据表明 已放弃/未运行，从未通过。 Telegram 单元测试和所有其他选定的门保持活动状态，包括稳定浸泡和性能检查。显式 Telegram 重新运行或套件过滤器（包括选择 Telegram 的 qa-live 或 qa-live-non-slack 等聚合）与豁免冲突并被拒绝。声明和目标版本绑定不可变的执行计划、清单和重用标识；发布者将豁免纳入发布验证说明中。上述仅限测试版的套餐延期保持不变。

源 Telegram QA 使用发布检查的共享上下文检查：确切的候选 SHA 必须保留其发布分支的祖先，或者等于其发布标记。构建和执行准入都独立地重复该检查并保留候选版本、signature/merge-attribution 和实时维护者检查。推进发布分支不会选择新的候选分支或使旧的候选分支失效。