[Mikola Lysenko (mikolalysenko)]

Stacked on #2005, including its review fix (9765178). This closes the two Maven false-attestation gaps #2005 left open in VEX discovery.

1. Profile <properties> redefining a pin's property

Take a live <version>${v}</version> whose build resolution is the Socket pin. If any profile's <properties> redefine v, or any property v names, Maven resolves something else while that profile is active: it merges active profile properties over the pom's own before it interpolates. Vendored mode refuses to pin over such a property (version_override), but discovery attested it.

• PomScope now reads each profile's <properties>.
• Each PomDep gains version_alternatives: the other versions its build_version can take under any profile, or any set of profiles active together.
  • User properties and project.* / pom.* model references stay fixed.
  • A value that some set leaves unresolved, cyclic or too deep counts as the text as written.
• A new resolutions(d, in_profile) helper lists every version the build may resolve for a declaration: its build_version, then each alternative. It plugs into Stop attesting Maven pins a profile or user property overrides #2005's helpers in three places:
  • unpatched_classifier_copy: live and profile classifier copies and their classifier-keyed management.
  • profile_override, profile declarations: every version they can take is checked against the pin.
  • profile_override, live declarations: it now also walks live main-jar declarations, with the same main_jar_declarations scope and management-governs filter. A declaration whose build_version is the pin but has an alternative off it keeps the ref, marked unattested with the existing UnattestedKind::MavenProfileUnpatched. This applies to hosted pins and the pre-v5 vendored wiring alike. No new variant was needed; the variant doc, the CLI note text and CLI_CONTRACT.md are updated.
• A <profiles> declaration's own ${v} reads its own profile's <properties> first.

2. Property versions resolved one level deep

${a} with <a>${b}</a> now resolves through every property it names, in both views PomDep keeps since #2005:

• version (as the pom spells it, which hosted writes and rolls back): the model, then the declaration's own profile's <properties>, then the root <properties>.
• build_version (as the build resolves it): .mvn/maven.config -D user properties first, at every level. project.* / pom.* stay the model's.

It follows the vendored reactor's limits: at most 16 levels, and a cycle, an undefined name or an unterminated ${ never resolves. The version then stays as written, which is never a pin. Partly literal versions (${a}.${b}-x) resolve too, and ${project.version} resolves from the model in both views. #2005's MavenConfigOverride check (spelled vs built effective versions) therefore also catches a user property that redefines a nested property.

Shared interpolator

The vendored reactor's interpolator moves to formats/maven (still pure). That covers both interpolate_by and the duplicate body of Reactor::interpolate_with.

• It is now interpolate_strict, a single-valued wrapper over interpolate_each. interpolate_each enumerates every value a name can take, capped at 16 results.
• The reactor calls it with its own chain-walking lookup, and Reactor::interpolate drops its depth argument, which was always zero.
• New in both modes: explicit cycle detection, plus work bounds of 1024 lookups and 4096 bytes. A pom whose properties each name the next one many times over now fails closed instead of expanding exponentially.
• Vendored behavior is otherwise unchanged.

Tests

Each of these fails before this change:

• vex::discover::maven::tests::profile_properties_redefining_a_pin_property_are_not_attested covers the base release, a nested property, an undefined value, a self-cycle, two profiles that move the pin only together, a managed pin, and a user property that wins over every profile.
• vex::discover::maven::tests::profile_declaration_reads_its_own_profile_properties
• vex::discover::maven::tests::version_property_resolves_through_nested_properties covers a 16-deep chain (resolves), a 17-deep chain (does not), two cycles and nested user overrides.
• vex::discover::maven::tests::vendored_ref_under_profile_properties_is_not_attested
• formats::maven::tests::{version_properties_resolve_recursively_and_fail_closed, profile_properties_give_version_alternatives, interpolation_is_bounded}. These also assert that a nested user property moves build_version but not version.

Changed expectation after the rebase. In version_property_resolves_through_nested_properties, the case where the pom resolves the base release and -Dp1=<pin> in .mvn/maven.config supplies the pin through a nested property now expects no attestation. Under #2005's review fix, a Socket version that only maven.config supplies is not pom.xml wiring: hosted never writes one and rollback / remove never edit .mvn/maven.config. It is diagnosed (patched_ref_unattributable), never a ref. Nested resolution now applies that rule to nested properties too.

Runs, on the rebased branch (ec89bd9):

• cargo test -p socket-patch-core --lib -- vex::discover:: formats::maven vendor::jvm:: passes 715. patch::redirect:: together with the golden test passes 872.
• The golden corpus is unchanged (committed_fixture_corpus_matches_golden passes).
• cargo test -p socket-patch-cli --lib vex_sources passes 14.
• cargo clippy --locked --workspace --all-features -- -D warnings and cargo fmt --all -- --check are clean.

Not done

• Coordinates moved by profile properties. A <groupId> / <artifactId> that is a property a profile redefines is the same class of gap; it is handled in Withhold Maven pins whose coordinates a profile redefines #2026, stacked on this branch.
• Activation is not evaluated. Every profile counts, as in vendored mode.

🤖 Generated with Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: merge conflict needs a decision (left unmerged, nothing pushed).

This PR now conflicts with its base fix/maven-discovery-false-attestation (#2005) after 9765178 ("Address review: Maven discovery bypass checks match Maven precedence"). Both sides changed the same version-resolution behavior in incompatible ways, in formats/maven/mod.rs (6 hunks), vex/discover/maven.rs (3 hunks) and CLI_CONTRACT.md (2 hunks):

• Stop attesting Maven pins a profile or user property overrides #2005 (base) splits PomDep::version (one-level, root <properties> only — what the hosted rewriter writes and rolls back) from a new build_version (user properties first, project.*/pom.* exempt), and reports a pin that .mvn/maven.config moves under a new UnattestedKind::MavenConfigOverride (vex_maven_config_override). It also narrows profile <dependencyManagement> to "only where management governs the pin" and drops the profile-classifier case from MavenProfileUnpatched (moved to MavenClassifierUnpatched).
• This PR makes PomDep::version the full strict interpolation (user properties, model, own profile, root; 16 deep) with version_text and version_alternatives, adds fixed / profile_properties to PomScope, and folds user-property and profile-property moves into MavenProfileUnpatched.

Question: should this PR be rebuilt on #2005's split — keep version = pom-spelled for the rewriter, put the strict/recursive interpolation into build_version (plus version_alternatives from profile <properties>), keep MavenConfigOverride for .mvn/maven.config moves and use MavenProfileUnpatched only for profile-driven moves? Or should #2005's split be replaced by this PR's single version? Once you choose, the conflict can be resolved mechanically. Since #2026 is stacked on this branch, it may be simpler for the author's own stack tooling to restack it.

---

Generated by Claude Code