Complete the v0.2.0 implementation audit

docs/roadmap/v0.2.0.md

@@ -1,10 +1,15 @@
 # ReleaseKit v0.2.0 roadmap
 
-Status: Agreed feature scope; implementation planning is recorded separately.
+Status: Implemented and locally verified. Stages 1–15 are complete; see the
+[implementation plan](implementation.md) for the completion record. Audita's
+module-selected local and CI integration is committed at `17421bc`. Broader
+consumer adoption, architecture review, hosted deployment, and release tagging
+remain separate work.
 
 This roadmap catalogs improvements to ReleaseKit v0.1.0. Each item records its
 rationale, target state, and relevant scope decisions. The
-[implementation plan](implementation.md) owns the staged work.
+[implementation plan](implementation.md) owns the staged work and verification
+evidence.
 
 The priorities in [ADR 0002](../adr/0002-routine-releases.md) guide this work:
 minimize application-owned release code, duplicated mechanics, and routine
@@ -12,13 +17,13 @@ developer decisions through a standard, minimal API.
 
 ## 1. Establish the shared validation API and profile model
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 The shared validation foundation and its remediation are complete. ReleaseKit
 has common candidate execution, facade-owned diagnostics, committed-file
 inspection, and a product-specific additional-check extension point. The
-optional v0.2.0 capabilities still need their functioning API/profile selections
-and checker implementations.
+optional v0.2.0 capabilities now have functioning API/profile selections and
+checker implementations.
 
 The [validation-model roadmap](model.md) records this enabling work and its
 rationale. A common model lets consumers declare choices once and receive
@@ -32,17 +37,16 @@ ReleaseKit owns coordination and diagnostics through the existing `Check` and
 `Publish` operations. Product-specific checks, publication expectations,
 artifact builds, and delivery retain their distinct responsibilities.
 
