GeezerVison

When nothing imports a package from a hosted-patched Go module (it is
only a transitive requirement), `go mod tidy` keeps just the socket
module's `/go.mod` go.sum line and drops its zip line. The build still
succeeds offline, but VEX discovery required both lines, so the patch
was skipped as `package_not_found` instead of attested.

The `/go.mod` line for the exact socket module+version is now enough to
recognise the pin. Without the zip line the ref has no locked integrity
and is not integrity-required, so it attests from the lockfile: go
compiles none of the module's packages, and the module path carries
the patch uuid. A zip line, when present, must still be the single
well-formed hash and supplies `locked_integrity`. Conflicting hashes or
a malformed line for the socket module+version still mean no pin.

The hosted writer is unchanged: it still writes both lines and refuses
a module outside the build graph.

Assisted-by: Claude Code:claude-opus-5-5

A `/go.mod`-only go.sum line also exists for versions MVS reads but
does not select, so in a go < 1.17 graph a `/go.mod`-only hosted pin
whose version go.sum shows is not selected is now reported as inert
instead of attested.

In workspace mode go verifies against go.work.sum and every member's
go.sum, so discovery now reads those too (in-root members only) and a
member's zip line still supplies the locked integrity.

go.sum parsing now follows go: a line of other than three tokens makes
the whole file unusable, a non-dirhash `h1:` breaks that module's pin,
and hashes of other algorithms are ignored.

Re-running the hosted rewrite over a project `go mod tidy` pruned to
the `/go.mod` line now leaves go.sum alone instead of re-adding the zip
line the next tidy removes again.

Assisted-by: Claude Code:claude-opus-5-5

Assisted-by: Claude Code:claude-opus-5-5

In a go.work workspace, Go builds the highest version any `use` member
requires. A Socket replace whose go.sum held only the `/go.mod` line
was still attested when another member required a newer version, so
VEX could claim a patch that no build links. Such a pin now attests
only when every member's go.mod is inside the project and readable and
together they select the replaced version; otherwise it is flagged as
inert or left unattested.

Pins are also looked up only in the sum files Go actually reads: in a
workspace, go.work.sum and the members' go.sum (the root go.sum only
when `.` is a member); with GOWORK=off, the root go.sum alone, and the
go.work replaces are ignored as Go ignores them.

Assisted-by: Claude Code:claude-opus-5-5

`go mod tidy` drops the Socket module's zip checksum line while no
package of the patched module is imported. If the project later
imports it, the build fails with "missing go.sum entry", and
re-running `scan --mode hosted` left that state untouched, so the
project had no supported way back. A re-run now always writes both
go.sum lines, so it repairs the project and the build uses the patched
module again. The trade-off is that the next `go mod tidy` may drop
the line again while the module stays unimported.

Assisted-by: Claude Code:claude-opus-5-5

A go.work build never makes a member's go.mod list the versions it
builds, and it adds missing checksums to go.work.sum on its own. So a
member's dependency can pull in a newer version of a patched module
than any committed file names, and the build links the unpatched
module. vex used to attest such a pin from the lockfile whenever the
members' go.mod files named the patched version.

In a workspace a pin with only the /go.mod line now needs a verifying
installed copy, and a newer version in a member's require or in any
recorded zip line marks the replace as inert. Docs and the CLI contract
say so, and a real-go test covers the member dependency case.

Assisted-by: Claude Code:claude-opus-5-5

go only ever appends to go.work.sum: once a member stops depending on
whatever raised a module, the zip line of the higher version stays
behind. vex treated such a line as proof the workspace builds that
version, so it dropped a Go /go.mod-only pin as inert even when go
builds the patched version.

Only a member's require or the zip lines of a member's go.sum now mark
a workspace pin inert. The pin still needs a verifying installed copy
to attest.

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

