fix: rename Go module to openclaw

[steipete]

Summary

• rename the Go module and every internal import to github.com/openclaw/gogcli
• update build, lint, release, Docker, generator, and test paths that embed the module identity
• document go install github.com/openclaw/gogcli/cmd/gog@latest and add the migration to the changelog

Compatibility

Pinned existing tags continue to work through the former module path because those tags still declare it. The first post-rename tag and all later versions require github.com/openclaw/gogcli; an old-path @latest install will fail once it selects a renamed tag. Conversely, new-path @latest starts working with the first post-rename tag. This PR does not move tags or publish a release.

Proof

• make ci
• clean temporary module/build cache: go build ./... and go vet ./...
• neutral consumer module with a local replacement built and ran the public cmd/gog command
• remote cold-cache install by commit resolved v0.34.3-0.20260809055158-706697b0a53c
• built binary: --version, --help, and --readonly auth services --json
• source-blind behavior validation: 5/5 clauses and 3/3 probes passed
• autoreview clean before opening

[clawsweeper]

Codex review: found issues before merge. Reviewed August 9, 2026, 2:01 AM ET / 06:01 UTC.

ClawSweeper review

What this changes

This PR renames the Go module and its source, build, release, test, and installation references to github.com/openclaw/gogcli.

Merge readiness

⚠️ Ready for maintainer review - 4 items remain

Keep open for maintainer review: current main and the latest release still use the former module identity, while this collaborator PR deliberately makes its @latest install path stop working after the next release.

Priority: P2
Reviewed head: 706697b0a53c647d02c6fea13343961c8ca85fe4
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The mechanical migration is broad and well-scoped, but its deliberate install-compatibility break needs maintainer release approval.
Proof confidence	🌊 off-meta tidepool	Not applicable: This collaborator PR is not subject to the external-contributor real-behavior-proof gate; its stated build and consumer checks remain useful supplemental validation.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This collaborator PR is not subject to the external-contributor real-behavior-proof gate; its stated build and consumer checks remain useful supplemental validation.
Evidence reviewed	5 items	Current main module identity: Current main declares the former Go module path, so the requested rename is not already implemented. Current build and release coupling: Current main still embeds the former module path in GoReleaser, Makefile, Docker, safe-build, command-entrypoint, and architecture-test surfaces; 579 tracked files contain that identity. Release state: The latest release is v0.34.1 at commit 4747fb0; current main identifies as v0.34.2-16-g69e2e65, and the reviewed PR is not on either revision.
Findings	1 actionable finding	[P1] Get explicit approval for the old module-path break
Security	None	None.

How this fits together

The module path identifies this Go CLI to source imports, Go package resolution, build linker flags, and release tooling. Those paths determine how users install the gog binary and how release builds embed version information.

flowchart LR
  Module[Go module identity] --> Imports[Source imports]
  Imports --> Builds[Local and release builds]
  Module --> Install[Go install resolution]
  Builds --> Releases[Release artifacts]
  Install --> Users[CLI users and automation]
  Releases --> Users

Loading

Decision needed

Question	Recommendation
Should the next release intentionally discontinue the former Go module path, knowing its @latest install command will stop working?	Approve the documented module migration: Accept the one-time old-path break and make the replacement command and migration prominent in install and release guidance.

Why: The source change is mechanically coherent, but whether to accept a breaking installation path is a release and compatibility policy choice that code review cannot determine.

Before merge

• Get explicit approval for the old module-path break (P1) - Changing the module declaration makes the first post-rename release incompatible with automated installs using the former go install github.com/steipete/gogcli/cmd/gog@latest command; the PR body confirms that it will fail. Obtain an explicit release/migration decision, or retain the former module identity, before merging this breaking change.
• Resolve merge risk (P1) - After the first renamed release, scripts and users running the former go install github.com/steipete/gogcli/cmd/gog@latest command will fail rather than upgrade.
• Complete next step (P2) - A maintainer must choose the release compatibility policy; this is not a narrow automated repair.

Findings

• [P1] Get explicit approval for the old module-path break — go.mod:1

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Module identity sweep	583 files changed; +1,143 / -1,135 lines	The rename reaches production, test, build, release, and documentation surfaces, making its upgrade boundary important to review.

Merge-risk options

Maintainer options:

1. Approve the documented breaking migration (recommended)
   Accept the old-path install break only with a clear release decision and prominent migration instructions for users and automation.
2. Pause the migration
   Keep the former module path until maintainers want to make the upgrade break in a planned release.

Technical review

Best possible solution:

Make an explicit release decision on the breaking Go-module migration, then publish the supported replacement install command and migration guidance in the user-facing install and release material.

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

Not applicable as a bug: this is an intentional module-identity migration, and the relevant validation is fresh-install and upgrade behavior.

Is this the best way to solve the issue?

Unclear until maintainers decide whether the intentional old-path break is acceptable; the mechanical rename is appropriate only after that release policy is confirmed.

Full review comments:

• [P1] Get explicit approval for the old module-path break — go.mod:1
  Changing the module declaration makes the first post-rename release incompatible with automated installs using the former go install github.com/steipete/gogcli/cmd/gog@latest command; the PR body confirms that it will fail. Obtain an explicit release/migration decision, or retain the former module identity, before merging this breaking change.
  Confidence: 0.98

Overall correctness: patch is incorrect
Overall confidence: 0.96

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 69e2e6555a13.

Labels

Label changes:

• add P2: This is a deliberate compatibility-affecting installation migration without evidence of a current runtime outage.
• add merge-risk: 🚨 compatibility: The PR states that the former go install ...@latest path will fail after the first renamed release.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This collaborator PR is not subject to the external-contributor real-behavior-proof gate; its stated build and consumer checks remain useful supplemental validation.

Label justifications:

• P2: This is a deliberate compatibility-affecting installation migration without evidence of a current runtime outage.
• merge-risk: 🚨 compatibility: The PR states that the former go install ...@latest path will fail after the first renamed release.
• 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 collaborator PR is not subject to the external-contributor real-behavior-proof gate; its stated build and consumer checks remain useful supplemental validation.

Evidence

What I checked:

• Current main module identity: Current main declares the former Go module path, so the requested rename is not already implemented. (go.mod:1, 69e2e6555a13)
• Current build and release coupling: Current main still embeds the former module path in GoReleaser, Makefile, Docker, safe-build, command-entrypoint, and architecture-test surfaces; 579 tracked files contain that identity. (.goreleaser.yaml:26, 69e2e6555a13)
• Release state: The latest release is v0.34.1 at commit 4747fb0; current main identifies as v0.34.2-16-g69e2e65, and the reviewed PR is not on either revision. (4747fb05a429)
• Relevant current-main history: Peter Steinberger most recently touched the module file, release workflow, and README surfaces that the migration changes. (go.mod:1, 69e2e6555a13)
• PR compatibility boundary: The PR description expressly states that the first renamed release makes the former go install ...@latest command fail, while enabling the new module path. (go.mod:1, 706697b0a53c)

Likely related people:

• Peter Steinberger: Current-main history attributes the latest module, release-workflow, and README changes to Peter Steinberger. (role: recent release, build, and documentation contributor; confidence: high; commits: 69e2e6555a13, 1c5a1ec15fa8, 0a3ebe9ad788; files: go.mod, .goreleaser.yaml, README.md)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Record the maintainer decision on the former module path and ensure the release-facing migration guidance matches it.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

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