Run the version increment check only where the base ref is fetched

[alexander-yevsyukov]

Problem

Applying the latest config to a consumer repo (compiler) broke its Ubuntu CI build:

org.gradle.api.GradleException: Unable to read `version.gradle.kts` from base `origin/master`
(git exit code 128): fatal: invalid object name 'origin/master'..
Ensure the Version Guard workflow fetches the base branch before this check.

Root cause

Commit 12e586f taught CheckVersionIncrement to compare the project version against the base branch via git show origin/<base>:version.gradle.kts, and added the base-fetch step only to the dedicated Version Guard workflow (increment-guard.yml).

But checkVersionIncrement was a dependsOn of the check lifecycle task (added in #708), so it also ran inside ./gradlew build on every CI pull request — including build-on-ubuntu.yml, which does a shallow checkout and never fetches origin/master. The fail-closed comparison then aborted the build. Windows CI survived only by accident (it uses fetch-depth: 0, which makes origin/master resolvable).

The design note in the task doc had even recorded the faulty assumption verbatim: "no wiring change needed (both paths inherit the task)." That "inheritance" is exactly the bug — the check path fires in the plain build workflows, not just the dedicated Version Guard one.

Fix

Decouple the check from the check/build lifecycle so it runs only where its precondition (a fetched base ref) is guaranteed:

• IncrementGuard.kt — removed tasks.check.configure { dependsOn(checkVersion) } (and the now-unused base.check import). The CI gate stays with the Version Guard workflow (which fetches the base and posts the required status); the publishToMavenLocal dependency is unchanged for local integration-test publishes. KDoc/comments now explain why it is deliberately not wired into check.
• IncrementGuardTest.kt — replaced the old "depends on check" assertion with a regression guard asserting it does not, so this cannot silently regress.
• task doc — corrected the falsified design note and logged the incident.

Why this is safe

No coverage is lost. Every case the check path handled on a protected-branch PR is already covered by the dedicated Version Guard workflow, and the registry's immutability remains the final publish backstop. Locally, GITHUB_BASE_REF is unset, so publishToMavenLocal never did the base comparison anyway. Decoupling at the task level also fixes any consumer-specific build workflow, not just config's own.

Verification

JAVA_HOME=17 ./gradlew :buildSrc:build detekt is green; all IncrementGuardTest cases pass, including the new keep 'checkVersionIncrement' out of › the 'check' lifecycle task. Reviewed by spine-code-review, kotlin-engineer, and review-docs — all APPROVE.

Reviewer notes

• After this lands and compiler re-applies config, its Ubuntu CI will stop running the base-compare during build and pass.
• The per-repo branch-protection item from the original design (requiring the Version Guard status context) is unaffected and still applies.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This pull request fixes CI breakage caused by checkVersionIncrement running during generic ./gradlew build workflows that do not fetch the PR base branch ref, by decoupling the increment check from the check lifecycle and ensuring it runs only in contexts where its prerequisites are satisfied.

Changes:

• Removed checkVersionIncrement from the check lifecycle wiring so it no longer runs in generic CI build workflows (e.g. shallow Ubuntu builds).
• Kept checkVersionIncrement as a dependency of all publishToMavenLocal tasks for local integration-test publishing safety.
• Updated tests and task documentation to prevent regressions and to record the incident/root cause.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
buildSrc/src/main/kotlin/io/spine/gradle/publish/IncrementGuard.kt	Removes check dependency wiring; documents why the task must run only via the dedicated Version Guard workflow (with base ref fetched) and before publishToMavenLocal.
buildSrc/src/test/kotlin/io/spine/gradle/publish/IncrementGuardTest.kt	Updates wiring assertions: verifies publishToMavenLocal depends on the guard task and adds regression coverage that check does not.
.agents/tasks/version-guard-parallel-pr-revalidation.md	Corrects prior design note and records the regression incident and mitigation for future reference.