GeezerVison

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

Fixes #427

Summary

A project-mode scan of a restored .NET project used to list every package in the shared NuGet packages folder (~/.nuget/packages, NUGET_PACKAGES, every packageFolders key). Agent mode then patched packages that other projects had left there, and VEX attested them. This PR turns the crawler into a locator for restored projects. When cwd holds a .csproj/.fsproj/.vbproj, and every project under cwd at any depth has a parsed obj/project.assets.json with libraries, the shared roots are no longer walked. They are looked up only for the union of those resolved libraries (type: "package").

Why (leverage)

• Issue #427 is the NuGet child of tracking issue #595, register row E05 (register). The living document covers it in Part 6, "Cache crawls are not project-scoped".
• B 1: Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427.
• U 1: sets the locator shape for the cargo, go, Maven (Maven hosted scan pins, and VEX attests, artifacts the project doesn't depend on (the crawler lists all of ~/.m2) #265) and Deno children.
• D: one project.assets.json parser (parse_project_assets) serves both packageFolders and libraries.
• S 3: measured below.
• R M: project-mode discovery changes on purpose, as Tracking: scope project-mode cache crawls to what the project resolves #595's acceptance criteria ask.

What changed (crawlers/nuget_crawler.rs only)

• package_roots builds the root list, plus an optional scope. get_nuget_package_paths (same output as before) and crawl_all both use it.
• is_dotnet_project became dotnet_root, which returns None, Marker (solution, packages.config or NuGet config) or Project. Only Project roots are scoped.
• parse_project_assets parses one assets file into packageFolders and libraries. It replaces parse_project_assets_package_folders.
• restore_scope walks the source tree and unions every project directory's libraries. It returns None if any project is uncovered.
• locate_libraries probes <root>/<id lowercased>/<version lowercased>/ with the same verify_nuget_package and path_safety::is_safe_name_version guards as find_by_purls. It emits the same rows the walk produced for those directories.

Deleted

• The whole-cache walk of the shared roots for a fully restored project.

Behavior

• Changed: a fully restored project no longer crawls packages from the shared roots that its restores did not resolve. "Fully restored" means a project file at cwd, and every project file under it has a parsed assets file with libraries. The resolved packages come out with the same name, version, purl and path as before, but in libraries order instead of readdir order.
• Unchanged:
  • --global / --global-prefix;
  • solution roots without a root project file;
  • any tree where some project at any depth has no assets file or an assets file without libraries;
  • any tree with a directory that can't be fully listed, or more than 10,000 directories;
  • the project-local packages/ folder, which is still walked in full;
  • get_nuget_package_paths and find_by_purls.
• Remaining for Tracking: scope project-mode cache crawls to what the project resolves #595's NuGet item: the packages.lock.json fallback, and the crawl_unscoped_cache warning. The warning needs CLI_CONTRACT.md, which open PRs change.

Test evidence

• New unit tests in nuget_crawler.rs:

  • restored_project_crawls_only_its_resolved_packages
  • located_rows_equal_the_walks_rows_for_resolved_packages
  • sub_project_restores_join_the_scope (a restored sub-project two levels down)
  • an_uncovered_sub_project_keeps_the_walk (review fix: an unrestored sub-project two levels down, and an assets file without libraries)
  • project_local_packages_folder_is_still_walked
  • solution_roots_and_unrestored_projects_keep_the_walk
  • global_prefix_crawl_is_not_scoped

• Red → green:

  • On main, the Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427 tests fail. For example, the Project-mode NuGet agent scan patches, and VEX attests, packages the project doesn't depend on (the crawler lists the whole ~/.nuget/packages) #427 test gets [[email protected], [email protected], [email protected]] where it expects [[email protected]].
  • an_uncovered_sub_project_keeps_the_walk fails on a05d7fc, the head before the review fix.
  • All of them pass on 038042f.

• cargo clippy --workspace --all-features -- -D warnings is clean.

• cargo test -p socket-patch-core --lib: 5805 passed on a05d7fc. Its only 4 failures are the known root-only sandbox ones, which also fail on main:

  • copy_tree::relax_loop_must_not_traverse_symlinked_root
  • vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry
  • pypi_poetry::wire_write_failure_maps_error_and_leaves_lock_untouched
  • pypi_requirements::wire_failure_rolls_back_already_written_files

  On 038042f I re-ran only the 40 crawlers::nuget tests, and they pass.

• crawler_nuget_e2e: 28 passed. CLI e2e_nuget: 21 passed. The NuGet crawler oracle equivalence suite also passes: its trees have no libraries, so they keep the walk.

• Timing (release build; I used a throwaway bench and removed it before committing). The fixture is a 3,000-package shared folder and a project that resolves 20 of them:

  • main: 58.5 ms per crawl, 3,000 packages;
  • branch: 0.80 ms per crawl, 20 packages.

• No dotnet in the sandbox, so I didn't run a real restore. The fixtures follow the assets format: libraries keyed "<Id>/<Version>", with type: package|project.

Risk

Medium.

• The scope walk lists the source tree. It skips hidden, symlinked, bin, obj, packages and node_modules dirs, and gives up after 10,000 directories.
• Any project the walk finds without a parsed restore, including one with a relocated BaseIntermediateOutputPath, makes the crawl fall back to the whole-cache walk. So a package is dropped only when no project's restore resolves it.
• A project outside cwd that is referenced by path is covered too, because its packages appear in the referencing project's libraries.
• The wrappers (npm/, pypi/, gem/) need no change.

🤖 Generated with Claude Code

Generated by Claude Code