Complete the v0.2.0 implementation audit

docs/roadmap/releasekit.md

@@ -1,7 +1,8 @@
 # ReleaseKit: shared release process
 
-Status: Initial implementation, policy adoption, and architecture remediation
-are complete. Consumer adoption and live CI integration work remain.
+Status: The v0.2.0 implementation, policy adoption, and architecture
+remediation are complete. Audita's module-selected local and CI integration is
+committed at `17421bc`; broader consumer adoption and live deployment remain.
 
 This roadmap records the shared release-process opportunity identified in
 PromptKit, ConfigKit, Audita, Notarius, Narratio, and Scriptorium on 2026-09-29,
@@ -9,8 +10,9 @@ and the remaining adoption goals. The [internal package inventory](../internal/o
 records implemented capability owners and behavioral evidence. The
 [architecture policy](../policy/architecture.md) and
 [ADR 0001](../adr/0001-public-facade.md) own the facade boundaries and rationale.
-The completed implementation, policy adoption, and remediation plans are
-preserved in Git history.
+The initial foundation, policy adoption, and remediation plans are preserved
+in Git history; the current v0.2.0 completion evidence is in the
+[implementation plan](implementation.md).
 
 ## Opportunity
 
@@ -212,7 +214,7 @@ These are migration assessments, not changes to either consumer.
 
 | Consumer | Retain in its profile and product checks | Adaptation and procedure changes |
 | --- | --- | --- |
-| PromptKit, source-only | Product identity; its `Summary`, `Compatibility`, `Upgrade`, and `Changes` release-note sections; checks that exercise the three maintained Go examples and their product outputs. No runtime `buildinfo` import or binary targets are needed. | Its current release scripts total 209 lines. The projected deletion is about 120–160 lines of shared publication and generic validation machinery; retain the note-content rule and product-example checks as a configured additional check plus a small wiring test. PromptKit already pushes `main` before publication and creates annotated tags. Its release policy and procedure still need to add the hosted note page, delivery credentials, versioned CI invocation, and separate delivery status and recovery. |
+| PromptKit, source-only | Product identity; its `Summary`, `Compatibility`, `Upgrade`, and `Changes` release-note sections; checks that exercise the three maintained Go examples and their product outputs. No runtime `buildinfo` import or binary targets are needed. | Its current release scripts total 209 lines. The projected deletion is about 120–160 lines of shared publication and generic validation machinery; retain the note-content rule and product-example checks as a configured additional check plus a small wiring test. PromptKit already pushes `main` before publication and creates annotated tags. Its release policy and procedure still need to add the hosted note page, delivery credentials, module-selected CI invocation, and separate delivery status and recovery. |
 | Narratio, binary | Product/module identity, the `./cmd/narratio` main package, `narratio` executable name, Linux amd64, Linux arm64, and macOS arm64 targets, and the `narratio <version>` command. Keep the module-graph check (`go mod tidy -diff`) if it remains useful as a product-specific candidate check. | Its release, check, asset-builder, and helper scripts total 304 lines; two dedicated release test files total 741 lines. Projected deletions are about 220–280 shell lines and 450–650 repeated test lines, leaving a small consumer wiring test and any retained module/note checks. Replace the private linker-version variable with `buildinfo.Version()` while preserving the current command output. Its policy and procedure need to change lightweight tags to annotated tags, state that a successful tag push completes source publication, and move plugin-based page/assets delivery to the shared versioned CI command with content-aware retries and separately provisioned delivery credentials. |
 
 The deletion figures are estimates from the reviewed files, not measured
@@ -227,14 +229,16 @@ publication and delivery operations.
 
 ## Remaining work
 
-- Use the [v0.1.0 baseline](../releases/v0.1.0.md) for initial consumer integration
-  under the [maintainer procedure](../release.md).
+- Use the [v0.1.0 baseline](../releases/v0.1.0.md) for initial consumer
+  integration under the [maintainer procedure](../release.md). Consumers that
+  adopt the maintained tag workflow select ReleaseKit through the tagged
+  source's `go.mod` rather than a separate workflow version value.
 - Choose the broader consumer integration test plan and migration sequence.
   Evaluate API clarity, product-specific checks, and the infrastructure removed
   from each consuming repository.
 - Provision delivery credentials and activate consumer Woodpecker workflows
-  using the maintained example's `v0.1.0` pin or a later selected immutable
-  version as part of deployment.
+  as part of deployment. The tagged consumer's module configuration selects
+  the ReleaseKit version used by the maintained workflow.
 - Verify live Gitea delivery and Woodpecker execution. Existing verification uses
   local Git and HTTP fixtures; no live deployment has been verified.
 - Keep ReleaseKit executable binary distribution deferred until deliverables