GeezerVison

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

Fixes #1564

Summary

From vlt 1.4.0, a workspace root can list its members in pnpm-workspace.yaml packages:. vlt reads that list only when neither vlt.json nor package.json has a workspaces field, and it installs those members from the root's vlt-lock.json. socket-patch now treats such a member like a vlt.json- or package.json-listed one:

• Hosted from the member: refused with redirect_workspace_lockfile_elsewhere, naming pnpm-workspace.yaml and the root to run from. This applies with or without a stray member lock.
• Vendored from a member with a stray vlt-lock.json: refused with vendor_lockfile_missing. Nothing is written.
• VEX from that member: its stray lock is read as absent, so nothing is attested not_affected.

Before this change, every one of these runs exited 0. The vendored run's VEX attested not_affected while vlt installed the pristine package.

Root cause

hosted/governing_root.rs vlt_workspace_root read member globs only from an ancestor vlt.json, and package_json_workspace_root covered the package.json fallback. Nothing modelled vlt 1.4's third source. The hosted refusal, the vendored member_stray_lock_refusal (vendor/npm_flavor.rs) and VEX discovery (ignore_member_stray_locks) all go through vlt_workspace_root / member_stray_lock, so all three missed it.

Fix

vlt_workspace_root now asks vlt_workspace_groups for each ancestor's patterns. That function mirrors vlt 1.4's resolveWSConfig:

1. vlt.json workspaces if the field exists.
2. Otherwise, if package.json has no workspaces field (vlt keys on the field existing, whatever its value), the pnpm-workspace.yaml packages:, minus . / ./ root entries, as long as a positive pattern remains.

The patterns are globbed with WorkspacesDialect::VLT. vlt 1.4's splitNegatedPatterns is the same as 1.3's, so !packages/b excludes b.

Version gate. vlt 1.3.8 and older ignore pnpm-workspace.yaml, so there a listed directory is its own project, and writing its lock is correct (the issue's control row). Both versions write the same lock format, so the root lock decides. vlt 1.4 records a workspace~<dir> edge from every member it installed that has a dependency. A lock with an edge from a packages:-listed directory is therefore 1.4's (vlt_lock_reads_pnpm_workspace). A lock with no such edge is older vlt's (or every member has no dependency, so there's nothing to patch). A lock that can't be read keeps the refusing side, as vlt_lists_member already does for #1542. A pnpm-workspace.yaml root with no vlt-lock.json isn't shown to be vlt's, so the walk carries on to an outer vlt.json root.

I checked the edge rule against real vlt (public registry, root pnpm-workspace.yaml listing packages/* and !packages/b, both members depending on left-pad):

• vlt 1.4.0 vlt install → edges ["workspace~packages+a left-pad"]
• vlt 1.3.8 vlt install → edges []

docs/ecosystems.md vlt notes gain a short "Workspace members" paragraph. docs/testing/vlt-compatibility.md still lists 1.3.8 as the newest supported release. Adding 1.4.0 to the real-vlt CI matrix is a separate change.

Tests (red → green)

The first commit (84c671a) adds only tests. All four failed on main.

Commands run locally (Linux, as root):

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test --workspace --all-features --lib: 7,435 passed. The 4 failures are environment-only write-failure tests that can't fail as root (vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, copy_tree::relax_loop_must_not_traverse_symlinked_root, pypi_poetry::wire_write_failure_maps_error_and_leaves_lock_untouched, pypi_requirements::wire_failure_rolls_back_already_written_files). They fail identically on main.
• Hermetic suites in_process_redirect, in_process_vendor, in_process_rollback_hosted, in_process_vendor_bun_takeover, e2e_vex, e2e_vex_redirect, redirect_golden, vlt_locks: all pass except 3 root-only write-failure tests in in_process_redirect (partial_lockfile_write_failure_exits_1_and_writes_no_ledger, redirect_json_mode_write_failures_emit_error_envelope, vlt::scan_redirect_vlt_heal_invalidation_failure_warns), which also fail on main as root. The sandbox disk can't hold every test binary of the full cargo test --workspace, so CI runs the rest (non-root).
• Real-vlt edge check as above (vlt 1.4.0 and 1.3.8). The real-vlt CI capstones pin releases ≤ 1.3.8, so a 1.4-only e2e leg would always skip in CI. I didn't add one.
• Wrappers (npm/, pypi/, gem/) only dispatch to the binary and need no change.

/code-review high: findings not fixed

• "Any listed directory" vs "the member" as lock evidence, and an unreadable lock refusing. This is deliberate. The edge only shows which vlt version wrote the lock. Membership itself comes from the globs, as with vlt.json. A member with no dependency has no edge of its own but is still a member. An unreadable root lock keeps the refusing side, matching vlt_lists_member (Hosted and vendored scans from a vlt workspace member with a stray vlt-lock.json still write to that lock and exit 0 when the root's workspaces glob uses an extglob (packages/+(a|b), packages/@(a|b)); vendored VEX then attests not_affected #1542): vlt can't install from that lock either.
• package.json workspaces: null / {nohoist: [...]} suppresses the yaml. This matches vlt. resolveWSConfig falls back to pnpm-workspace.yaml only when workspaces === undefined, and asManifestWSConfig returns {} for an object without packages. So vlt reads no members there either.
• Extra reads per ancestor. The walk reads pnpm-workspace.yaml per ancestor, and reads package.json only where a yaml exists. That is one stat for each ancestor without a yaml, the same cost as the existing vlt.json probe. Left as is.

🤖 Generated with Claude Code

https://claude.ai/code/session_01P3dvgTvNF8SCp2PAoebdaA

Generated by Claude Code