release-openclaw-maintainer

OpenClaw 发布维护人员

用于发布操作，而非日常开发或咨询性变更。 阅读 docs/reference/RELEASING.md 以了解当前策略。在解析私有凭据定位器或主机拓扑之前，如可用则加载 $release-private； 凭据操作使用 $one-password。

选择操作

仅阅读所选阶段所需的参考资料：

• 常规 beta/stable 准备或发布：常规发布，其中包含准备阶段和特定阶段的证明流程。如果请求未指定 stable/full，则默认为 beta；beta 授权并不授权后续推进 stable 发布。
• 回移发现：候选清单。对于 extended-stable，还需阅读回移准备；SDK/配置变更必须明确显示维护风险警告，并由维护人员决策。
• Extended-stable .33+ Gateway 发布：extended-stable 发布。使用共享发布器并传入 extended-stable 输入；其非 Latest GitHub Release 承载证据，但不发布原生应用，也不发布至 ClawHub。
• 验证选择或证明失败：验证与置信度，使用 $release-openclaw-ci 执行工作流并生成不可变清单。
• 发布或注册表晋级中断：发布恢复。
• 原生资产：平台发布，使用 $release-openclaw-mac 执行 macOS 操作。
• Stable 发布后同步和精确 SHA 部署交接： main 收尾。
• 发布说明：$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*、打包/npm 资格验证、包完整性， 以及 Linux/Windows/macOS Gateway 检查，其中包括 Release Checks 中的 Windows 打包 安装/升级检查。已取消的运行仍会阻塞发布。恢复前应保留 首次失败，并按下方方式逐一分类。Stable 发布需要 stable/full 证据、浸泡测试和作为阻断条件的性能验证。 Beta 配置文件证据不能授权 stable 发布。任何验证通道或浸泡测试 豁免都不能绕过这些要求。Linux、Windows 和 macOS 上的全部九种 Gateway 安装/升级 组合都是全组认证的必要条件。必须保留身份、来源、完整证据和现有 发布批准。 每个失败的测试都会得到明确的负责人决策——是真正的发布阻塞项还是 flake——并连同其证据记录在交接中：同一 SHA 在别处或重新运行时通过、与发布增量无关、带有 runner 或基础设施特征、同一用例有 flake 历史，或是不属于回归的既有产品 bug（例如 2026.9.6 的 "Assign to…" bug）。真正的阻塞项是已发布字节或行为的回归，或更新/安装/发布缺陷；请在发布分支上修复它。对 flake 在同一 Release SHA 上重新运行，默认最多记录两次重新运行，并在 main 上提交一个并行修复的 issue 或 PR，附上证据。绝不要为 flake 重新切版本、更改工具链或启动新的 FRV。仍然为红的 flake 会阻止发布。仅 main 上的失败和基础设施故障（runner 中断、GitHub 幽灵任务、托管 runner 卸载）对发布而言算作 flake。

依赖公告从不会推迟发布。新发布的公告绝不是重新切版本、更改工具链或重新运行验证的理由。将其记录在发布证据和交接中，然后在发布后作为常规后续工作在 main 上提交或排队依赖升级。只有已知恶意软件发现才会停止发布。发布依赖证据和发布分派的 CI 会强制执行这一点。

main 的 CI 健康状况从不会成为发布的关卡。验证和发布从发布分支加上固定工具链运行，因此 main 为红不是等待、重新切版本或暂停的理由。当发布需要在 main 上进行发布工具链修复时（工具链 SHA 必须是受信任的 main 提交），该修复未导致的 main 失败不得阻止其落地：在干净的 main 检出上证明该失败已存在于此，记录在 PR 正文中，然后合并。在发布进行期间，正是这种情况下允许对发布工具链 PR 进行管理员合并。main 为红仍会被修复，由单独通道并行处理，绝不在发布的关键路径上。