A workspace's sum files are only appended to, so the socket zip line a
past build wrote to go.work.sum (or a member go.sum) stays after a member
starts requiring a higher version of the replaced module. Go then builds
that higher version and the replace is inert, but discovery attested the
zip-pinned ref from the lockfile anyway, and the CLI's post-gate reads
only the root go.mod and go.sum, so vex claimed a patch the build never
links. Run the same inert check GoModOnly pins already get on Zip pins
in workspace mode.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Each Go command checked go.work its own way, and some of those checks
disagreed with go. A replace pinned to v1.0.0 counted as patched even
when another workspace member required v1.1.0, so go built the newer,
unpatched version while apply, vendor and vex treated it as fixed. A
go.work replace of a different version was taken to override a
member's replace, though go still uses the member's. GOWORK=auto was
treated as a file name, and a relative GOWORK, which go rejects, was
read as if it were in effect.

Every Go path now asks one workspace model. It finds go.work as go
does, picks the version the whole workspace builds from all members'
requirements, and applies go's replace precedence. A member go.mod
that can't be read leaves the answer unknown, so nothing is attested
on a guess. VEX now also reads member go.mod files from a go.work root
that has no go.mod of its own, and apply and vendor refuse there and
name the members to run them in.

Assisted-by: Claude Code:claude-opus-5-5

`scan --mode hosted` wrote a Go replace without looking at the go.work
in effect, and only warned afterwards. A replace that conflicted with
another member's broke every build in the workspace, and one that
go.work overrode was reported as redirected while go built something
else.

Hosted mode now checks the workspace before writing. A replace go.work
would override, ignore or reject is not written, the run warns
`redirect_golang_workspace_conflict`, and the patch is not reported
as redirected. The version check uses the whole workspace too, so a
member that doesn't require the module can still carry the replace
when another member does, and one that raises it to a newer version
refuses the pin. From a go.work root with no go.mod of its own, the
pin goes into each member that lists the module.

Assisted-by: Claude Code:claude-opus-5-5

`rollback` only looked at the root go.mod and go.sum. A hosted pin
in go.work was refused with a "restore it from version control"
error, the Socket module's lines that go writes to go.work.sum in
workspace mode were left behind, and a pin in a workspace member's
go.mod was not found from the workspace root.

The restore now edits the go.mod or go.work each pin was found in,
removes the Socket module's lines from that file's go.sum,
go.work.sum and, for a go.work pin, the members' go.sum, and puts
the upstream module's lines back where the Socket ones were.

Assisted-by: Claude Code:claude-opus-5-5

Real-go tests now cover a go.work root without a go.mod (hosted pins
in each member, attested from the root, rolled back byte for byte),
a member raising the patched module's version, GOWORK unset, `auto`,
`off` and relative, the hosted go.work gate under go's replace
precedence, and rollback of a go.work pin and its go.work.sum lines.
Each test fails before this branch's fixes.

The CLI contract and the Go ecosystem docs now describe how the
workspace is found, how its version and replace precedence are
read, and what each command does from a go.work root.

Assisted-by: Claude Code:claude-opus-5-5

In a go.work workspace go keeps no member's go.mod tidy, so a member's
dependency can raise a patched module above the version the Socket
replace is pinned to; the only trace is the zip line go writes to
go.work.sum or a member's go.sum. A higher zip line now proves the pin
inert even when a member's go.mod is out of reach, for vex and for
apply, vendor and hosted writes.

Another member replacing every version of the module (replace M =>
...) now blocks apply, vendor and hosted writes and makes vex leave the
patch out: go links that target or refuses to build.

At a go.work root, a hosted pin lands in every member that lists the
module or in none, instead of staying half-written when one member
refuses.

When GOWORK names a file other than the project's go.work, or a
relative path go rejects, vex attests no Go patch and reports each one.

Assisted-by: Claude Code:claude-opus-5-5

In a go.work workspace three things made socket-patch report a Go patch
as applied, or refuse one, when go did otherwise:

- A module that is itself a `use` member (a local checkout) is built
  from its directory, and go ignores every replace of it. apply, vex and
  hosted mode still wrote and attested the replace.
- go only ever appends to go.work.sum, so a zip line of a version that
  nothing requires any more stayed behind and made apply and hosted mode
  refuse a pin that go builds.
- A member's dependency can raise the module past every member require.
  Before a build wrote go.work.sum nothing showed it, so a fresh clone
  attested a pin that go ignores.

