GeezerVison

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

Fixes #584

Summary

After a Maven reactor is vendored, a module added later (or a dependency
added to an existing module) that declares the patched artifact at its
plain base version builds Central's unpatched jar. vendor --check
already reported this as drift, but vex kept attesting
not_affected. Now vex skips the package as vendor_unwired until
vendor is re-run, and attests again once it is.

Root cause

vex decides whether a vendored Maven reactor entry is still live with
maven_reactor::attestable_checked. Since #1787 that function re-runs the
planner's declaration walk (rewrite_declarations), but it only looked
at the uncertain set (${prop} versions it can't resolve, or that a
profile or inheriting pom overrides). A declaration at the literal base
version is something the planner would rewrite. It produces an edit,
not an uncertain entry, so the check ignored it.

Fix

attestable_checked now also withholds when the walk still finds a
declaration it would rewrite: Ok(edits.is_empty() && uncertain.is_empty()).
Right after a successful vendor the re-plan is idempotent, so that map
is empty. The unit tests' vendor() helper asserts this. A healthy
reactor therefore still attests. The same rule covers a module left on
an earlier patch's suffix, which builds that patch's jar, not this
one.

Tests (red → green)

Commands run locally (Linux, as root):

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --lib maven_reactor: 87 passed
• cargo test -p socket-patch-cli --test vendor_jvm_cli: passed
• cargo test -p socket-patch-cli --test e2e_vendor_jvm_build -- --ignored maven_reactor (Maven at /opt/maven): 2 passed
• cargo test --workspace --all-features --no-fail-fast: 15248 passed, 11 failed. None of the failures touch the JVM code, and none can pass in this sandbox. 9 simulate write or remove failures with file permissions, which root bypasses: repair ×2, in_process_redirect ×3, and core copy_tree, vlt_heal, pypi_poetry, pypi_requirements. The other 2 are e2e_bun_lockb: the patch API is unreachable through the sandbox proxy, and the local bun is 1.4.4. CI runs these as non-root with network access.

No wrapper changes are needed (npm/, pypi/, gem/ only dispatch to the binary).

/code-review high findings not fixed here

• A new root module that has no versioned declaration and no pin (e.g. its own external parent). Telling whether that root should be pinned depends on management outside the checkout. vendor --check resolves that through the local Maven repo (local_external_poms). A no-repo re-plan inside vex would wrongly withhold for roots vendor left unpinned on purpose (conflicting_managed_version / management_unresolved). This is a different shape from Vendored Maven reactor vex attests not_affected after a module added later declares the base version, although vendor --check flags the drift and that module builds Central's unpatched jar #584 and should be a follow-up that passes the local repo to vex's liveness check.
• Range or classifier declarations are only warned about and still attest. That was already true before this PR and already shows at the first vendor, so it isn't drift. Left for a separate issue.
• Perf: the liveness walk builds throwaway warning strings. It runs once per entry and is negligible next to Reactor::discover.

https://claude.ai/code/session_011f9aeRZEvH2uAFQPt5iJJJ

Generated by Claude Code