[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1751

Summary

In a go.work workspace, Go builds the highest version of a module that any use member requires. The Go version check behind agent apply, apply --check, vendor and vex read only the current module's go.mod/go.sum. So when another member required a newer version, apply wrote a replace the build ignored, apply --check said "in sync", and vex attested not_affected while the workspace linked the unpatched module.

Root cause

go_build_list::project_selection trusted the member's own require. In workspace mode it only relaxed NotInGraph to Unknown, never looking at what other members select.

Fix

• project_selection now also reads every use member's go.mod/go.sum (go_consumer_sync::workspace_member_dirs, which shares go.work parsing with the existing conflict check). It weighs the versions they prove the way MVS does: a higher version anywhere is Other(v), and the patched version proven anywhere is Selected. When every member proves a lower version and none is undecided, that version is reported.
• Every caller picks this up: agent apply and vendor refuse, apply --check fails, and vex omits the patch with go_version_not_selected. That includes hosted pins, since vex checks every Socket-owned replace.
• docs/ecosystems.md says which commands read the other members.

Follow-up (not in this PR)

The hosted write gate (rewrite_golang in patch/redirect/mod.rs) is an in-memory rewriter that only sees the root module's files, so scan --mode hosted in a member can still write a pin another member outranks. vex no longer attests it. Tracked in #1753. Fixing it means feeding member files into the hosted read set, which is a separate change to the hosted pipeline.

Test evidence

Issue	Test	Without fix	With fix
#1751	go_build_list::tests::workspace_member_requiring_a_higher_version_wins	FAIL (Selected)	ok
#1751	go_build_list::tests::workspace_lower_or_unused_members_do_not_change_the_selection	FAIL	ok
#1751	go_build_list::tests::workspace_lower_versions_decide_only_without_unknown_members	n/a (review follow-up)	ok
#1751	e2e_golang_build::go_work_member_requiring_a_newer_version_makes_the_replace_inert (real go 1.24.7: apply refuses, --check exits 1, vex omits with go_version_not_selected, positive control)	FAIL (apply exit 0)	ok

Commands run locally:

• cargo fmt --all -- --check: ok

• cargo clippy --workspace --all-features -- -D warnings: ok

• SOCKET_PATCH_GO_E2E_REQUIRED=1 cargo test --workspace --all-features --no-fail-fast: 15078 passed, 12 failed. All Go, vendor and vex suites pass (e2e_golang 23, e2e_golang_build 28, e2e_golang_hosted_build 22, e2e_golang_hosted_state 29, e2e_golang_workspace_build 16, e2e_vendor_golang_build 38, vendor 151, vex 47). The 12 failures are outside this diff and come from this container:

  • 9 write-failure tests (copy_tree, vlt_heal, pypi_poetry/requirements wire failures, in_process_redirect, repair) rely on chmod denying writes, and the container runs as root.
  • 3 in e2e_bun_lockb run with local bun 1.4.4, while CI pins 1.4.2.

  CI runs these suites on the PR.

• CI on ac7071b: 32 success, 50 skipped by path filters, Bugbot clean. The Go patch compatibility workflow (multi-Go-release matrix) is disabled in this repo, so it did not run and workflow_dispatch returns 422. The same suites passed locally on go 1.24.7 (above).

• No wrapper (npm/, pypi/, gem/) changes: they only dispatch to the binary.

/code-review high findings not fixed

• Hosted rewriter still single-module: out of scope, tracked in Hosted Go scan in a go.work member pins a version another member outranks #1753 (see above).
• A newer version that enters only through another member's dependency, which that member doesn't import: project_selection reads go.mod/go.sum evidence only, the same limit as the single-module check (a pruned graph trusts require). Seeing it would mean reading dependency go.mod files from the module cache.
• Re-reading member files on each call: one go.mod/go.sum read per member per patched module, offline. That is negligible next to apply/vex I/O, so caching isn't worth the code.
• Unit tests read the ambient GOWORK: the same dependency as the existing go.work tests in go_consumer_sync. CI doesn't set it.

https://claude.ai/code/session_011f9aePrKGvQCvZ5cTmj8ZB

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit ac7071b. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at head ac7071b.

• CI: 82/82 checks on ac7071b passed or skipped (32 success, 50 skipped by path filters). Mergeable with main; no main-wide failures.
• Bugbot: reviewed ac7071b, no issues found. No open review threads.
• Reviewer focus: go_build_list::project_selection now weighs every go.work member's go.mod/go.sum MVS-style; the hosted write gate is left to Hosted Go scan in a go.work member pins a version another member outranks #1753.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. In a go.work workspace, Go builds the highest version of a module that any use member requires. The Go version gate behind apply, apply --check, vendor and vex now reads every member's go.mod/go.sum. Before, it read only the current module's files, so a member requiring a newer version made the Socket replace inert without anyone noticing. Fixes #1751.

Risk: low. The change is limited to project_selection. Its callers act only on Selection::Other, so the most it can do is refuse or flag more. It can't attest anything new. The read is offline: one go.mod/go.sum per member. Outside a workspace nothing changes.

Look here

• go_build_list.rs:117-151:`` the MVS-style merge. A higher version anywhere gives Other, and a lower one counts only when no member is `Unknown`.
• go_consumer_sync.rs:304:``` workspace_member_dirs, which shares go.work parsing with the existing conflict check.
• vex.rs:1003: the vex caller, unchanged. It drops only proven Other.
• e2e_golang_build.rs:992: real-go e2e covering apply refusing, --check exiting 1, vex omitting the patch, and a positive control.

Verified

• Read the full diff and traced every project_selection caller (vex, golang_local drift and write gates).
• cargo test -p socket-patch-core --lib go_build_list: 10/10 passed.
• SOCKET_PATCH_GO_E2E_REQUIRED=1 cargo test -p socket-patch-cli --test e2e_golang_build go_work on go 1.24.7: 4/4 passed. CI doesn't run the Go e2e because the Go compatibility workflow is disabled, so this local run is the only e2e evidence.
• CI on ac7071b: 32 passed, 50 skipped by path filters, 0 failed. Bugbot clean. CHANGELOG.md untouched.

Changes I made. None.

Open questions. None blocking. Known limits are in the PR description: the hosted rewriter is still single-module (#1753, and vex no longer attests those pins), and a newer version that enters only through a member's dependency isn't seen.

Auto-merge is armed, so approving sends this straight to the merge queue.

---

Generated by Claude Code