[Mikola Lysenko (mikolalysenko)]

Problem

Vendored Gradle keeps the original GAV, routes it to the committed repository with exclusiveContent, and leaves lock files unchanged. Neither the vendored planner nor its VEX liveness (vendor::jvm::gradle::wired / wired_checked, which re-plan and require no degraded warning) read any lock file. If gradle.lockfile (or another lock of the build) pins the patched GA at a different version, Gradle resolves that locked version (or fails lock validation), yet vendored liveness still attested the patch. Hosted discovery already checks every lock (vex/discover/gradle.rs).

Fix

The planner in vendor/jvm/gradle.rs now runs check_locks after check_graph. It reads the build's lock inventory, which is now shared with hosted discovery: ScriptGraph::read_locks, covering gradle.lockfile, buildscript-gradle.lockfile, settings-gradle.lockfile and the legacy gradle/dependency-locks/*.lockfile of every project of every build. It also reads every custom lockFile the graph can follow (ScriptGraph::custom_lock_files).

Each problem below adds a vendor_jvm_degraded warning. wired requires a re-plan with no degraded warning, so each one also withholds VEX attestation. The patch is still applied.

Reason	When
gradle_lock_overrides_vendored	An entry for the GA is at a version no vendored row serves (neither this patch's version nor another vendored version of the GA).
gradle_settings_lock_unrouted	A settings-gradle.lockfile entry exists, but that build's settings script does not hold the in-block exclusiveContent entry for the GAV in every block that needs one (buildscript, and pluginManagement when there are settings plugins{}).
gradle_lock_unreadable	A listed lock file, or a followed custom one, can't be read as UTF-8 text: I/O error, refused or outside the checkout, missing, or not UTF-8.
gradle_custom_lock_file	A lockFile location can't be followed statically. Only a literal file('…') or "$projectDir/…" in a project's own build script, outside allprojects / subprojects / configure / project(…) blocks and inside the checkout, can be followed.

How hosted's rules map to vendored (also in the doc comment). Hosted pins a suffixed version: a lock below the base is invalid, and a lock above it is LockAboveBase (unattested). Vendored keeps the original GAV, so a lock entry is served only at a vendored version. Any other locked version, above or below, means the build doesn't consume the patch.

Hosted rejects every settings-classpath lock, because its script runs after that classpath resolves. Vendored instead routes that classpath with in-block entries, so it accepts a settings lock only when the settings script actually holds them:

• Vendoring: the entry may already be committed, or written by this plan (Committed::OrPlanned).
• Liveness: the entry must already be committed (Committed::Only); one a re-plan would write doesn't count.

Anything else is rejected, as hosted rejects it.

Docs: the reason codes are added to the vendored table in CLI_CONTRACT.md, with a paragraph in docs/design/maven-vendoring.md.

Liveness judges committed wiring, never a re-plan

wired re-plans over the committed tree but used to ignore the re-plan's writes. So wiring a re-plan would add again stood in for wiring missing from the checkout. For example, a settings classpath on the module whose in-block entry had been removed still attested, with or without a settings lock.

The liveness re-plan (Committed::Only) now reports gradle_wiring_uncommitted when it would still write any wiring file. This reason is liveness-only; vendor never reports it. It is documented in CLI_CONTRACT.md. Vendoring's own first run still counts the entries it is about to write.

Audit of wired / wired_checked: every place where a pending re-plan write masked missing committed wiring is now caught.

• Settings in-block entries: buildscript, and pluginManagement for settings plugins{}, including a plugins{} block added after vendoring. This is the gap from the last round.
• Apply lines of buildSrc and included builds: references checks only the root's apply line.
• Index rows: references matches only GAV and uuid, so a row whose hash no longer matches the tree passed.
• The derived maven-metadata.xml.
• gradle/verification-metadata.xml: patched hashes missing.
• The script: already covered by is_ours; it is counted too.

Not counted, on purpose:

• Tree files: rebuilt from the committed bytes. The script checks their hashes against the index, and index writes do count.
• Git hygiene files (.gitattributes, .gitignore): Gradle never reads them, so they don't change what this checkout resolves.

wired_checked adds only parse guards on top of wired. The Maven half's attestable_checked already requires edits.is_empty() from its declaration rewrite. A missing Maven repository tail makes the suffixed version unresolvable, so the build fails rather than using another copy. sbt and scala-cli liveness were not audited.

Test: liveness_judges_committed_wiring_not_a_replan. All 7 cases above were attested before this change (verified: all 7 were listed as masked), and none are now. A missing hygiene file still attests, and vendoring's first run reports no degraded warning. settings_lock_needs_the_committed_in_block_entry now also asserts that the unlocked, stripped case is not live.

Review findings (/code-review high)

1. False attestation of a settings lock without the in-block entry: confirmed, fixed. See the table and mapping above. Test: settings_lock_needs_the_committed_in_block_entry. A settings lock is accepted with the committed entry. If the entry is stripped, liveness fails even though a re-plan would write it again. A settings script with no in-block entry is rejected (also covered in lock_at_another_version_withholds_liveness).
2. Two vendored versions of one GA degraded each other: confirmed, fixed. A lock at a version the vendored index serves is no longer an override. Test: two_vendored_versions_of_a_ga_do_not_override_each_other.
3. Degradation is build-wide: kept conservative, by design. A Gradle lock file belongs to one project and lists exactly the configurations that resolve each module, so only entries for the GA count; other locks are ignored. A project that locks the GA at another version (an unrelated tools/ test classpath included) does resolve the GA, just at that version, so that part of the build doesn't consume the patch. Hosted, which is ground truth, also withholds the whole build for one above-base lock. What can't be decided statically is whether Gradle reads a lock at all (whether that project enables dependencyLocking), so every lock of the build counts. The message now names the locking configurations.
4. Unreadable locks skipped (fail open): confirmed, fixed. Paths come from the directory listing, so a listed lock that read can't return (I/O error, refused symlink outside the checkout, non-UTF-8) now fails closed. Test: unreadable_lock_files_fail_closed.
5. Unreadable locks reported as an override: confirmed, fixed. They now get gradle_lock_unreadable with an accurate message, documented in CLI_CONTRACT.md.
6. Every lockFile degraded every patch: confirmed, fixed. A followable custom lock is read and parsed like any lock. A missing one fails closed, since it was set explicitly. Only an unfollowable one is gradle_custom_lock_file. Tests: custom_lock_file_is_followed_when_static, plus the path-resolution cases in gradle::graph::tests::custom_lock_file_and_settings_classpath. Hosted keeps its blanket rejection of lockFile, because the hosted planner can't rewrite such a lock.
7. Perf, locks re-read on every plan: refuted as a blocker, noted for follow-up. The lock pass reuses the ScriptGraph that plan already builds. Per call it lists two directories per project and reads each lock once. That is the same order as the existing per-call cost, since every plan call (one per patch, and one per entry in vex liveness) already re-collects and re-tokenizes the whole script graph. Lock files are small line-oriented text. A real per-root cache has to cover the graph and the locks together, and it needs a planning context threaded through plan, plan_with_external, wired, entry_wired_checked and the CLI vex loop. That is better done as its own change than bolted onto locks alone.
8. Duplicated lock gathering: confirmed, fixed. ScriptGraph::read_locks is now the single inventory. Hosted discovery and the vendored check both use it, ScriptGraph::custom_lock_file is built on custom_lock_files, and is_settings_lock moved to gradle::locks (re-exported from patch::redirect::gradle). The hosted planner's lock rewrite still lists files through the same lockfile_paths because it needs the raw text to edit.

Tests

• All 5 lock tests in vendor::jvm::gradle::tests fail against the previous commit's check_locks, verified by splicing the old function back in. They pass with this change:
  • lock_at_another_version_withholds_liveness
  • settings_lock_needs_the_committed_in_block_entry
  • two_vendored_versions_of_a_ga_do_not_override_each_other
  • unreadable_lock_files_fail_closed
  • custom_lock_file_is_followed_when_static
• lock_at_another_version_withholds_liveness also fails on origin/main.
• liveness_judges_committed_wiring_not_a_replan fails before the committed-wiring change (all 7 cases masked) and passes after it.
• cargo test -p socket-patch-core --lib -- vendor::jvm:: vex::discover:: gradle::: 776 passed.
• cargo test -p socket-patch-core --lib -- vex::discover::testing::golden::tests::committed_fixture_corpus_matches_golden vendor:: patch::redirect::gradle: 2893 passed. No golden changes.
• cargo test -p socket-patch-cli --test contract_gradle_codes --test vendor_jvm_cli --test gradle_agent_cli: 1 + 54 + 54 passed. Every new reason code is documented, and end-to-end vex on vendored JVM entries is unchanged.
• cargo clippy --locked --workspace --all-features -- -D warnings and cargo fmt --all -- --check are clean.

Not done

• No planner refusal. Degrading is the smaller, clearly-correct change. A refusal when every governing lock pins another version could follow later, alongside gradle_range_excludes_vendored.
• No lock rewriting. Vendored keeps the original GAV, so a lock at the vendored version needs no edit.
• Per-root planning cache. See finding 7.
• sbt / scala-cli liveness were not audited for the committed-wiring rule.

🤖 Generated with Claude Code