Plan ReleaseKit v0.9.0 implementation

docs/roadmap/releasekit-v0.9.0.md

@@ -2,7 +2,9 @@
 
 Status: R1 and R2 remediation is complete in separate commits. ReleaseKit v0.9.0
 adoption and the completion assertion repair remain planned; the root tool still
-selects v0.8.0. This document does not authorize source or hosted publication.
+selects v0.8.0. The [implementation plan](implementation.md) owns stage order,
+tasks, and validation tracking. This document owns the target and selected
+choices; it does not authorize source or hosted publication.
 
 ## Purpose and authority
 
@@ -20,7 +22,7 @@ and owning package tests until implementation updates them.
 
 ## Current baseline and review evidence
 
-Current CommandKit baseline: `4d92ee4ee6a8403b22a4172e0f04face802b9499`.
+Reviewed CommandKit code baseline: `4d92ee4ee6a8403b22a4172e0f04face802b9499`.
 The original upgrade review used `98e7e9933353cf43f2be4a96cb0436a0bce068d2`;
 its findings and validation history are retained below.
 
@@ -40,7 +42,7 @@ its findings and validation history are retained below.
   their acceptance evidence, including passing focused tests, shell syntax
   checks, and profile assertions running when no shell is available.
 - Both integrations still require older published CommandKit dependencies than
-  their current source needs. The completed [implementation record](implementation.md)
+  their current source needs. The completed [release-tooling implementation record](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/87eb84ccb462bf54e6250c8b287ac217efe90883/docs/roadmap/implementation.md#stage-5-verify-the-final-source-and-record-validation-boundaries)
   distinguishes workspace-backed tests from independent release readiness.
 
 The upstream v0.9.0 tag identifies commit
@@ -144,55 +146,17 @@ markers and acceptance evidence in [remediation.md](remediation.md). Preserve
 their selector rejection, legitimate raw helper forms, and optional-shell test
 boundary during adoption; no further implementation of those findings remains.
 
-The completion test's incidental ordering assumption remains unresolved and is
-separate from the completed remediation findings. Correct it in its own
-reviewable commit within the remaining maintenance work. Compare the
-expected alias source/target records without depending on their iteration
-order, while still detecting missing, unexpected, or duplicate records. Sorting
-test-owned copies is one straightforward approach. Preserve the other routing
-and visible-completion assertions. Do not restore production sorting or promise
-a new internal alias order merely to make this assertion pass.
+The completion assertion compares the expected alias source/target records
+without depending on their iteration order, while detecting missing, unexpected,
+or duplicate records. Its routing and visible-completion assertions remain.
+Production alias ordering and public contracts are unchanged. This correction
+remains part of the maintenance scope, separate from completed R1/R2 remediation;
+the implementation plan owns the test changes and focused verification.
 
-## Work needed
-
-- [x] Complete R1 in its own commit (`7eac3fe`), recording verification in
-  [remediation.md](remediation.md).
-- [x] Complete R2 in its own commit (`4d92ee4`), recording verification in
-  [remediation.md](remediation.md). R1/R2 scheduling is resolved by their delivery
-  before adoption.
-- [x] Review remaining release code against v0.9.0. Retain the helper, legacy
-  wrapper, profiles, and focused wiring tests for the reasons above.
-- [ ] Repair the completion assertion's ordering assumption and verify the
-  correction with focused repetitions. Preserve production ordering behavior
-  and the remaining routing assertions.
-- [ ] Select the root tool at v0.9.0, tidy module metadata, and inspect the
-  actual `go.mod`/`go.sum` diff. Investigate unexpected version changes rather
-  than accepting unrelated upgrades. Use normal cache preparation; direct
-  retrieval can diagnose proxy lag without becoming permanent configuration.
-- [ ] Update current owners: `docs/release.md`, the local selection in
-  `docs/policy/release.md`, `docs/consumers/guide.md`, and the root ReleaseKit
-  entry in `docs/oss/attribution.md`. Check affected source links and fragments
-  at the v0.9.0 commit. Update the earlier feature roadmap's pending-request
-  statement while retaining its historical evidence.
-- [ ] Validate the actual upgraded helper with inherited foreign target values,
-  and run the owning offline suites with Go 1.26.8. During development, use
-  focused repetitions to check the completion repair; do not treat rerunning
-  until green as a substitute for fixing it.
-- [ ] Exercise selected ReleaseKit checks on the final committed candidate
-  inputs using disposable source snapshots where appropriate. Reuse the
-  completed implementation record's one-time procedure for workspace-backed
-  integration diagnostics; do not add it to ordinary publication or claim it
-  proves independent published-dependency alignment.
-- [ ] Review whitespace, affected documentation links, and the final diff;
-  record what passed, what remains open, and the reviewed source revision.
-  Commit completed units under the local commit policy.
-
-No live token, model call, hosted write, or authoritative tag push is needed to
-verify this maintenance work. Do not read the credential file as part of the
-upgrade. Ordinary releases still use their single selected-module publication
-suite, with hosted delivery reported separately. Focused repetitions and
-disposable-copy diagnostics here are maintenance evidence, not permanent extra
-release gates.
+Ordinary releases retain their single selected-module publication suite and
+separate hosted-delivery outcome. One-time upgrade diagnostics are maintenance
+evidence, with no new recurring release gate. Credentials and live publication
+are unnecessary for this adoption.
 
 ## Completion evidence
 
@@ -208,15 +172,14 @@ corrected launcher behavior. Independent integration dependency alignment
 remains separate release-preparation work; this roadmap selects no future
 versions or sums.
 
-## Sequencing after remediation
+## Resolved choices
 
-The former OD-1 question about bundling R1/R2 with adoption is resolved: both
-findings were corrected and committed separately before the upgrade. They are
-neither open decisions nor remaining adoption tasks.
+R1 and R2 were corrected in separate commits before adoption, resolving the
+former OD-1 scheduling question. Their acceptance evidence remains in
+[remediation.md](remediation.md).
 
-For the remaining work, repair the completion assertion, then adopt v0.9.0 and
-align current documentation and attribution, keeping the test repair and tool
-adoption reviewable as separate commits. Validate the resulting source and
-record the actual evidence before marking adoption complete. A passing rerun
-alone does not resolve the known nondeterministic assertion. The older
-integration dependency-version mismatch remains outside this maintenance scope.
+The selected maintenance scope is the completion assertion repair, root tool
+upgrade, aligned current documentation and attribution, and validation of the
+resulting source. The older integration dependency-version mismatch remains
+separate release-preparation work. The implementation plan defines execution
+and commit sequencing.