GeezerVison

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

Fixes #1534

Summary

Some repositories hold an independent npm project below the root, such as tools/x/ with
its own package-lock.json and node_modules. A root scan --mode vendored in such a
repository used to fail on every run (exit 1, partialFailure) and skip the in-run VEX.
It now leaves that project's packages to that project's own run and prints a
nested_project_skipped warning naming the PATH to pass. The exit code and status are
unchanged.

Root cause

The scan crawls every node_modules below the root, including a nested project's.
Agent and report-only scans assign each crawled copy to the project that owns it
(judge_nested_roots, #554). Hosted and vendored scans skip that step, so a vendored scan
passed tools/x's copy of left-pad to the root's package-lock.json backend. The root
lock has no entry for it, and the backend treats a missing entry as the hard
vendor_lock_entry_not_found refusal. The suggested fix (npm install) can't clear that,
so the run fails every time. Hosted mode only skipped the package (redirect_unconfirmed).

Fix

• core hosted::governing_root::nested_npm_project(scan_root, copy) finds the nearest
  directory below the scan root, above the copy's first node_modules, that is its own
  npm-family lock root. A workspace member whose lock its package manager ignores
  (member_stray_lock, Hosted and vendored scans run from an npm workspace member that has a stray package-lock.json of its own rewrite that lock, which npm ignores, and report success while npm installs the unpatched package and VEX attests not_affected #1094/Hosted and vendored scans from a Bun workspace member with a stray bun.lock / bun.lockb pin that ignored lock, exit 0, and lock-only VEX attests not_affected while Bun installs the unpatched package #1101/Hosted and vendored scans from a vlt workspace member with a stray vlt-lock.json write to that lock, which vlt ignores, and exit 0 (vendored VEX then attests not_affected while vlt ci fails) #1134) does not count, because the root's lock installs
  that member.

• cli scan::discovery::nested_project_skips runs after the patch query in hosted and
  vendored root scans. It drops a patched npm purl only when all three hold:

  1. the root's lock inventory doesn't list it;
  2. its crawled copy is in a nested project;
  3. no node_modules in the root's own install has another copy. The crawl keeps one copy
     per purl, so this check stops a package the root also installs from being dropped. If a
     tree can't be read, every package stays with the root.

  Each nested project gets one nested_project_skipped run warning that names the purls,
  the directory, and the command to run (socket-patch scan --mode vendored tools/x). The
  path is relative to the shell's directory, so it's correct under --cwd and on PATH-list
  legs, and it's quoted when needed.

• Docs: a CLI_CONTRACT.md code-table row, and a paragraph in docs/ecosystems.md
  ("npm: which node_modules trees are crawled").

Test evidence

New crates/socket-patch-cli/tests/scan/scan_nested_project_e2e.rs, run with
cargo test -p socket-patch-cli --all-features --test scan scan_nested_project_e2e.
On main with the tests committed, 3 fail (red); with the fix, all pass (green).

Unit tests: governing_root::tests::nested_npm_project_finds_the_independent_lock_root and
scan::discovery::tests::shell_word_quotes_only_what_the_shell_would_split.

Local checks:

• cargo fmt --all -- --check: ok.

• cargo clippy --workspace --all-features -- -D warnings: ok.

• cargo test -p socket-patch-cli --all-features --test e2e_redirect_npm_build -- --ignored
  (real npm): 6 passed.

• cargo test --workspace --all-features: every failure from this change is fixed. 10 tests
  still fail locally, all for environment reasons:

  • the sandbox runs as root, so read-only and write-failure injection has no effect. This
    covers the *_write_failure_* tests, repair_*_unremovable, copy_tree's read-only
    parent, and vlt heal_invalidation_failure;
  • e2e_bun_lockb fetches a blob from the live patch API, which isn't reachable here.

  None of them touch scan's npm discovery. CI runs them as a non-root user.

Review (/code-review high)

Fixed:

• the suggested PATH was relative to the leg's directory and wasn't quoted;
• errors fell open and dropped packages; they now keep every package with the root;
• the plural wording is computed once.

Not fixed:

• An independent nested project with no lock of its own is not detected. Agent mode's Agent-mode scan ignores socket.yml includePaths / ignorePaths (and the built-in tests/ default) for nested npm projects, patching every nested project's node_modules #554
  rule uses lock markers too, and without a lock there is no project boundary to read. A root
  vendored scan still refuses such a copy (vendor_lock_entry_not_found), as before. This
  is a narrower case than the one reported, which has a lock.
• The . leg of scan . tools/x still warns about tools/x even though the next leg
  patches it. The warning is accurate for that leg, and silencing it would mean passing sibling
  PATHs into each leg.
• nested_npm_project and ScanPolicy::nested_owner share a walk shape but use
  different rules. Agent mode doesn't exclude stray-lock members. Unifying them would change
  agent-mode ownership, which is out of scope here.
• The second node_modules walk happens only when some patched package is a candidate,
  which is rare. Reusing NpmCrawlSnapshot would mean threading it through run_scan's
  agent path.
• No per-directory memoization in nested_npm_project. It runs once per patched
  candidate, not once per crawled package.
• scannedPackages still counts the nested copy. It counts what the crawl found; the
  copy just isn't selected. The in-run VEX test confirms the copy isn't attested.

🤖 Generated with Claude Code

https://claude.ai/code/session_0165v5yieeSffKsNoz1RbLKx

Generated by Claude Code