OpenClaw 发布维护者 是做什么的？
用于发布操作，而非普通开发或建议变更。
阅读 docs/reference/RELEASING.md 了解当前策略。在解析私有凭证定位器或主机拓扑前，加载 $release-private（如果可用）；凭证操作使用 $one-password。
选择操作
仅阅读所选阶段所需的参考资料：
- 常规 Beta/稳定版准备或发布：常规发布，其中包含准备流程和阶段特定证明。如果请求未指定稳定版/完整版，默认使用 Beta；Beta 授权不会授权后续的稳定版升级。
- 向后移植发现：候选清单。对于扩展稳定版，还需阅读向后移植准备；SDK/配置变更需要可见的维护风险警告和维护者决策。
- 扩展稳定版
.33+Gateway 发布：扩展稳定版发布。使用包含扩展稳定版输入的共享发布器；其非 Latest GitHub Release 携带证据，但不进行原生应用或 ClawHub 发布。 - 验证选择或失败证明：验证与信心，使用
$release-openclaw-ci进行工作流执行和不可变清单。 - 中断的发布或注册表升级：发布恢复。
- 原生资产：平台发布，macOS 操作使用
$release-openclaw-mac。 - 稳定版发布后同步与精确 SHA 部署交接：主分支关闭。
- 发布说明：
$openclaw-changelog-update，包括其独立的已批准发布后文档镜像路由。初始发布生成保持现有格式；文档发布不会在发布期间自动运行。请求的公告：Discord 使用$release-openclaw-announcement，X 使用$release-tweets。公告不会阻塞发布，并需要明确的发布授权。 - 已发布制品验证：
$verify-release。GHSA 操作：仅在有明确安全工作流授权时使用$openclaw-ghsa-maintainer。
共享发布边界
每个选定的验证通道都必须成功：Windows 和 macOS Node 及其他正常 CI 作业、安装冒烟测试、survivor 通道、update-first-hop-compat*、pack/npm 资格验证、包完整性以及 Linux/Windows/macOS Gateway 检查，包括 Release Checks 中的 Windows 打包安装/升级检查。取消的运行仍会阻塞。保留首次失败，并在恢复前将每个失败分类如下。稳定版发布需要稳定版/完整版证据、浸泡测试和性能阻塞。Beta 配置文件证据不能授权稳定版发布。任何通道或浸泡豁免都不能绕过这些要求。Linux、Windows 和 macOS 上的所有九个 Gateway 安装/升级组合都是全组资格验证所必需的。保留身份、来源、完整证据和现有发布批准。
每个失败的测试都需得到明确的负责人决策——真正发布阻塞器或不稳定测试——并记录在交接中，附带其证据：相同 SHA 在其他地方或重新运行时通过、与发布增量无关、运行器或基础设施特征、相同案例过去出现过不稳定行为、或非回归的既有产品缺陷（例如 2026.9.6 的“Assign to…”错误）。真正的阻塞器是已发布字节或行为中的回归，或更新/安装/发布缺陷；在发布分支上修复。对相同发布 SHA 上的不稳定测试默认最多重新运行两次并记录，并在 main 上提交并行修复的问题或 PR，附带证据。切勿因不稳定测试而重新切分、更改工具链或启动新的 FRV。若不稳定测试持续为红色，将阻塞发布。仅 main 分支失败和基础设施故障（运行器故障、GitHub 幽灵作业、托管运行器卸载）视为发布的失败。
依赖项安全通告绝不会延迟发布。新发布的通告不能成为重新切分、更改工具链或重新运行验证的原因。将其记录在发布证据和交接中，然后作为发布后的正常后续操作在 main 上提交或排队依赖项升级。只有已知的恶意软件发现会停止发布。发布依赖项证据和发布调度的 CI 强制执行此规则。
Main 分支的 CI 健康状态绝不会阻塞发布。验证和发布在发布分支加上固定工具链上运行，因此红色的 main 不是等待、重新切分或暂停的理由。当发布需要在 main 上修复发布工具链时（工具链 SHA 必须是受信任的 main 提交），该修复未导致的 main 失败不得阻止其合并：在干净的 main 签出上证明该失败已存在，记录在 PR 主体中，然后合并。在活跃发布期间，在这种情况下允许对发布工具链 PR 进行管理员合并。红色的 main 仍需修复，由单独的通道并行进行，绝不影响发布的关键路径。
操作目标大约是在一小时内用 20 分钟完成验证和发布，这不是有保证的指标。仅源代码的子任务与制品生产者同时启动；候选消费方在候选就绪后立即启动。已独立验证为绿色的子任务，即使其父任务失败、被取消或仍处于活动状态，也可为相同的精确目标和输入重用；验证其原始接受的资格身份（或历史受信任主工作流 SHA）和当前尝试。已封装的清单提供 SDK 证据摘要和 npm 发布决策；它从不确认 SDK API 变更，因此当 SDK 报告包含变更时，需提供 plugin_sdk_api_acknowledgement。发布器不能接受已豁免的验证证据。明确的发布器输入选择发布范围；候选助手仍在需要时验证其明确的 SDK 确认。
版本更改和不可逆的发布需要明确批准。请求切分、发布或完成指定发布时，贯穿其已验证的发布和验证；除非身份、通道、范围或重大风险发生变化，否则不要再次询问。普通代码的发布权不等于发布权限。
操作员明确批准为准备指定发布所需的一切操作，即为必要的准备决策和修复的持续授权。将其贯穿候选和工具链修复、升级/迁移设计、已审查的测试或安全清单对齐、隔离证明、提交、推送和验证恢复。记录决策、其证据和选定的支持合同；不要仅仅因为已批准的工作类别到达实施或验证步骤就再次询问。在解决阻塞器的同时继续独立工作。此权限不允许隐藏缺陷、降低门槛以制造成功、对操作员状态进行破坏性更改、无关工作或发布。仅准备请求在释放制品或桥接版本之前仍需要单独的发布指令。
使用一个紧凑的状态记录，按照交接模板：有效目标、版本/标签/分支、切分/代码/发布 SHA、C/Q/P 身份、活动父运行和尝试、成功子制品、已批准的更改、阶段和下一步操作。最新的操作员指示取代已取代的范围。完成的证据保持完整，直到命名变更使其失效。
对于常规发布，尽可能在冻结 Code SHA 之前准备完整的说明。如果这些说明是最终版，则 Code SHA 和 Release SHA 为同一提交：一次成功的全新完整资格验证可以为两个角色及其精确发布字节提供支持。不要仅为分离标签而创建另一个提交或运行。如果说明在资格验证后更改，则其后代（其完整增量包含 CHANGELOG/<version>.md（精确 Beta 版本或稳定基础）且仅包含该条目、其匹配记录和根索引）可以使用 split-changelog-release-v1 在资格验证新发布字节的同时重用产品证明。任何其他源增量、重命名或删除都将返回 Code SHA 循环。历史仅根收据保留 changelog-only-release-v1。
新的资格验证冻结 Q=C：整个资格验证工作流闭包属于候选。保持独立受信任的 P（准入、验证器和发布器）分开。Q harness 修复需要新的 C/Q 和新绑定的证据；仅 P 或基础设施修复可以保留候选。缺失的资格验证合同需要故意的向后移植，绝不能回退到未来的 main 分支。
一旦切分了候选，其基础就是操作员的决策。除非 Peter 在特定发布中明确要求，否则不要重新切分（将候选重新基于更新的 main）。在不询问的情况下，仅为了修复确认的发布阻塞器，才将已经合并的 main 提交挑选到发布分支上：一个必需的通道在冻结的候选上确定性失败，或更新/安装/发布字节缺陷。在交接记录中命名每个挑选的提交。不允许的：机会主义的向后移植、功能回滚、或为了“捡起”一个通过微小冲突解决就能干净挑选的修复而采用新的基础。
在发布期间进行的发布流程改进需合并到两个分支。工作流、发布脚本、发布测试、RELEASING.md 和发布技能的更改首先合并到 main，然后被挑选（带 -x）到 release/YYYY.M.PATCH 以用于下一个候选或补丁。此发布所需的资格验证修复必须在冻结新的 C/Q 之前合并；切勿为已资格验证的候选静默交换 harness。如果分支上缺少仅 main 的 CI 基础设施，则保留分支的表达式形式，仅移植逻辑。发布分支上的产品代码仅限阻塞器修复，遵循上述规则。
只要为发布打开的任何事项仍未关闭，发布就没有完成。在最终报告之前，列出发布期间创建的每个 PR（gh pr list --author @me --state open 加上与会话绑定的任何 PR），并合或明确关闭每个 PR，附上原因；确认其修复位于 main 上，如果是发布工具链，则位于发布分支上。还要删除发布的临时工作树、废弃的本地切分分支和过时的 scripts/pr 工作树。
已发布的版本和最终标签不可变。重用成功的精确来源制品；不要作为隐式重试而重建或重新发布。活跃发布是工作队列：没有机会主义的移动 main 修复或向后移植。分类失败，修复其负责人，重试受影响的面，然后重新评估，而不是重复整个发布。
所需的发布证据和强制环境批准仍然需要。通过的兄弟任务不能替换缺失的必要证据。npm + ClawHub 是优先路径。macOS、Windows、Linux 和 Android 原生发布并行运行，绝不阻塞 npm/ClawHub、GitHub 发布完成或主分支关闭。选定的 Windows Node、Linux/Windows/macOS Gateway 和原生应用 CI 失败会阻塞发布验证。平台发布器保留其自己的制品和更新器合同；准确报告待定平台和证据差距。