GeezerVison

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

Fixes #1799

Summary

If GOFLAGS contains -modfile=<file>, go builds from <file> and its .sum and ignores the replaces in go.mod. This works whether GOFLAGS is set in the environment or with go env -w. Before this change, socket-patch still wrote its replace into go.mod, apply reported the patch applied, apply --check said it was in sync, and vex attested not_affected. The build linked the unpatched module. Now socket-patch refuses to write the replace and refuses to attest it, the same way it already handles a go.work that overrides the replace.

Root cause

socket-patch never read GOFLAGS. Every Go writer (agent apply, vendor, scan --mode hosted) edited go.mod/go.sum, and both --check and VEX discovery read only those files.

Fix

• utils::go_env::goflags_modfile reads -modfile from GOFLAGS the way go's InitGOFLAGS does:
  • fields are split as quoted.Split splits them;
  • flags may be written -flag or --flag;
  • the last -modfile wins, and -modfile= means go's default.
  • It also reports a setting go refuses outright: a non-flag field, a bare -modfile, or an unterminated quote.
• go_workspace::modfile_setting / modfile_conflict return a new WorkspaceConflict::ModFile in these cases:
  • -modfile names anything other than the project's go.mod. A relative path is taken from the project directory.
  • A go.work is in effect, where go refuses any -modfile.
  • GOFLAGS itself is one go refuses.
• That conflict goes through the gates that already fail closed on a go.work override. No new codes:
  • go_consumer_sync::replace_refusal: agent apply and vendor write nothing.
  • go_consumer_sync::audit / workspace_audit: apply --check and vendor --check fail with go_workspace_replace_ineffective, and vex omits the patch with go_workspace_override. This covers go.mod replaces and root go.work replaces. The message names go.work for the latter.
  • VEX discovery withholds every Go ref as patched_ref_invalid, as it does for a foreign GOWORK. The probe runs only when GOFLAGS sets -modfile (or is one go refuses). It declares the files it reads through disk_root_reading, so a tracked hosted pass keeps its read recording.
  • The hosted engine reads the setting for on-disk projects and passes it as HostedGoWorkspace.modfile. The rewriter then refuses with redirect_golang_workspace_conflict.
• CLI_CONTRACT.md and docs/ecosystems.md document the behavior.
• No wrapper changes are needed. npm/, pypi/ and gem/ only dispatch to the binary.

Tests (red → green)

Per-issue checklist:

• Go apply, apply --check and vex ignore GOFLAGS=-modfile, so they report a patch as applied while go builds from another go.mod and links the unpatched module #1799: agent apply (and its dry run), apply --check, vex (env and go env -w), all in the e2e test above. The vendored and hosted writers go through the same gate, covered by replace_refusal and golang_goflags_modfile_refuses_the_pin.

Local runs (0b99e93, then re-run at 801d50f):

• cargo fmt --all -- --check and cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test -p socket-patch-core --all-features --lib: 6928 passed. 4 failed, all chmod-based write-failure tests that can't fail as root in this container: copy_tree::relax_loop…, vlt_heal::an_unremovable…, pypi_poetry::wire_write_failure… and pypi_requirements::wire_failure…. None of them touch Go. hosted::engine::tests::a_writing_pass_hands_back_the_discovery_of_its_writes passes.
• socket-patch-core integration suites: 32 suites, 656 passed.
• Go e2e with SOCKET_PATCH_GO_E2E_REQUIRED=1 --include-ignored (go 1.24.7): e2e_golang_build 30, e2e_golang_workspace_build 28, e2e_golang_hosted_build 25, e2e_golang_hosted_state 30, e2e_vendor_golang_build 44, e2e_golang 23. All pass.
• CLI lib (936), plus e2e_vex, e2e_vex_redirect, e2e_vex_vendor, hosted_memory_engine, hosted_memory_parity, in_process_remote_ecosystems_apply, in_process_rollback_all_ecosystems, in_process_vendor, cli_apply_silent and ecosystem_dispatch_e2e: all pass.
• I didn't finish a full cargo test --workspace locally because the sandbox disk filled while linking every CLI test binary. CI runs it.

/code-review high

Fixed in 0b99e93:

• VEX discovery took a raw disk_root() read.
• In-memory discovery disagreed with the hosted engine. Both now skip in-memory projects.
• The quote splitting didn't match go's quoted.Split.
• Non-flag GOFLAGS fields weren't treated as a setting go refuses.
• The message named go.mod for a go.work replace.
• A relative GOWORK was counted as workspace mode.
• The conflict was converted back and forth to a string.

Not changed:

• Fold the gate into go_workspace::load/Loaded. Loaded describes the go.work in effect, and -modfile matters in module mode too. Mapping it to Loaded::Invalid/None would change every resolve() != GoWork::None "is this a workspace" check (selection gates, modules.txt location). I kept the rule in one function (modfile_setting_with) and called it at the existing fail-closed boundaries.
• go.work read twice in audit, and GOFLAGS re-read per module. Each is one small file read per module, only on --check/apply runs. I didn't think threading a resolved setting through every signature was worth it.

Bugbot

• 0b99e93: "GOFLAGS voids hosted discovery recording" (-modfile=go.mod still took the raw root read). Fixed in 801d50f, with a regression test.

https://claude.ai/code/session_011f9aePoQ9gtsKv1zP8Rxsg

Generated by Claude Code