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 July 4, 2026, 4:27 AM ET / 08:27 UTC.

Summary
The PR removes the manual ClawHub CLI GitHub Release repair workflow and trims the deploy runbook instructions that referenced it.

Reproducibility: yes. Source inspection shows the deleted workflow is the documented post-publish GitHub Release repair path, while the remaining npm release workflow exits before release creation when the package version is already published.

Review metrics: 3 noteworthy metrics.

• Workflow deletion: 1 workflow removed, 285 lines deleted. The removed file is CODEOWNERS-covered release repair automation with contents write permission.
• Runbook deletion: 23 lines removed from specs/deploy.md. The operator instructions for repairing GitHub Release creation after npm publish are removed without replacement.
• Current test contract: 1 test file references the deleted workflow. Current main has explicit release-workflow assertions that must be reconciled before the workflow can be retired.

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] Preserve the standalone workflow or add a release-only repair mode that works after npm has already accepted the package.
• [P2] Update the deploy runbook and release-workflow tests to match the retained or replacement repair path.

Risk before merge

• [P1] Merging as-is would remove the documented post-publish GitHub Release repair path; if npm publish succeeds and release creation fails, the remaining publish workflow fails early because the npm package is already published.
• [P1] The PR is currently conflicting, and current main has release-workflow tests that read the workflow being deleted, so intentional retirement needs branch refresh and test-contract reconciliation.

Maintainer options:

1. Replace The Repair Path Before Deletion (recommended)
   Add a tested release-only repair mode or equivalent workflow path that still works after npm has already accepted the package, then update the runbook to that path.
2. Keep The Existing Workflow
   Leave the standalone workflow and runbook in place until release owners decide the post-publish repair path is no longer needed.
3. Retire With Owner Acceptance
   Release/security automation owners may accept the operational tradeoff if they also document how maintainers should recover a failed GitHub Release after npm publish.

Next step before merge

• [P2] A release/security automation owner needs to decide whether to keep the repair workflow or replace it with an explicit post-publish release-only mode.

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

Review findings

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

Review details

Best possible solution:

Preserve the standalone repair workflow or replace it with an equivalent tested release-only repair mode; if release owners intentionally retire it, document the approved recovery procedure and update the workflow contract tests.

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

Yes. Source inspection shows the deleted workflow is the documented post-publish GitHub Release repair path, while the remaining npm release workflow exits before release creation when the package version is already published.

Is this the best way to solve the issue?

No. Deleting the workflow is too broad unless the PR preserves an equivalent repair-only path or release owners explicitly retire it with updated docs and tests.

Full review comments:

• [P1] Preserve a post-publish release repair path — .github/workflows/clawhub-cli-github-release.yml:1
  This remains unresolved from the prior review: deleting this workflow removes the documented fallback for creating or updating a GitHub Release after npm publish has already succeeded. The surviving npm release workflow fails on an already-published package before release creation, so this PR needs an equivalent repair-only path or explicit owner-approved retirement before merge.
  Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.93

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 76b4f36bb0f7.

Label changes

Label justifications:

• P2: This is a bounded release automation regression risk with limited user blast radius but real maintainer workflow impact.
• merge-risk: 🚨 automation: The PR removes the only documented post-publish GitHub Release repair workflow without an equivalent recovery path.
• 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: Contributor proof is not required for this collaborator-authored workflow/runbook cleanup PR, though maintainer release-automation validation is still needed before merge.

Evidence reviewed

What I checked:

• Live PR state: Live GitHub state shows the PR is open, collaborator-authored, conflicting, and changes 2 files with +4/-308: it deletes the release workflow and edits specs/deploy.md. (cfff19cdfb9a)
• Deleted repair workflow: Current main still has a manual ClawHub CLI GitHub Release workflow with tag/proof inputs and update_existing support for creating or repairing releases. (.github/workflows/clawhub-cli-github-release.yml:1, 76b4f36bb0f7)
• Remaining workflow is not equivalent: The npm release workflow rejects an already-published package before it reaches the GitHub Release creation step, so it cannot repair a failure that happens after npm publish succeeds. (.github/workflows/clawhub-cli-npm-release.yml:239, 76b4f36bb0f7)
• Runbook contract: The deploy runbook currently tells operators to rerun the standalone GitHub Release workflow when npm publish succeeds but GitHub Release creation needs repair. (specs/deploy.md:86, 76b4f36bb0f7)
• Current test contract: Current main has a release-workflow test that reads .github/workflows/clawhub-cli-github-release.yml and asserts its proof and release-view safeguards. (src/__tests__/clawhub-cli-release-workflow.test.ts:11, 76b4f36bb0f7)
• Feature introduction history: Merged commit d67583f introduced the standalone GitHub Release workflow, updated the npm release workflow, and documented the repair runbook in specs/deploy.md. (.github/workflows/clawhub-cli-github-release.yml:1, d67583f0756c)

Likely related people:

• Patrick-Erichsen: Patrick authored the merged automation PR that added the standalone GitHub Release workflow and runbook section, and also authored this proposed retirement branch. (role: introduced behavior and release automation contributor; confidence: high; commits: d67583f0756c, cfff19cdfb9a; files: .github/workflows/clawhub-cli-github-release.yml, .github/workflows/clawhub-cli-npm-release.yml, specs/deploy.md)
• vincentkoc: Vincent authored recent hardening and test coverage for the CLI release workflows, including publish-proof validation and release workflow tests. (role: recent area contributor; confidence: high; commits: e86aa30a77aa, 81b06595d647; files: .github/workflows/clawhub-cli-github-release.yml, .github/workflows/clawhub-cli-npm-release.yml, src/__tests__/clawhub-cli-release-workflow.test.ts)
• openclaw/openclaw-secops: CODEOWNERS assigns .github/workflows/ and specs/deploy.md to this group, so workflow retirement should route through them. (role: explicit CODEOWNERS route; confidence: high; files: .github/CODEOWNERS, .github/workflows/clawhub-cli-github-release.yml, specs/deploy.md)

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.

Review history (1 earlier review cycle)

• reviewed 2026-07-03T07:36:33.435Z sha cfff19c :: found issues before merge. :: [P1] Preserve a post-publish release repair path