Vendored uv repair pairs a hashless pure wheel with another wheel's hash, because ledger recovery re-parses uv.lock with its own scanner

[mikolalysenko]

[agent] Filed by the scheduled architecture audit routine (ecosystems and formats). Register: E89.

Kind: bug (with a duplicated predicate). Source: new finding; register E89.

Problem

Verified on main 05ecc6e. Two parts of vendor/lock_inventory pick "the hash-pinned pure wheel" of a uv.lock [[package]], and they parse it differently.

• Live inventory: python_package_archive reads the lock with toml_edit through the shared utils::python_lock::package_artifacts. It pairs each artifact's url with that artifact's hash.
• Ledger recovery (repair / re-vendor of a missing artifact): pure_wheel_from_uv_unit, called at recover.rs#L239, is a string scanner. It finds url = ", then takes the first hash = "sha256: anywhere after it (rest.find(...)), even when that hash belongs to a later wheel. Its doc and its test claim the opposite ("fail-closed, never a guessed pairing").

The "is this a pure wheel" rule is also written four times:

Site	Rule
pypi_distribution::wheel_platform_from_filename	Tag triple parsed. Shared by vendored (vendor_platform_locked) and hosted (redirect_pypi_platform_wheel, redirect/mod.rs#L580).
lock_inventory/pypi.rs#L313	url.split(['?','#'])…ends_with("-none-any.whl")
lock_inventory/pypi.rs#L393 (poetry)	file.ends_with("-none-any.whl")
recover.rs#L464	url.ends_with("-none-any.whl"), with no ?/# strip

On main the suffix rule and the shared classifier agree on well-formed names. Open PR #1053 (fix for #1048) changes only the shared classifier: cp311-none-any, pp310-none-any and py2-none-any become non-portable. The three inventory copies will keep choosing those wheels as "pure", so the modes drift as soon as it lands.

Repro. A throwaway test in vendor/lock_inventory/tests.rs, run twice on 05ecc6e. One uv [[package]] unit whose pure wheel has no hash, followed by a hashed platform wheel:

wheels = [
    { url = "https://files.example/six-1.16.0-py3-none-any.whl" },
    { url = "https://files.example/six-1.16.0-cp312-cp312-manylinux_2_17_x86_64.whl", hash = "sha256:bbbb…" },
]

RECOVER:   Some(("https://files.example/six-1.16.0-py3-none-any.whl", "bbbb…"))   ← the platform wheel's digest
INVENTORY: resolved=None integrity=None                                          ← correctly no pure pinned wheel

The same test showed that pure_wheel_from_uv_unit also accepts cp311-none-any, which the shared rule will reject after #1053.

Symptoms

None filed. Impact: low severity and fail-closed. The fetch layer verifies the digest, so repair fails with a hash mismatch for the wrong wheel instead of the honest NO_URL / "no hash-pinned pure wheel" message. The structural cost is a third uv.lock reader, and portability drift between hosted/vendored and inventory/recovery once #1053 lands. The fixture is realistic for uv locks from --find-links or flat indexes, which carry no hashes.

Proposed change

1. Add pub(crate) fn is_portable_wheel(file_name: &str) -> bool beside wheel_platform_from_filename, or use !wheel_platform_from_filename(..).0. Use it at the three inventory sites, stripping ?/# once in a shared helper.
2. In recover.rs, parse the recorded uv_lock_package / pdm_lock_package fragment as TOML (it is a [[package]] unit) and reuse python_package_archive.
3. Deleted: pure_wheel_from_uv_unit (about 25 lines) and the three ends_with("-none-any.whl") literals.

Size and scope

• Files: vendor/lock_inventory/{pypi,recover,tests}.rs, vendor/pypi_distribution.rs.
• Size: under 100 production lines.
• Out of scope: moving the classifier out of vendor/ (the redirect → vendor import is E20/Tracking: move the pure lock codecs and neutral lock types into formats/ so formats imports nothing from vendor or redirect #833 territory) and the PEP 425 rule itself (Fix interpreter-bound wheels treated as portable (#1048) #1053).

Acceptance criteria

• The repro unit recovers to the NO_URL / "no hash-pinned pure wheel" error, not to a mismatched pair.
• Inventory and recovery give the same answer for the same [[package]] unit. Add a table test over py3-none-any, py2.py3-none-any, cp311-none-any, *-abi3-*, a hashless pure wheel and a #sha256= URL.
• After Fix interpreter-bound wheels treated as portable (#1048) #1053, an interpreter-bound wheel is non-portable in hosted, vendored, inventory and recovery alike.
• Existing pure_wheel_rejects_short_hash_missing_hash_and_non_http_url, uv_lock_inventories_pure_wheels, uv_lock_one_line_wheels_array_pairs_the_pure_wheel_with_its_own_hash and poetry_lock_carries_the_pure_wheel_sha256_when_listed stay green.

Dependencies

• Not blocked. If Fix interpreter-bound wheels treated as portable (#1048) #1053 lands first, step 1 picks up its rule automatically.
• Related: E20 (Tracking: move the pure lock codecs and neutral lock types into formats/ so formats imports nothing from vendor or redirect #833), the formats/vendor/redirect layering.

---

Backlog review — 2026-10-08

Priority: P1 → P3. Digest verification rejects the mismatched recovery wheel. This is a fail-closed recovery/diagnostic issue, explicitly low severity; keep active #1121.

[mikolalysenko]

[agent] Triage: priority:p1 (uv, PyPI-family). Not a duplicate. It's related to open agent PR #1053 (fix for #1048), which changes only the shared wheel classifier, but the cause is different (a string scanner in recover.rs pairs a URL with the wrong hash), so it isn't added to that PR's scope. Worth picking up after #1053 lands so the inventory sites inherit its rule.

---

Generated by Claude Code

[mikolalysenko]

[agent] Re-checked against main @ ea09714 (architecture audit, ecosystems and formats).

#1053 has merged since this was filed, and the portability drift that the issue predicted is now on main:

• The shared classifier pypi_distribution.rs#L99-L127 (wheel_platform_from_filename / tag_is_platform_specific) now treats cp311-none-any and py2-none-any as platform-specific (Hosted Pipenv scan still pins an interpreter-bound cp311-none-any patched wheel into Pipfile.lock with no warning, so pipenv sync fails on every other Python version (gap in the #932 fix) #1048).
• The three suffix checks still treat every -none-any.whl as pure:
  • inventory uv/pylock: lock_inventory/pypi.rs#L308-L318;``
  • inventory poetry: lock_inventory/pypi.rs#L390-L396;``
  • recovery: lock_inventory/recover.rs#L456-L470.``

So a lock whose only none-any wheel is cp311-none-any is now pure to the inventory and recovery, but platform-specific to hosted and vendored. Routing all three through wheel_platform_from_filename, as proposed, closes both halves. The hash-pairing defect in the recovery string scanner is unchanged.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue for the architecture refactor routine (highest leverage: the only p1 bug whose structural cause, a third uv.lock reader in recover.rs, sits entirely in files no open PR changes). Branch: arch-refactor/1079-recover-uv-wheel. Claim-ID: 2026-10-08T08:55:47Z-e20b0d

Slice taken: recovery reads the recorded [[package]] unit through utils::python_lock::package_artifacts and classifies wheels through the shared pypi_distribution classifier (recover.rs, pypi_distribution.rs, recover_tests.rs). Remaining for slice 2: the two -none-any.whl suffix checks in lock_inventory/pypi.rs and the pure_wheel_from_uv_unit rename/test move in lock_inventory/{mod,tests}.rs, which open PRs #1058, #1009, #1045 and #768 change.

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #1121 (slice 1, ledger recovery).

---

Generated by Claude Code