ci: remove redundant cli github release workflow

[Patrick-Erichsen]

Summary

• Delete the repair-only ClawHub CLI GitHub Release workflow.
• Remove the deploy runbook instructions for the deleted workflow.
• Clarify that the app deploy workflow, not the CLI release repair workflow, owns the Vercel wait/smoke note.

Release Run

• Started ClawHub CLI NPM Release preflight for v0.19.0: https://github.com/openclaw/clawhub/actions/runs/26919293889

Verification

• rg -n "clawhub-cli-github-release|ClawHub CLI GitHub Release|GitHub Release workflow" .github docs specs README.md package.json scripts -g '!node_modules' || true
• git diff --check

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
clawhub	Ready	Preview, Comment	Jun 3, 2026 11:22pm

[clawsweeper]

Codex review: found issues before merge. Reviewed June 19, 2026, 4:59 PM ET / 20:59 UTC.

Summary
The PR deletes the standalone ClawHub CLI GitHub Release workflow and removes deploy-runbook text that documented using it for release repair.

Reproducibility: yes. From source inspection, after npm publish succeeds the remaining npm release workflow exits on the already-published version before GitHub Release creation, while the deleted workflow is the documented repair path for that state.

Review metrics: 2 noteworthy metrics.

• Workflow deletion: 1 workflow removed. The removed file is privileged manual GitHub Release repair automation, so the recovery path is the central merge question.
• Diff size: +4/-308 across 2 files. Nearly all of the patch is release automation removal, not implementation complexity.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🌊 off-meta tidepool
Patch quality: 🧂 unranked krab
Result: blocked by patch quality or review findings.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P2] Restore the workflow or add an equivalent repair-only release path.
• Document the supported recovery procedure if release owners intentionally retire this workflow.
• Refresh the branch against current main and resolve the workflow conflict.

Risk before merge

• [P1] Merging would remove the documented recovery path for creating or repairing a GitHub Release after npm publish already succeeded.
• [P1] The branch is currently conflicting against main because main modified the workflow that the PR deletes; the conflict should be resolved before final review.
• [P1] The touched .github/workflows/ surface is CODEOWNERS-marked release/security automation, so owner sign-off is needed even though the diff removes a privileged workflow.

Maintainer options:

1. Preserve or Replace the Repair Path (recommended)
   Before merge, keep the standalone workflow or add an equivalent repair-only mode that works after npm already contains the released version.
2. Retire It With Owner Signoff
   Release automation owners can intentionally remove the workflow if they document the supported manual recovery procedure and accept the operational tradeoff.
3. Refresh Before Final Review
   Refresh the branch against current main so the workflow deletion, deploy spec, and workflow test conflict are reconciled in one reviewable diff.

Next step before merge

• [P2] The blocker is a release-automation owner decision and recovery-path design choice, not a narrow automated repair.

Security
Cleared: The diff removes a privileged workflow rather than adding code execution, dependencies, secrets, or broader permissions; release owner review remains tracked as automation merge risk.

Review findings

• [P1] Preserve the post-publish release repair path — .github/workflows/clawhub-cli-github-release.yml:1

Review details

Best possible solution:

Keep the workflow, or replace it with an explicit tested repair-only path that can create or update the GitHub Release after npm already contains the version, then update the runbook accordingly.

Do we have a high-confidence way to reproduce the issue?

Yes. From source inspection, after npm publish succeeds the remaining npm release workflow exits on the already-published version before GitHub Release creation, while the deleted workflow is the documented repair path for that state.

Is this the best way to solve the issue?

No. Removing the workflow is too broad unless the PR preserves or replaces the post-publish GitHub Release repair path, and the final direction needs release-automation owner judgment.

Full review comments:

• [P1] Preserve the post-publish release repair path — .github/workflows/clawhub-cli-github-release.yml:1
  Deleting this workflow removes the documented fallback for repairing a GitHub Release after npm publish has already succeeded. The remaining NPM release workflow exits when the version is already published before it reaches release creation, so this PR needs an equivalent repair-only path before the workflow can be removed.
  Confidence: 0.92

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 7accfb71c771.

Label changes

Label justifications:

• P2: This is bounded release-automation cleanup with limited end-user blast radius but real maintainer workflow impact.
• merge-risk: 🚨 automation: The diff deletes manual GitHub Release repair automation, which could break CLI release recovery after a partial publish.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🌊 off-meta tidepool and patch quality is 🧂 unranked krab.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The external contributor proof gate is not applied to this collaborator-authored release-automation cleanup; workflow source and owner review are the relevant evidence path.

Evidence reviewed

What I checked:

• Repository policy applied: AGENTS.md was read fully; its production-release guidance treats CLI npm releases as manual, tag-based workflows and release automation as a maintainer-controlled surface. (AGENTS.md:76, 7accfb71c771)
• Current main still has the repair workflow: Current main contains the manual ClawHub CLI GitHub Release workflow with workflow_dispatch inputs for a release tag and update_existing repair mode. (.github/workflows/clawhub-cli-github-release.yml:1, 7accfb71c771)
• Runbook documents the deleted recovery path: The deploy spec says that if npm publish succeeds but GitHub Release creation needs repair, operators should rerun the separate GitHub Release workflow without publishing to npm again. (specs/deploy.md:75, 7accfb71c771)
• Remaining npm workflow cannot repair already-published versions: The real publish job exits when clawhub@PACKAGE_VERSION is already published before it reaches the GitHub Release create/update step. (.github/workflows/clawhub-cli-npm-release.yml:230, 7accfb71c771)
• Current tests encode the workflow contract: A current-main test reads the GitHub Release workflow and asserts that it verifies publish proof artifacts before adding release proof. (src/__tests__/clawhub-cli-release-workflow.test.ts:11, 7accfb71c771)
• PR diff removes the recovery workflow: The PR deletes .github/workflows/clawhub-cli-github-release.yml and removes the matching repair instructions from specs/deploy.md. (.github/workflows/clawhub-cli-github-release.yml:1, cfff19cdfb9a)

Likely related people:

• Patrick-Erichsen: Patrick authored the merged work that added the standalone GitHub Release workflow and current main blame also points to recent release/runbook work by Patrick. (role: feature owner and recent area contributor; confidence: high; commits: 12da0179b142, d67583f0756c, 8d7ac580d15d; files: .github/workflows/clawhub-cli-github-release.yml, .github/workflows/clawhub-cli-npm-release.yml, specs/deploy.md)
• vincentkoc: Vincent authored the commit that added publish-proof verification to both release workflows and added the test that reads the workflow this PR deletes. (role: recent adjacent contributor; confidence: medium; commits: e86aa30a77aa; files: .github/workflows/clawhub-cli-github-release.yml, .github/workflows/clawhub-cli-npm-release.yml, src/__tests__/clawhub-cli-release-workflow.test.ts)
• osolmaz: The original guarded CLI npm release workflow was introduced through merged PR history by Onur, and that workflow is central to whether the standalone repair workflow is redundant. (role: original release workflow contributor; confidence: medium; commits: 86b397110dc4, a309ebc71c34, 65bc5d333549; files: .github/workflows/clawhub-cli-npm-release.yml, scripts/clawhub-cli-npm-release-check.mjs, scripts/clawhub-cli-npm-publish.sh)
• openclaw/openclaw-secops: CODEOWNERS assigns .github/workflows/ and release/security automation files to this owner group. (role: CODEOWNERS reviewer; confidence: medium; files: .github/CODEOWNERS, .github/workflows/clawhub-cli-github-release.yml)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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 keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.