graphitron-model ships its junit-platform.properties to four consumers that never asked for it

Re-verified at 7a3fae6e while measuring the build for R733’s fourth pass, because a leak this quiet is worth confirming rather than assuming. junit-platform.properties is still an entry in the installed graphitron-model-10-SNAPSHOT-tests.jar, and graphitron-lsp, graphitron-mcp and graphitron-maven-plugin all still consume that test-jar at test scope. Nothing has changed about the mechanism or the exposure since this item was filed.

One figure for the ordering argument, from the same pass: those three modules now spend 89.5 s, 44.7 s and 33.3 s in surefire:test. The parallelism the leak supplies is real time nobody declared, so settling this cannot mean simply stripping the entry without deciding what replaces it.

graphitron-maven-plugin is the consumer this item originally missed, and it is where the predicted symptom first surfaced: CatalogRefreshTest.javaSourceWriteMovesTheStoreRowWithoutAGeneratorPass failed twice on one machine on 2026-08-25 (both on the cold first build of a session, passing on rerun and in isolation), because its 1.6 s latch budget competes with `DevMojoTest’s ~13 s of generator work under the four-way class parallelism this leak enables, parallelism the module’s own pom and test resources never mention. R832 owns the test’s budget; this item owns the channel. A Spec pass should answer its questions for all four consumers, not three.

The second one arrived in graphitron-lsp on 2026-08-27: LspTraceTest.doubleCloseIsIgnored counts close lines in a sink it rebinds JVM-wide and read two, because a class running beside it opened a span while it held tracing on. R860 owns that test and takes this module’s concurrency as given; this item still owns the channel. Worth noting for the questions below: the draft of R860 reasoned from `graphitron-lsp’s pom and test resources that the module "declares no parallel execution at all today" and looked for the cause elsewhere, which is the invisible-provenance cost predicted above, paid.

Re-measured on the 2026-08-27 tree by the system-property arm switch below rather than by stripping the jar, one pair per module, mvn test -pl <module> -Plocal-db, all six arms green:

So 62 s across the three consumers on this machine, against the 25 s measured in August over two of them. What pins the arms beyond the totals is the sum of the per-class elapsed times surefire reports for graphitron-lsp: 591.1 s in the concurrent arm against 96.6 s in the sequential one. A sum can only exceed the module total when class wall-clocks overlap, and it lands within a couple of seconds of it when they do not, so the two arms are what they claim to be without trusting either total.

graphitron/pom.xml configures maven-jar-plugin’s `test-jar goal with an explicit exclusion, and the comment beside it states the hazard exactly:

graphitron-model/pom.xml has no such exclusion, because when its test-jar was set up the module had no properties file. The file arrived later, and nothing connected the two facts. The predicted warning is now in the tree, in graphitron/target/surefire-reports/null-output.txt:

graphitron is unharmed in behaviour: its own file is in target/test-classes, which precedes dependency jars on the classpath, so its own configuration wins and the second copy is only noise. graphitron-lsp and graphitron-mcp have no file of their own, so for them the second copy is the only copy and it takes effect.

mvn test -pl :<module> -Plocal-db, arms alternated, the properties entry removed from and restored to the installed test-jar between runs so that nothing else differs.

Repeatable to under half a second per arm. User CPU time is about 115 s for graphitron-lsp in both arms, which is worth noting because it means these tests were always multi-threaded internally, from the language server, the tree-sitter natives and the async warm-up; what the file adds is overlap between classes, not threads where there were none.

So this is 25 seconds of a 339-second build, arriving by accident, and the accident is the only reason anyone would find it. A separate measurement of the same change reported "lsp and mcp: nothing", taken with -pl against an installed graphitron-model test-jar that predated the change. That is the footgun CLAUDE.md warns about under the scoped-build command, and it is worth recording here as the reason the number was missed rather than as an aside: a -pl A/B is only valid when the arm being varied is what got installed.