[Mikola Lysenko (mikolalysenko)]

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

Fixes #1809

Summary

Maven 4 builds every direct subdirectory holding a pom.xml under a 4.1.0, pom-packaged root that lists no <subprojects>/<modules>. #1807 taught this to the vendored reactor planner. Every other place that asks "is this a reactor?" still used maven_reactor::declares_modules, which only sees lists that are written out. The user-visible results:

• Hosted scan pinned only the root pom while a module kept its own literal <version>. It reported the dependency as redirected, and the build still used the unpatched jar.
• VEX attested that root pin as not_affected instead of reporting vex_maven_reactor_root.
• Vendored sbt: the vendor_jvm_build_ambiguous guard let such a pom root sitting next to build.sbt through.
• Project-mode Maven cache scope didn't seed the discovered modules' dependencies, so a hosted or agent crawl scoped them out.

Root cause and fix

The reactor rule existed only inside Reactor::discover. It is now exposed from vendor/jvm/maven_reactor.rs, and every caller uses it:

• is_reactor_root(read, list): declared lists, or Maven 4 discovery with at least one discovered subproject.
• may_discover_subprojects(pom, maven_config): the planner's discovers_subprojects, plus the maven.project.discoverSubprojects opt-out (now one discovery_on helper, shared with the planner).
• implicit_subprojects / implicit_subprojects_in(view): the one probe for "a direct subdirectory holding a pom.xml", with .git excluded.

Callers:

• patch/redirect/mod.rs rewrite_maven_pom refuses the root with redirect_maven_multimodule_unsupported.
• hosted/engine.rs read_candidate_files reads each discovered <dir>/pom.xml as advisory input. These files are never edited, and an unreadable one still counts as present. The rewriter needs them to decide.
• hosted/engine.rs confirm: module poms never feed the needle probe. Once the root is refused as a reactor, a stale suffixed version in pom.xml / .mvn/ (written by an older release) no longer confirms the dependency. Code review raised this; it also covers declared reactors from Hosted Maven mode edits only the root pom of a multi-module build, leaves child literals unpatched, and still attests VEX #261.
• vex/discover/maven.rs: an implicit reactor root's hosted pin is marked unattested (MavenReactorRoot).
• vendor/jvm/sbt.rs plan / plan_with_digest now take a ListFn, so the ambiguity guard sees discovered subprojects.
• vendor/jvm/mod.rs detect / detect_builds take a ListFn, so MavenShape classifies correctly.
• crawlers/maven_scope.rs: discovered subprojects (recursively, as Maven does) seed the scope.
• CLI_CONTRACT.md: the hosted Maven rewriter and vex_maven_reactor_root text now cover discovered reactors.

Tests (red → green)

Each new test fails with discovery stubbed out (may_discover_subprojects forced to false) and passes with the fix. Six tests failed in the red run. The stale-pin case was checked separately by disabling the new probe filter.

Caller	Test
Hosted rewriter	patch::redirect::tests::maven_4_implicit_subprojects_root_is_refused (also controls: no subproject, model 4.0.0, discovery off)
Hosted engine, disk and memory, plus stale pins	hosted::engine::tests::a_maven_4_implicit_reactor_root_is_refused
VEX	vex::discover::maven::tests::hosted_pin_in_a_maven_4_implicit_reactor_root_is_not_attested (same controls)
sbt ambiguity guard	vendor::jvm::sbt::tests::detect_routes_sbt_and_keeps_existing_backends (new implicit-root case, plus a lone-root control)
MavenShape	vendor::jvm::tests::a_maven_4_implicit_subprojects_root_is_a_reactor
Cache scope	crawlers::maven_scope::tests::maven_4_discovered_subprojects_seed_the_scope (discovery on and off)

Run locally:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test --workspace --all-features --no-fail-fast: every Maven/JVM, hosted, VEX and crawler suite passes. 11 failures, all from the sandbox and none in code this PR touches: (a) write/unremovable-file tests that can't simulate a failure as root (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_…, pypi_requirements::wire_failure_rolls_back_…, three in in_process_redirect, two in repair), which other agent PRs also report; (b) two e2e_bun_lockb tests that need the live patch API (patches-api.socket.dev), blocked by the sandbox proxy (tunnel error: unsuccessful)

There is no local Maven 4 e2e. The CI real-Maven legs (e2e_redirect_maven_build, e2e_vendor_maven_build) run against this change.

Review notes (code-review high)

Fixed:

• Advisory module poms fed the confirmation probe.
• A stale root pin was confirmed after a refusal.
• The subproject probe was implemented four ways.
• A doc comment was misplaced in maven_scope.rs.
• The CLI contract was out of date.

Not changed, deliberately:

• sbt::legacy_pom_wired keeps declares_modules. It recognizes pre-v5 single-pom wiring, which read only the root pom and so could have wired a Maven 4 implicit root. Switching it to is_reactor_root would route such a legacy-wired root to sbt and orphan its <repository> wiring, which vendor --revert must unwind first.
• detect / detect_builds take a ListFn only for MavenShape, which nothing outside tests reads today. I kept it so Detected doesn't misreport an implicit reactor as Single. The extra listing happens only when the root pom is a discovering 4.1.0 pom.
• maven_scope reads a reactor pom a second time to check discovery. That cost is one small file read per reactor pom on the crawl path. Moving the flag into PomModel would mean changing the parser shared with the planner, so I left it out of this fix.

https://claude.ai/code/session_011f9aeRdqEhwVwx91en466Q

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[burn-down agent] Labeled Ready for review at b57c4a5.

• CI: 82/82 checks green on b57c4a5; mergeable.
• Bugbot: Cursor Bugbot check passed on b57c4a5 with no findings.
• Reviewer note: callers outside the vendored reactor planner now detect Maven 4 implicit subprojects, not just <modules> declarations.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does: Maven 4 builds every direct subdirectory that has a pom.xml when the root pom is model 4.1.0, has pom packaging and lists no modules. Until now only the vendored planner knew this rule. This PR moves it into shared helpers in maven_reactor.rs and uses them in the hosted rewriter and engine, VEX, the sbt guard, detect/MavenShape and the crawler's Maven scope. It also stops confirm() from accepting a stale suffixed pin in a refused reactor root.

Risk: low to medium. The logic reuses the planner's existing predicate, and the ListFn signature change is mechanical. One visible behavior change also reaches declared reactors (#261): a stale pin in a refused root or in .mvn/ no longer counts as redirected, so re-runs on projects patched by older releases will report differently. That is the more correct result, and the description states it.

Look here

• maven_reactor.rs:79:`` is_reactor_root, and L104:``` `implicit_subprojects_in`
• engine.rs:742: module poms read as advisory input only (never written, kept out of the symlink/undecodable guards)
• engine.rs:3275: the is_unpinned_maven filter in confirm
• maven_scope.rs:476: implicit-subproject listing in the crawler scope
• vex/discover/maven.rs:165: the VEX side

Verified: I read the full diff. The rewriter, VEX and the planner all use the same probe and exclude .git the same way. Maven isn't served by the in-memory engine, so that path is unaffected. There is no debug code, and CHANGELOG.md is untouched. CI is 82/82 green. Bugbot passed and left no comments.

Changes I made: none.

Open questions:

• Is reporting stale pins in declared (Hosted Maven mode edits only the root pom of a multi-module build, leaves child literals unpatched, and still attests VEX #261) reactor roots as unconfirmed the intended behavior for existing users?
• Nits:
  • engine.rs:756 reads each module pom's full text, but only the key is used.
  • The maven_scope.rs:476 listing doesn't resolve paths before deduplicating them, so an a -> . symlink loop wastes a crawl until MAX_REACTOR stops it.

Auto-merge is armed, so approving sends this straight to the merge queue.

---

Generated by Claude Code