GeezerVison

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

A workspace member that still held its own package-lock.json or
npm-shrinkwrap.json skipped the workspace-member refusal. npm never
reads a lock inside a member: it installs every member from the
workspace root's lock. So hosted scan/get pinned the ignored member
lock and vendored mode vendored into it. Both exited 0 while npm kept
installing the unpatched package.

Hosted scan/get from such a member now refuse with
redirect_workspace_lockfile_elsewhere, naming the root lock and the
ignored member lock. Vendored refuses with vendor_lockfile_missing, as
it does for a member with no lock. A member that also holds a lock its
own manager reads (pnpm, yarn, Bun, vlt, Rush), or a workspace root
with no npm lock, keeps the own-lock shortcut.

Fixes #1094 (hosted and vendored legs)

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

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

…stray-lock

# Conflicts:
#	crates/socket-patch-cli/CLI_CONTRACT.md
#	crates/socket-patch-core/src/hosted/governing_root.rs

A vendored run from an npm workspace member with a stray lock refused
only inside the vendor backend, after the hosted-to-vendored takeover
had already restored a leftover hosted pin. The takeover preflight now
raises the same vendor_lockfile_missing refusal first, so nothing is
reverted.

The hosted and vendored messages no longer suggest deleting the stray
lock: the directory is still a listed workspace member, so it would be
refused again. Both name the workspace root to run from.

Refs #1094

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

…stray-lock

main replaced the hosted lock-name lists with NpmLockFamily. The
stray member-lock check now reads npm's own locks and the other
families' locks from that table instead of the removed constants.

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

Ported from #1118. The upstream v2 tag moved off the pinned commit,
so zizmor's ref-version-mismatch audit fails every PR on main. The
pin itself is unchanged; only its comment now names 2.37.2. This
no-ops once #1118 lands.

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

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

A Bun or vlt workspace member that still holds its own bun.lock,
bun.lockb or vlt-lock.json (typically left behind when the package
moved into the monorepo) skipped the workspace-member refusal. Bun and
vlt never read that lock: they install the member from the root lock.
Hosted and vendored scans then pinned or vendored a lock nothing
installs from and reported success, and vex from the member attested
not_affected.

The npm-only check from #1094 now covers every manager that ignores a
member lock. Hosted runs refuse with
redirect_workspace_lockfile_elsewhere, vendored runs and the takeover
preflights refuse with vendor_lockfile_missing, and vex discovery reads
the ignored lock as absent, naming it in one diagnostic.

Fixes #1101, #1134.

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

Regression tests for #1101 and #1134 at every layer the fix touches:
the vendored engine and the Bun and vlt takeover preflights refuse a
member holding a stray bun.lock, bun.lockb or vlt-lock.json; vex
discovery from such a member reads the ignored lock as absent and
names it in one warning; and hosted scan and get from the member
refuse, leaving both locks untouched. CLI_CONTRACT documents the Bun
and vlt cases next to the npm one.

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

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

Takes main's squash of #1095 and keeps only this branch's Bun and vlt
changes on top. Also drops the unrelated reformatting an earlier commit
picked up from a workspace-wide cargo fmt.

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.

The refusal names the workspace root as the walk resolves it, which
is canonical: a \\?\ prefix on Windows, /private on macOS. The test
now compares against the canonical root, so the Windows test leg
passes.

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.

…y-bun-vlt-lock

# Conflicts:
#	crates/socket-patch-cli/CLI_CONTRACT.md

main (#1027) changed the --json top-level error to a {code, message}
object. CLI_CONTRACT.md now uses main's `error.code` rows with this
branch's Bun/vlt sentence, and the new CLI test reads
error.message.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0118z8gCQpYXnzeeinQdsTEp

…ock'

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0118z8gCQpYXnzeeinQdsTEp

cursor Bot left a comment •

edited

Loading

Uh oh!

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

…y-bun-vlt-lock

main (#1058) dropped DiscoverCtx::root, which broke the merge-queue
build of this branch. The check now gets the root from
disk_root_reading and declares the project files it reads
(member_stray_lock_own_files). A read recording therefore stays usable,
and an npm-only discovery still reads only through the view. The
ancestors it walks are above the project, which no overlay of the
project's files changes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0118z8gCQpYXnzeeinQdsTEp

cursor Bot left a comment •

edited

Loading

Uh oh!

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

CLI_CONTRACT.md conflict: this branch changed the
redirect_pnpm_lockfile_elsewhere / redirect_workspace_lockfile_elsewhere
row and main changed the redirect_pnpm_settings_elsewhere row next to
it. The merge keeps both changes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0118z8gCQpYXnzeeinQdsTEp

…y-bun-vlt-lock

cursor Bot left a comment