Clarify the ReleaseKit adoption roadmap

docs/roadmap/releasekit.md

@@ -4,7 +4,7 @@
 **Status:** Implementation complete; first adopting release and live delivery
 observation pending.
 
-## Purpose and Baseline
+## Purpose and Original Baseline
 
 Implement the decision in [ADR 0001](../adr/0001-releasekit.md): standardize
 Audita's release process on ReleaseKit to improve maintainability and reduce
@@ -26,6 +26,21 @@ The adoption baseline is ReleaseKit v0.1.0, commit
 mechanics. The upstream test suite passes; its documentation records live
 Woodpecker/Gitea verification as remaining deployment work.
 
+## Current Baseline
+
+The adoption implementation is now present: `go.mod` selects ReleaseKit
+v0.1.0, `releasekit.json` supplies Audita's product and delivery facts,
+`scripts/release.sh` builds and forwards arguments to its executable, and
+`.woodpecker/release.yml` invokes the same pinned version for tag delivery.
+The application exposes `audita version` through `buildinfo`; the custom
+release builder has been removed. The sections below retain the intended
+adoption scope rather than describing work that still needs implementation.
+
+The [adoption review](remediation.md) records focused CLI and wiring-test
+findings and their resolution status. Remaining implementation corrections
+belong there. First-release delivery observation remains deployment work,
+separate from source-release completion.
+
 ## Target End State
 
 - ReleaseKit owns candidate validation, source publication, version injection,
@@ -75,7 +90,7 @@ ReleaseKit's retained-artifact workflow remains available when a delivery retry
 needs the original bytes. Follow its content-aware recovery behavior rather
 than reproducing that machinery in Audita.
 
-## Work Required
+## Adoption Scope
 
 ### Dependency, Profile, and Tool Entry Point
 
@@ -170,10 +185,20 @@ Adoption is complete when:
   mechanics tests and the old builder have been retired.
 - Current documentation and attribution describe the adopted behavior.
 
+## Remaining Release and Deployment Work
+
+Prepare the first adopting release under the [release procedure](../release.md),
+including a release note explaining the maintainer workflow change. Resolve
+outstanding adoption-review findings through the linked remediation record.
+Version selection and publication timing remain release-preparation decisions.
+
 Offline integration evidence and live delivery observations are distinct.
 Observe the shared workflow during the first adopting release and address any
-deployment failures through delivery recovery. CI success or asset availability
+deployment failures through ReleaseKit's delivery recovery. Check that the
-does not become a source-release completion gate.
+tagged commit, hosted note with its licensing footer, selected Linux assets,
+and checksums reach the intended destination. This observation is asynchronous;
+CI success or asset availability does not become a source-release completion
+gate or require the publication command to wait.
 
 The accepted ADR settles the architectural choice and standard workflow
 trade-offs. No significant feature decisions remain open. The next Audita