docs: clarify macOS release workflow refs#97116
Conversation
|
Codex review: needs changes before merge. Reviewed June 26, 2026, 7:07 PM ET / 23:07 UTC. Summary PR surface: Docs +41. Total +41 across 1 file. Reproducibility: yes. for the review finding: source inspection of the PR head shows the mac skill changed to Review metrics: 1 noteworthy metric.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Copy recommended automerge instructionNext step before merge
Security Review findings
Review detailsBest possible solution: Merge after Do we have a high-confidence way to reproduce the issue? Yes for the review finding: source inspection of the PR head shows the mac skill changed to Is this the best way to solve the issue? No, not yet; updating the mac skill is the right layer, but the maintainable fix needs the sibling release-maintainer runbook aligned in the same PR. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a82902c725b2. Label changesLabel justifications:
Evidence reviewedPR surface: Docs +41. Total +41 across 1 file. View PR surface stats
Acceptance criteria:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
|
@clawsweeper re-review |
|
🦞🧹 Reason: re-review requires an open issue or PR. |
* docs: clarify macOS release workflow refs * docs: clarify macOS release repo roles * docs: document macOS release approval gate * docs: align maintainer macOS release repo refs
* docs: clarify macOS release workflow refs * docs: clarify macOS release repo roles * docs: document macOS release approval gate * docs: align maintainer macOS release repo refs
* docs: clarify macOS release workflow refs * docs: clarify macOS release repo roles * docs: document macOS release approval gate * docs: align maintainer macOS release repo refs
* docs: clarify macOS release workflow refs * docs: clarify macOS release repo roles * docs: document macOS release approval gate * docs: align maintainer macOS release repo refs
What Problem This Solves
The macOS release skill made it easy to confuse the workflow ref shown in GitHub Actions with the source ref that the workflow checks out. It also did not make the two repos explicit enough:
openclaw/openclawowns the product release page, whileopenclaw/releasesowns the restricted macOS signing/notarization/publish workflows.Why This Change Was Made
This updates
.agents/skills/release-openclaw-mac/SKILL.mdwith the exact public handoff command and explains the split between public OpenClaw validation and the release-ops publisher. The public validation should run fromrelease/YYYY.M.PATCHso Actions displays the release branch, while the release-opsopenclaw/releasespublisher runs from its own trustedmainworkflow ref and selects public source throughtag/source_refinputs.User Impact
Future macOS release recovery work has a copy-paste command that matches prior successful stable macOS handoff runs and a clear warning not to use
--ref mainor--ref vYYYY.M.PATCHfor the public validation workflow. It also states that public handoff validation never uploads macOS assets, regardless ofpreflight_only, and that release-ops preflight/publish may pause at the protectedmac-releaseenvironment for Vincent or another reviewer to approve.Evidence
git diff --checkmacos-release.ymldispatch from--ref release/2026.6.10created successful run28269425203withheadBranch=release/2026.6.10andheadSha=aa69b12d0086b631b139c1435c9621a5783e3a40.OpenClaw macOS Publishhas a real-publish guard requiring workflow refrefs/heads/main.OpenClaw macOS Publishuses protected environmentmac-releasein thebuild_sign_and_packagejob.