fix(cli): report source install version

[steipete]

What changed

• resolve the displayed version from linker injection first, Go main-module build metadata second, and devel last
• use the resolved version for both CLI version forms, release checks, and remote user-agent strings
• add regression coverage for linker precedence, tagged and pseudo module versions, development fallback, CLI routes, release checks, and user agents
• document the fix in the Unreleased changelog

Why

Plain source and module installs reported the stale hard-coded version 0.11.2 after newer releases. This applies the pattern proven in openclaw/wacrawl#39 to Discrawl's larger version-consumer surface.

Fixes #132.

Proof

• GOWORK=off go test ./...
• focused version, CLI, release-check, and user-agent tests
• real GOBIN=<temp> GOWORK=off go install ./cmd/discrawl: both --version and version matched the module pseudo-version recorded by go version -m
• linker-stamped test build: both CLI forms reported 9.8.7
• source-blind behavior contract: PASS
• AutoReview: clean, no accepted/actionable findings, 0.95 confidence

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 16, 2026, 4:28 PM ET / 20:28 UTC.

Summary
The branch centralizes Discrawl version resolution from linker or Go module metadata and applies it to CLI output, release checks, and remote user-agent strings with regression coverage.

Reproducibility: yes. at source level: current main hard-codes 0.11.2 even though the repository's latest release is v0.11.5, so source-built binaries follow the stale value. The review did not independently execute a binary in this read-only environment.

Review metrics: 3 noteworthy metrics.

• Patch surface: 9 files; 76 additions, 11 deletions. The change is bounded to version consumers, focused tests, and one release-note entry.
• Version consumers: 6 call sites updated. CLI output, update checks, and all identified remote user-agent construction paths now share one resolver.
• Regression coverage: 1 test file added, 2 changed. Coverage spans resolver semantics and propagation through CLI and release-check behavior.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #132
Summary: This PR is the direct candidate fix for the linked source-installed-version bug.

Members:

• canonical: Source-installed binaries report stale version #132 - The issue defines the same stale-version behavior, expected precedence, affected consumers, and acceptance proof implemented by this branch.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

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

Next step before merge

• [P2] No repair lane is needed because the existing branch already contains a focused, review-ready fix; only normal draft and check completion remains.

Security
Cleared: The diff adds no dependencies, workflow permissions, secret handling, downloaded code, or other concrete security or supply-chain concern.

Review details

Best possible solution:

Merge the centralized resolver after the draft is marked ready and required checks finish, then let the linked issue close through the PR relationship.

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

Yes at source level: current main hard-codes 0.11.2 even though the repository's latest release is v0.11.5, so source-built binaries follow the stale value. The review did not independently execute a binary in this read-only environment.

Is this the best way to solve the issue?

Yes. A single resolver with linker precedence, Go module metadata fallback, and shared consumers is narrower and less drift-prone than updating individual literals or call sites independently.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against 2a2ab86a2323.

Label changes

Label changes:

• add P2: This fixes incorrect version reporting and downstream metadata for source installs, with meaningful but limited CLI and remote-client impact.
• add rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The external-contributor proof gate does not apply to this collaborator-authored PR; the body nevertheless reports real module-install and linker-stamped binary validation.

Label justifications:

• P2: This fixes incorrect version reporting and downstream metadata for source installs, with meaningful but limited CLI and remote-client impact.
• rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The external-contributor proof gate does not apply to this collaborator-authored PR; the body nevertheless reports real module-install and linker-stamped binary validation.

Evidence reviewed

What I checked:

• Current-main bug remains: At base SHA 2a2ab86a232360801df73e2ce729627086389a96, internal/cli/version.go still defines the displayed version as the stale literal 0.11.2, so current main does not solve the linked source-install problem. (internal/cli/version.go:3, 2a2ab86a2323)
• Centralized version resolution: The PR resolves a non-empty linker value first, then the Go main-module version, strips a leading v, and falls back to devel. (internal/cli/version.go:8, 61bfc157f2b4)
• All known consumers updated: Both CLI version forms, release-check options, cloud publishing, remote login, and general remote clients now use the resolved version rather than the stale variable directly. (internal/cli/cli.go:59, 61bfc157f2b4)
• Focused regression coverage: Tests cover linker precedence, tagged and pseudo module versions, development fallbacks, both CLI routes, release-check propagation, and user-agent construction. (internal/cli/version_test.go:5, 61bfc157f2b4)
• Release mismatch confirms impact: Repository context identifies v0.11.5 at 6dbb9e2c5e8eb9fc5ece02f161ffb747686594f8 as the latest release, three releases newer than the hard-coded value on the PR base. (CHANGELOG.md:11, 6dbb9e2c5e8e)
• Real runtime validation reported: The PR body reports a module-install-style build whose CLI output matched go version -m, plus a linker-stamped build where both version forms returned 9.8.7. (61bfc157f2b4)

Likely related people:

• steipete: Repository package metadata identifies Peter Steinberger with Discrawl, the GitHub context marks steipete as a collaborator, and this commit updates every current CLI version consumer plus the linked report; exact earlier-file blame was unavailable, so routing confidence is medium. (role: CLI and release-version contributor; confidence: medium; commits: 61bfc157f2b4; files: internal/cli/version.go, internal/cli/cli.go, internal/cli/releasecheck.go)

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.