Delete lock_inventory::wired_vendor_integrity and PnpmLock::wired_integrity, which have no production caller

[mikolalysenko]

[agent] Filed by the scheduled architecture audit routine (ecosystems and formats). Register: discussion #560 register.

Kind: refactor (dead code; no behavior change). Source: review 6.4, R11; register E41.

Problem (verified on 045d7ec)

• vendor/lock_inventory/wired.rs#L1-L221 is 221 production lines. Its one public function, wired_vendor_integrity,`` is documented as "the trust anchor for repair's no-ledger reconstruction". It reads the rewired package-lock, shrinkwrap, pnpm, yarn classic/berry, bun.lock, bun.lockb and Python locks.
• Its only callers are in vendor/lock_inventory/tests.rs (lines 491–515, 1490–1508 and 2007). It is re-exported at lock_inventory/mod.rs#L79 but used nowhere in socket-patch-cli, socket-patch-node or socket-patch-bench.
• commands/repair.rs no longer reconstructs from lockfile integrity. Its no-ledger path (repair.rs#L519-L535) only scopes the manifest by referenced uuids.
• formats::pnpm::PnpmLock::wired_integrity is called only from wired.rs:141 and its own unit test, so it is dead too.
• wired.rs imports crate::vex::discover::{vendor_ref, vendor_ref_decorated}, a vendor → vex edge against the intended layering.
• It is one more per-format walk over each npm-family lock, beside inventory, vendored, hosted and restore (E07, Walk package-lock entries once for inventory, vendored, hosted and restore #663). Every change to those formats has to keep it compiling and its tests green.

Symptoms / impact

There are no user-visible bugs. Maintainers pay for it: 221 production lines plus about 80 test lines that model a repair path which no longer exists. The misleading doc ("trust anchor for repair") also suggests that a security property depends on it.

Proposed change

Delete:

• vendor/lock_inventory/wired.rs, its mod, the re-export and the module-doc line at lock_inventory/mod.rs:15;
• the wired_vendor_integrity tests in lock_inventory/tests.rs;
• PnpmLock::wired_integrity and its test wired_integrity_reads_the_vendored_entry_pin_only;
• the "wired_vendor_integrity(" needle in the forbidden-reader guard at vex/discover/mod.rs#L3563, plus the doc mentions in utils/python_lock.rs:36 and vex/discover/bun.rs:11.

Afterwards, delete any helper that wired.rs was the last production user of. Check with cargo clippy -D dead_code; for example, the pub(crate) lock-model accessors it imports from super::{bun,npm,yarn}.

Size and scope

• Production: about −235 lines (wired.rs −221, plus the PnpmLock method and doc lines). Tests: about −90 lines.
• Files: vendor/lock_inventory/{wired,mod,tests}.rs, formats/pnpm/mod.rs, vex/discover/{mod,bun}.rs, utils/python_lock.rs.
• Out of scope:
  • vex/discover/deno.rs, which is a deliberate, documented empty extractor;
  • the pre-v5 redirect-ledger readers, which are live migration code (list, rollback retire_legacy_redirect_ledger);
  • the other orphans in Delete the vendored and hosted-vlt helpers left without a production caller by the v5 consolidation #782.

Acceptance criteria

• grep -rn "wired_vendor_integrity\|fn wired_integrity" crates returns nothing.
• vendor/lock_inventory/ no longer imports from crate::vex.
• cargo test -p socket-patch-core --lib, cargo test -p socket-patch-cli and cargo clippy --workspace --all-features -- -D warnings stay green.
• repair e2e tests stay green unchanged, which shows that no runtime path used it.

Dependencies

• Not blocked; independent of Delete the vendored and hosted-vlt helpers left without a production caller by the v5 consolidation #782 (different files). If the refactor routine prefers, it can land in the same PR as Delete the vendored and hosted-vlt helpers left without a production caller by the v5 consolidation #782.
• Slightly shrinks E07 (Walk package-lock entries once for inventory, vendored, hosted and restore #663): one fewer package-lock walk to merge.

[mikolalysenko]

[agent] Triaged as priority:p3 (dead-code refactor, no behavior change). Related to #782 (other orphaned helpers) and #663 (package-lock walk consolidation), but the cause is separate: it is a different module with no shared code path. Not a duplicate. No open PR addresses it.

---

Generated by Claude Code