Source-installed binaries report stale version

[steipete]

Problem

Source-built Discrawl binaries report the stale hard-coded version 0.11.2, even though the latest release is v0.11.5.

This affects plain source builds and module installs. It also risks passing an empty or stale value into release checks and remote user-agent strings once the hard-coded fallback is removed.

The same bug class was fixed in openclaw/wacrawl#39.

Expected behavior

• Prefer a non-empty linker-injected release version.
• Otherwise use the main module version from Go build metadata.
• Strip a leading v from either source.
• Return devel when build metadata is missing or reports (devel).
• Use the resolved value for both CLI version paths, release checks, and Discrawl user-agent strings.

Acceptance proof

• Regression tests cover linker precedence, tagged and pseudo module versions, (devel), and missing metadata.
• Both discrawl --version and discrawl version report the resolved value.
• A real module-install-style build reports its module version instead of 0.11.2.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 16, 2026, 5:34 PM ET / 21:34 UTC.

Summary
The report describes a current bug in a documented source-install workflow, and the open, cleanly mergeable pull request at #133 explicitly owns the fix. This issue should remain open until that PR merges; it is also collaborator-authored and therefore requires explicit maintainer handling.

Reproducibility: yes. at source level: the documented source-build path exercises the affected version command, and the linked PR describes the concrete stale fallback and real module-install reproduction. This read-only review did not independently execute the build.

Next step
Do not dispatch a second fix PR because the collaborator-authored linked PR already owns the implementation; review and land or close that candidate first.

Review details

Best possible solution:

Land one canonical tested resolver through #133, verify both CLI forms plus release-check and user-agent consumers, and then let the merged closing reference resolve this issue.

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

Yes at source level: the documented source-build path exercises the affected version command, and the linked PR describes the concrete stale fallback and real module-install reproduction. This read-only review did not independently execute the build.

Is this the best way to solve the issue?

Yes: one shared resolver with linker precedence, Go main-module metadata fallback, normalization, and a devel fallback is narrower and safer than updating another hard-coded constant, provided every existing consumer uses it.

AGENTS.md: not found in the target repository.

Remaining risk / open question:

• Closing before fix(cli): report source install version #133 merges would leave the documented source-install workflow unfixed on current main.
• A partial CLI-only repair could leave release checks or remote user-agent strings using an empty or inconsistent version.

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

Label changes

Label changes:

• add P2: A supported source-install workflow reports incorrect version identity across several bounded consumers, but the core runtime remains usable.
• add impact:other: The bug affects CLI diagnostics, release checks, and remote user-agent identity without matching a more specific owned impact category.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.

Label justifications:

• P2: A supported source-install workflow reports incorrect version identity across several bounded consumers, but the core runtime remains usable.
• impact:other: The bug affects CLI diagnostics, release checks, and remote user-agent identity without matching a more specific owned impact category.

Evidence reviewed

What I checked:

• Documented affected workflow: Current documentation instructs users to build ./cmd/discrawl from source and immediately run ./bin/discrawl --version, establishing correct source-build version output as supported behavior. (README.md:401, 2a2ab86a2323)
• Release version mismatch: The latest supplied release is v0.11.5, while the report identifies 0.11.2 as the hard-coded value returned by source-built binaries. (CHANGELOG.md:5, 6dbb9e2c5e8e)
• Open implementation candidate: The linked draft PR is open and cleanly mergeable, uses closing syntax for this issue, and reports real module-install and linker-stamped terminal proof for the requested behavior. (61bfc157f2b4)
• Fix remains outside current main: The supplied current-main SHA is the linked PR's base and differs from its head, so the proposed version resolver has not merged into main or shipped in v0.11.5. (2a2ab86a2323)
• Protected authorship state: The GitHub context identifies the issue author as a repository collaborator, which requires keeping the item open for explicit maintainer handling.

Likely related people:

• steipete: The collaborator reported the exact affected version-consumer surface and authored the focused linked implementation candidate. (role: feature owner and linked fix proposer; confidence: high; commits: 61bfc157f2b4; files: cmd/discrawl/main.go, cmd/discrawl/main_test.go, README.md)
• vincentkoc: Recent repository history shows substantial work on remote and cloud request paths, making this person a useful secondary reviewer for affected user-agent consumers. (role: recent adjacent contributor; confidence: medium; commits: dcf0c9c, 09e3701, f01e699; files: internal/cli, internal/share)

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.

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this issue: Source-installed binaries report stale version This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.