运营目标大约是 20 分钟完成验证封存、一小时内完成发布，并非有保障的指标。仅源码的子项与产物生产者同时启动；候选消费者在候选就绪后立即启动。独立封存的绿色子项可复用于同一确切目标和输入，即使其父项失败、被取消或仍处于活动状态；请验证其最初被接纳的资格身份（或历史受信任 main 工作流 SHA）和当前尝试。封存清单提供 SDK 证据摘要和 npm 发布决策；它从不确认 SDK API 更改，因此只要 SDK 报告包含更改，就提供 plugin_sdk_api_acknowledgement。发布器不能接受被豁免的验证证据。显式发布器输入选择发布范围；候选辅助程序在需要时仍会验证其显式 SDK 确认。

版本更改和不可逆发布需要显式批准。对指定发布进行切版本、发布或完成的请求会贯穿其经过验证的发布和验证；除非身份、渠道、范围或重大风险发生变化，否则不要再次询问。普通代码的交付权限不是发布权限。 操作员明确批准为准备指定版本执行所需的一切工作，即构成必要准备决策和修复的持续授权。应将此授权贯彻到候选版本和工具修复、升级／迁移设计、经审查的测试或安全清单对齐、隔离验证、提交、推送和验证恢复等环节。记录决策、证据和选定的支持合同；不要仅仅因为已批准类别的工作进入实现或验证阶段就再次询问。解决阻塞问题期间，继续推进彼此独立的工作。此授权不允许隐瞒缺陷、降低门槛以制造成功、破坏操作员状态、处理无关工作或发布内容。仅准备的请求仍需另行获得发布指示，才能发布制品或桥接版本。

使用交接模板维护一份简洁的状态记录：有效目标、版本／标签／分支、cut／Code／Release 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 测试框架需要新的 C/Q 和重新绑定的证据；仅 P 或基础设施修复可以保留候选版本。缺失的资格验证合同需要有意地回移植，绝不可回退到未来的 main。

候选版本切出后，其基准由操作员决定。除非 Peter 在该次发布中明确要求，否则绝不可重新切出（将候选版本变基到更新的 main）。未经询问，仅当已合并到 main 的提交用于修复已确认的发布阻塞问题时，才可将其 cherry-pick 到发布分支：冻结候选版本上的必需阶段确定性失败，或更新／安装／发布字节缺陷。在交接记录中列出每个 cherry-pick。禁止：机会性回移植、还原功能，或为“获取”一个能够通过少量冲突解决干净地 cherry-pick 的修复而采用新的基准。

发布期间进行的发布流程改进必须合入两个分支。工作流、发布脚本、发布测试、RELEASING.md 和发布技能的更改先合入 main，然后再以 -x cherry-pick 到 release/YYYY.M.PATCH，用于下一个候选版本或补丁。如果本次发布需要修复资格验证，则必须在冻结新的 C/Q 前合入；绝不可悄悄替换已完成资格验证的候选版本所用的测试框架。如果分支缺少仅限 main 的 CI 基础设施，应保留分支上的表达形式，仅移植逻辑。根据上述规则，发布分支上的产品代码修改仅限于解决阻塞问题。 只要为本次发布打开的任何内容仍未关闭，发布就尚未完成。在 最终报告之前，列出发布期间创建的每个 PR（gh pr list --author @me --state open，以及与会话绑定的任何 PR），并逐一合入，或明确关闭并注明原因； 确认其修复已合并到 main，若属于发布工具，则也已合并到 发布分支。同时，移除本次发布的临时工作树、被放弃的本地 cut 分支，以及 过期的 scripts/pr 工作树。

已发布版本和最终标签不可变。复用成功生成且与源码完全一致的 制品；不要将重建或重新发布当作隐式重试。当前发布 就是工作队列：不得顺手加入针对持续变动的 main 的修复或回移。对失败 进行分类，修复其所属组件，重试受影响的部分，然后重新评估，而不是重复 整个发布流程。

规定的发布证明和强制执行的环境审批仍是必要条件。 同级项通过不能替代缺失的必要证据。npm + ClawHub 是 优先路径。macOS、Windows、Linux 和 Android 的原生发布任务并行 运行，且绝不阻塞 npm + ClawHub、GitHub 发布收尾或 main 的收尾。 指定的 Windows Node、Linux/Windows/macOS Gateway 和原生应用 CI 失败 会阻止发布验证。各平台发布器保留各自的制品和 更新器契约；准确报告尚未完成的平台和证据缺口。