ci: add deadcode check

[vincentkoc]

Summary

• add an enforced Go deadcode CI gate pinned to golang.org/x/tools/cmd/deadcode@v0.45.0
• make the workflow fail when deadcode emits findings
• bump the Go directive to the patched 1.26.4 toolchain so existing govulncheck stays green

Validation

• git diff --check
• go run golang.org/x/tools/cmd/deadcode@v0.45.0 -test ./...
• GOTOOLCHAIN=go1.26.4+auto go test -count=1 ./...
• GOTOOLCHAIN=go1.26.4+auto go run golang.org/x/vuln/cmd/govulncheck@v1.3.0 ./...
• go build ./cmd/discrawl
• autoreview --mode branch --base origin/main --no-web-search --thinking low clean

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 7, 2026, 11:40 PM ET / 03:40 UTC.

Summary
The PR adds a pinned Go deadcode check to CI and bumps the Go directive from 1.26.3 to 1.26.4.

Reproducibility: not applicable. this is a CI cleanup PR, not a user-facing bug report. The relevant check is whether the PR head passes the new workflow gate.

Review metrics: 2 noteworthy metrics.

• CI gate added: 1 analyzer install and 1 fail-closed step added. The PR changes the lint job from advisory analyzer coverage to a new blocking deadcode gate.
• Protected files touched: 2 CODEOWNERS-protected files changed. Both .github/workflows/ci.yml and go.mod are owned by @openclaw/openclaw-secops.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

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

Rank-up moves:

• [P2] Wait for CI on the current head to prove the new deadcode gate.
• [P2] Get the protected CI/toolchain owner review required for the touched paths.

Risk before merge

• [P1] Merging intentionally changes CI policy by adding a fail-closed deadcode analyzer and raising the Go version used by go-version-file workflow setup, so protected CI/toolchain owners should explicitly accept that behavior.
• [P1] This read-only review did not execute the new analyzer or workflow; the PR body lists validation commands, but CI should prove the exact head before merge.

Maintainer options:

1. Accept after CI owner review (recommended)
   If required checks pass and @openclaw/openclaw-secops accepts the new fail-closed analyzer gate and Go patch bump, this can land as-is.
2. Soften or defer enforcement
   If maintainers are not ready for a blocking deadcode policy, keep the analyzer non-blocking or pause the PR until the CI policy is settled.

Next step before merge

• [P2] This member-authored draft touches CODEOWNERS-protected CI and module toolchain files, so the next action is normal protected-owner review rather than a repair branch.

Security
Cleared: No concrete security or supply-chain regression was found; the new Go tool install is version-pinned and workflow permissions stay read-only.

Review details

Best possible solution:

Land the new deadcode gate only after the protected CI/toolchain owners accept the enforcement policy and CI passes on the current PR head.

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

Not applicable: this is a CI cleanup PR, not a user-facing bug report. The relevant check is whether the PR head passes the new workflow gate.

Is this the best way to solve the issue?

Yes: placing the check in the existing lint job is the narrow maintainable path if maintainers want deadcode to be enforced. The only safer alternative is to make it non-blocking until the CI policy is accepted.

AGENTS.md: not found in the target repository.

Codex review notes: model gpt-5.5, reasoning high; reviewed against f1ca1ceabac1.

Label changes

Label changes:

• add merge-risk: 🚨 automation: The diff changes CI automation by adding a new blocking analyzer gate and changing the Go version selected by workflow setup.

Label justifications:

• P3: This is a low-risk CI cleanup PR rather than a user-facing runtime change.
• merge-risk: 🚨 automation: The diff changes CI automation by adding a new blocking analyzer gate and changing the Go version selected by workflow setup.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a member-authored PR, so the external contributor real-behavior proof gate does not apply.

Evidence reviewed

What I checked:

• PR head adds the deadcode gate: At the PR head, the lint job installs golang.org/x/tools/cmd/deadcode@v0.45.0 and adds a Deadcode step that fails when the tool emits output. (.github/workflows/ci.yml:40, 55df94f1dca0)
• PR head bumps the Go directive: At the PR head, go.mod declares go 1.26.4, which setup-go will use through go-version-file in the workflows. (go.mod:3, 55df94f1dca0)
• Current main does not already include this check: Current main has staticcheck, gofumpt, gosec, and govulncheck references, but no deadcode reference, so the PR is not obsolete on main. (.github/workflows/ci.yml:37, f1ca1ceabac1)
• Touched paths are CODEOWNERS-protected: CODEOWNERS assigns /.github/workflows/ and /go.mod to @openclaw/openclaw-secops, so this CI/toolchain change should receive protected-owner review before merge. (.github/CODEOWNERS:4, f1ca1ceabac1)
• Security-sensitive workflow sweep: The PR head keeps workflow permissions at contents: read and pins the new analyzer install to an exact Go module version; no new secret use or pull_request_target trigger was introduced. (.github/workflows/ci.yml:9, 55df94f1dca0)
• CI/toolchain history: The existing analyzer and Go toolchain patterns trace through prior main commits by Peter Steinberger and recent current-main baseline commits by vincentkoc. (.github/workflows/ci.yml:35, e0e487fbd0a9)

Likely related people:

• Peter Steinberger: Git history shows Peter added the existing extra analyzer gate and prior Go toolchain bumps that this PR extends. (role: introduced analyzer/toolchain behavior; confidence: high; commits: e0e487fbd0a9, 733714a5e7ea, 7519bcb1b922; files: .github/workflows/ci.yml, go.mod)
• vincentkoc: Recent current-main commits changed go.mod and the CI workflow area, including the current checked-out baseline for both files. (role: recent area contributor; confidence: medium; commits: dcf0c9c8dbb3, 09e3701ca01c; files: .github/workflows/ci.yml, go.mod)

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.