fix(release): build+install in release:prepare so cross-module test-jars resolve

.github/workflows/release.yml

@@ -81,13 +81,16 @@ jobs:
           git config user.name "github-actions[bot]"
           git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
 
-      - name: release:prepare (poms only; commits + tag vX; pushes to master)
+      - name: release:prepare (build+install, commits + tag vX; pushes to master)
+        # preparationGoals=clean install (in pom.xml): the modules cross-depend on core's test-jar,
+        # which only exists after core is packaged+installed, so a poms-only "validate" prepare cannot
+        # resolve it. -DskipTests keeps it fast; the "refuse red master" guard already gated on tests.
         run: |
           ./mvnw --batch-mode release:prepare \
             -DreleaseVersion=${{ inputs.releaseVersion }} \
             -DdevelopmentVersion=${{ inputs.developmentVersion }} \
             -DdryRun=${{ inputs.dryRun }} \
-            -Dlicense.skip -Darguments="-Dlicense.skip"
+            -Dlicense.skip -Darguments="-Dlicense.skip -DskipTests"
 
       - name: Deploy the release tag to Maven Central
         if: ${{ !inputs.dryRun }}

README.adoc

@@ -1382,7 +1382,7 @@ Releases use `maven-release-plugin` and are *tag-as-truth*: `release:prepare` ta
 To cut a release:
 
 . Run the *Release* workflow (Actions tab), supplying the release version (e.g. `0.6.0.0`) and the next development version (e.g. `0.6.0.1-SNAPSHOT`). Tick *Dry run* first to rehearse with no side effects.
-. It runs `release:prepare` (poms only, no build; tags `v<version>` and pushes the two version commits to `master`), then checks out that tag and deploys it to Maven Central via `.github/workflows/release.yml`, then creates a GitHub release. `master` returns to the next `-SNAPSHOT` automatically.
+. It runs `release:prepare` (builds+installs the reactor to validate the release compiles, then tags `v<version>` and pushes the two version commits to `master`), then checks out that tag and deploys it to Maven Central via `.github/workflows/release.yml`, then creates a GitHub release. `master` returns to the next `-SNAPSHOT` automatically.
 
 Required GitHub repository secrets:
 

docs/plans/2026-07-28-release-pipeline-hardening.md

@@ -95,6 +95,17 @@ deliberate human gate. If PR review of the release itself is a hard requirement,
 (release-please)** is the robust PR-native choice; **Option 2 is not recommended** — it reintroduces the
 merge-strategy fragility we're trying to eliminate.
 
+## Correction (post dry-run, 2026-07-28)
+
+The first dry run failed at `release:prepare` phase 10/17 (`run-preparation-goals`): `preparationGoals=validate`
+could **not resolve `bz.stub.parallelconsumer:parallel-consumer-core:jar:tests`** — the vertx/reactor/mutiny
+modules depend on core's *test-jar*, which does not exist until core is packaged+installed, so a poms-only
+`validate` prepare tries Central and 404s. Fix: **`preparationGoals=clean install`** with `-DskipTests` (passed
+via `release.yml`'s `-Darguments`). Prepare now builds+installs the reactor (producing the test-jars, resolving
+cross-module deps, and proving the release-versioned poms compile) but skips test execution — the "refuse red
+master" guard already gates on a green test run. "Poms only, no build in prepare" was not achievable given the
+inter-module test-jar dependency. The dry run did its job: it caught this with zero side effects.
+
 ## Detailed design (Option 1)
 
 **`.github/workflows/release.yml`** — `workflow_dispatch` (inputs: `releaseVersion`, `developmentVersion`):

pom.xml

@@ -599,10 +599,20 @@
                          release:prepare rewrites the poms, makes the two release commits
                          ("prepare release vX" + "prepare for next development iteration"), tags vX,
                          and PUSHES them to master (pushChanges=true) using a repo-admin PAT that
-                         bypasses the master ruleset's pull_request requirement. preparationGoals=validate
-                         keeps prepare pom-only (no build); release.yml then checks out the exact tag vX
-                         and deploys it. The tag is the single source of truth - nothing scans history. -->
-                    <preparationGoals>validate</preparationGoals>
+                         bypasses the master ruleset's pull_request requirement. release.yml then checks
+                         out the exact tag vX and deploys it. The tag is the single source of truth -
+                         nothing scans history.
+
+                         preparationGoals=clean install (not the "poms only" validate we first tried):
+                         the modules cross-depend on parallel-consumer-core's test-jar
+                         (bz.stub.parallelconsumer:parallel-consumer-core:jar:tests), which does not exist
+                         until core is packaged+installed. A validate-only prepare therefore fails to
+                         resolve it (tries Central, 404). "clean install" builds+installs the reactor so
+                         the test-jars are present, cross-module deps resolve, and the release-versioned
+                         poms are proven to compile before the tag is cut. -DskipTests (passed via
+                         release.yml's -Darguments) keeps prepare fast - the "refuse red master" guard
+                         already gates on a green test run. -->
+                    <preparationGoals>clean install</preparationGoals>
                     <pushChanges>true</pushChanges>
                 </configuration>
             </plugin>

src/docs/README_TEMPLATE.adoc

@@ -1133,7 +1133,7 @@ Releases use `maven-release-plugin` and are *tag-as-truth*: `release:prepare` ta
 To cut a release:
 
 . Run the *Release* workflow (Actions tab), supplying the release version (e.g. `0.6.0.0`) and the next development version (e.g. `0.6.0.1-SNAPSHOT`). Tick *Dry run* first to rehearse with no side effects.
-. It runs `release:prepare` (poms only, no build; tags `v<version>` and pushes the two version commits to `master`), then checks out that tag and deploys it to Maven Central via `.github/workflows/release.yml`, then creates a GitHub release. `master` returns to the next `-SNAPSHOT` automatically.
+. It runs `release:prepare` (builds+installs the reactor to validate the release compiles, then tags `v<version>` and pushes the two version commits to `master`), then checks out that tag and deploys it to Maven Central via `.github/workflows/release.yml`, then creates a GitHub release. `master` returns to the next `-SNAPSHOT` automatically.
 
 Required GitHub repository secrets: