Best possible solution:

Keep the repair-only release path, or replace it with an equivalent tested recovery mode before removing the standalone workflow and updating the runbook.

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

Yes. From source inspection, after npm publish has already put the version on npm, the remaining release workflow exits at the already-published check before GitHub Release creation, while the deleted workflow is the documented repair path.

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, or release owners explicitly retire that recovery workflow.

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 6f28659e7bfb.

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, runbook, and owner review are the relevant evidence path.

What I checked:

• Live PR state: The live PR is open, collaborator-authored, changes 2 files with +4/-308, deletes the GitHub Release workflow, and GitHub reports it as conflicting/dirty against the current base. (cfff19cdfb9a)
• Current main repair workflow: Current main still has the standalone manual ClawHub CLI GitHub Release workflow with workflow_dispatch, release tag inputs, update_existing, and contents: write release creation permissions. (.github/workflows/clawhub-cli-github-release.yml:1, 6f28659e7bfb)
• Runbook recovery path: The deploy spec documents rerunning clawhub-cli-github-release.yml when npm publish succeeds but GitHub Release creation needs repair, including the update_existing behavior. (specs/deploy.md:86, 6f28659e7bfb)
• Remaining workflow cannot repair already-published versions: The npm release workflow exits when clawhub@PACKAGE_VERSION is already published before it reaches the GitHub Release create/update step later in the job. (.github/workflows/clawhub-cli-npm-release.yml:230, 6f28659e7bfb)
• Release creation step is after the publish guard: GitHub Release creation/update remains later in the real publish job, after the already-published guard that exits first on repair attempts. (.github/workflows/clawhub-cli-npm-release.yml:426, 6f28659e7bfb)
• Workflow contract test: A current-main test reads the GitHub Release workflow and asserts that it verifies publish-proof artifacts before adding npm publish release proof. (src/__tests__/clawhub-cli-release-workflow.test.ts:11, 6f28659e7bfb)

Likely related people:

• Patrick-Erichsen: Patrick authored the merged CLI GitHub Release automation and current blame/history for the release workflow and deploy runbook points to recent release work by Patrick. (role: feature owner and recent area contributor; confidence: high; commits: d67583f0756c, 5be7035a691c; files: .github/workflows/clawhub-cli-github-release.yml, .github/workflows/clawhub-cli-npm-release.yml, specs/deploy.md)
• vincentkoc: Vincent authored the publish-proof hardening and test coverage that currently depends on the GitHub Release repair workflow. (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)
• Onur: Onur authored the original guarded CLI npm release workflow, which is central to whether the standalone GitHub Release repair workflow is redundant. (role: original release workflow contributor; confidence: medium; commits: 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 group; confidence: medium; files: .github/CODEOWNERS, .github/workflows/clawhub-cli-github-release.yml)

• 🦀 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.

• 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.