fix: join the build lifecycle with dependsOn, not finalizedBy

[jimisola]

Closes #88.

What & Why

Since 0.1.2, a consumer that declares its own build.dependsOn(assembleRequirements) fails at configuration time — nothing compiles:

Circular dependency between the following tasks:
:assembleRequirements
\--- :build
     \--- :assembleRequirements (*)

0.1.2 added build.finalizedBy(assembleRequirements), which says the task runs after build. The consumer's line says before. Gradle rejects the contradiction.

Consumers had every reason to have written that line. 0.1.0 and 0.1.1 shipped no lifecycle wiring at all, while the 0.1.0 README documented assembleRequirements as "Depends on check task (ensures tests have run)" and "Runs automatically as part of build task". The plugin implemented neither, so consumers wired it by hand to get the documented behaviour — and 0.1.2 added the opposing edge with no migration note. Affected: 0.1.2, 1.0.0 and main; 0.1.1 is the last clean version.

The fix

Wire build dependsOn assembleRequirements dependsOn check instead of build finalizedBy assembleRequirements.

Same execution order — the task still runs after the tests whose XML it reads — but dependsOn composes where finalizedBy contradicts. dependsOn is idempotent, so an existing consumer's line becomes redundant rather than fatal, and no consumer has to edit its build file.

It also makes gradle assembleRequirements on its own meaningful: it now runs check first, so the zip contains test results instead of silently omitting them. Verified — running the task standalone produces both test_results/*.xml.

Verification

New BuildLifecycleWiringTest drives a real consumer project through TestKit. --dry-run is deliberate: a circular dependency is raised while Gradle builds the task graph, so the regression reproduces without compiling or resolving anything — the suite stays fast and offline.

I confirmed the test fails against the old wiring before making it pass:

BuildLifecycleWiringTest > consumerDeclaringBuildDependsOnAssembleRequirementsStillConfigures() FAILED
    org.gradle.testkit.runner.UnexpectedBuildFailure
3 tests completed, 1 failed

tests/fixtures/test_project structurally cannot catch this — it declares no wiring of its own, so it only ever exercises the case where the plugin is the sole author of these edges. That is why CI stayed green through the regression.

End-to-end, with the fixed plugin published to mavenLocal and the fixture given the wiring that used to break:

> Task :test
> Task :integrationTest
> Task :check
> Task :assembleRequirements
> Task :build
BUILD SUCCESSFUL

Zip contents unchanged and correct — requirements.yml, software_verification_cases.yml, annotations.yml carrying both SVC_001 and SVC_002, both test-result XMLs, reqstool_config.yml.

Docs

README.md, docs/ (usage, configuration, index) and CLAUDE.md all described build as finalized by the task. Updated, including a note that an existing build.dependsOn(assembleRequirements) is now redundant but harmless.

Author checklist

• Conventional Commit title
• DCO sign-off
• ./gradlew build green, formatting applied via ./gradlew format
• New test verified to fail before the fix
• End-to-end validated against tests/fixtures/test_project
• Docs updated to match behaviour

Test Plan

1. ./gradlew build — all tests pass, including the three new lifecycle tests.
2. Revert the one-line wiring change and re-run: consumerDeclaringBuildDependsOnAssembleRequirementsStillConfigures must fail with Circular dependency.
3. From tests/fixtures/test_project, add tasks.named('build') { dependsOn(tasks.named('assembleRequirements')) } and run gradle build against a locally published plugin — configures and builds; check precedes assembleRequirements.

Note for release

This wants a patch release so affected consumers can move forward — 1.0.0 carries the regression, so the fix version is 1.0.1. Until then the workaround is to delete the manual wiring, which #88 records.