[Mikola Lysenko (mikolalysenko)]

Stacked on #2012 (base fix/cargo-members-liveness-origin).

Problem

#2012 made Cargo VEX discovery read workspace member manifests, but left one case open. When one declaration pins a crate to socket-patch-<uuid> and another declaration of the same crate is not pinned (crates.io, another registry, a path or git) with a requirement that may select the locked version, discovery still emitted an attested Cargo.lock ref. "Some declaration pins the patch" was enough. The other declaration can be the root's or a member's.

Cargo resolves each source on its own. The unpinned declaration builds a separate, unpatched copy, and that copy can be the very version the pin covers. The hosted rewriter pins every declaration in the root and every member (patch/redirect/mod.rs), so this mixed state comes from a partial revert or a hand edit.

Fix

Each declaration of a Socket-locked crate is classified once (route). It is one of three things:

• routed to a Socket patch: by its own socket-patch-<uuid> registry, or by a Socket [patch.<source>] registry entry in the root manifest or project config that redirects it;
• unpinned: cargo builds its own copy for it;
• saying nothing about the locked version. That covers a requirement that excludes it, a [patch] entry itself, a [workspace.dependencies] template no manifest inherits, and a malformed socket-patch-* name (diagnosed elsewhere).

What the classification decides when some declaration names the lock's patch A:

• Unpinned declaration: the ref stays (rollback, remove and the ledger liveness gates keep working) but is marked unattested with the new UnattestedKind::CargoUnpinnedDeclaration.
  • The mark names the declaration's manifest, requirement and source.
  • It also says whether re-running scan can pin the declaration. Only a crates.io declaration whose requirement matches no other locked version can be re-pinned; for anything else the rewriter refuses, so the remedy is to change the declaration or roll the patch back.
• What counts as a pin: registry = "socket-patch-<uuid>" beside path, git or registry-index is not a pin, because cargo builds that other source. This matches the hosted rewriter's own pinned check.
• Another patch B: a declaration routed to patch B that may select the locked version, where the lock does not resolve the crate from B, adds B's Cargo.toml ref. The CLI then gates the package as wiring_conflict.
• Same-version twin: when the lock already holds a same-version copy from another source, no mark is added. The existing twin rule (Hosted cargo vex attests not_affected while Cargo.lock also builds an unpatched crates.io copy of the same crate@version #679) withholds the ref and names the lock entry.

Version requirements go through patch::redirect::cargo_req_selects, with the lock's other versions of the crate, so "may select" and "ambiguous" agree with the rewriter.

CLI: a new note arm vex_cargo_unpinned_declaration in vex_sources.rs. Its remedy is generic ("not attested while that declaration stands"); the per-case remedy is in the detail. Both places in CLI_CONTRACT.md are documented.

Vendored mode

Vendored mode does not have this bug. Its wiring is a root [patch.crates-io] entry, which cargo applies workspace-wide to every crates.io declaration the copy satisfies. The related gap (a member declaring the crate from another registry or git) is handled in #2024, which is stacked on this PR.

Review findings (/code-review high)

All nine were confirmed and fixed. For the behaviour bugs I wrote the test first and saw it fail; 7 tests failed before the fix.

1. Fixed. A crates.io declaration that a Socket [patch] registry entry redirects was marked unpinned. Redirected declarations now count as pins. Added out.unattested.is_empty() to patch_table_registry_pin_counts_as_the_declaration and config_patch_registry_pin_counts_for_a_declared_crate, plus a case where a declaration from another registry, not redirected by [patch.crates-io], is still marked.
2. Fixed. A socket registry beside path / git / registry-index counted as pinned. Test: a_socket_registry_beside_another_source_is_not_a_pin. Next to a real pin, it marks the ref. As the only declaration, it keeps the ref because Socket's wiring is present, but marks it.
3. Fixed. The remedy now depends on the case (the_remedy_says_whether_a_rescan_can_pin_it). A requirement that also matches another locked version names that version and says scan cannot pin it.
4. Fixed. In the same-version twin case the mark is skipped, and the Hosted cargo vex attests not_affected while Cargo.lock also builds an unpatched crates.io copy of the same crate@version #679 diagnostic stands (a_locked_same_version_twin_is_left_to_the_twin_rule).
5. Fixed. A [workspace.dependencies] template counts only when inherited (an_unpinned_workspace_template_counts_only_when_inherited).
6. Fixed. A registry-index declaration is reported as "the registry index ", with the roll-back remedy.
7. Fixed. Root pins A and a member pins B: B's ref is emitted beside A's (a_member_pinned_to_another_patch_is_a_conflict_pair). No conflict is emitted when B's requirement excludes the locked version, or when the lock resolves the crate from B at another version (a separate, patched package with its own ref). This overlaps with the split-patch part of Withhold a vendored Cargo copy a member's other source bypasses #2024; see the note there.
8. Fixed. The code uses cargo_req_selects with the lock's other versions; Decl::accepts is gone.
9. Fixed. Decl carries a DeclSource enum and a live flag. The origin text is formatted only for messages, and [patch] pins use Decl::patch, which has no dead version parameter.

Tests

• cargo test -p socket-patch-core --lib -- vex::discover:: vendor::cargo patch::redirect:: utils::cargo_workspace: 1555 passed. The golden corpus test passes with no golden changes.
• cargo test -p socket-patch-cli --lib vex_sources: 15 passed.
• cargo test -p socket-patch-cli --test in_process_redirect cargo: 6 passed.
• cargo clippy --locked --workspace --all-features -- -D warnings and cargo fmt --all -- --check are clean.

Not done

• The lockless path (unresolved_manifest_pins, from Read Cargo members in discovery; match liveness uuids by origin #2012) still treats a socket-patch-<uuid> registry beside path / git as pinning, and an uninherited template as a declaration. It is unchanged here.
• In the old "no declaration pins the lock's patch" branch, the conflict pair is still emitted without a requirement check.
• I did not read the lock's per-package dependencies lists to tell which copy a declaration actually resolved.

---

Generated by Claude Code