Release Openclaw Maintainer

OpenClaw Release Maintainer

Use for a release operation, not ordinary development or advisory mutation. Read docs/reference/RELEASING.md for current policy. Load $release-private when available before resolving private credential locators or host topology; credential operations use $one-password.

Choose the operation

Read only the references needed for the selected phase:

• Regular beta/stable preparation or publication: regular release, which routes preparation and phase-specific proof. If the request does not specify stable/full, default to beta; beta authorization does not authorize later stable promotion.
• Backport discovery: candidate inventory. For extended-stable also read backport preparation; SDK/config changes need a visible maintenance-risk warning and maintainer decision.
• Extended-stable .33+ Gateway publication: extended-stable publication. Use the shared publisher with extended-stable inputs; its non-Latest GitHub Release carries evidence without native-app or ClawHub publication.
• Validation selection or failed proof: validation and confidence, with $release-openclaw-ci for workflow execution and immutable manifests.
• Interrupted publication or registry promotion: publication recovery.
• Native assets: platform publication, with $release-openclaw-mac for macOS operations.
• Stable postpublish synchronization and the exact-SHA deployment handoff: main closeout.
• Release notes: $openclaw-changelog-update, including its separate approved post-release docs-mirror route. Initial release generation keeps its existing format; docs publication does not run automatically during release. Requested announcements: $release-openclaw-announcement for Discord, $release-tweets for X. Announcements never gate publication and require explicit posting authorization.
• Published artifact verification: $verify-release. GHSA operations: $openclaw-ghsa-maintainer only with explicit security-workflow authorization.

Shared release boundaries

Every selected validation lane must succeed: Windows and macOS Node and other normal CI jobs, install smoke, survivor lanes, update-first-hop-compat*, pack/npm qualification, package integrity, and Linux/Windows/macOS Gateway checks, including Windows packaged install/upgrade checks in Release Checks. A cancelled run still blocks. Preserve first failures and classify each one as below before recovery. Stable publication requires stable/full evidence, soak, and blocking performance. Beta-profile evidence cannot authorize stable publication. No lane or soak waiver can bypass these requirements. All nine Gateway install/upgrade combinations across Linux, Windows, and macOS are required for all-group qualification. Preserve identity, provenance, complete evidence, and existing publication approvals.

Every failed test gets an explicit lead decision, real release blocker or flake, recorded in the handoff with its evidence: the same SHA passing elsewhere or on rerun, no relation to the release delta, a runner or infra signature, a history of the same case flaking, or a pre-existing product bug that is not a regression (for example the 2026.9.6 "Assign to…" bug). A real blocker is a regression in shipped bytes or behavior, or an update/install/ publish defect; fix it on the release branch. Rerun a flake on the same Release SHA with at most two recorded reruns by default, and file a fix-in-parallel issue or PR on main with the evidence. Never re-cut, change tooling, or start a new FRV for a flake. A flake that remains red blocks publication. Main-only failures and infrastructure failures (runner outages, GitHub ghost jobs, hosted-runner offload) count as flakes for the release.

Dependency advisories never delay a release. A newly published advisory is never a reason to re-cut, change tooling, or rerun validation. Record it in the release evidence and handoff, then file or queue the dependency bump on main as a normal follow-up after publication. Only a known-malware finding stops publication. Release dependency evidence and release-dispatched CI enforce this.

Main's CI health never gates a release. Validation and publication run from the release branch plus pinned tooling, so a red main is not a reason to wait, re-cut, or pause. When the release needs a release-tooling fix on main (tooling SHAs must be trusted main commits), main failures the fix does not cause must not hold that landing: prove on a clean main checkout that the failure already exists there, record it in the PR body, and merge. During an active release, an admin merge is allowed for a release-tooling PR in exactly that situation. Red main still gets fixed, in parallel by a separate lane, never on the release's critical path.

The operating objectives are approximately 20 minutes to seal validation and publication within an hour, not measured guarantees. Source-only children start alongside artifact producers; candidate consumers start as soon as the candidate is ready. Independently sealed green children can be reused for the same exact target and inputs even when their parent failed, was cancelled, or remains active; verify their original admitted qualification identity (or historical trusted-main workflow SHA) and current attempt. The sealed manifest supplies the SDK evidence digest and npm publication decisions; it never acknowledges SDK API changes, so supply plugin_sdk_api_acknowledgement whenever the SDK report contains changes. The publisher cannot accept waived validation evidence. Explicit publisher inputs select publication scope; the candidate helper still validates its explicit SDK acknowledgement when needed.

Explicit approval is required for version changes and irreversible publication. A request to cut, publish, or complete a named release carries through its validated publication and verification; do not ask again unless identity, channel, scope, or material risk changes. Ship authority for ordinary code is not release authority.

An operator's explicit approval to do whatever is needed to prepare a named release is standing authority for the necessary preparation decisions and repairs. Carry it through candidate and tooling fixes, upgrade/migration design, reviewed test or security-inventory alignments, isolated proof, commits, pushes, and validation recovery. Record the decision, its evidence, and the selected support contract; do not ask again merely because an already-approved class of work reaches an implementation or verification step. Continue independent work while resolving a blocker. This authority does not permit hiding defects, lowering a gate to manufacture success, destructive changes to operator state, unrelated work, or publication. A prepare-only request still requires a separate publication instruction before releasing artifacts or a bridge version.