Best possible solution:

Land this only after release owners either complete a first Docker Hub publish/backfill or qualify the docs as pending, and explicitly accept or adjust the fail-closed Docker Hub release gating.

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

Yes for the PR finding: the live Docker Hub tag API returns count: 0, while the PR docs advertise openclaw/openclaw:latest. This is an after-patch documentation/runtime mismatch, not a current-main bug.

Is this the best way to solve the issue?

No, not as-is. The workflow belongs in the release surface, but the docs should wait for or qualify the first Docker Hub publish, and release owners should explicitly accept the fail-closed Docker Hub secret and availability policy.

Full review comments:

• [P2] Gate Docker Hub docs on the first publish — docs/install/docker.md:50
  The new install docs tell users to pull openclaw/openclaw:latest, but the live Docker Hub repository currently has zero tags. Since docs can publish as soon as this merges, users can hit a broken pull path unless a first backfill/release has populated Docker Hub or the docs are worded as pending until that proof exists.
  Confidence: 0.92

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 55d7b5b36ca1.

Label justifications:

• P2: This is a normal-priority release automation and install documentation change with operator impact but no current production outage.
• merge-risk: 🚨 automation: The diff changes release automation so Docker Hub secrets and registry availability can block Docker release publishing.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This is a maintainer-labeled member PR, so the external-contributor real behavior proof gate does not apply; operational Docker Hub publish proof is still needed for release-owner confidence.

PR surface:

Tests +33, Docs +13, Config +139. Total +185 across 4 files.

What I checked:

• Current main is GHCR-only: Current main defines only REGISTRY: ghcr.io and IMAGE_NAME: ${{ github.repository }} for the Docker release workflow, with no Docker Hub target. (.github/workflows/docker-release.yml:27, 55d7b5b36ca1)
• PR adds Docker Hub secret gating: The PR head adds DOCKERHUB_REGISTRY, DOCKERHUB_IMAGE_NAME, and a validate_publish_config job that fails when DOCKERHUB_USERNAME or DOCKERHUB_TOKEN is absent; build and manifest jobs depend on that validation. (.github/workflows/docker-release.yml:72, 3d9f9e710542)
• PR extends manifest and attestation publication: The PR creates Docker Hub manifests from the architecture tags and adds Docker Hub refs to attestation verification, which is the right surface but needs operational proof on the new registry. (.github/workflows/docker-release.yml:626, 3d9f9e710542)
• Docs advertise Docker Hub latest: The PR docs tell users to set OPENCLAW_IMAGE="openclaw/openclaw:latest" before a live Docker Hub tag exists. Public docs: docs/install/docker.md. (docs/install/docker.md:50, 3d9f9e710542)
• Live Docker Hub repository has no tags: Docker Hub metadata is public for openclaw/openclaw, but the tag listing returned count: 0, so the documented latest pull target is not available yet.
• Tests are workflow text guards: The added tests assert Docker Hub registry strings, login text, tag outputs, and beta alias wording, but they do not prove Docker Hub credentials, first publish, or registry attestation behavior. (src/dockerfile.test.ts:352, 3d9f9e710542)

Likely related people:

• vincentkoc: Recent history shows release-control hardening, Docker BuildKit retry handling, alpha image publish disabling, and this Docker Hub release PR in the same workflow area. (role: recent release workflow contributor; confidence: high; commits: abb6f04e0cac, ff5fac143973, b7450f83a16e; files: .github/workflows/docker-release.yml, docs/install/docker.md, src/dockerfile.test.ts)
• obviyus: Recent merged PRs added browser release images and main/latest alias behavior that this PR extends to Docker Hub. (role: recent Docker release workflow contributor; confidence: medium; commits: dc31f73b394a, 3cb7ae535036; files: .github/workflows/docker-release.yml, src/dockerfile.test.ts)
• steipete: History shows Docker attestation setup, attestation verification, and runtime-template Docker packaging in the same release surface. (role: adjacent Docker release and attestation contributor; confidence: medium; commits: 824c3e2b71a1, b61954919c2c, 659b5dce79ee; files: .github/workflows/docker-release.yml, scripts/verify-docker-attestations.mjs, src/dockerfile.test.ts)
• onutc: Merged history added manual Docker release backfills and the rule that backfills keep latest aliases unchanged, which this PR updates for beta and Docker Hub paths. (role: manual backfill behavior contributor; confidence: medium; commits: 9fbcb81a8375, df0c06b98bac, 41bbea91bfcc; files: .github/workflows/docker-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.