-Completion should provide equivalent Go and profile declarations for the
+The implemented API and profile provide equivalent declarations for the
 validation capabilities below through the existing shared foundation.
 
 ## 2. Use the application's module-selected ReleaseKit version in CI
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
-The maintained [CI template](../../examples/woodpecker/tag-delivery.yml) selects
-ReleaseKit through a separate `RELEASEKIT_VERSION` value and invokes its command
-with an explicit `@version`. The [adoption guidance](../consumers/delivery.md#woodpecker-tag-workflows)
-instructs consumers to maintain that workflow pin.
+At the v0.1.0 planning baseline, the maintained CI template selected ReleaseKit
+through a separate `RELEASEKIT_VERSION` value and invoked its command with an
+explicit `@version`.
 
 Audita demonstrates the resulting duplication: its local release wrapper builds
 ReleaseKit using the application's module dependencies, while CI independently
@@ -51,6 +55,9 @@ Maintainers must remember to coordinate both declarations.
 
 Using the application's module-selected version for both paths gives upgrades
 one dependency declaration and keeps local publication and CI delivery aligned.
+Stages 12–14 changed the maintained template and Audita's workflow to this
+approach; the current [adoption guidance](../consumers/delivery.md#woodpecker-tag-workflows)
+describes it.
 
 ### Target end state
 
@@ -69,14 +76,15 @@ validation and builds. Source publication and hosted delivery retain separate
 outcomes. ReleaseKit's own source bootstrap and consumers using a separately
 installed tool remain supported use cases.
 
-Audita adopts the module-based integration as the first consumer migration.
+Audita adopted the module-based integration as the first consumer migration in
+commit `17421bc`.
 
-Completion should leave downstream maintainers with one ReleaseKit dependency
-update for this integration and a maintained template they can adopt directly.
+The maintained template and Audita's first migration now use one ReleaseKit
+module declaration for local and hosted integration.
 
 ## 3. Select one base test invocation, including race testing
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 ReleaseKit always runs its standard offline Go suite before additional product
 checks. ConfigKit selects race-enabled testing for its release validation.
@@ -99,12 +107,13 @@ scope, offline execution, ordering, and failure reporting. Additional product
 checks remain available after shared validation. Selecting race testing reports
 unavailable prerequisites clearly and preserves the selected validation.
 
-Completion should let ConfigKit and PromptKit select a race-enabled suite once
-and remove the corresponding consumer-owned test invocation.
+The API and profile now let ConfigKit and PromptKit select a race-enabled suite
+once and remove the corresponding consumer-owned test invocation when they
+adopt the selection.
 
 ## 4. Offer a separate full vet pass
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 ConfigKit and PromptKit currently run a full `go vet` pass in addition to their
 test suites. ReleaseKit relies on test-time vet unless a consumer supplies an
@@ -121,12 +130,12 @@ with failures reported through the ordinary check and publication flow.
 The option preserves current defaults for consumers that leave it unset.
 ReleaseKit owns the offline command and its coordination with base testing.
 
-Completion should replace ConfigKit's and PromptKit's separate vet commands and
-manual test-time vet settings with one declarative choice.
+The API and profile now support replacing ConfigKit's and PromptKit's separate
+vet commands and manual test-time vet settings with one declarative choice.
 
 ## 5. Verify package compilation for selected targets
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 ReleaseKit's existing build declaration selects executable artifacts and their
 delivery. ConfigKit is a source-only library that checks package compilation
@@ -148,12 +157,12 @@ require no binary name, version smoke command, or artifact manifest. Successful
 compilation establishes build compatibility; execution on a target remains a
 separate concern. Consumers select targets for their support commitments.
 
-Completion should let ConfigKit declare its two Linux targets and remove its
-release-specific compilation loop.
+The API and profile now let ConfigKit declare its two Linux targets and remove
+its release-specific compilation loop when it adopts the selection.
 
 ## 6. Check an optional expected publication endpoint
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 ReleaseKit resolves and captures the selected remote's push endpoint and
 rechecks it during publication. ConfigKit additionally declares an expected
@@ -173,12 +182,12 @@ The expectation applies to the publication destination. Fetch configuration
 retains its existing semantics, and `Check` retains its local-only behavior.
 Consumers that omit the expectation keep the current remote-selection model.
 
-Completion should let consumers declare the intended push destination without
-maintaining their own publication preflight logic.
+Consumers can now declare the intended push destination without maintaining
+their own publication preflight logic.
 
 ## 7. Offer Go formatting validation
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 PromptKit maintains a shell loop that enumerates tracked Go files and checks
 their formatting. ReleaseKit currently leaves this generic mechanism to
@@ -196,12 +205,12 @@ Consumers select the capability once and rely on ReleaseKit for enumeration,
 format checking, and failure reporting. Existing validation defaults remain
 unchanged when the option is unset.
 
-Completion should let PromptKit remove its local formatting loop and select
-the shared check through its release profile.
+PromptKit can now remove its local formatting loop and select the shared check
+through its release profile when it adopts the capability.
 
 ## 8. Offer offline Markdown-link validation
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 PromptKit's largest generic validation block is a local Markdown-link checker.
 It owns parsing, destination resolution, heading anchors, and diagnostics.
@@ -232,12 +241,12 @@ the checkout a validation failure, using the same parser and diagnostics.
 Boundary validation remains independent of neighboring checkout contents.
 Existing validation defaults remain unchanged when the option is unset.
 
-Completion should let PromptKit replace its local Markdown checker with a
-profile selection and rely on shared parsing rules and diagnostics.
+PromptKit can now replace its local Markdown checker with a profile selection
+and rely on shared parsing rules and diagnostics when it adopts the capability.
 
 ## 9. Offer module-distribution checks
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 PromptKit checks that released source is independent of neighboring checkouts
 by excluding committed workspace files and local filesystem module replacements.
@@ -260,12 +269,12 @@ The checks inspect candidate contents independently of the Go test environment.
 `Check` and `Publish`, including their CLI forms, apply the same offline,
 read-only checks. Omitted selections preserve current defaults.
 
-Completion should let PromptKit declare its distribution requirements and
-remove the corresponding consumer-owned checks.
+PromptKit can now declare its distribution requirements and remove the
+corresponding consumer-owned checks when it adopts the selections.
 
 ## 10. Offer an individual-file-size check
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 Unintentionally committed binaries and large assets can increase the size of
 released source. ReleaseKit currently leaves file-size inspection to consumers.
@@ -286,5 +295,5 @@ repository size remain separate concerns. `Check` and `Publish`, including
 their CLI forms, use the same offline, read-only inspection. The check is
 disabled by default.
 
-Completion should let consumers catch oversized candidate files through a
-small declaration and remove any corresponding local inspection code.
+Consumers can now catch oversized candidate files through a small declaration
+and remove corresponding local inspection code when they adopt the check.