The selection is now worked out the way go does it: minimal version
selection over each member's requires and the go.mod of every
dependency go loads, read from its replacement directory or the module
cache. Sum files are no longer evidence. When a needed go.mod is missing
the answer is unknown: apply --check fails, vex leaves the patch out
(go_version_not_selected) and hosted mode writes nothing, until
`go mod download` fills the cache. A replace of a workspace module is
refused as a workspace conflict.

Assisted-by: Claude Code:claude-opus-5-5

The repo guard forbids private --json envelope readers in test files,
so the workspace e2e reads warning codes through the shared helper.

Assisted-by: Claude Code:claude-opus-5-5

With the workspace model, the go.work-level check reports a raised
zip-pinned replace as inert (the workspace requires the higher
version), so the test asserts the verdict and version, not the
module-mode sentence.

Assisted-by: Claude Code:claude-opus-5-5

The VEX selection gate only read Socket replaces from each module
root's go.mod, so a replace written into go.work itself skipped it and
was attested on a fresh clone with no module graph cached, contradicting
golang_workspace_without_its_module_graph_is_not_attested. Feed the
workspace's own replaces through the same gate (Bugbot, vex.rs:1006).

The go.work fixture now caches the module graph, as `go mod download`
would, since two existing go.work tests relied on attesting with an
empty module cache.

Co-Authored-By: Claude <[email protected]>

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

read_workspace dropped every main module when any `use` member was
outside the root or unreadable, so a readable member requiring a higher
version no longer marked a workspace zip pin inert and vex attested a
replace go does not build (Bugbot, golang.rs:271). In a workspace the
members' requires only ever prove a replace inert, so the readable ones
still count when another member cannot be read.

Co-Authored-By: Claude <[email protected]>

…into fix/golang-workspace-model-bd

# Conflicts:
#	crates/socket-patch-core/src/vex/discover/golang.rs

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

read_graph_from queued every member requirement and every raised
version as pruned, so it could miss a higher version of the patched
module that go loads and report the pin as Selected. Go enqueues each
main module at its workspace level, which loads the member's
requirements at the member's own pruning: a go 1.16 member loads its
whole transitive graph. It enqueues raised versions at the workspace
level too, so their direct requirements always load. Mirror that, and
dedup as go's loading/loadingUnpruned maps do.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Main landed lighter fixes for the same go.work gaps this PR models in
full: #1752 (version gate reads every member), #1753 (hosted pins
outranked by another member), #1767 (stale go.work vendor warning) and
the squashed #1748. Resolve them onto this PR's GoWorkspace model
instead of keeping two workspace readers:

- go_build_list: keep project_selection on GoWorkspace. Drop main's
  ModuleEvidence / workspace_selection / other_workspace_members and
  its three on-disk selection tests: GoWorkspace::selection covers
  those cases from the module graph (go_workspace tests), and without
  a module cache it answers Unknown by design.
- hosted: drop #1753's go_members plumbing (engine RewriteOptions
  closure, rewrite_golang argument, CLI wiring). The PR's
  HostedGoWorkspace already refuses a pin another member outranks.
  Main's e2e test for it now seeds the module cache the workspace
  graph reads, and passes, including the rescan that removes the pin.
- go_consumer_sync: port #1767's modules.txt audit (per-member replace
  resolution, member_owned, unreadable members skipped) onto
  go_workspace::load and its shared same_dir_key / lexical_target.
- vex discover, CLI_CONTRACT, e2e_golang_hosted_build: keep the PR's
  stricter rules (a zip pin is checked against the workspace selection
  too; sum-file zip lines are no evidence of it).

Co-Authored-By: Claude <[email protected]>

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

In a workspace go tidies no member, so a dependency can raise a module
above every member's `require`. `replaced_purl` compared a versioned
replace only against the highest member `require`, so a pin of the
version go actually builds was diagnosed inert and dropped from
discovery, attribution and VEX, even though hosted writes exactly that
pin. Accept the pin when the workspace module graph proves the build
selects it.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_011f9aeTFZLxrPhMwPH9kqv4