GeezerVison

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

Fixes #393
Fixes #458
Fixes #531

Summary

In a Go workspace, apply and vendor no longer write a go.mod replace
that the go.work in effect would override, ignore or reject. apply --check
and vendor --check now fail on such a replace that was written earlier, and
vex no longer attests the patch as not_affected.

Shared root cause

Every Go mode wires a patch by writing a replace into the project's own
go.mod. Every check (apply --check, vendor --check, VEX) then treated
that line as effective, and none of them asked which go.work the go command
uses. In workspace mode Go:

• lets a go.work replace of the module, for any version, override every
  member's replace (A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393). The build links the user's target;
• ignores the go.mod of a module the go.work doesn't use (Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458). The
  build stays unpatched;
• rejects two members that replace the same module@version with different
  targets (Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531). The whole workspace stops building.

In all three cases socket-patch exited 0, --check said "in sync" and VEX
attested not_affected.

Fix (one shared boundary)

vendor::go_consumer_sync already knew how to find the workspace for its
vendor/modules.txt audit. It now:

• loads the go.work in effect once: GOWORK from the environment or from
  go env -w, otherwise the nearest go.work at or above the project. It
  reads go.work's replaces, its use members and each member's replaces;
• gets workspace_conflict / replace_refusal, which decide which of the
  three cases applies to a module@version replace, matching go's own rules:
  • any go.work replace of the module path drops every member replace, unless
    go.work's own replace for this version sends it to the project's copy;
  • membership is compared on resolved directories;
  • targets are compared lexically, as go compares replacements;
  • a hosted replace names the same Socket module in every member, so it
    never conflicts.

Callers:

• Agent apply (golang_local::apply_go_redirect) and vendor
  (vendor::golang::vendor_go_module, new code vendor_go_workspace_conflict)
  refuse before copying or fetching anything. Dry runs and re-runs over an
  inert replace therefore refuse too, and no orphan copy is left.
  go_mod_edit::ensure_replace_entry refuses as well, as a second guard.
• audit reports a replace that was already written as
  go_workspace_replace_ineffective. As a result apply --check and
  vendor --check fail, and apply, vendor and scan --mode hosted warn.
• vex leaves the patch out with the new omission tag
  go_workspace_override, plus the warning.

Docs: docs/ecosystems.md (new "Go workspaces (go.work)" section) and the
golang entry in CLI_CONTRACT.md. No wrapper changes: the npm, pypi and gem
wrappers only dispatch to the binary.

Per-issue tests (red on main → green)

The three e2e tests below use the real go toolchain with a hermetic file
GOPROXY. On main (fix stashed) all three fail at the first assertion: apply
exits 0. With the fix they pass.

• A user replace in go.work silently overrides the Socket go.mod replace: Go apply and vendor report success and VEX attests not_affected while the build links the user's target #393: e2e_golang_build::go_work_replace_overrides_the_socket_replace.
  A go.work replace to ../fork makes apply --dry-run, apply and a re-run
  refuse. go.mod is untouched, no copy is left, and the build still links
  FORK. For a replace written before the go.work: apply --check exits 1 and
  vex omits it with go_workspace_override. Unit test:
  go_consumer_sync::go_work_replace_of_the_module_makes_the_replace_inert
  (versioned, version-less, other-version and module replaces; ours moved
  into go.work is fine).
• Go apply writes its replace into a root go.mod that go.work doesn't use, so the workspace build links the unpatched module while apply, apply --check and VEX all report it patched #458: e2e_golang_build::go_work_without_the_project_ignores_its_replace.
  With go.work: use ./svc, apply refuses. A replace written earlier fails
  --check and is omitted from VEX. Positive control: after use (. ./svc)
  the svc build prints PATCHED and --check passes. Unit test:
  go_work_that_does_not_use_the_project_makes_the_replace_inert (ancestor
  go.work, and every spelling of the member path).
• Running Go apply in a second go.work member writes a second replace for the same module@version, so every workspace build fails with "conflicting replacements" while apply, apply --check and VEX all report success #531: e2e_golang_build::go_work_member_replaces_must_not_conflict.
  Applying in member a patches the workspace. Applying in b refuses, and
  the workspace still builds PATCHED. Replaces written in both members before
  the go.work existed reproduce "conflicting replacements", fail --check in
  both members and are omitted from VEX. Unit test:
  member_replaces_of_one_module_version_must_agree (same target, other
  version and hosted replaces don't conflict).
• Also: go_work_replace_is_judged_by_where_it_points (from review) and
  go_mod_edit::test_ensure_refuses_a_replace_go_work_defeats (all three
  cases, dry run included, go.mod unchanged).

Commands run

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test -p socket-patch-core --all-features: 6276 passed. The 4 that failed are read-only-permission tests that can't fail as root in this sandbox (copy_tree, vlt_heal, pypi_poetry, pypi_requirements); they're unrelated to Go. A full cargo test --workspace --all-features build ran out of the sandbox's disk allowance, so CI runs the rest
• cargo test -p socket-patch-cli --all-features --lib --bins: 911 passed
• cargo test -p socket-patch-cli --all-features --test e2e_vex_lockfile --test covgap_commands_vex --test e2e_vex_vendor --test e2e_vex_redirect --test covgap_commands_rollback: all pass
• SOCKET_PATCH_GO_E2E_REQUIRED=1 cargo test -p socket-patch-cli --all-features --test e2e_golang_build --test e2e_golang_workspace_build --test e2e_vendor_golang_build --test e2e_golang_hosted_build --test e2e_golang: all pass (go 1.24.7)

/code-review high findings

Fixed in 1413d3c:

• The go.work exemption was keyed on socket_owned; it now compares the
  actual target.
• When go.work's own replace was exempted, member checks still ran.
• The check ran after the copy, which skipped dry runs and left orphan
  copies.
• vendor re-runs used a misleading error code.
• go env -w GOWORK was ignored. Bugbot then pointed out that my own env-file reader mishandled an empty GOWORK and skipped the regular-file guard; e91342d switches to the shared utils::go_env.
• Each replace caused another read of the workspace (N×M reads), duplicating
  workspace_replaces.
• Symlink canonicalisation of targets didn't match go's lexical comparison.

Not fixed: the hosted writer doesn't refuse. scan --mode hosted rewrites
through the pure, in-memory rewrite_golang, which only sees project-relative
file contents and can't look at an ancestor or GOWORK go.work. Hosted mode
is covered by the post-write warning, the --check failure and the VEX
omission, so it never makes a false attestation. A write-time refusal there
needs the go.work context passed into the rewriter. That's left as a
follow-up rather than widening this PR. For #531 hosted mode was never
affected: identical module replaces don't conflict.

🤖 Generated with Claude Code

https://claude.ai/code/session_018LqNhpS1viyHzW6Jmp3Wuq

Generated by Claude Code