Update ReleaseKit adoption plan after remediation

docs/roadmap/releasekit-v0.9.0.md

@@ -1,8 +1,8 @@
 # ReleaseKit v0.9.0 adoption
 
-Status: proposed maintenance roadmap; no implementation has started. Upgrade
-scope is defined below. The scheduling of existing local corrections remains
-open under OD-1. This document does not authorize source or hosted publication.
+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.
 
 ## Purpose and authority
 
@@ -20,7 +20,9 @@ and owning package tests until implementation updates them.
 
 ## Current baseline and review evidence
 
-CommandKit baseline: `98e7e9933353cf43f2be4a96cb0436a0bce068d2`.
+Current CommandKit baseline: `4d92ee4ee6a8403b22a4172e0f04face802b9499`.
+The original upgrade review used `98e7e9933353cf43f2be4a96cb0436a0bce068d2`;
+its findings and validation history are retained below.
 
 - The root [module](../../go.mod) selects
   `go.maximumdirect.net/releasekit v0.8.0` as a Go tool. Its selected version
@@ -32,8 +34,11 @@ CommandKit baseline: `98e7e9933353cf43f2be4a96cb0436a0bce068d2`.
 - All three profiles already select the agreed generic file checks, forbidden
   token path, and page-only Gitea destination. Source publication and hosted
   delivery are separate operations. The local token directory remains ignored.
-- [R1 and R2](remediation.md) remain open: legacy selector/raw-command collisions
-  and loss of optional POSIX-shell handling in launcher tests.
+- [R1 and R2](remediation.md) are complete. Commit `7eac3fe` rejects invalid
+  legacy selectors before invoking Go; commit `4d92ee4` restores explicit,
+  optional POSIX-shell invocation in launcher tests. The remediation record owns
+  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)
   distinguishes workspace-backed tests from independent release readiness.
@@ -57,6 +62,13 @@ A disposable CommandKit upgrade changed only the selected ReleaseKit version in
 workspace-backed integration suites passed, and the real helper reported v0.9.0
 under foreign target settings. No production publication or delivery was run.
 
+A later disposable review at `7eac3fe` confirmed that downloading and tidying
+v0.9.0 changed only the ReleaseKit requirement and its checksum entries. The
+offline root suite and both workspace-backed integration suites passed with
+Go 1.26.8, and the helper reported v0.9.0 under Windows/ARM64 target settings.
+That snapshot excluded the then-uncommitted R2 change; it does not replace
+validation of the eventual adoption commit.
+
 The initial upgrade run failed in
 [`TestCompletionCommandContext`](../../completion_context_test.go). The same
 alias-order failure reproduced four times in 30 focused repetitions on the
@@ -99,14 +111,16 @@ Integration attribution describes its own selected published dependency graph;
 update it only if that actual selection changes. No license-text replacement
 is needed for the unchanged upstream texts.
 
-### Local correctness work
+### Completed remediation and remaining correctness work
 
-R1 and R2 keep their scope and acceptance evidence in [remediation.md](remediation.md).
-The dependency upgrade does not close either finding. Subject to OD-1, address
-them in the same maintenance effort while retaining the simplified test boundary
-and the legitimate raw helper commands.
+R1 and R2 were delivered before the dependency upgrade, with their completion
+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.
 
-Also correct the completion test's incidental ordering assumption. Compare the
+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
@@ -115,8 +129,14 @@ a new internal alias order merely to make this assertion pass.
 
 ## Work needed
 
-- [ ] Record the chosen maintenance scope for OD-1. Keep the upgrade and each local
-  correction reviewable, whether delivered together or separately.
+- [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.
+- [ ] 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
@@ -126,9 +146,6 @@ a new internal alias order merely to make this assertion pass.
   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.
-- [ ] For bundled correctness work, implement R1 and R2 and the completion
-  assertion repair, with focused verification of the defects. Close existing
-  remediation findings only when their stated behavior has been verified.
 - [ ] 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
@@ -156,32 +173,22 @@ v0.9.0 for the host, aligned current documentation and attribution, and recorded
 validation of the final source. The reviewed upgrade introduced no other module
 version change; verify rather than assume that result during implementation.
 
-If local corrections are bundled, completion also includes R1/R2 acceptance
-evidence and a stable, order-independent completion assertion. If delivered
-separately, report those items as outstanding rather than implying that adoption
-resolved them. Independent integration dependency alignment remains separate
-release-preparation work; this roadmap selects no future versions or sums.
+R1/R2 acceptance evidence is complete in the remediation record. Completion of
+the remaining maintenance work also includes a stable, order-independent
+completion assertion and validation that the adopted helper retains the
+corrected launcher behavior. Independent integration dependency alignment
+remains separate release-preparation work; this roadmap selects no future
+versions or sums.
 
-## Open Decisions
+## Sequencing after remediation
 
-### OD-1: Bundle the existing local corrections with the upgrade?
+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.
 
-**Recommendation:** Deliver v0.9.0 adoption, R1, R2, and the completion assertion
-repair as one focused maintenance effort, using separate reviewable commits as
-appropriate. The existing issues are small, directly affect maintainer tooling
-or the default suite, and otherwise leave misleading validation after a passing
-upgrade run. Fixing the assertion without changing runtime ordering restores
-useful evidence while keeping the requested contracts intact.
-
-This is a scheduling recommendation, not a requirement that every dependency
-upgrade include unrelated repository repairs. It does not fold the older
-integration dependency-version mismatch into this scope.
-
-**Viable alternative:** Land the tool and current-documentation updates first,
-then deliver the three local corrections as separately tracked units. This
-keeps the dependency change especially easy to review or revert and makes the
-new recovery behavior available sooner. It leaves the known routing and test
-issues active, so a passing upgrade run cannot be reported as resolution of
-those issues or as proof of a consistently passing baseline. Keep their
-follow-up explicit and apply existing candidate-validation requirements before
-any actual source publication.
+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.